Opérer : clavier, focus, ARIA, formulaires

Opérer : tout doit être faisable au clavier

1. Le clavier comme mode de contrôle complet

   Le critère 2.1.1 (niveau A) impose que toute fonctionnalité soit utilisable au clavier. C'est le critère le plus discriminant du web : il échoue là où les sites ont été construits avec de la souris.

   Ce qui n'est pas faisable au clavier sans travail

   • Un élément qui n'est focusable que parce qu'on lui a mis onclick sans tabindex, ni rôle, ni gestionnaire clavier.
   • Un menu déroulant implémenté uniquement en survol : sans focus, il ne s'ouvre pas au clavier.
   • Un lien dont le href est vide ou valant #, qui exécute l'action en JavaScript : parfois focusable, parfois pas, jamais fiable.
   • Un composant sur mesure — onglet, carrousel, sélecteur de date — sans gestion du clavier : le cas le plus fréquent.

   La ligne de démarcation : bouton ou pas bouton

   Ce n'est pas une question d'apparence. Un élément est un bouton s'il déclenche une action dans la page ; c'est un lien s'il va quelque part. Beaucoup d'interfaces confondent les deux, et la confusion coûte cher : un « bouton » qui est en réalité un lien styled ne déclenche pas l'action attendue avec la touche Entrée ou Espace, et ne fait rien de ce qu'on attend d'un bouton.

   Le bon réflexe : utiliser <button> pour une action et <a href> pour une navigation, sans homotrophie d'apparence. Les deux sont focusables, les deux sont focusables au clavier — mais chacun réagit à la bonne touche et est annoncé avec le bon rôle.

   Les pièges clavier (2.1.2, niveau A)

   Un piège clavier est un composant dont le focus ne peut pas quitté au clavier. Le cas le plus grave est la modale : si le focus ne revient pas sur le déclencheur à la fermeture, l'utilisateur perd le fil de la page. Les autres pièges sont moins spectaculaires et plus fréquents : un widget de carousel où les flèches font défiler sans permettre de sortir, un menu dont la fermeture au clavier est impossible.

   La règle : toute interaction doit pouvoir être annulée avec la touche Échap, et le focus doit être ramené explicitement. Sur une modale, la séquence attendue est Échap ferme, le focus revient sur ce qui a ouvert.

