10 conseils pour développer des éléments accessibles au clavier

1. Rendre atteignable et activable au clavier tout élément interactif

Un problème bloquant en accessibilité survient lorsque des éléments ne sont pas accessibles au clavier. Ces obstacles peuvent empêcher les utilisateurs d'accéder à des fonctionnalités et des informations importantes du site.

Cette balise <span> utilisée comme un bouton fonctionne à la souris mais ne peut pas fonctionner au clavier en l'état :

<span onclick="alert('Action!');">Action</span>

Il est donc essentiel que tous les éléments interactifs, tels que les liens, boutons et champs de formulaire, puissent être atteints et activés au clavier. Cela permet aux utilisateurs de technologies d'assistance de naviguer et d'interagir avec le site web.

Un lien HTML accessible :

<a href="#">Lien</a>

Un bouton HTML accessible :

<button type="button">Bouton HTML</button>

Un lien ARIA accessible :

<div role="link" tabindex="0">Lien ARIA</div>

Un bouton ARIA accessible :

<div role="button" tabindex="0">Bouton ARIA</div>

Un autre bouton ARIA accessible :

<a role="button" tabindex="0">Bouton ARIA</a>

Note : l'attribution d'un rôle ARIA à un élément, comme role="button" ou role="link", ne suffit pas pour rendre ces éléments pleinement fonctionnels comme leurs homologues HTML natifs. Pour que ces éléments personnalisés soient utilisables avec le clavier, il est nécessaire d'implémenter une gestion appropriée des événements clavier via JavaScript. Par exemple, pour un bouton ARIA, vous devez ajouter un gestionnaire d'événements pour réagir à l'activation des touches Entrée et Espace. Les rôles HTML natifs sont recommandés pendant le développement initial pour leur comportement intégré, mais les attributs ARIA sont précieux pour ajuster l'accessibilité après les audits, sans affecter la présentation CSS existante.

2. S'assurer de la visibilité du focus

La visibilité du focus est indispensable pour l'accessibilité des liens, des boutons et des éléments de formulaire. Elle permet aux utilisateurs naviguant au clavier de visualiser l'emplacement du focus sur la page. Un élément focusable qui n'est pas clairement visible peut semer la confusion et entraver l'interaction efficace avec le site.

Il est donc impératif de rendre chaque élément recevant le focus parfaitement visible pour tous les utilisateurs :

• Soit avec l’outline natif du navigateur
• Soit avec l'ajout d'un style CSS personnalisé, une bordure par exemple, avec un contraste d’au moins 3:1 par rapport aux couleurs adjacentes

:focus {
    outline: 2px solid #000; /* A la prise de focus, bordure noire de 2px */
}

Note :assurez-vous de tester les styles de focus dans divers contextes de conception pour garantir qu'ils sont toujours visibles. Par exemple, un outline noir peut ne pas être visible sur un fond très sombre, nécessitant l'utilisation de couleurs de contraste plus élevé ou de techniques alternatives.

3. Utiliser un ordre de tabulation cohérent

Un ordre de tabulation désordonné peut désorienter les utilisateurs du clavier, en particulier ceux qui dépendent des technologies d'assistance pour naviguer. Cela peut rendre difficile l'accès à des informations importantes ou à des fonctionnalités du site.

Par exemple, un attribut tabindex avec des valeurs supérieures à "0", peut perturber l'ordre naturel et intuitif du focus s'il n'est pas maîtrisé.

Assurez-vous que l'ordre de tabulation (la séquence dans laquelle les éléments reçoivent le focus lors de l'utilisation de la touche Tab) est logique. Un ordre de tabulation bien structuré permet aux utilisateurs de naviguer de manière prédictible et cohérente à travers la page, améliorant ainsi l'accessibilité et l'expérience utilisateur globale.

