Ce qu’il faut retenir
- Le clavier doit permettre de terminer les tâches, avec un ordre compréhensible et un focus visible.
- Une modale doit gérer l’entrée, la navigation, la fermeture et le retour du focus.
- Les contrôles automatiques repèrent certaines erreurs ; une recette des parcours reste nécessaire.
Un utilisateur ouvre un formulaire, choisit une valeur et valide. À la souris, tout paraît fluide. Au clavier, le focus se perd dans le menu, le bouton reste derrière un bandeau fixe et la confirmation ne permet plus de revenir à la page. L’interface contient bien des éléments focusables, mais la tâche est bloquée. L’accessibilité se vérifie dans cette séquence, au-delà de la présence d’une propriété HTML.
Un parcours utilisable sans dispositif de pointage
Le critère 2.1.1 des WCAG demande que les fonctionnalités puissent être utilisées au clavier, sous réserve de ses exceptions liées aux gestes dépendant intrinsèquement d’un trajet. Le besoin concerne notamment les utilisateurs qui ne peuvent pas employer une souris, mais sert aussi ceux qui naviguent avec des technologies d’assistance ou préfèrent le clavier.
Cette exigence se traduit par des commandes disponibles, un ordre de navigation logique et des états compréhensibles. Un lien mène à une ressource ; un bouton déclenche une action. Les éléments natifs apportent des comportements attendus. Remplacer un bouton par un bloc cliquable puis ajouter un tabindex ne recrée pas automatiquement les activations, le nom accessible et les états utiles.
La logique rejoint l’amélioration des parcours de conversion : un utilisateur doit pouvoir achever sa tâche. La mesure ne se limite pas au clic sur le premier écran. Un paiement accessible jusqu’à la dernière étape et une inscription qui renvoie correctement une erreur constituent des résultats produit concrets.
L’ordre du document compte davantage qu’une numérotation artificielle
La navigation séquentielle suit normalement le document. Organiser correctement le HTML rend l’ordre plus prévisible. Les valeurs positives de tabindex risquent de créer une seconde logique difficile à maintenir : chaque ajout d’élément peut déplacer la séquence. Un composant complexe peut gérer sa navigation interne, mais cette gestion doit respecter un modèle attendu et être testée.
Un changement visuel produit par CSS peut éloigner l’ordre affiché de l’ordre de navigation. Le test se réalise donc sur le rendu réel, avec les points de rupture mobile et desktop. Les liens d’évitement permettent de passer une navigation répétée. Les éléments cachés ne doivent pas capter le focus, et un panneau fermé ne laisse pas ses commandes dans la séquence.
Visible signifie repérable à chaque étape
Un contour supprimé pour des raisons esthétiques laisse l’utilisateur sans position. Le remplacement doit rester suffisamment perceptible selon les fonds, états et thèmes. Le critère 2.4.11 des WCAG 2.2 vise aussi le focus masqué : un élément recevant le focus ne doit pas être entièrement dissimulé par un contenu créé par l’auteur.
Une barre de consentement, un en-tête fixe ou un panneau flottant peut cacher une commande pourtant présente dans le document. Tester la page sans ces états ne suffit pas. Le zoom, le petit écran et les messages d’erreur longs modifient la disposition. Le produit doit préserver l’accès dans les configurations qu’un utilisateur rencontre réellement.
Une fenêtre modale a un début et une sortie
Le guide WAI-ARIA des dialogues modaux décrit la gestion du focus à l’ouverture, sa navigation à l’intérieur et son retour à la fermeture. Le choix du premier élément dépend du contenu : pour un dialogue long, commencer par une commande en bas peut faire perdre le contexte. Le titre et les instructions doivent être accessibles sans imposer une lecture confuse.
Pendant l’ouverture, l’arrière-plan ne doit pas rester un parcours interactif concurrent. Le focus est contenu dans le dialogue de façon cohérente. La fermeture dispose d’une commande utilisable et d’un comportement clavier attendu. Après fermeture, le focus revient en général vers le déclencheur, ou vers une destination logique si celui-ci a disparu à la suite de l’action.
Ajouter aria-modal n’implémente pas ces comportements à lui seul. ARIA exprime une sémantique ; le code et les éléments choisis doivent produire la réalité correspondante. Un dialogue qui annonce sa modalité mais laisse les commandes arrière accessibles donne des informations contradictoires aux technologies d’assistance.
Terminer une demande avec une erreur de validation
Exemple hypothétique : un SaaS permet de demander un export. L’utilisateur ouvre un dialogue, choisit une période puis valide une date impossible. Le message explique le problème et indique le champ concerné. La position du focus reste utile pour corriger la valeur. Une nouvelle validation produit une confirmation, puis la fermeture ramène vers le suivi de l’export. Le clavier permet d’achever l’ensemble sans chercher la souris.
Une simple bannière « Erreur » en haut du dialogue ne suffit pas si elle n’est pas perçue. À l’inverse, déplacer le focus de façon agressive à chaque frappe perturbe la correction. La politique de validation distingue erreur bloquante, information de statut et mise à jour automatique. Le texte du message donne une instruction concrète, pas un code interne destiné au développeur.
Une grille de recette par tâche
| Étape | Question | Résultat attendu |
|---|---|---|
| Entrer | Où commence la navigation ? | Position et ordre compréhensibles |
| Choisir | Le composant répond-il aux commandes attendues ? | Valeur sélectionnable et annoncée |
| Corriger | L’erreur permet-elle d’agir ? | Champ et consigne identifiables |
| Terminer | Que devient le focus ? | Confirmation et destination logique |
Tester avec le clavier et les états difficiles
La recette commence sans souris : Tab, Maj+Tab, Entrée, Espace, Échap et les flèches quand le composant les prévoit. Elle suit une tâche complète avec une donnée valide, puis une donnée invalide. Elle observe la position, la visibilité et le nom des commandes. Les pages à chargement asynchrone sont examinées avant et après la réponse, car un changement de contenu peut déplacer ou supprimer l’élément actif.
Des contrôles automatiques complètent ce travail en détectant, par exemple, des noms manquants ou certains défauts de structure. Leur absence d’erreur ne prouve pas un ordre logique ni une expérience fluide. Une recette avec lecteur d’écran, selon le périmètre du produit, vérifie la cohérence des annonces. Elle exige des outils et des compétences propres ; il faut rapporter ce qui a réellement été essayé.
Les outils qui accélèrent le travail des équipes peuvent aider à inventorier les composants, mais leur production se contrôle. Un composant généré contenant beaucoup d’attributs ARIA peut rester inutilisable. La qualité se juge sur la tâche et le comportement, pas sur la quantité de balises.
Le système de composants est un point de contrôle
Tester une bibliothèque de composants évite de répéter certains défauts sur toutes les pages. Il faut néanmoins vérifier leur assemblage : deux dialogues corrects peuvent produire un mauvais retour du focus quand ils s’ouvrent l’un depuis l’autre. Une navigation, un tableau et un formulaire peuvent créer un ordre confus malgré des tests isolés réussis.
Les intégrations de services introduisent aussi des iframes et widgets tiers. Leur parcours doit être inclus dans la recette, avec les erreurs réseau et l’authentification éventuelle. Le responsable produit conserve la liste des obstacles, leur effet sur les tâches et la priorité de correction.
La prochaine action utile consiste à choisir votre parcours principal, poser la souris et le terminer avec une erreur volontaire. Documenter l’endroit où le focus disparaît ou devient incompréhensible donne une correction directement vérifiable.
Sources et références
Mise à jour du 1er octobre 2026 : références vérifiées à cette date. Les mécanismes décrits sont durables ; les options exactes restent à vérifier dans la version du produit utilisée.
- W3C — Understanding WCAG 2.2, Keyboard — fonctionnalités accessibles au clavier
- W3C — Focus Not Obscured (Minimum) — focus non entièrement masqué
- W3C — WAI-ARIA APG, Modal Dialog — gestion du focus dans un dialogue
