RGAA 7.3 — Chaque script est-il contrôlable par le clavier et par tout dispositif de pointage ?

Navigation au clavier impossible

Le problème

La navigation au clavier est un pilier fondamental de l'accessibilité web. Le critère 7.3 du RGAA exige que chaque fonctionnalité déclenchée par un script soit utilisable au clavier, sans dépendre exclusivement de la souris ou du toucher. Pourtant, un nombre considérable de sites web modernes construisent des interactions qui ne fonctionnent qu'à la souris : menus déroulants qui ne s'ouvrent qu'au survol (hover), boutons construits avec des div ou span au lieu de button, carrousels sans contrôles clavier, modales qui ne se ferment pas avec Échap, onglets sans support des flèches directionnelles. Quand un élément interactif n'est pas accessible au clavier, l'utilisateur qui dépend du clavier se retrouve bloqué. Il ne peut pas cliquer sur ce bouton, ouvrir ce menu, fermer cette modale, ou naviguer dans ce carrousel. Son parcours sur le site s'arrête net. Ce problème est particulièrement insidieux car il est invisible pour les développeurs qui testent exclusivement à la souris. Un bouton en div peut sembler fonctionner parfaitement — il a le bon visuel, le bon curseur, le bon comportement au clic. Mais il est totalement transparent pour le clavier : il ne reçoit pas le focus avec Tab, ne se déclenche pas avec Entrée, et n'est pas annoncé comme un bouton par les lecteurs d'écran. Les frameworks JavaScript modernes (React, Vue, Angular) aggravent souvent ce problème en encourageant l'utilisation de div avec des onClick au lieu de balises sémantiques HTML natives. Un button HTML est nativement focusable, activable au clavier et annoncé correctement par les lecteurs d'écran. Un div avec un onClick ne fait rien de tout cela sans un travail supplémentaire conséquent (ajout de tabindex, role, gestion du keydown). La solution est presque toujours la même : utiliser les éléments HTML natifs (button, a, input, select) plutôt que de réinventer la roue avec des div.

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

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

Testez votre site gratuitement

Impact sur les utilisateurs

Les personnes en situation de handicap moteur qui ne peuvent pas utiliser une souris dépendent entièrement du clavier (ou d'un dispositif de saisie émulant le clavier, comme un contacteur, une commande vocale, ou un eye-tracker). Pour ces utilisateurs, un site non navigable au clavier est un site inutilisable — aussi inaccessible qu'un bâtiment sans rampe pour un utilisateur de fauteuil roulant. Les personnes aveugles utilisant un lecteur d'écran naviguent aussi exclusivement au clavier. Si un élément interactif ne peut pas recevoir le focus, il n'existe tout simplement pas pour elles. Les utilisateurs expérimentés et les power users utilisent aussi le clavier par préférence pour sa rapidité. Les développeurs, les professionnels de la saisie de données, et toute personne ayant une tendinite temporaire au poignet sont aussi affectés. En France, selon l'enquête Handicap-Santé de l'INSEE, environ 850 000 personnes ont un handicap moteur des membres supérieurs qui peut rendre l'utilisation d'une souris difficile ou impossible.

Exemple de code

Avant (non conforme)
<div class="menu-toggle" onclick="toggleMenu()">
  Menu
</div>
<div class="dropdown" onmouseover="showDropdown()">
  <span>Services</span>
  <div class="dropdown-content" style="display:none">
    <div onclick="navigate('/conseil')">Conseil</div>
    <div onclick="navigate('/audit')">Audit</div>
  </div>
</div>
Après (conforme)
<button type="button" class="menu-toggle" onclick="toggleMenu()">
  Menu
</button>
<div class="dropdown">
  <button type="button" aria-expanded="false" aria-haspopup="true"
    onclick="toggleDropdown(this)" onkeydown="handleDropdownKey(event)">
    Services
  </button>
  <ul role="menu" class="dropdown-content" hidden>
    <li role="menuitem"><a href="/conseil">Conseil</a></li>
    <li role="menuitem"><a href="/audit">Audit</a></li>
  </ul>
</div>

Questions fréquentes

Comment tester la navigation clavier de mon site ?
Débranchez votre souris (ou ne la touchez plus) et essayez d'utiliser votre site uniquement au clavier. Utilisez Tab pour avancer, Shift+Tab pour reculer, Entrée ou Espace pour activer un élément, Échap pour fermer une modale ou un menu, et les flèches directionnelles dans les menus et onglets. Si vous êtes bloqué à un endroit ou si vous ne voyez pas le focus, c'est un problème d'accessibilité.
Pourquoi ne pas utiliser tabindex pour rendre un div focusable ?
Ajouter tabindex="0" à un div le rend focusable mais ne lui donne ni le rôle sémantique de bouton, ni la capacité de se déclencher avec Entrée ou Espace. Il faut aussi ajouter role="button", un gestionnaire onkeydown, et gérer l'état aria-pressed. C'est beaucoup de code pour réinventer ce que la balise <button> fait nativement en une ligne.
Les menus au survol (hover) sont-ils accessibles ?
Les menus qui ne s'ouvrent qu'au survol de la souris (CSS :hover ou JavaScript onmouseover) ne sont pas accessibles au clavier. Il faut soit les ouvrir aussi au focus (:focus-within en CSS) et au clic, soit les remplacer par un pattern de menu conforme au WAI-ARIA Authoring Practices avec gestion complète du clavier (Entrée pour ouvrir, Échap pour fermer, flèches pour naviguer).
Les carrousels doivent-ils être navigables au clavier ?
Oui. Les carrousels doivent fournir des boutons Précédent/Suivant focusables et activables au clavier, ainsi qu'un mécanisme de pause si le défilement est automatique. Les utilisateurs de clavier doivent pouvoir interagir avec le contenu de chaque diapositive. Le carrousel ne doit pas piéger le focus.

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