Chapitre 10.1 — Le principe des patterns

⏱️ TL;DR — Un widget accessible n’est pas une œuvre d’art personnelle : c’est un contrat connu. L’ARIA Authoring Practices Guide (APG) du W3C décrit, pour chaque composant (modale, onglets, menu, combobox…), le rôle attendu, le nom accessible, les touches clavier à câbler, les états à tenir à jour et la gestion du focus. Suivre ces patterns, c’est offrir à l’utilisateur un comportement qu’il connaît déjà. À l’inverse, improviser un widget « original » le condamne à réapprendre — ou à ne pas pouvoir s’en servir. Et avant même d’ouvrir l’APG, pose-toi la vraie question : ai-je besoin d’un composant custom, ou le natif suffit-il ?

🎯 Objectifs

• Comprendre pourquoi on suit un pattern établi au lieu d’inventer.
• Connaître la check-list universelle d’un widget accessible.
• Distinguer les deux modèles de focus interne : roving tabindex et aria-activedescendant.
• Savoir quand ne pas coder un composant custom.

Pourquoi des patterns, et pas de l’improvisation

Quand un utilisateur de lecteur d’écran rencontre des onglets, il s’attend à un comportement précis : Tab pour entrer dans la barre d’onglets, les flèches pour changer d’onglet, l’annonce « onglet sélectionné, 2 sur 3 ». Ce comportement n’est pas une convention que tu décides : c’est un standard partagé, documenté dans l’APG, que les gens ont appris une fois pour toutes.

Improviser un widget « à ta sauce » revient à inventer une nouvelle langue et à espérer que l’utilisateur la parle. Il ne la parle pas. Le pattern APG n’est donc pas une contrainte bureaucratique : c’est le vocabulaire commun qui rend ton composant utilisable sans mode d’emploi.

💡 Réflexe — Avant d’écrire une seule ligne d’un widget custom, ouvre la page APG correspondante (ARIA Authoring Practices Guide, w3.org/WAI/ARIA/apg). Elle te donne le rôle, le clavier attendu et les états à gérer, cas par cas. Tu ne devines pas : tu implémentes une spec. C’est le prolongement direct de la Partie 6 sur ARIA — l’APG, c’est ARIA mise en recettes.

La check-list universelle d’un widget

Tout composant interactif custom, quel qu’il soit, doit satisfaire cinq points. Retiens-les : ils reviennent à chaque chapitre de cette partie.

ARIA (points 1, 2, 4) est la partie déclarative : elle informe l’arbre d’accessibilité. Mais les points 3 et 5 — clavier et focus — sont du JavaScript que personne n’écrit à ta place. C’est tout le sujet de cette partie : ARIA nomme le widget, toi tu le fais fonctionner.

<!-- ❌ Rôle déclaré, mais widget mort : aucune touche, aucun état géré -->
<div role="tablist">
  <div role="tab">Profil</div>
  <div role="tab">Sécurité</div>
</div>

Ici l’ARIA ment : elle promet des onglets, mais les flèches ne font rien, rien n’est focusable, aucun aria-selected ne bouge. L’utilisateur entend « onglet » et… reste bloqué. Un role sans le comportement associé est un piège, pas une fonctionnalité.

Les deux modèles de focus interne

Dans un widget composite (onglets, menu, listbox), plusieurs éléments sont candidats au focus. Comment Tab et les flèches se répartissent-ils le travail ? L’APG propose deux modèles — tu en choisis un par widget, jamais les deux.

Modèle 1 — le roving tabindex. Un seul élément du groupe est focusable à la fois (tabindex="0"), tous les autres sont retirés de la tabulation (tabindex="-1"). Les flèches déplacent le tabindex="0" d’un élément à l’autre et appellent .focus(). Le focus réel du navigateur se promène (« rove ») dans le groupe.

