Partie 10 — Composants interactifs (patterns APG)
⏱️ TL;DR — Les composants interactifs custom — modales, menus, onglets, combobox — sont l’endroit où l’accessibilité devient vraiment difficile. Pourquoi ? Parce qu’ARIA ne code pas le clavier à ta place : elle déclare un rôle, mais c’est à toi d’écrire les touches, les états et la gestion du focus. La bonne nouvelle : tu n’as rien à inventer. Des patterns éprouvés existent — l’ARIA Authoring Practices Guide (APG) du W3C — et cette partie te les donne, widget par widget. Le premier réflexe reste pourtant le même : préférer l’élément natif ou une lib accessible (Partie 11) avant de tout recoder.
Le problème qu’on résout
Jusqu’ici, tu avais un filet de sécurité : le HTML natif. Un <button>, un <a href>, un <input> t’offrent gratuitement le rôle, le focus et le clavier. Mais dès qu’on te demande une modale, un système d’onglets ou une autocomplétion, il n’existe pas toujours de balise native qui fasse tout — et c’est là que 90 % des bugs d’accessibilité apparaissent.
Le piège classique : coller un role="dialog" ou un role="tablist" sur des <div> et croire que « c’est accessible ». Faux. ARIA a déclaré un widget que le clavier, lui, ne connaît pas : Échap ne ferme rien, les flèches ne font rien, le focus s’échappe. Un composant à moitié accessible est souvent pire qu’un composant honnêtement basique. Cette partie te donne le contrat complet de chaque widget : rôle, nom, clavier, états, focus.
Ce que tu sauras faire à la fin de cette partie
- Comprendre pourquoi suivre un pattern établi (l’APG) plutôt qu’improviser.
- Coder une modale accessible :
role="dialog", focus piégé,Échap, focus rendu au déclencheur — ou déléguer à<dialog>. - Distinguer et implémenter disclosure, menu button, onglets, accordéon avec le bon clavier.
- Savoir pourquoi combobox et listbox sont les patterns les plus durs, et quand passer la main à une lib.
- Traiter les cas restants — tooltips, carrousels, data grids, toasts — et surtout te demander « en ai-je vraiment besoin ? ».
Les chapitres
| # | Chapitre | En un mot |
|---|---|---|
| 10.1 | Le principe des patterns | Pourquoi l’APG, la check-list universelle d’un widget. |
| 10.2 | La modale (dialog) | Le pattern le plus demandé : focus piégé, Échap, <dialog>. |
| 10.3 | Menus, onglets, accordéon | Disclosure, menu button, tablist, flèches et aria-expanded. |
| 10.4 | Combobox & listbox | L’autocomplétion, le pattern le plus complexe. |
| 10.5 | Tooltips, carrousels & Cie | Tooltip vs toggletip, carrousel, data grid, toasts. |
Le fil conducteur de la partie
Un seul mantra traverse ces cinq chapitres : le natif d’abord, la lib ensuite, le custom en dernier recours. Chaque fois que tu t’apprêtes à recoder un widget à la main, demande-toi si <dialog>, <details>, un <select> ou une bibliothèque éprouvée (Radix, React Aria, Headless UI — voir Partie 11) ne ferait pas le travail mieux que toi. Les patterns de cette partie servent autant à coder juste qu’à comprendre ce qu’une lib fait pour toi.
On commence : Le principe des patterns.