2. Focus : visible, ordonné, jamais masqué

   Le focus doit être visible (2.4.7, niveau AA)

   Un focus invisible est un piège silencieux : l'utilisateur sait qu'il a(tabulé, il ne sait pas où il est. La cause la plus fréquente n'est pas l'absence de style, c'est le outline: none posé par défaut et jamais remplacé.

   Le correctif : soit conserver le contour par défaut du navigateur, soit le remplacer par quelque chose de visible et contraste suffisant — critère 1.4.11, ratio 3:1 sur les éléments non textuels. Un indicateur custom doit aussi signaler le focus focus-visible, sans supprimer l'indicateur au survol de la souris.

   L'ordre du focus doit suivre l'ordre visuel (2.4.3, niveau A)

   C'est le critère qui échoue le plus souvent, et il n'est visible que lorsqu'on tabule. Si le tabindex est à 0 ou absent, l'ordre suit le DOM. Il faut alors que le DOM suive l'ordre visuel — ce qui est vrai sauf quand la mise en page est en CSS Grid ou Flexbox avec réordonnation, ou quand une colonne latérale est placée avant le contenu dans le HTML pour des raisons de structure.

   Le test tient en une phrase : tabuler de haut en bas doit-il donner l'ordre de lecture naturel ? Si à un moment on passe du pied de page au menu, ou d'un bouton « Suivant » au bouton « Précédent », l'ordre est faux.

   Le lien d'évitement (2.4.1, niveau A)

   Critère sous-estimé : un lien « Aller au contenu principal », le premier élément focusable de la page, visible quand il reçoit le focus. Il paraît anecdotique, il est pourtant l'un des critères les plus utiles sur un site avec une navigation de vingt liens : il évite de tabuler trente fois à chaque changement de page.

   Le focus ne doit pas être masqué (2.4.11, niveau AA)

   Introduit par la WCAG 2.2 : l'indicateur de focus ne doit pas être entièrement masqué par du contenu à défilement ou par une barre d'outils fixe. Le cas typique est un bouton d'acceptation de cookies fixe en bas de page qui recouvre le focus d'un lien situé juste au-dessus. Le critère impose que l'élément masquant puisse être déplacé — par exemple un bandeau qui se replie sur un bouton.

   Les raccourcis clavier ne doivent rien piéger (2.1.4, niveau A)

   Si l'on ajoute des raccourcis — un Ctrl+S pour sauvegarder, un / pour chercher — ils doivent pouvoir être désactivés ou remappés, et ne pas entrer en conflit avec ceux du navigateur ou de la technologie d'assistance. Un raccourci qui survit au changement de contexte capture le clavier et devient un piège.

3. ARIA : le nom, le rôle, la valeur

   Le critère 4.1.2 (niveau A) demande que le nom, le rôle et la valeur de chaque composant soient déterminables par le code. C'est la définition du mot « robuste ».

   La première règle d'ARIA : ne rien ajouter

   « La première règle de l'utilisation d'ARIA est de ne pas utiliser ARIA. » Un élément HTML natif porte déjà son rôle, son nom et son comportement au clavier : un <button> est un bouton pour tout le monde, sans une ligne de plus. ARIA sert à compléter le HTML là où il n'a pas d'équivalent, pas à le réécrire.

   Ce que l'on peut legitimately ajouter

   • aria-label ou aria-labelledby pour nommer un composant qui n'a pas de texte visible — un bouton icône, un champ de recherche.
   • aria-expanded sur un accordéon ou un menu, pour dire s'il est ouvert.
   • aria-current sur le lien de la page courante.
   • aria-describedby pour relier un champ à son aide et à son message d'erreur.
   • role="alert" pour qu'un message d'erreur inséré dynamiquement soit annoncé.

   Les erreurs qui coûtent cher

   • Faux rôle sur un élément natif — un div en role="button" sans gestion clavier ni état : annoncé comme un bouton, inopérant au clavier. Pire que de ne rien faire.
   • Redondance — <button role="button">. Inutile et source de conflits.
   • aria-hidden sur un élément focusable — il devient invisible pour le lecteur d'écran tout en restant focusable : on crée un focus qui mène nulle part.
   • alt sur un élément non-image — un alt sur un <div> ne fait rien, et donne l'illusion d'avoir travaillé.

   Contrôler ce que la technologie d'assistance annonce vraiment

   La seule vérification qui compte se fait dans l'inspecteur d'accessibilité de la barre de développement, sur l'onglet des rôles. Si un composant n'apparaît pas dans la liste, il n'existe pas pour l'utilisateur. Cette vérification prend trente secondes et remplace la moitié des vérifications manuelles : elle dit ce que le lecteur d'écran va annoncer, au lieu de le deviner.

   Le piège à connaître : un composant peut être annoncé correctement et rester inutilisable — un bouton sans nom, un champ sans étiquette. L'ARIA donne des noms, il ne rend pas un composant fonctionnel.

4. Formulaires et erreurs : le point de rupture des parcours

   Le formulaire est l'endroit où l'accessibilité se paie le plus cher en temps d abandons, et le plus souvent en causes perdues. Cinq exigences à ne pas négocier.

   1. Une étiquette liée à chaque champ (3.3.2, niveau A)

   Un champ a besoin d'une étiquette persistante — présente avant, pendant et après la saisie. Un placeholder qui disparaît à la première frappe est un défaut classique : il ne laisse plus rien pour identifier le champ, et il est souvent trop pâle pour passer le contraste.

   2. Les erreurs identifiées en texte (3.3.1, niveau A)

   Le message doit dire quel champ est en erreur et quoi faire pour le corriger. « Erreur de validation » ne dit rien. « Le code postal doit contenir 5 chiffres » règle le problème. L'erreur doit être associée au champ, pas seulement affichée au-dessus du formulaire.

   3. Les erreurs signalées avant ou au moment de la perte de contexte

   Une erreur validée seulement au clic sur « Envoyer », sans que le focus n'aille nulle part, oblige à relire tout le formulaire pour trouver le champ fautif. L'ARIA role="alert" sur le message d'erreur, et un déplacement du focus vers le premier champ en erreur, transforment une recherche en une confirmation.

   4. Pas d'appels redondants (3.3.7, niveau AA, WCAG 2.2)

   Critère ajouté par la WCAG 2.2 : si le même champ déclenche plusieurs fois l' announces du même message d'erreur, l'utilisateur ne comprend plus. On annonce une fois, puis on laisse l'utilisateur corriger.

   5. La taille des cibles (2.5.8, niveau AA, WCAG 2.2)

   Critère également nouveau en 2.2 : les cibles interactives font au moins 24 × 24 pixels, ou elles disposent d'un espacement suffisant. Les liens de navigation inline échappent à la règle, mais les icônes de barre d'outils, les boutons-icônes et les petites croix de fermeture y sont soumis. C'est là que l'on gagne réellement : ces cibles sont minuscules au doigt comme à la souris.

   Le temps et la cognition

   Si le formulaire a une limite de temps, elle doit être annoncée, extensible, et l'avertissement doit être possible avant expiration (critères 2.2.x). De même, une étape qui exige de mémoriser une information servie ailleurs — un code dans un e-mail à recopier — est une barrière cognitive réelle. La corriger fait partie du travail.