L’accessibilité, c’est un truc de dev ça !
C’est souvent ce qu’on entend quand on évoque l’accessibilité numérique pour la première fois avec des professionnels et des décideurs du web. Ce mauvais raccourci aux allures de réflexe pavlovien cache évidemment une méconnaissance de l’accessibilité voire pire, une déresponsabilisation face au sujet.
Dans les faits, cette prise de position découle du grand nombre de critères d’accessibilité traités et vérifiés pendant le développement. Mais ce serait mentir que de lier spécifiquement l’accessibilité au code. Par exemple, la vérification de la pertinence de chaque étiquette associée à un champ de formulaire n’implique la technique que par l’utilisation du bon élément HTML (<label>
Nous ne le répèterons jamais assez : l’accessibilité numérique est pluridisciplinaire !
Cependant, chaque métier a ses propres règles et leviers vis-à-vis de l’accessibilité. C’est par ce biais que nous allons traiter la thématique principale de cet article : La responsabilité des équipes de développement dans l’amélioration de l’accessibilité.
Pour répondre à cette problématique, nous allons donc nous concentrer sur les exigences minimales en matière de code auxquelles les professionnels du développement doivent répondre, peu importe leur degré de sensibilisation à l’accessibilité. Nous aborderons donc cela dans le cadre de bonnes pratiques génériques, applicables à tout type de contenu web.
Dans un souci d’inclusivité et de confort de lecture, le mot « dev » désignera les personnes responsables de l’intégration et du développement web.
Voici les 6 thématiques que nous aborderons dans cet article :
Vous avez déjà entendu parler de la divite aigüe ? C’est une maladie apparue au début des années 2000 et qui frappe encore beaucoup de dev, tous niveaux d’expérience confondus.
Les symptômes ? Une utilisation automatique et abusive de la balise<div> pour décrire n’importe quel contenu web.
Le problème ? <div> est un élément HTML neutre (comme <span>), autrement dit il ne donne pas la nature de ce qu’il contient et n’apporte aucune valeur ajoutée au contenu.
La divite aigüe c’est comme si vous décidiez d’appeler “truc” toutes les choses dont vous connaissez le nom. Par exemple : la phrase “Sur mon bureau, il y a mon ordinateur, mon cahier et la photo de Pierre Perrin” deviendrait “Sur mon truc, il y a mon truc, mon truc et la truc de Pierre Perrin“ ! Compliqué de se faire comprendre, n’est-ce pas ?
Fort heureusement la divite aigüe possède un remède efficace : la sémantique HTML !
Il existe une centaine de balises HTML, chacune possède un rôle précis et permet de décrire exactement ce qu’on manipule. C’est ce qu’on appelle la sémantique HTML.
Quand vous écrivez du code HTML, vous ne donnez pas que des instructions informatiques. Vous êtes en train de structurer un contenu pour lui donner du sens et de la pertinence. Comprendre le contenu et lui associer la bonne balise fait partie des exigences de qualité de code à adopter.
Vous utilisez déjà sûrement :
<p> pour les paragraphes<ol> pour les listes ordonnées<strong> pour mettre en évidence un mot ou un groupe de motsMais connaissez vous, par exemple :
<abbr> pour les abréviations ou les acronymes<address> pour les informations de contact d’une personne ou d’une organisation<dialog> pour les fenêtres modales<dl> pour les listes de définitions (ex : un glossaire)Il y a pratiquement une balise HTML pour tout et elles sont toutes utiles. De plus, certaines balises sont encore plus importantes, notamment pour renforcer l’accessibilité.
Les landmarks sont des régions de la page que l’on peut déclarer grâce à certains éléments HTML. Ces régions servent à organiser sémantiquement une page web et permettent aux utilisateurs de naviguer rapidement à travers le contenu. Parmi les landmarks, nous trouvons :
<header><footer><nav><main><article><aside><section>En utilisant correctement les landmarks vous fournissez une cartographie de la page web et des accès rapides à chacune de ses zones clés. Les personnes utilisant des technologies d’assistance vous en seront très reconnaissantes !
Suggestion d’extension pour afficher les landmarks sur Chrome et Firefox
Quand on lit un livre ou bien quand on consulte un document numérique, il est fort appréciable de trouver un sommaire (ou table des matières) qui nous donne un plan clair et surtout un fléchage du contenu.
Imaginons que l’on puisse proposer une telle fonctionnalité dans le cadre d’un site web : avoir un sommaire virtuel au début de chaque page pour que des personnes puissent avoir un aperçu du contenu et naviguer vers les parties qui les intéressent. Utile, n’est-ce pas ?
Et si ce n’était pas de l’ordre de l’imaginaire et que vous aviez la possibilité de générer cette table des matières ? Cela est possible grâce aux balises de titres <title><h1><h6>
La balise <title>
C’est son texte qui est affiché dans l’onglet du navigateur correspondant à la page.
C’est donc le premier contact que les utilisateurs ont avec le site, la balise <title> doit être optimisée avec suffisamment d’information pour avoir un aperçu rapide du contenu. Elle doit idéalement contenir :
<title>Titre de l'article | Thématique | Blog Frontguys</title>
Cette combinaison donnera un titre unique à chacune des pages et permettra aux utilisateurs d’identifier et contextualiser le contenu et le site sans même l’avoir consulté. Cela évite également de se retrouver avec des noms d’onglets identiques quand plusieurs pages du même site sont ouvertes en même temps.
Concernant le contenu de la page, vous allez devoir utiliser les balises de titre <h1> à <h6>. Les règles de la sémantique HTML s’appliquent ici également : il est important d’utiliser ces balises uniquement pour les titres (logique !) et pas pour styler des choses qui ressembleraient à des titres (ex : des paragraphes en gras).
Les règles principales à respecter pour les titres et sous-titres :
<h1> correspondant au titre de la section principale du contenu de la page (c’est généralement ce même titre qui est utilisé dans le <title>). Bien qu’il soit techniquement possible d’avoir plusieurs <h1> dans une page, ce n’est pas recommandé.<h2> à <h4>).Suggestion d’extension pour afficher le plan de la page sur Chrome et Firefox
Comme expliqué précédemment, les landmarks sont très importants pour l’accessibilité et la cartographie de la page. Cependant, les landmarks ne possèdent pas forcément tous des titres explicites et le fait d’avoir plusieurs balises <header> ou <nav> peut demander un effort supplémentaire aux personnes utilisant des lecteurs d’écran pour connaître le contenu de la section en question.
Il est possible de titrer les landmarks grâce à l’attribut aria-labelledby qui contiendra l’identifiant HTML du titre associé.
<header> <nav aria-labelledby="main-menu-title"> <h2 id="main-menu-title" class="visually-hidden">Menu principal</h2> <!-- Items de navigation --> </nav> </header> <footer> <nav aria-labelledby="footer-menu-title"> <h2 id="footer-menu-title" class="visually-hidden">Menu pied de page</h2> <!-- Items de navigation --> </nav> </footer>
Si ces titres ne sont pas censés apparaître dans l’interface graphique, il est toujours possible de les masquer tout en les rendant lisibles par les outils d’assistance.
L’absence ou le manque de pertinence des alternatives textuelles pour les éléments graphiques est l’un des points les plus bloquants pour l’accessibilité.
En tant que dev, vous êtes la plupart du temps responsables de l’intégration des images, des pictos, des graphiques de données, etc. Il va donc de soi que vous êtes en charge de la qualité des alternatives textuelles que vous devez fournir !
Cet exercice n’est pas aussi simple que l’on peut le croire car il vous faudra analyser en détail le contexte d’utilisation des éléments graphiques concernés. Une alternative vide ? Un texte à restituer ? Une information à compléter ? Une action à expliquer ? Autant de questions à se poser que de contextes.
Fort heureusement, vous pouvez vous appuyer sur notre guide : Comment choisir la bonne alternative textuelle !
Les intitulés des liens et des boutons présentent également un enjeu majeur dans l’optimisation de l’accessibilité. Evidemment, quand le travail est fait en phase d’UX Design, il y a peu d’effort à fournir côté développement. Cependant, il arrive que la responsabilité bascule vers le côté technique, exigeant la mise en place de règles d’accessibilité.
Quand vous avez un bouton contenant seulement un picto “oeil” à côté d’un champ mot de passe, vous n’avez pas forcément le texte “afficher le mot de passe” qui est affiché.
On estime que ce picto est suffisamment connu des utilisateurs pour qu’ils comprennent la fonction du bouton sans texte supplémentaire. Oui, mais de quels utilisateurs s’agit-il ? Comment font les personnes avec une assistance vocale pour savoir ce que fait ce bouton sans intitulé qui contient uniquement cet élément svg ou bien ce caractère bizarre issu d’une police d’icônes ?
Techniquement, cela donne ce genre de code :
<!-- Bouton avec une icône svg --> <button type="button"> <svg viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg"> <!-- ... --> </svg> </button> <!-- Bouton avec une icône "police de caractères" --> <button type="button"> <i class="eye-icon"></i> </button>
Pour corriger ce problème, le mieux est d’ajouter du texte à l’intérieur du bouton ou du lien et de le rendre lisible uniquement par les lecteurs d’écran :
<button type="button"> <span class="visually-hidden">Afficher le mot de passe</span> <!-- Votre picto ici --> </button>
Point de vigilance : Il peut être tentant de considérer une infobulle (ou tooltip) affichée au survol comme étant un intitulé de bouton ou de lien. Cela reste à vérifier car le texte en question se trouve souvent en dehors de l’élément HTML visé.
Maintenant que vos boutons et vos liens ont des intitulés, attardons nous sur leur pertinence.
“Lire la suite”, “Voir plus”, “Cliquez ici”, “OK”… Il vous est certainement arrivé de voir ce type d’intitulés pour des liens ou des boutons. Il vous est également arrivé de croiser plusieurs fois le même intitulé rattaché à des URL ou des actions pourtant différentes.
Le problème de ces intitulés est qu’ils ne permettent pas aux utilisateurs de savoir ce qu’il y a derrière. Certaines personnes naviguent de lien en lien, elles ont donc besoin de comprendre leur intitulé hors contexte. Il faut donc fournir des intitulés explicites !
Evidemment, la meilleure solution est de remonter ces problèmes aux personnes en charge des textes et de demander les modifications nécessaires.
Toutefois dans le cas contraire, vous avez la possibilité d’agir en tant que dev sur ces éléments aux intitulés problématiques. La solution consiste encore une fois à enrichir les intitulés avec du texte masqué de manière accessible :
<a href="#"> Lire la suite <span class="visually-hidden">- Comment faire des liens accessibles ?</span> </a> <button type="submit"> OK <span class="visually-hidden">- Valider l'envoi du formulaire</span> </button>
Nous aurions pu envisager de mettre un attribut title ou aria-label pour apporter ces informations supplémentaires mais cela reste des rustines, il vaut mieux toujours privilégier la solution HTML la plus naturelle.
L’accessibilité des formulaires mériterait plusieurs articles en soi tant la thématique est riche et complexe. Ici, nous n’aborderons que 2 points importants : les étiquettes de formulaires et le bon usage des champs.
Les étiquettes (ou libellés) servent à donner des instructions sur ce que les utilisateurs doivent saisir dans chaque champ.
En tant que dev, votre responsabilité est de créer ces étiquettes et de les associer correctement aux champs de formulaires. Cela passe par l’utilisation de la balise <label> et de l’attribut for.
<label for="email-control"> Votre adresse e-mail : </label> <input type="email" id="email-control" name="email" />
Pour une accessibilité optimale, chaque champ doit avoir une étiquette associée. Un champ sans étiquette c’est comme une boîte aux lettres sans nom, on ne sait pas quoi faire avec !
Point de vigilance : L’attribut placeholder ne remplace pas la balise label. Bien qu’étant utile pour apporter une précision, il peut poser des problèmes cognitifs du fait de sa disparition à la saisie.
Les éléments de contrôle de formulaire tels que input, select ou textarea sont accessibles de base dans les navigateurs. Les utilisateurs et les technologies d’assistance savent très bien comment interagir avec, il est alors essentiel de les utiliser sans les dénaturer pour des besoins graphiques.
Il peut par exemple être tentant d’utiliser autre chose qu’une checkbox pour créer un bouton “switch”. Graphiquement, ça fera l’affaire mais vous rendrez inaccessible quelque chose qui l’était par nature.
Pour chaque élément de contrôle que vous créez, vérifiez si un élément natif ne répond pas déjà au besoin. Dans le cas contraire, vous risquez de faire moins bien que ce qui existe en introduisant des obstacles aux utilisateurs. Il est évidemment possible de créer ses propres contrôles de formulaire sans se baser sur les éléments natifs, mais cela demande plus d’efforts, de vigilance et de tests pour les rendre accessibles.
Il vous est déjà arrivé d’avoir une souris inutilisable (batterie, panne, …) et d’utiliser le clavier pour naviguer dans une page web ? Et bien, vous avez été dans une situation de handicap temporaire et vous avez utilisé une aide technique pour arriver à vos objectifs.
Certaines personnes utilisent le clavier ou d’autres outils d’assistance en permanence. Cela implique qu’il faut leur garantir un accès et une interopérabilité équivalente à une personne utilisant une souris par exemple.
Tous les contenus du site doivent pouvoir être consultables peu importe le mode de navigationEnsemble de liens et de boutons qui aident les utilisateurs à se déplacer et à trouver des informations dans une interface. More. Cela veut dire que la lisibilité, l’affichage et l’utilisation des contenus ne doit pas être restreinte à la souris par exemple. Il faut donc s’assurer de certaines choses :
Pour s’assurer de tout cela, il n’y a pas de secret, il faut a minima tester le site au clavier avec la tabulation et si possible avec un outil de synthèse vocale.
Lors de la première consultation d’une page web, vous la parcourez systématiquement dans un ordre précis. Cela peut être, par exemple, de haut en bas selon le sens de lecture. Les éléments sont étudiés et positionnés spécifiquement pour respecter cette façon de consulter.
La navigationEnsemble de liens et de boutons qui aident les utilisateurs à se déplacer et à trouver des informations dans une interface. More au clavier ou avec tout autre outil d’assistance doit être faite dans un ordre prévisible, aussi proche que possible de l’ordre de lecture. Cependant, il est possible que les éléments n’apparaissent pas dans le même ordre visuel que dans le code. C’est souvent le cas pour adapter une mise en page suivant différentes tailles d’écran.
La navigationEnsemble de liens et de boutons qui aident les utilisateurs à se déplacer et à trouver des informations dans une interface. More à la tabulation suit l’ordre du code et pas la mise en page CSS. Vous devez donc veiller à ne pas complexifier l’ordre des éléments dans le code et plutôt vous appuyer sur des techniques de mises en page avec flexbox ou grid par exemple.
Suggestion d’extension pour afficher l’ordre de navigationEnsemble de liens et de boutons qui aident les utilisateurs à se déplacer et à trouver des informations dans une interface. More au clavier sur Chrome et Firefox
Les éléments HTML d’interaction peuvent recevoir le focus naturellement : <a>, <button>, <input>, <select>, <textarea>, … Les utilisateurs peuvent y accéder grâce à la tabulation ou aux commandes mises à leur disposition.
Comme mentionné précédemment dans cet article, il est essentiel d’utiliser des balises sémantiques sans altérer leurs comportements natifs. Cependant, des éléments d’interface utilisateur personnalisés et complexes nécessitent également d’être rendus focusables pour assurer leur interopérabilité. Pour cela il existe des solutions telles que :
tabindex qui permet à un élément de recevoir le focus de manière programmatiquerole qui permet de donner un rôle sémantique à un élément (encore une fois, attention la mauvaise utilisation d’ARIA)Point de vigilance : Par défaut, les navigateurs ajoutent un contour sur l’élément ayant le focus. Ceci est une indication visuelle importante pour suivre la navigationEnsemble de liens et de boutons qui aident les utilisateurs à se déplacer et à trouver des informations dans une interface. More. Vous avez la possibilité de modifier graphiquement cet état focus mais vous devez veiller à ne pas le supprimer avec des styles !
Le but de cet article n’est pas forcément d’être exhaustif par rapport à l’ensemble des critères d’accessibilité liés au code. Les leviers mentionnés ici peuvent être actionnés en autonomie par une équipe de développement et auront un grand impact sur l’accessibilité du produit développé.
Que vous soyez dans une optique de mise en conformité de l’accessibilité ou simplement dans un désir de produire du code de qualité, prenez vos responsabilités et agissez !