Toutefois, il ne faudrait pas invalider abusivement ce critère. En effet, dans certains cas, l'ordre de tabulation n'a pas besoin de suivre strictement l'ordre visuel. Par exemple, trois liens de réseaux sociaux situés dans un footer peuvent être parcourus dans un ordre non linéaire, comme de droite à gauche, sans compromettre l'accessibilité. Cependant, il est important que cet ordre soit cohérent et prévisible pour les utilisateurs, afin de ne pas créer de confusion.

4. Éviter les pièges au clavier

Un piège au clavier se produit lorsqu'un utilisateur ne peut pas naviguer hors d'un élément interactif en utilisant seulement le clavier. Aucune touche ne lui permet de quitter cet élément. Il se trouve ainsi littéralement piégé, coincé sur cet élément interactif. Bien que ce problème soit rare, sa présence constitue un véritable blocage pour l'utilisateur qui dépend du clavier.

Les pièges de focus peuvent donc créer une expérience utilisateur frustrante et limitante. Cela peut empêcher les utilisateurs de compléter des tâches essentielles ou d'accéder à des informations importantes.

Veillez à ce qu'il n'y ait pas de pièges de focus où l'utilisateur peut entrer mais ne peut pas sortir en utilisant uniquement le clavier. Tous les éléments focusables doivent être atteignables et quittables avec le clavier.

5. Donner un rôle à chaque élément focusable

Sans rôles clairement définis, les utilisateurs de lecteurs d'écran et autres technologies d'assistance peuvent avoir du mal à comprendre l'action attendue ou la réponse d'un élément interactif. Cela peut entraîner une confusion et rendre la navigation plus difficile.

Chaque élément interactif, comme les liens, les boutons ou les champs de formulaire, doit être identifiable par son rôle. Ceci aide les utilisateurs de technologies d'assistance à comprendre la fonction de chaque élément.

• Un élément <a href="..."> est naturellement interprété comme un lien, ce qui signifie qu'il communique sa fonction de navigation entre les pages ou vers des sections spécifiques d'une page.
• Un élément <button type="button"> a un rôle natif de bouton, indiquant qu'il est destiné à déclencher une action après son activation.
• En revanche, un élément <div> ne possède pas de rôle natif interactif, mais ce rôle peut lui être attribué avec ARIA, par exemple le rôle d'un bouton (<div role="button">). Une fois attribué, il prend la même valeur fonctionnelle qu'un rôle natif, rendant l'élément interprétable par les technologies d'assistance comme s'il s'agissait d'un bouton.

Note : voir le point 1 pour un exemple de <div role="button"> opérationnel, ici il est seulement question du rôle des éléments, il est nécessaire d'utiliser JavaScript pour le rendre utilisable.

6. Nommer chaque élément focusable

Un lien sans intitulé ou un lien mal nommé, un bouton sans intitulé ou mal nommé, un champ de formulaire sans étiquette ou un champ avec une étiquette peu pertinente posent un véritable problème d'accessibilité à certains utilisateurs. En effet, si le nom des éléments interactifs n'est pas explicite, il est difficile de naviguer.

Il est impératif que chaque élément interactif sur une page web, tel qu'un lien, un bouton, ou un champ de formulaire, soit explicitement nommé. Cela assure que les utilisateurs, notamment ceux utilisant des technologies d'assistance, soient correctement informés sur la destination ou la fonction de chaque élément.

Chaque lien doit contenir un intitulé entre les balises <a > et </a> dans le code source HTML. Ce nom peut être visible pour tous, visuellement masqué avec une classe de type sr-only ou intégrer une valeur d'attribut alt pour un lien-image par exemple.

Les liens peuvent aussi bénéficier de leur contexte pour être considérés comme explicites. Par exemple, un lien "En savoir plus" répété plusieurs fois sur une page peut être considéré comme explicite si un titre de hiérarchie le précède et lui donne du sens. D'autres éléments sont tolérés pour donner un contexte au lien.

<h2>Titre</h2>
<p>Lorem ipsum</p>
<a href="details.html">En savoir plus</a>

