L’accessibilité c’est comme la pâtisserie, il faut savoir doser !

Quand j’ai débuté dans l’accessibilité numérique, je voulais être sûre que le contenu présenté était lisible par tout le monde.
Comme toute personne apprenant un nouveau domaine, j’étais maladroite dans ma façon de faire. Au lieu de rendre simplement l’information, je la rendais trop verbeuse, trop complexe, en la doublant ou en utilisant des attributs non nécessaires. D’où mon analogie avec la pâtisserie, car, comme vous le savez, trop ou pas assez d’un ingrédient et votre gâteau devient immangeable.

Donnée redondante

Avec des liens

Je commence par une erreur que je faisais quand j’ai travaillé sur mon premier projet d’accessibilité : doubler l’information d’un lien avec l’attribut title. Double combo gagnant : je précisais aussi dans le title qu’il s’agissait d’un lien, on ne sait jamais.

Imaginez-vous dans un site avec un méga menu de six catégories avec dix à vingt liens sous chacune d’entre-elles. C’est utile sur n’importe quel site ayant beaucoup de contenus à proposer et ce n’est pas un problème en soi. Mais dans mon cas, tous les liens étaient construits comme ceci :

<a href="monlien.html" title="Lien vers top 10 des choses à faire en accessibilité">Top 10 des choses à faire en accessibilité</a>

La restitution (sur NVDA) donne le résultat suivant : « Top 10 des choses à faire en accessibilité lien, lien vers top 10 des choses à faire en accessibilité ».

Et voilà tout le problème, c’est inutile et très pénible pour les personnes utilisant un lecteur d’écran. Comme le fait de mettre trop de beurre ou trop de crème dans sa recette, c’est lourd.

En simplifiant comme ceci :

<a href="monlien.html">Top 10 des choses à faire en accessibilité</a>

NVDA va lire « Top 10 des choses à faire en accessibilité lien ». Cela remis dans le contexte de notre méga menu, c’est un peu plus digeste.

Avec des images

C’est la même chose pour les images ; lorsque vous remplissez l’attribut alt (uniquement pour les images porteuses d’information, attention) il est inutile de repréciser qu’il s’agit d’une image, le lecteur d’écran le sait et l’indique.
Voici un exemple à ne pas reproduire chez vous :

<img src="tournoi.jpg" alt="image de la 2ème édition du tournoi des sorciers du 3 au 7 octobre 2023" />

Et voici un bon exemple :

<img src="tournoi.jpg" alt="2ème édition du tournoi des sorciers du 3 au 7 octobre 2023" />

Exceptions

Il y a quelques contextes dans lesquels on peut préciser la nature d’une image, par exemple dans le monde artistique : « Photographie en noir et blanc de la tour Eiffel », « Portrait de Frida Kahlo portant une robe marron avec une couronne de fleur sur la tête ». Ici, la précision enrichit le sens de l’image, c’est un peu comme une pincée de sel dans votre préparation pour en rehausser le goût.

Aria

Qu’est-ce que ceci ? Ce sont des attributs et des rôles HTML qui permettent d’ajouter du sens, de la sémantique aux différents composants que l’on code. Par exemple, ARIA va permettre de savoir si un menu est ouvert ou fermé, si un onglet est sélectionné, etc. Voici une excellente définition donnée par Mozilla.

Rappel de la première règle d’ARIA : ne pas s’en servir.
Il est très facile de faire n’importe quoi avec ARIA. Même si on pense bien faire, le mieux est souvent de s’en passer.

Utilisation des mauvais rôles

Une erreur que je rencontre assez régulièrement est l’utilisation des rôles menu et menuitem.
C’est vrai que le nom comme ça donne envie de s’en servir, pour l’appliquer sur un menu principal par exemple. Eh bien n’en faites rien !
Ces rôles sont réservés exclusivement à des menus applicatifs. Si vous recodez un logiciel Word en ligne, ce sera tout à fait indiqué mais pour n’importe quel site web, utilisez simplement <nav><ul><li></li></ul></nav>, cela suffira amplement.
C’est un peu comme le sucre, vous pouvez en enlever un peu, ça restera mangeable pour tout le monde et ce sera meilleur pour quelqu’un qui doit faire attention.

Un exemple d’utilisation pertinente de ces rôles est disponible sur le site d’ARIA Authoring Practices Guide (en anglais).

Redondances ou surinformation inutile

La balise button a nativement un rôle de bouton. Il est inutile de repréciser celui-ci. Pareil pour les liens, listes, titres et bien d’autres.

