Partie 6 — WAI-ARIA en profondeur

⏱️ TL;DR — ARIA est un scalpel, pas un pansement. Elle enrichit la sémantique exposée aux technologies d’assistance quand le HTML natif ne suffit pas — mais mal utilisée, elle dégrade l’accessibilité au lieu de l’améliorer. Cette partie démonte ce qu’ARIA fait vraiment (et ce qu’elle ne fait pas), passe en revue les rôles, les états & propriétés, les live regions, et finit par les erreurs qui coûtent cher.

Le problème qu’on résout

ARIA fascine les dévs : elle a l’air puissante, technique, « pro ». Résultat, on la sort trop tôt et trop fort — un role="button" sur un <button> qui n’en demandait pas, un aria-label collé sur une <div> qui l’ignore, un aria-expanded qui reste bloqué à false. Le piège, c’est qu’ARIA ne répare rien toute seule : elle ne fait que déclarer du sens à l’arbre d’accessibilité. Elle n’ajoute ni comportement, ni focus, ni clavier, ni style. Une ARIA fausse est même pire que pas d’ARIA : elle ment au lecteur d’écran. Cette partie te donne le modèle mental juste — quand ARIA est légitime, comment l’utiliser sans casser la sémantique native, et comment repérer les abus les plus fréquents.

Ce que tu sauras faire à la fin de cette partie

• Expliquer ce qu’ARIA change (nom / rôle / valeur exposés) et ce qu’elle ne fait pas (aucun comportement, focus ni style).
• Citer et appliquer les cinq règles d’ARIA, à commencer par « n’utilise pas ARIA si un élément natif existe ».
• Distinguer les catégories de rôles (landmark, widget, structure, live region) et éviter d’écraser un rôle natif.
• Tenir à jour les états (aria-expanded, aria-checked…) et poser les bonnes propriétés (aria-label, aria-controls…).
• Annoncer un changement dynamique avec une live region sans déplacer le focus.
• Reconnaître et corriger les erreurs ARIA les plus courantes.

Les chapitres

On commence : À quoi sert (vraiment) ARIA.