En revanche, un bouton doit être explicite par lui-même et ne peut pas bénéficier de son contexte pour clarifier sa fonction. Un bouton de type "En savoir plus" ouvrant une modale par exemple, ne peut donc pas bénéficier de son contexte. Il faut donc compléter l'intitulé visible du bouton par le code, par exemple avec un attribut title="xxx : en savoir plus" où xxx est la valeur du titre le précédant par exemple. D'autres techniques d'explicitation du nommage existent, comme l'attribut aria-decribedby par exemple, et feront l'objet d'articles spécifiques.

<h2>Titre</h2>
<p>Lorem ipsum</p>
<button type="button" title="Titre : en savoir plus">En savoir plus</button>

Il est obligatoire que chaque champ de formulaire soit accompagné d'une étiquette visible, accollée et clairement associée. Ces étiquettes doivent être liées par le code aux champs correspondants, ce qui permet aux technologies d'assistance de comprendre la relation entre l'étiquette et le champ.

<label for="nom">Nom :</label>
<input type="text" id="nom" name="nom">

Note : d'autres techniques permettent de fournir une étiquette visible à un champ

7. Informer l'utilisateur sur l'état de l'élément

Si l'état d'un élément n'est pas indiqué, il devient compliqué pour les utilisateurs d'assistance technologique de comprendre l'interface.

Il est important que chaque élément interactif communique clairement son état aux utilisateurs, notamment à ceux qui utilisent des technologies d'assistance. Cela peut inclure des indications sur leur état d'expansion, de sélection ou d'activation.

L'état d'un élément peut être communiqué par des moyens variés, tels que l'usage d'attributs ARIA, de textes visuellement masqués ou de l'attribut title. Voici comment vous pouvez utiliser les attributs ARIA pour informer clairement les utilisateurs des différents états des éléments :

Pour informer les utilisateurs sur l'état masqué ou affiché d'un dépliant (Disclosure), utilisez l'attribut aria-expanded="false" :

<button aria-expanded="false>Voir plus</button>
<div id="section" style="display: none;">Contenu détaillé...</div>

Passez sa valeur à "true" quand il est affiché :

<button aria-expanded="true>Voir plus</button>
<div id="section" style="display: block;">Contenu détaillé...</div>

Pour un bouton à bascule qui peut être activé ou désactivé, utilisez aria-pressed pour montrer l'état du bouton. Ici, le bouton est activé :

<button aria-pressed="true">J'aime</button>

8. Maîtriser les changements de contexte inattendus

Un changement de contexte est perturbant pour de nombreux utilisateurs, en particulier pour les utilisateurs de technologies d'assistance.

Il est nécessaire de contrôler les changements de contexte provoqués par des éléments focusables qui ne sont pas des boutons ou des liens, pour éviter des actions inattendues. Un exemple courant est l'utilisation d'un élément <select> où la sélection d'une <option> entraîne un rechargement complet de la page, un comportement normalement associé aux liens ou aux boutons de soumission de formulaire.

Pour un <select> qui recharge la page, il est possible d'informer l'utilisateur avant le changement de contexte en utilisant un attribut title explicatif :

<label for="lang">Changer de langue</label>
                    <select id="lang" title="Changer de langue : la sélection recharge la page">
  <option value="en">Anglais</option>
  <option value="fr">Français</option>
</select>

Une autre approche consiste à ajouter un bouton de soumission pour confirmer l'action avant qu'elle ne se produise. Avec cette technique, nous n'avons plus de changement de contexte. En effet, ce n'est pas la sélection de l'option qui entraîne le chargement inattendu d'une nouvelle page, mais un bouton de soumission de formulaire <button type=”submit”>. L'action de charger une nouvelle page est donc bien déclenchée par un élément ayant le rôle adéquat :

<label for="lang">Choisir la langue</label>
                    <select id="lang">
  <option value="en">Anglais</option>
  <option value="fr">Français</option>
</select>
<button type="submit">Changer de langue</button>

