Les limites de HTML pour l'accessibilité : ARIA, composants complexes et angles morts

Le HTML sémantique est une fondation solide pour l'accessibilité numérique — mais une fondation n'est pas un bâtiment. Dès que vos interfaces dépassent la page de contenu statique pour entrer dans le territoire des applications web modernes, vous découvrez rapidement les zones où HTML seul ne suffit plus, où les spécifications accrochent sur les implémentations, et où l'accessibilité réelle diverge de l'accessibilité théorique.

Ce que HTML fait bien — et ses premières limites

Les éléments HTML natifs sont, de loin, la meilleure base accessible disponible. Un <button> est focusable au clavier, activable à la barre espace et à Entrée, et expose automatiquement son rôle (button) à l'arbre d'accessibilité. Un <input type="checkbox"> expose son état coché ou non. Un <select> propose une navigation par flèches.

Mais la réalité des projets produit des frictions :

• Personnalisation visuelle : styler un <select> natif au-delà d'un certain point est impossible sans reconstruire le composant en JavaScript — avec tous les risques d'accessibilité que cela implique.
• Composants inexistants en HTML natif : il n'existe pas de balise <tabs>, <combobox>, <tree>, <datepicker> ou <toast>. Ces patterns d'interface doivent être construits à la main, en dehors du HTML sémantique.
• Le contenu dynamique : HTML est un langage de document statique. Tout contenu qui change après le chargement initial est invisible aux technologies d'assistance sans instrumentation explicite.

ARIA : la promesse et les pièges

WAI-ARIA (Accessible Rich Internet Applications) est la spécification qui complète HTML pour les interfaces dynamiques. Elle permet d'annoter le DOM avec des rôles, des états et des propriétés que les technologies d'assistance peuvent interpréter. Mais ARIA est un outil de chirurgie, pas de peinture au rouleau.

Les live regions : quand le contenu change sans rechargement

Les live regions sont le mécanisme ARIA permettant de notifier les lecteurs d'écran qu'une zone de la page vient d'être mise à jour. Elles s'implémentent via l'attribut aria-live :

• aria-live="polite" — l'annonce attend que l'utilisateur soit inactif. Adapté aux notifications non urgentes.
• aria-live="assertive" — l'annonce interrompt immédiatement la lecture en cours. À réserver aux erreurs critiques.

Le piège classique : injecter du contenu dans une live region avant qu'elle ne soit présente dans le DOM. La région doit exister au chargement de la page pour que les lecteurs d'écran l'enregistrent. Insérer dynamiquement une <div aria-live="polite"> puis y ajouter du texte immédiatement ne fonctionnera pas de façon fiable.

Les rôles composites : un contrat strict

ARIA définit des patterns de design qui spécifient précisément quels rôles, états et interactions clavier sont attendus pour chaque composant :

• Combobox (role="combobox") : nécessite la gestion de aria-expanded, aria-autocomplete, aria-activedescendant et d'un pattern clavier précis. La spécification a changé entre ARIA 1.0 et 1.2, rendant obsolètes de nombreuses implémentations.
• Tree (role="tree") : arborescence navigable. Chaque nœud doit porter role="treeitem" avec aria-expanded, et la navigation doit suivre un modèle composite.
• Dialog (role="dialog") : la gestion du focus est critique — il doit être déplacé vers la modale à l'ouverture, piégé à l'intérieur (focus trap), et restauré à l'élément déclencheur à la fermeture. Manquer l'un de ces points rend la modale inutilisable au clavier.

La première règle d'ARIA — souvent ignorée

La spécification pose une règle fondamentale : n'utilisez pas ARIA si un élément HTML natif peut faire le travail. Cette règle est régulièrement violée :

• role="button" sur un <div> : expose le rôle mais ne donne pas la focusabilité native, ni l'activation à la barre espace. Il faut ajouter tabindex="0" et gérer les événements clavier — pour un résultat inférieur à <button>.
• aria-label sur un élément visible : écrase le nom visible dans l'arbre d'accessibilité. Un bouton libellé "Envoyer" avec aria-label="Soumettre" ne sera pas trouvé par un utilisateur de contrôle vocal.
• aria-hidden="true" sur un élément focusable : masque l'élément aux technologies d'assistance mais le laisse dans l'ordre de tabulation.