<!-- Roving tabindex : un seul tab stop, les flèches déplacent le focus réel -->
<div role="tablist">
  <button role="tab" tabindex="0"  aria-selected="true">Profil</button>
  <button role="tab" tabindex="-1" aria-selected="false">Sécurité</button>
</div>

Modèle 2 — aria-activedescendant. Le focus réel ne bouge pas : il reste sur le conteneur (souvent un input). Un attribut aria-activedescendant pointe vers l’id de l’élément « virtuellement » actif, et c’est lui que le lecteur d’écran annonce. On l’utilise surtout pour les combobox, où le focus doit rester dans le champ de saisie pendant qu’on parcourt la liste.

<!-- aria-activedescendant : le focus reste dans l'input, l'option active est pointée -->
<input role="combobox" aria-expanded="true"
       aria-controls="lb" aria-activedescendant="opt-2">
<ul role="listbox" id="lb">
  <li role="option" id="opt-1">Paris</li>
  <li role="option" id="opt-2" aria-selected="true">Lyon</li>
</ul>

Règle simple : roving tabindex quand le focus peut réellement se déplacer sur les éléments (onglets, menu, radios) ; aria-activedescendant quand le focus doit rester ailleurs, typiquement dans un champ de saisie (combobox).

♿ Côté utilisateur — Ces deux modèles servent le même but : un seul « point d’arrêt » au Tab pour tout le groupe. Sans ça, un utilisateur de menu à 30 entrées devrait tabuler 30 fois pour en sortir. Avec un roving tabindex, il entre au Tab, choisit aux flèches, ressort au Tab suivant. Le widget se comporte comme un tout, pas comme 30 obstacles.

Quand NE PAS coder un composant custom

Le meilleur widget accessible est souvent celui que tu n’écris pas. Avant de te lancer, remonte cette échelle, du plus sûr au plus risqué :

1. Un élément natif existe-t-il ? <dialog> pour une modale, <details> pour une disclosure, <select> pour une liste simple. Le natif t’offre rôle, clavier et focus gratuitement.
2. Sinon, une lib accessible et éprouvée fait-elle le travail ? Radix UI, React Aria, Headless UI implémentent déjà les patterns APG, testés avec de vrais lecteurs d’écran (Partie 11).
3. Sinon seulement, code le pattern APG toi-même — en sachant que tu signes pour le clavier, les états et le focus, à la main et pour de bon.

Recoder un combobox from scratch « parce que ça a l’air simple » est l’une des meilleures façons de produire un composant inutilisable. La compétence experte, ce n’est pas de tout réécrire : c’est de savoir quand ne pas le faire.

🧭 Sur A11yLearn — Sur A11yLearn, la première version du sélecteur de langue était une <div role="listbox"> maison, sans clavier ni gestion du focus. On a tranché avec l’échelle ci-dessus : un <select> natif couvrait exactement le besoin (choisir une valeur dans une courte liste). Trois lignes de HTML ont remplacé 200 lignes de JavaScript bancal — et le composant est devenu utilisable au clavier, au lecteur d’écran et en commande vocale d’un coup. Le custom n’est arrivé que là où le natif ne suffisait plus : l’autocomplétion de recherche (voir 10.4).

✏️ Exercices

Exercice 1 — Diagnostique le widget mort. Un collègue livre ce « menu » et jure qu’il est accessible parce qu’il a mis les rôles ARIA. Cite au moins trois choses qui manquent.

<div role="menu">
  <div role="menuitem" onclick="aller('/profil')">Profil</div>
  <div role="menuitem" onclick="aller('/reglages')">Réglages</div>
</div>

Exercice 2 — Choisis le modèle de focus. Pour chacun, dis si tu utiliserais un roving tabindex ou aria-activedescendant : (a) une barre d’onglets, (b) un champ d’autocomplétion de ville, (c) un menu contextuel.

🧠 Quiz de révision

Chapitre suivant : La modale (dialog) — le pattern le plus demandé, et le plus souvent raté : focus piégé, Échap, focus rendu au déclencheur.