Une autre approche encore consiste à remplacer l'élément <select> par une liste de liens. Dans la même logique, le changement de contexte est ici supprimé, puisque c'est bien le rôle d'un lien que de déclencher le chargement d'une nouvelle page :

<ul>
  <li><a href="?lang=en">Anglais</a></li>
  <li><a href="?lang=fr">Français</a></li>
</ul>

9. Activer la fonctionnalité attendue, et après ?

Un focus mal géré est problématique et peu entraîner des situations de blocages.

Chaque élément interactif sur un site web doit répondre de façon appropriée aux actions des utilisateurs.

Après l'activation d'un lien (<a href=”...”>)

• Si c'est un lien externe, une nouvelle page doit se charger entièrement.
• Si c'est un lien interne à la page, il doit mener à la section correspondante sans recharger la page.

Après l'activation d'un bouton (<button type=”button”>), une action est effectuée sur la page, par exemple :

• un dépliant s’affiche ou se masque
• une modale s’ouvre
• un onglet active un panneau
• un élément de navigation affiche l’élément suivant ou précédent d’un carrousel
• une vidéo se lance
• un calcul se réalise

Une fois le bouton activé et l'action effectuée, si nécessaire :

• Soit on déplace le focus sur le nouvel élément affiché, par exemple on déplace le focus sur la nouvelle slide affichée après l’activation du bouton de type “Suivant” d’un carrousel
• Soit on laisse le focus là où il est et on vocalise, par exemple, après l’activation du premier filtre d’une série, on conserve le focus sur le bouton, mais on vocalise le nombre de résultats affichés avec les live regions ARIA, par exemple aria-live="polite" ou role="status" :

Note : nous précisons bien sûr "si nécessaire", car de nombreuses situations permettent de conserver le focus sur l'élément déclencheur après son activation, donc ne nécittent pas de déplacement de focus ou de vocalisation des changements intervenus sur les contenus.

<div aria-live="polite"><p>5 résultats affichés.</p></div>

10. Gérer les pages réactives

Dans les pages web réactives, où les contenus changent dynamiquement sans recharger complètement la page, il est requis de gérer efficacement le focus pour assurer une bonne accessibilité.

• Soit on utilise des boutons, dans ce cas, on doit gèrer le focus, c’est-à-dire qu’on le déplace là où il est pertinent de le déplacer selon le contexte du composant.
• Soit on utilise des liens, dans ce cas on simule un rechargement complet de la page. D’une part en ajoutant en premier dans l’ordre du code source un <p>xxx</p> masqué visuellement avec une classe de type sr-only où xxx est la valeur de la balise <title> de la page. D’autre part en déplaçant le focus sur ce paragraphe afin de donner à l’utilisateur la même expérience que s’il avait rechargé entièrement la page, dans ce cas, le focus repart donc naturellement du haut de la page.

Conclusion

Tous les développeurs n'ont pas encore bénéficié d'une formation en accessibilité. Et tous n'ont pas accès à des spécifications techniques accessibilité ou un accompagnement RGAA. Adopter ces 10 conseils pour améliorer l'accessibilité des éléments focusables constitue une étape fondamentale dans la création de sites web accessibles à tous. L'implémentation de ces pratiques dès les premières phases de développement non seulement simplifie le processus d'audit mais assure également une fondation solide pour une accessibilité effective. En anticipant les besoins d'accessibilité, les développeurs peuvent éviter les modifications coûteuses et laborieuses après un audit d'accessibilité.

Ce guide constitue un point de départ vers une compréhension plus approfondie et une intégration effective de l'accessibilité dans le développement web. Des sujets, tels que les liens d'accès rapides par exemple, mériteraient également d'être évoqués, et chacun des dix conseils présentés pourrait faire l'objet d'un article détaillé. Cet article donne tout de même quelques clés pour développer des éléments focusables de façon accessible. Il est aussi à noter que les liens vers les critères d'accessibilité du RGAA concernés sont fournis. Les équivalences WCAG sont disponibles dans chaque critère RGAA.