Menus déroulants et composants interactifs : les pièges d'accessibilité

Un menu déroulant qui s'ouvre au survol paraît anodin. Pourtant, c'est l'un des composants qui bloque le plus d'utilisateurs. C'est aussi l'un des plus coûteux à corriger après coup.

Cet article s'adresse à ceux qui écrivent le code, ou qui doivent juger le travail d'un prestataire. Voici les composants interactifs accessibles qui posent problème, et ce qui les répare.

Tester mon site gratuitement

Des composants interactifs accessibles commencent par le natif

Un élément natif du navigateur est accessible par construction. Un bouton écrit avec la balise prévue reçoit le focus, réagit à la touche Entrée, s'annonce comme un bouton.

Le même bouton fabriqué avec une simple division n'existe pour personne d'autre que la souris. Il faudra alors lui rendre à la main tout ce qu'il aurait eu gratuitement.

Autrement dit, la première question n'est pas « comment rendre ce composant accessible », mais « existe-t-il déjà en natif ».

Les menus déroulants, cas d'école

Le menu de navigation concentre trois défauts à lui seul.

L'ouverture au survol uniquement

Le survol n'existe ni au clavier ni sur écran tactile. Un sous-menu qui ne s'ouvre qu'au passage de la souris rend une partie du site inatteignable.

La correction consiste à ouvrir aussi au clic et à la touche Entrée, puis à refermer avec la touche Échap.

Le sous-menu qui reste dans l'ordre de tabulation

Un menu fermé visuellement mais toujours présent dans le code piège l'utilisateur au clavier. Le focus part sur des liens invisibles, sans que rien ne l'explique.

Un sous-menu masqué doit l'être réellement, et non simplement déplacé hors de l'écran.

L'état non annoncé

Le bouton qui ouvre le menu doit indiquer s'il est ouvert ou fermé. Sans cette information, un lecteur d'écran annonce un bouton sans dire ce qu'il fait.

Onglets, accordéons et carrousels : trois composants interactifs accessibles à surveiller

Ces trois composants partagent la même logique. Un déclencheur, une zone révélée, et un état à tenir à jour.

• Le déclencheur doit être un vrai bouton, atteignable au clavier.
• La relation entre le déclencheur et la zone doit être écrite dans le code.
• Le contenu masqué ne doit pas rester lisible par un lecteur d'écran.
• Le carrousel doit pouvoir être arrêté, car un défilement automatique gêne la lecture.

Le carrousel mérite d'ailleurs une remarque commerciale. Il est rarement lu, souvent lourd, et presque toujours mal codé. Beaucoup de sites gagneraient à le remplacer par une image fixe.

Les fenêtres modales, sources de blocage complet

Une modale mal faite est le pire scénario. L'utilisateur au clavier se retrouve derrière la fenêtre, sans pouvoir agir ni la fermer.

Trois exigences règlent la question. Le focus entre dans la modale à l'ouverture. Il y reste tant qu'elle est ouverte. Il revient sur l'élément déclencheur à la fermeture.

Ajoutez la fermeture par la touche Échap, qui coûte deux lignes et évite un blocage total.

Ce que le code doit dire, et ce qu'il ne doit pas dire

Les attributs qui décrivent un rôle ou un état sont utiles, mais dangereux quand ils mentent. Une case à cocher annoncée comme telle, mais impossible à cocher au clavier, vaut moins qu'un composant sans annotation.

La règle est donc simple : n'annoncez que ce que le composant fait réellement. Ensuite, testez au clavier avant de considérer le travail terminé, en suivant notre protocole de test au clavier.

Composants interactifs accessibles : la recette à exiger

Voici le contrôle minimal à inscrire dans une commande de développement.

• Chaque composant s'utilise entièrement au clavier, sans souris.
• Le focus reste visible à chaque étape.
• Aucun piège au clavier ne subsiste, modale comprise.
• Les états ouverts et fermés sont annoncés correctement.
• Aucun contenu masqué n'est lu par erreur.

Ce niveau d'exigence relève du contrat, pas de la bonne volonté. Notre article sur la responsabilité de l'agence web explique comment l'écrire noir sur blanc.

Pour resituer ces composants interactifs accessibles dans l'ensemble des critères, consultez notre guide des critères RGAA.

Lancer le dépistage gratuit

Dépistage automatique : il couvre environ 30 % des critères du référentiel. Il ne remplace pas un audit manuel et ne vaut pas attestation de conformité.

Un composant maison vous inquiète ? Écrivez-nous, nous le testons et vous disons ce qu'il faut reprendre.

Références : modèles de composants du W3C et portail de l'accessibilité numérique de l'État.