Voici un exemple de code à éviter :

<button type="button" role="button">Mon bouton</button>
<a href="monlien.html" role="link">Mon lien</a>
<ul role="list"><li role="listitem">Mon item de liste</li></ul>
    

Préférer le code suivant :


<button type="button">Mon bouton</button>
<a href="monlien.html">Mon lien</a>
<ul><li>Mon item de liste</li></ul>

Exceptions

Parce que le monde de l’accessibilité et des technologies d’assistance est plein de surprises, dans certaines versions de VoiceOver (le lecteur d’écran par défaut sur macOS et iOS) avec le navigateur Safari, les images au format SVG ne sont pas détectées mais considérées comme un groupe (et restituées avec le rôle groupe au lieu d’image). Dans des versions plus anciennes, l’attribut alt n’est pas du tout restitué. Pour pallier à ce comportement, il faut ajouter la redondance suivante :

<img src="logo.svg" alt="24 jours de web" role="img" />

Cette technique est à appliquer uniquement sur les images SVG ayant besoin d’un attribut alt renseigné.

Une autre exception, sur les listes. Pour des raisons de design, on peut vouloir utiliser une liste sans en afficher les puces. Dans ce cas, vous allez appliquer le style list-style:none;. En faisant ainsi, la liste perd sa valeur sémantique et n’est pas correctement restituée dans certaines versions de VoiceOver, toujours avec Safari. Deux solutions s’offrent à vous : mettre un rôle list sur la balise <ul> ou mettre des puces transparentes avec un PNG via CSS. Personnellement, j’applique la deuxième méthode car je préfère gérer cela en CSS que de contourner ce problème avec ARIA. C’est une question de goût, libre à vous d’appliquer la technique que vous préférez.

tabindex

J’ai aussi fait cette erreur au début : mettre des valeurs positives à l’attribut tabindex pour m’assurer que l’ordre de navigation serait cohérent.

On ne met jamais de valeur positive à un tabindex. Ce serait un peu comme mettre d’abord les œufs puis la farine puis le beurre et enfin la levure au lieu de mettre œuf, beurre, mélanger puis farine, levure, cela donnerait n’importe quoi. Si votre code est structuré de manière logique, il n’y en a pas besoin. Les deux seules valeurs à utiliser sur l’attribut tabindex sont 0 et -1.
tabindex="0" permet de rendre focusable un élément qui ne le serait pas nativement (une <div> par exemple). Le focus sera intégré dans l’ordre logique de navigation (de haut en bas et de gauche à droite dans notre partie du monde).
tabindex="-1" permet de donner le focus à un élément via programmation. Par exemple :

<div id="message" tabindex="-1">
    <p>Mon message</p>
</div>
<button type="submit" id="submitBtn">Envoyer mon commentaire</button>

En JavaScript nous allons pouvoir positionner le focus sur cette div comme ceci :

<script>
    document.getElementById('submitBtn').addEventListener('click', () => {
        document.getElementById('message').focus();
    })
</script>

Déséquilibre de contenu selon le public

Il est clair que le déséquilibre est, pour la majorité du temps, au préjudice des personnes handicapées.
Et, pourtant, un autre piège dans lequel je tombe encore parfois, c’est de donner plus d’informations aux personnes utilisant un lecteur d’écran qu’aux personnes n’en ayant pas besoin.
L’information ou le manque d’information doit être égal pour tous les publics. Si une information est présente, elle doit être visible par tout le monde.

Prenons une image affichant un numéro surtaxé :

0811 123 456 (service 0.05€ / min + prix de l’appel)

<img src="numero-surtaxe.png" alt="0811 123 456 (service 0.05€ / min + prix de l’appel)">

Ici, une personne utilisant un lecteur d’écran saura que le numéro est surtaxé ainsi que son coût.
Dans le RGAA et les WCAG (en anglais), il s’agit d’une non-conformité.

Une bonne implémentation serait de mettre l’image avec l’ensemble des informations tarifaires :
0811 123 456 (service 0.05€ / min + prix de l’appel)


<img src="numero-surtaxe-ok.png" alt="0811 123 456 (service 0.05€ / min + prix de l’appel)">
    

L’image contient les informations relatives au coût de l’appel. Tout le monde y a accès.

Exception

