Script incompatible lecteur d'écran : RGAA 7.1, correction

Q: aria-hidden="true" suffit-il à masquer un composant décoratif ?

aria-hidden="true" masque l'élément aux technologies d'assistance, mais ne le retire pas de la tabulation clavier. Attention : laisser des éléments focusables à l'intérieur d'un conteneur aria-hidden crée un focus fantôme (l'utilisateur reçoit le focus sur un élément signalé comme masqué). Pour masquer un bloc interactif entier, utilise l'attribut inert sur le conteneur, ou retire chaque élément de la tabulation avec tabindex="-1" en plus de les masquer.

C'est quoi

Le critère RGAA 7.1 exige que chaque script modifiant l'interface ou générant du contenu interactif soit compatible avec les technologies d'assistance.

La compatibilité repose sur trois piliers :

Un rôle ARIA approprié sur le composant (ex : role="dialog" pour une modale, role="tablist" / role="tab" / role="tabpanel" pour des onglets).
Des propriétés et états ARIA tenus à jour (ex : aria-expanded="true/false" sur un bouton d'accordéon, aria-selected="true" sur l'onglet actif).
Une gestion du clavier conforme aux patterns ARIA Authoring Practices (flèches pour naviguer dans un menu, Échap pour fermer une modale, Tab pour circuler dans le contenu actif).

Ce critère correspond à WCAG 4.1.2 (Nom, rôle, valeur, niveau A) et WCAG 1.3.1 (Information et relations, niveau A).

Qui est touché

Les personnes aveugles utilisant un lecteur d'écran : un composant sans rôle ARIA est annoncé comme un simple texte ou est ignoré. L'utilisateur ne sait pas qu'il peut interagir avec lui.
Les personnes naviguant au clavier uniquement : un composant sans gestion du clavier est inaccessible. Le focus peut même se trouver piégé à l'intérieur (piège au clavier).
Les personnes utilisant un commutateur d'accès ou un contacteur : elles ne peuvent atteindre que les éléments dans l'ordre de tabulation.

Impact business

Un composant JS non compatible bloque une fonctionnalité entière. Une modale inaccessible peut bloquer l'accès à un formulaire, une confirmation ou une information critique. Un menu déroulant inaccessible peut empêcher la navigation vers une section entière du site.

Ce type d'erreur est particulièrement fréquent avec les composants issus de bibliothèques tierces (sliders, carrousels, menus) dont l'accessibilité n'a pas été vérifiée avant intégration.

Sources des chiffres

Comment le détecter

Audit Mynto : le scan détecte les composants interactifs courants (boutons, menus, modales) sans rôles ARIA appropriés.
Manuel au lecteur d'écran : interagis avec chaque composant interactif. Le lecteur d'écran doit annoncer son rôle, son état et son nom. Si tu n'entends qu'un clic sans annonce de rôle, c'est un problème.
Manuel au clavier : vérifie que tu peux ouvrir, naviguer à l'intérieur et fermer chaque composant avec Tab, Entrée, Échap et les flèches directionnelles.

Comment corriger

Avant - HTML

<!-- Modale sans rôle ni gestion du clavier -->
<div class="modal" id="modale">
  <div class="modal-content">
    <span class="close">×</span>
    <p>Contenu de la modale</p>
  </div>
</div>

Après - HTML

<!-- Modale accessible avec ARIA -->
<div
  class="modal"
  id="modale"
  role="dialog"
  aria-modal="true"
  aria-labelledby="modale-titre"
>
  <div class="modal-content">
    <h2 id="modale-titre">Titre de la modale</h2>
    <p>Contenu de la modale</p>
    <button aria-label="Fermer la modale">×</button>
  </div>
</div>

Pour rendre un composant JS compatible, suis le pattern ARIA correspondant dans l'ARIA Authoring Practices Guide (APG) du W3C. Chaque composant courant (accordéon, onglets, modale, menu) a son propre pattern avec les rôles, propriétés et interactions clavier attendus.

Points essentiels pour une modale :

role="dialog" et aria-modal="true" sur le conteneur.
aria-labelledby pointant vers le titre visible.
Focus piégé à l'intérieur tant que la modale est ouverte.
Fermeture avec la touche Échap.
Retour du focus sur l'élément déclencheur à la fermeture.

Sur WordPress, préfère des composants et thèmes qui intègrent nativement l'accessibilité (ex : accessible-slick pour les carrousels, qui est un fork accessible de Slick). Évite les plugins de type "barre d'accessibilité" ou overlay : ils ne corrigent pas le code source et ne mettent pas réellement en conformité. Teste tout composant tiers au lecteur d'écran avant production.

Questions fréquentes

Comment savoir si un composant du marché est accessible ?

Cherche une section "Accessibility" dans sa documentation. Teste-le avec NVDA ou VoiceOver. Des bibliothèques comme Radix UI ou Headless UI sont conçues avec l'accessibilité comme contrainte de départ.

aria-hidden="true" suffit-il à masquer un composant décoratif ?

aria-hidden="true" masque l'élément aux technologies d'assistance, mais ne le retire pas de la tabulation clavier. Attention : laisser des éléments focusables à l'intérieur d'un conteneur aria-hidden crée un focus fantôme (l'utilisateur reçoit le focus sur un élément signalé comme masqué). Pour masquer un bloc interactif entier, utilise l'attribut inert sur le conteneur, ou retire chaque élément de la tabulation avec tabindex="-1" en plus de les masquer.

Faut-il implémenter tous les raccourcis clavier du pattern ARIA ?

Oui pour les patterns courants (onglets, accordéon, menu). Certains utilisateurs de lecteurs d'écran s'appuient sur ces conventions et sont désorientés si elles ne sont pas respectées.

Cette erreur est-elle sur ton site ?

Lance un audit Mynto gratuit. Tu sauras en quelques minutes si ton site est concerné, sur quelles pages, et avec quel impact.

Script incompatible avec les technologies d'assistance