Les limites d'implémentation : la théorie contre la réalité

Même une implémentation ARIA parfaitement conforme peut ne pas fonctionner comme attendu. Le support des attributs ARIA varie entre les combinaisons de lecteurs d'écran, navigateurs et systèmes d'exploitation. Le terrain de test qui fait foi est la matrice NVDA/JAWS/VoiceOver × Chrome/Firefox/Safari/Edge. Quelques exemples documentés :

• Live regions dans les SPAs : dans les Single Page Applications, les transitions de page ne rechargent pas le DOM. Les live regions utilisées pour annoncer les changements de route se comportent différemment selon que la région était présente au chargement initial ou injectée dynamiquement.
• role="status" et role="alert" : leur comportement varie entre lecteurs d'écran — certains annoncent immédiatement, d'autres attendent, certains ignorent les mises à jour si la fenêtre n'est pas au premier plan.
• aria-describedby sur des éléments complexes : le support est inconsistant. Certains lecteurs d'écran n'annoncent la description que quand le focus arrive sur l'élément, d'autres l'ignorent dans certains contextes.

L'accessibilité cognitive : le parent pauvre de HTML

WCAG 2.2 introduit des critères d'accessibilité cognitive, mais HTML ne fournit quasiment aucun outil natif pour adresser ces besoins :

• Dyslexie : aucun attribut HTML ne permet de signaler qu'un texte est disponible en police adaptée. Les solutions reposent sur des préférences utilisateur côté navigateur ou des extensions tierces.
• Surcharge cognitive : HTML n'a pas de mécanisme pour signaler la complexité d'un contenu ou proposer une version simplifiée.
• Temps limité : les composants avec timeout n'ont aucun équivalent sémantique standardisé pour avertir l'utilisateur et lui laisser le choix de prolonger.
• Navigation prévisible : le critère WCAG 3.2.3 demande une navigation cohérente entre les pages. HTML ne peut pas l'imposer — c'est une question d'architecture et de discipline de développement.

Les contenus non textuels : une frontière encore floue

• Les graphiques et visualisations de données : SVG permet d'insérer des éléments <title> et <desc>, mais décrire un graphique complexe dépasse ce qu'un texte alternatif court peut exprimer. La solution recommandée — fournir un tableau de données équivalent — est rarement implémentée.
• Les canvas : l'élément <canvas> est, par nature, opaque aux technologies d'assistance. La solution est de maintenir un DOM fantôme accessible parallèle au rendu canvas — ce que font rarement les frameworks de façon complète.
• Les cartes interactives : Leaflet, Mapbox, Google Maps ne sont pas accessibles par défaut. La navigation clavier dans une carte et sa compréhension par un lecteur d'écran restent un problème non résolu à l'échelle de l'industrie.
• Les PDF : omniprésents sur les sites publics. Un PDF accessible nécessite une structure de balises interne, des textes alternatifs et un ordre de lecture correct — des contraintes que la majorité des documents produits par les collectivités ne respectent pas.

Vers l'accessibilité augmentée : les pistes

• ARIA Authoring Practices Guide : le W3C maintient des exemples d'implémentation de référence, avec les patterns clavier attendus, testés sur les principales combinaisons lecteurs d'écran / navigateurs.
• Les tests avec de vrais utilisateurs : aucun outil automatisé (axe, Lighthouse, WAVE) ne peut détecter plus de 30 à 40 % des problèmes d'accessibilité réels. Seuls les tests avec des utilisateurs en situation de handicap révèlent les frictions que les spécifications ne capturent pas.
• Les bibliothèques de composants accessibles : Headless UI, Radix UI, Adobe React Aria ou Ariakit implémentent les patterns ARIA complexes de façon robuste et testée.
• L'API Accessibility Object Model (AOM) : spécification en cours de développement qui permettrait de manipuler l'arbre d'accessibilité directement depuis JavaScript, sans passer par des contournements ARIA. Son support reste expérimental.

L'accessibilité numérique avancée est une discipline à part entière, qui requiert de connaître autant les spécifications que leurs implémentations réelles. HTML en est le point de départ indispensable — mais rarement le point d'arrivée.