Chaque script est-il contrôlable par le clavier et par tout dispositif de pointage (hors cas particuliers) ?
Un utilisateur qui navigue au clavier, qu’il soit tétraplégique, qu’il utilise un clavier adapté ou qu’il préfère simplement ne pas utiliser de souris, doit pouvoir déclencher chaque fonctionnalité JavaScript de votre page. Si une action n’est accessible qu’à la souris, cet utilisateur est bloqué. Pas de souris ? Pas d’accès.
Ce critère couvre deux exigences distinctes. La première : chaque élément portant un gestionnaire d’événements JavaScript doit être atteignable et activable au clavier, et utilisable avec tout dispositif de pointage (test 7.3.1). La seconde : aucun script ne doit supprimer le focus clavier d’un élément qui vient de le recevoir (test 7.3.2).
Le piège classique : un <div> ou un <span> avec un onclick. Il réagit bien à la souris, mais n’est pas dans l’ordre de tabulation et ne répond pas à la touche Entrée. L’utilisateur clavier ne peut tout simplement pas l’atteindre. La solution la plus simple reste d’utiliser les éléments HTML natifs — <button> pour les actions, <a href> pour les liens — qui gèrent la navigation clavier sans aucun JavaScript supplémentaire.
2 tests pour vérifier que chaque script est utilisable au clavier
Accessibilité clavier et pointeur des scripts
- Identifiez tous les éléments portant un gestionnaire d’événements JavaScript :
onclick,onmouseover,onmouseout,onfocus,onblur,onkeydown,ontouchstart, etc. - Pour chaque élément, vérifiez l’accessibilité clavier :
- L’élément est-il atteignable avec Tab ?
- Pour une action simple (ouverture, sélection) : s’active-t-il avec Entrée ?
- Pour une action complexe (slider, menu arborescent) : fonctionne-t-il avec les touches de direction ?
- Si l’élément lui-même n’est pas accessible au clavier, vérifiez qu’un autre élément de la page permet de réaliser la même action au clavier.
- Vérifiez que l’élément est utilisable avec tout dispositif de pointage (souris, écran tactile, stylet).
- Si ce n’est pas le cas, vérifiez qu’un élément alternatif accessible au pointage est présent dans la page.
- Le test est validé si la condition de l’étape 2 ou 3 est remplie, ET si la condition de l’étape 4 ou 5 est remplie.
Absence de suppression du focus par script
- Naviguez au clavier (Tab) sur l’ensemble de la page et activez chaque élément focusable l’un après l’autre.
- Pour chaque élément : après avoir reçu le focus, vérifiez que l’indicateur visuel de focus reste visible et que le focus n’est pas immédiatement déplacé ou supprimé par un script.
- Confirmez en inspectant le JavaScript : cherchez les appels
blur()déclenchés automatiquement, ou lesfocus()qui transfèrent le focus sans action explicite de l’utilisateur. - Le test est validé si aucun script ne supprime le focus sur un élément après que l’utilisateur l’a atteint.
Exemples
❌ Non conforme : Pseudo-bouton <div> déclenché uniquement à la souris
<div class="btn-open" onclick="toggleMenu()">
Ouvrir le menu
</div>Ce <div> n’est pas dans l’ordre de tabulation naturel du navigateur et ne répond pas aux événements clavier. Un utilisateur naviguant avec Tab ne peut pas l’atteindre, et même s’il y arrivait, appuyer sur Entrée ne déclencherait rien. La fonctionnalité « ouvrir le menu » est totalement inaccessible sans souris.
✅ Conforme : Bouton natif : accessible clavier et pointage sans JavaScript supplémentaire
<button type="button" onclick="toggleMenu()" aria-expanded="false" aria-controls="nav-menu">
Ouvrir le menu
</button>Un <button> est nativement focusable (Tab), activable au clavier (Entrée et Espace) et utilisable à la souris ou au toucher. Aucun JavaScript de gestion clavier n’est nécessaire. L’attribut aria-expanded informe en plus les lecteurs d’écran de l’état ouvert ou fermé du menu.
✅ Conforme : <div> rendu accessible avec tabindex, role et gestionnaire clavier
<div
class="card-action"
tabindex="0"
role="button"
aria-pressed="false"
onclick="toggleFavorite(this)"
onkeydown="if(event.key==='Enter'||event.key===' '){event.preventDefault();toggleFavorite(this)}">
Ajouter aux favoris
</div>Quand un élément HTML natif ne convient pas au design, il est possible de rendre un <div> accessible : tabindex="0" l’intègre dans l’ordre de tabulation, role="button" informe les technologies d’assistance de son rôle, et le gestionnaire onkeydown ajoute la réponse aux touches Entrée et Espace. La solution avec <button> reste préférable — ici, c’est un contournement acceptable, pas un modèle à généraliser.
Astuces et pièges
⚠️ onmouseover/onmouseout sans équivalents clavier
Les événements mouseover et mouseout ne se déclenchent pas lors de la navigation clavier. Si une info-bulle ou un sous-menu s’affiche uniquement au survol, les utilisateurs clavier n’y accèdent jamais. La correction : doublez systématiquement ces événements avec onfocus et onblur, ou gérez les deux états en CSS avec :hover et :focus-within dans la même règle.
⚠️ Supprimer le focus avec element.blur() pour des raisons esthétiques
Appeler blur() dans un gestionnaire d’événement — pour éviter un contour de focus jugé inesthétique ou pour prévenir un double-clic — supprime le focus et désoriente totalement l’utilisateur clavier : il ne sait plus où il se trouve dans la page. C’est l’erreur visée par le test 7.3.2. Redéfinissez le style du focus en CSS, ne le supprimez pas en JavaScript.
💡 Les éléments HTML natifs sont votre meilleure protection
<button>, <a href>, <input>, <select> et <textarea> sont focusables et activables au clavier par défaut, sans une ligne de JavaScript supplémentaire. Chaque fois que vous les remplacez par un <div> ou un <span> pour des raisons de style, vous créez une dette d’accessibilité. Stylisez les éléments natifs plutôt que de recréer leur comportement.
⚠️ Widgets complexes : les touches de direction sont acceptées
Pour les composants interactifs avancés (slider de prix, carrousel, menu arborescent), la touche Entrée seule ne suffit pas et n’est pas attendue. Le RGAA accepte l’usage des touches de direction pour ces cas. Référez-vous aux patterns du W3C ARIA Authoring Practices Guide (APG) pour connaître le comportement clavier attendu selon le type de widget.
⚠️ Fonctionnalités sans équivalent clavier possible
Le critère prévoit des cas particuliers : les fonctionnalités dont la réalisation est impossible au clavier par nature, comme le dessin à main levée ou un geste multi-touch, sont exemptées. Cette exception est stricte et ne s’applique pas aux menus, boutons, accordéons ou autres composants courants. Elle ne dispense pas non plus de proposer une alternative accessible quand la fonctionnalité est indispensable au service.
💡 Test rapide : cinq minutes sans souris
Débranchez la souris ou désactivez le trackpad, rechargez la page et tentez d’utiliser toutes les fonctionnalités interactives uniquement au clavier. Chaque blocage est une non-conformité potentielle au critère 7.3. Ce test informel détecte les problèmes évidents avant même d’ouvrir les outils de développement, et donne une expérience directe de ce que vivent les utilisateurs concernés.
Questions fréquentes
Quelles limites d'accessibilité clavier pose un onclick sur un <div> en RGAA ?
Non. onclick sur un <div> répond à la souris, mais le <div> n’est pas dans le flux de tabulation et Entrée n’y déclenche rien nativement. Pour qu’un <div> soit accessible au clavier, trois attributs sont obligatoires : tabindex="0" pour l’inclure dans le flux, role="button" (ou rôle approprié) pour les technologies d’assistance, et un gestionnaire onkeydown sur Entrée et Espace. Solution directe : remplacez le <div> par un <button> et le problème disparaît.
Comment auditer le critère 7.3 RGAA sans analyser chaque ligne de JavaScript ?
Débranchez la souris et naviguez uniquement au clavier. Tab pour avancer, Shift+Tab pour reculer, Entrée pour activer. Toute action disponible à la souris doit l’être aussi au clavier. Pour identifier les éléments avec gestionnaires d’événements, les DevTools (Elements → Event Listeners) listent tous les handlers attachés. Concentrez-vous sur les composants riches : menus déroulants, carrousels, onglets, fenêtres modales. Ce sont eux qui échouent le plus souvent.
Comment rendre accessible au clavier un carrousel contrôlé par swipe selon RGAA ?
Oui, sauf si le swipe constitue une interaction sans équivalent standard, ce qui est rarement le cas pour un carrousel. Les boutons Précédent/Suivant accessibles au clavier constituent l’alternative attendue. Le swipe peut rester comme geste supplémentaire pour les utilisateurs tactiles, mais la navigation doit être réalisable sans lui. L’exception du critère 7.3 ne couvre que les interactions physiquement impossibles à traduire, comme le dessin libre ou la pression variable.
Pourquoi la perte du focus visuel constitue-t-elle une violation du critère 7.3 RGAA ?
Pas du critère 7.3.2. Ce test vérifie que le focus n’est pas supprimé par JavaScript, c’est-à-dire que l’élément reste réellement focusé dans le DOM. La visibilité de l’indicateur relève du critère RGAA 10.7. Les deux problèmes coexistent souvent : un outline: none masque le focus visuellement pendant qu’un .blur() le supprime techniquement. Signalez chacun sous son propre critère dans votre rapport.
Comment rendre accessible au clavier un composant complexe comme un slider ou un datepicker ?
Suivez les patterns décrits dans l’ARIA Authoring Practices Guide (APG). Un slider (role="slider") doit répondre aux flèches directionnelles, Début et Fin. Un datepicker doit permettre la navigation dans le calendrier avec les flèches et la validation avec Entrée. Chaque rôle ARIA a ses interactions clavier définies. Implémentez-les manuellement ou utilisez une bibliothèque qui les respecte, comme Radix UI, Headless UI ou Adobe React Aria.