Vous me voyez venir, encore une exception ! Si vous concevez un composant complexe en JavaScript qui sort un peu des sentiers battus, disons un système de glisser-déposer ; il peut être utile de préciser à une personne se servant d’un lecteur d’écran comment interagir avec. Dans ce cas, une description uniquement accessible via un lecteur d’écran est tout à fait indiquée.
Par exemple : « Utilisez la barre d’espace pour sélectionner un élément puis les flèches directionnelles haut/bas pour le déplacer. Enfin, appuyez sur espace pour déposer l’élément. »

Conclusion

Vous l’aurez constaté : il faut aller à l’essentiel ! Tout est une question de dosage la plupart du temps. Il y a certes des exceptions dues à des bugs de lecteurs d’écran mais ce sont des cas à la marge.

Aujourd’hui encore, j’ai tendance à vouloir ajouter plus de détails à restituer par un lecteur d’écran. Mais maintenant que j’en ai conscience, je suis plus attentive et je prends du recul.
L’important est de ne pas parasiter la restitution avec des informations inutiles ou redondantes.
En dehors de la conception accessible de base qui permet aux personnes handicapées d’avoir le même accès au contenu que n’importe qui, l’ajout d’indications doit se faire dans des cas spécifiques : pour aider à la navigation dans un composant d’interface complexe ou pour palier à des problèmes de support de technologie d’assistance.

Puisque vous êtes encore là, je vous donne une recette que j’affectionne tout particulièrement qui marche avec pas mal de fruits selon la saison :

Pour 6 personnes :

  • 160 grammes de farine
  • 150 grammes de sucre (vous pouvez en mettre moins)
  • 130 grammes de beurre
  • 1 sachet de levure chimique
  • 3 œufs
  • 3 poires

Préchauffez le four à 180° et pendant ce temps, coupez les poires en petits morceaux, ensuite, mélangez le sucre et les œufs puis ajoutez la farine et la levure. Faites fondre le beurre puis mélangez-le à la préparation. Enfin, ajoutez les morceaux de poires et mélangez le tout.
À votre goût, vous pouvez ajouter une pincée de sel, un petit peu de rhum pour avoir un petit parfum intéressant.

Versez dans un plat à gâteaux et laissez cuire pendant 40 minutes à 180°.

L’accessibilité, c’est bon, mangez-en !

Merci à l’équipe de relecture ainsi qu’à Romain Gervois pour ses retours toujours riches !

8 commentaires sur cet article

  1. Zougane, le jeudi 22 décembre 2022 à 09:20

    Bonjour Lena, merci pour tes 2 recettes qui sont facile d’accès.

  2. Romy, le jeudi 22 décembre 2022 à 12:27

    Ah c’est drôle, je file aussi la métaphore de l’accessibilité avec la pâtisserie, mais pour autre aspect : pour souligner la nécessité d’anticiper, parce qu’il est trop tard, après cuisson/fabrication, pour se préoccuper d’être comestible/accessible : http://romy.tetue.net/accessibilite-et-patisserie ;)

  3. PinGoo, le jeudi 22 décembre 2022 à 14:14

    Article très intéressant et sympa à lire. Merci.

  4. Lena Chandelier, le jeudi 22 décembre 2022 à 17:46

    Merci pour vos retours !
    @Romy Excellent ! Comme quoi, cette analogie tient la route. J’aime beaucoup la partie où tu parles de ne pas attendre que le gâteau sorte du four pour en retirer les allergènes :)

  5. Anne-Sophie, le samedi 24 décembre 2022 à 08:52

    Merci pour cet article ! Je ne suis pas front mais j’y ai appris des choses et il est très agréable à lire .

    @Lena et @Romy : vos articles pourraient être sur cet annuaire d’articles qui font analogie entre nourriture et accessibilité : https://www.lflegal.com/2020/05/accessibility-is-delicious/

  6. Gaëtan, le mercredi 28 décembre 2022 à 07:34

    Bonjour, dans ton exemple de la fonctionnalité « glisser déposer « , je me disais que l’information des raccourcis clavier puissent être visible pour tout public (pas seulement aux personnes utilisant un lecteur d’écran), qu’en penses-tu ?

  7. Lena Chandelier, le mercredi 4 janvier 2023 à 08:18

    @Anne-Sophie, merci pour le lien !

    @Gaëtan, oui c’est toujours utile. L’exemple ici est pour appuyer sur le fait que cette information est indispensable pour qu’une personne n’utilisant que la navigation clavier puisse se servir de la fonctionnalité. Pour les autres, ce sera plus du confort, une option supplémentaire mais rien d’indispensable.

  8. Romy, le jeudi 5 janvier 2023 à 19:56

    @Anne-Sophie : elle est extraordinaire, cette compilation d’analogies, j’adore, merci !