RGAA 7.1 — Chaque script est-il, quand c'est nécessaire, compatible avec les technologies d'assistance ?

Composants interactifs sans ARIA

Le problème

Les composants interactifs personnalisés sans attributs ARIA sont des éléments d'interface construits avec des <div>, <span> ou autres éléments non sémantiques qui se comportent comme des boutons, onglets, accordéons, menus déroulants ou autres widgets, mais qui ne communiquent pas leur rôle, état et propriétés aux technologies d'assistance. Le critère RGAA 7.1 (correspondant au WCAG 4.1.2, niveau A) exige que chaque composant d'interface compatible avec les technologies d'assistance ait un nom, un rôle et des propriétés accessibles.

Les exemples typiques incluent : des <div onclick> utilisés comme boutons sans role="button", des onglets construits avec des <li> sans role="tab" et aria-selected, des accordéons sans aria-expanded, des menus déroulants sans role="menu" et aria-haspopup, des modales sans role="dialog" et aria-modal, et des sliders personnalisés sans role="slider" et aria-valuenow.

Les frameworks JavaScript modernes (React, Vue, Angular) facilitent la création de composants personnalisés, mais les développeurs oublient souvent d'ajouter les attributs ARIA nécessaires. Les bibliothèques de composants comme Headless UI, Radix UI ou React Aria ont été créées spécifiquement pour résoudre ce problème en fournissant des composants accessibles par défaut.

Impact sur les utilisateurs

Pour les utilisateurs de lecteurs d'écran, un composant personnalisé sans ARIA est invisible ou incompréhensible. Un <div onclick> est annoncé comme un simple « groupe » sans aucune indication qu'il est cliquable. L'utilisateur ne sait pas qu'il peut interagir avec cet élément, quelle action il effectue, ni dans quel état il se trouve (ouvert/fermé, sélectionné, développé).

Les utilisateurs de clavier sont aussi affectés : les <div> et <span> ne sont pas focalisables par défaut et ne répondent pas à la touche Entrée ou Espace. Sans tabindex et gestion du clavier, ces composants sont inaccessibles au clavier.

Le problème est systémique dans les applications web modernes qui construisent des interfaces complexes avec des composants personnalisés. Un tableau de bord avec 20 composants custom sans ARIA est effectivement inutilisable pour les technologies d'assistance.

Votre site a-t-il ce problème ?

106 critères RGAA analysés en 5 minutes par notre IA.

Testez votre site gratuitement

Exemple de code

Avant (non conforme)

<!-- "Bouton" en div -->
<div class="btn" onclick="submit()">
  Envoyer
</div>

<!-- Onglets sans ARIA -->
<div class="tabs">
  <div class="tab active" onclick="showTab(1)">Profil</div>
  <div class="tab" onclick="showTab(2)">Paramètres</div>
</div>

<!-- Accordéon sans ARIA -->
<div class="accordion-header" onclick="toggle()">
  FAQ
</div>
<div class="accordion-body" style="display: none;">
  Contenu...
</div>

Après (conforme)

<!-- Vrai bouton HTML -->
<button type="button" onclick="submit()">
  Envoyer
</button>

<!-- Onglets avec ARIA -->
<div role="tablist">
  <button role="tab" aria-selected="true"
    aria-controls="panel-1" id="tab-1">Profil</button>
  <button role="tab" aria-selected="false"
    aria-controls="panel-2" id="tab-2">Paramètres</button>
</div>
<div role="tabpanel" id="panel-1"
  aria-labelledby="tab-1">...</div>

<!-- Accordéon avec ARIA -->
<h3>
  <button aria-expanded="false"
    aria-controls="faq-content">FAQ</button>
</h3>
<div id="faq-content" role="region" hidden>
  Contenu...
</div>

Comment Scrutia détecte ce problème

Scrutia identifie les composants interactifs personnalisés en détectant les éléments non sémantiques (<div>, <span>) avec des gestionnaires d'événements (onclick, onkeydown) ou des comportements interactifs (toggle de visibilité, changement de classe). Il vérifie la présence des rôles ARIA appropriés, des propriétés d'état (aria-expanded, aria-selected, aria-pressed), et de l'accessibilité clavier (tabindex, gestion Enter/Space). Le rapport identifie le pattern de design et propose le balisage ARIA complet.

Questions fréquentes

Quand utiliser un élément HTML natif vs ARIA ?

La première règle d'ARIA est : si un élément HTML natif peut remplir le rôle, utilisez-le au lieu d'ARIA. Un <button> est toujours préférable à un <div role='button'>. ARIA doit être réservé aux widgets qui n'ont pas d'équivalent HTML natif (onglets, accordéons, trees, etc.).

Quels sont les rôles ARIA les plus courants ?

button, tab/tablist/tabpanel, dialog, menu/menuitem, slider, switch, tree/treeitem, alert, alertdialog, progressbar, combobox. Chaque rôle a des propriétés d'état associées qui doivent être mises à jour dynamiquement (aria-expanded, aria-selected, etc.).

Les bibliothèques de composants React sont-elles accessibles ?

Cela dépend de la bibliothèque. Headless UI, Radix UI, React Aria et Reach UI sont conçues pour l'accessibilité. Material UI et Ant Design ont un support partiel. Les composants personnalisés ou les bibliothèques non spécialisées nécessitent souvent un travail ARIA supplémentaire.

Comment tester l'accessibilité d'un composant ARIA ?

Testez avec un lecteur d'écran (NVDA, VoiceOver) pour vérifier que le rôle, le nom et l'état sont annoncés correctement. Testez au clavier pour vérifier la navigation (Tab, Entrée, Espace, flèches). Vérifiez l'arbre d'accessibilité dans les DevTools. Scrutia automatise ces vérifications.

Votre site a-t-il ce problème ?

Scrutia audite votre site sur 106 critères RGAA en 5 minutes. Navigation clavier, composants ARIA, focus visible, contrastes, et bien plus.

Lancer un audit gratuit