WCAG 2.1.1 : Clavier

Ce que signifie cette règle

WCAG 2.1.1 (Clavier) impose que chaque fonctionnalité d’une page web ou d’une application soit exploitable au moyen d’une interface clavier. Cela signifie que si un utilisateur peut cliquer sur un bouton, faire glisser un élément, survoler pour révéler un menu ou interagir avec tout autre élément à l’aide d’une souris, il doit pouvoir effectuer exactement la même action en utilisant uniquement des entrées clavier — généralement les touches Tab, Shift+Tab, Entrée, Espace et les flèches directionnelles.

Ce critère s’applique à tous les éléments interactifs : liens, boutons, contrôles de formulaire, widgets personnalisés, boîtes de dialogue modales, menus déroulants, accordéons, carrousels, sélecteurs de date, interfaces de glisser-déposer, interactions basées sur canvas et tout autre composant qui répond aux entrées utilisateur. Si un contenu exige que l’utilisateur trace un chemin de dessin (où le chemin lui-même constitue l’entrée, et pas seulement le point d’arrivée), il s’agit de la seule exception officiellement reconnue dans WCAG. En dehors de cette exception étroite, toute autre fonctionnalité doit être accessible au clavier.

Un succès signifie qu’un utilisateur n’utilisant que le clavier peut atteindre chaque élément interactif via la navigation avec Tab ou les flèches, l’activer avec Entrée ou Espace, et accomplir l’action prévue sans nécessiter de souris à aucun moment. Un échec se produit lorsque l’une des situations suivantes s’applique : un élément interactif ne reçoit aucun focus ; le focus est reçu mais l’élément ne peut pas être activé ; une fonction est déclenchée exclusivement par un événement souris tel que onmouseover ou ondblclick sans équivalent clavier ; ou un conteneur défilable n’est pas atteignable au clavier, piégeant le contenu à l’intérieur.

Il est important de distinguer WCAG 2.1.1 de WCAG 2.1.2 (Absence de piège au clavier). Le critère 2.1.1 garantit que les utilisateurs au clavier peuvent accéder à et utiliser tout le contenu ; le critère 2.1.2 garantit que les utilisateurs au clavier ne sont jamais bloqués à l’intérieur d’un composant. Les deux doivent être satisfaits pour une conformité complète au niveau A.

Pourquoi c’est important

L’accessibilité clavier n’est pas une préoccupation marginale. On estime que 1 adulte sur 4 aux États-Unis vit avec une forme de handicap, et les déficiences motrices — y compris des affections telles que la maladie de Parkinson, la sclérose en plaques, les lésions de la moelle épinière, les troubles musculo-squelettiques (TMS), les différences de membres et les tremblements — empêchent fréquemment les utilisateurs d’utiliser une souris standard ou un écran tactile. Ces utilisateurs dépendent entièrement des claviers, des commandes par contacteurs, des dispositifs sip-and-puff, des pointeurs de tête ou d’autres technologies d’assistance qui, en fin de compte, émulent l’entrée clavier au niveau du système d’exploitation.

Les personnes aveugles ou malvoyantes qui utilisent des lecteurs d’écran tels que NVDA, JAWS ou VoiceOver naviguent entièrement au clavier. Si un élément n’est pas atteignable au clavier, le lecteur d’écran ne l’annoncera jamais, rendant le contenu complètement invisible pour cet utilisateur. Selon l’Organisation mondiale de la Santé, au moins 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle de près ou de loin.

Considérons un scénario concret : une personne atteinte de polyarthrite rhumatoïde avancée aux deux mains visite une page de paiement d’un site de commerce en ligne. Le sélecteur de mode de paiement, développé sur mesure, est implémenté comme une série d’éléments <div> stylisés qui ne répondent qu’aux clics de souris. L’utilisateur peut atteindre le conteneur avec Tab, mais aucune option individuelle ne reçoit le focus et appuyer sur Entrée ne fait rien. Il ne peut pas finaliser l’achat. Il ne s’agit pas d’un simple désagrément — c’est une exclusion totale d’une transaction commerciale, et cela représente à la fois un risque juridique et un scénario de perte de revenus significative pour l’entreprise.

Au-delà du handicap, l’accessibilité clavier bénéficie aux utilisateurs avancés qui préfèrent les raccourcis clavier pour aller plus vite, aux utilisateurs dans des environnements d’entreprise ou gouvernementaux où l’usage de la souris est restreint par la politique, et aux utilisateurs de dispositifs d’entrée non standard. Elle est également positivement corrélée à des structures HTML propres et sémantiques que les moteurs de recherche analysent plus fiablement, contribuant à de meilleures performances SEO et à une meilleure maintenabilité à long terme de la base de code.

Règles axe-core associées

• scrollable-region-focusable : Cette règle vérifie si tout élément qui possède du contenu débordant (c’est-à-dire qui est défilable) est atteignable au clavier. Lorsqu’un conteneur a des propriétés CSS telles que overflow: auto ou overflow: scroll, les utilisateurs voyants à la souris peuvent le faire défiler avec une molette ou un trackpad. Les utilisateurs au clavier, en revanche, doivent pouvoir atteindre le conteneur avec Tab ou utiliser les flèches pour le faire défiler. La règle signale les régions défilables qui n’ont pas d’attribut tabindex et aucun élément enfant naturellement focalisable, ce qui signifie qu’un utilisateur n’utilisant que le clavier n’aurait aucun moyen d’accéder au contenu débordant. La détection automatisée est fiable ici car axe peut inspecter les styles calculés et l’arbre DOM pour identifier les éléments avec débordement défilable dépourvus de capacité de focus clavier.
• server-side-image-map : Cette règle signale l’utilisation de cartes d’images côté serveur — des éléments HTML <img> avec l’attribut ismap. Les cartes d’images côté serveur envoient au serveur les coordonnées brutes en pixels d’un clic de souris pour déterminer quel lien a été activé. Comme l’action dépend entièrement de coordonnées en pixels issues d’un dispositif de pointage, il n’existe aucun mécanisme équivalent au clavier. Contrairement aux cartes d’images côté client (qui utilisent les éléments <map> et <area> et peuvent être rendues accessibles au clavier), les cartes d’images côté serveur sont fondamentalement incompatibles avec une navigation uniquement au clavier. Axe signale tout élément <img ismap> comme un échec d’accessibilité clavier. Une vérification manuelle doit confirmer si la carte d’images est le seul moyen d’accéder à la navigation ou à la fonctionnalité sous-jacente.

Il est essentiel de comprendre que les outils automatisés comme axe-core ne peuvent détecter qu’un sous-ensemble des défaillances d’accessibilité clavier. De nombreuses violations nécessitent des tests manuels car elles impliquent des écouteurs d’événements JavaScript personnalisés, une gestion dynamique du focus ou des schémas d’interaction complexes qu’une analyse statique ne peut pas évaluer pleinement. Par exemple, un bouton implémenté comme un <div> avec un écouteur d’événement click peut recevoir le focus via tabindex='0' mais ne pas répondre aux pressions sur Entrée ou Espace — un échec qu’axe ne peut pas toujours détecter sans exécuter l’interaction.

Comment tester

1. Analyse automatisée avec axe DevTools ou Lighthouse : Installez l’extension de navigateur axe DevTools pour Chrome ou Firefox. Accédez à la page à tester et lancez une analyse de page complète. Filtrez les résultats pour les règles étiquetées avec wcag2a et keyboard. Recherchez spécifiquement les violations de scrollable-region-focusable et server-side-image-map. Dans Lighthouse (Chrome DevTools), exécutez un audit d’accessibilité et examinez la catégorie « Keyboard ». Notez que ces outils mettront en évidence les défaillances structurelles évidentes mais ne détecteront pas tous les problèmes liés aux widgets personnalisés.
2. Test manuel de navigation au clavier : Débranchez ou mettez complètement de côté votre souris. À partir de la barre d’adresse du navigateur, appuyez de manière répétée sur Tab pour avancer à travers tous les éléments focalisables de la page. Appuyez sur Shift+Tab pour revenir en arrière. Pour chaque élément interactif — liens, boutons, champs de saisie, menus déroulants personnalisés, modales, curseurs — vérifiez : (a) qu’il reçoit un indicateur de focus visible ; (b) qu’appuyer sur Entrée ou Espace l’active comme prévu ; (c) que toute boîte de dialogue ou tout panneau résultant peut également être parcouru et fermé au clavier. Utilisez les flèches à l’intérieur des widgets qui implémentent des modèles composites (menus, listes d’onglets, groupes de boutons radio, listes de sélection).
3. Test lecteur d’écran + clavier avec NVDA et Firefox : Lancez NVDA (gratuit, Windows) et ouvrez Firefox. Utilisez le mode navigation de NVDA (touches fléchées) pour lire la page et identifier tous les éléments interactifs. Passez en mode formulaire (Insert+Espace ou automatique sur les champs de formulaire) pour interagir avec les contrôles. Vérifiez que les widgets personnalisés annoncent leur rôle, leur état et leur nom, et que toute la fonctionnalité peut être réalisée sans souris. Testez les conteneurs défilables en essayant d’y accéder avec Tab et d’utiliser les flèches pour les faire défiler.
4. Test lecteur d’écran avec VoiceOver et Safari (macOS/iOS) : Activez VoiceOver (Commande+F5 sur macOS). Utilisez VO+Flèche droite pour naviguer linéairement dans la page. Utilisez Tab pour passer d’un élément interactif à l’autre. Confirmez que les régions défilables sont atteignables et qu’aucune fonctionnalité ne nécessite un geste de balayage ou une interaction au pointeur sans alternative accessible au clavier.
5. Test JAWS et Chrome : Avec JAWS en cours d’exécution, ouvrez Chrome et accédez à la page. Utilisez le curseur virtuel JAWS pour parcourir le contenu et la touche Tab pour passer d’un élément interactif à l’autre. Testez spécifiquement tout widget JavaScript personnalisé — accordéons, carrousels, boîtes de dialogue modales, listes de sélection personnalisées — en y accédant avec Tab et en tentant de les utiliser entièrement au clavier. Notez tout élément qui reçoit le focus mais ne peut pas être activé, ou toute fonctionnalité uniquement atteignable via un survol de la souris.
6. Test spécifique des régions défilables : Identifiez tous les conteneurs de la page avec des barres de défilement visibles ou qui contiennent plus de contenu que leur zone visible. Essayez d’atteindre chaque conteneur avec Tab. Si Tab ne déplace pas le focus à l’intérieur du conteneur et qu’il n’y a aucun élément enfant focalisable, le conteneur est probablement une défaillance d’accessibilité clavier. Essayez d’appuyer sur les flèches lorsque le conteneur ou un élément proche a le focus pour voir si le défilement est possible.

Comment corriger

Scénario 1 : Conteneur défilable — Incorrect

<!-- Scrollable div with no tabindex: keyboard users cannot scroll this content -->
<div style='height: 200px; overflow-y: auto;'>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Scénario 1 : Conteneur défilable — Correct

<!-- Adding tabindex='0' makes the container focusable so keyboard users
     can scroll it with arrow keys once it receives focus -->
<div
  tabindex='0'
  role='region'
  aria-label='Terms and Conditions'
  style='height: 200px; overflow-y: auto;'
>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Scénario 2 : Carte d’images côté serveur — Incorrect

<!-- ismap sends pixel coordinates to the server — no keyboard equivalent exists -->
<a href='/map-handler'>
  <img src='navigation-map.png' ismap alt='Site navigation map' />
</a>

Scénario 2 : Carte d’images côté serveur — Correct

<!-- Replace with a client-side image map using <map> and <area> elements.
     Each <area> is focusable and activatable by keyboard. -->
<img
  src='navigation-map.png'
  alt='Site navigation map'
  usemap='#site-nav'
/>
<map name='site-nav'>
  <area shape='rect' coords='0,0,100,50' href='/home' alt='Home' />
  <area shape='rect' coords='100,0,200,50' href='/about' alt='About Us' />
  <area shape='rect' coords='200,0,300,50' href='/contact' alt='Contact' />
</map>

Scénario 3 : Widget personnalisé utilisant uniquement des événements souris — Incorrect

<!-- div acting as a button with only onclick: keyboard users pressing Enter
     or Space will get no response -->
<div onclick='submitForm()'>Submit Order</div>

Scénario 3 : Widget personnalisé utilisant uniquement des événements souris — Correct

<!-- Option A: Use a native <button> — it handles keyboard activation natively -->
<button type='submit' onclick='submitForm()'>Submit Order</button>

<!-- Option B: If a custom element is required, add tabindex, role, and
     a keydown listener for Enter (13) and Space (32) -->
<div
  role='button'
  tabindex='0'
  onclick='submitForm()'
  onkeydown='if(event.key==="Enter"||event.key===" "){submitForm();}'
>
  Submit Order
</div>

Scénario 4 : Menu déroulant uniquement au survol — Incorrect

<!-- Menu only appears on CSS :hover — keyboard focus on the parent
     does not reveal the submenu -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <a href='/products'>Products</a>
      <ul class='dropdown'> <!-- only visible on :hover in CSS -->
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Scénario 4 : Menu déroulant uniquement au survol — Correct

<!-- Use a button to toggle the dropdown and manage aria-expanded.
     CSS shows the submenu when the button has aria-expanded='true'.
     Keyboard users press Enter/Space on the button to open the menu. -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <button
        aria-expanded='false'
        aria-controls='products-submenu'
        onclick='toggleMenu(this)'
      >
        Products
      </button>
      <ul id='products-submenu' hidden>
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Erreurs courantes

• Utiliser onclick comme seul gestionnaire d’événement sur un élément non natif sans ajouter de gestionnaire onkeydown ou onkeyup correspondant — les clics de souris déclenchent onclick mais l’activation au clavier sur un <div> ou un <span> ne le fait pas.
• Ajouter tabindex='0' à un élément interactif personnalisé mais oublier d’ajouter role='button' (ou un rôle approprié), ce qui signifie que les lecteurs d’écran ne communiquent pas la fonction de l’élément à l’utilisateur.
• Construire une navigation déroulante qui repose exclusivement sur la pseudo-classe CSS :hover sans bascule clavier pilotée par JavaScript, rendant les sous-menus invisibles et inatteignables pour les utilisateurs au clavier.
• Implémenter des interfaces de glisser-déposer — listes triables, tableaux de type kanban, zones de dépôt de fichiers — sans mécanisme alternatif accessible au clavier, comme des commandes de déplacement déclenchées au clavier ou un contrôle de réorganisation séparé.
• Créer des conteneurs défilables (tels que des boîtes de conditions d’utilisation, des fenêtres de chat ou des tableaux de données dans des wrappers de hauteur fixe) sans tabindex='0', empêchant les utilisateurs au clavier de faire défiler pour voir tout le contenu.
• Utiliser <img ismap> pour des composants de navigation hérités de bases de code anciennes sans les remplacer par des cartes d’images côté client ou des liens de navigation standard.
• Appliquer tabindex='-1' à des éléments interactifs pour les retirer de l’ordre naturel de Tab sans fournir de stratégie de gestion programmatique du focus, ce qui aboutit à des contrôles définitivement inatteignables au clavier.
• Déclencher une fonctionnalité exclusivement sur les événements mouseenter, mouseleave ou mousemove (info-bulles, aperçus, menus contextuels) sans alternatives équivalentes d’événements focus, blur ou clavier.
• Supposer qu’une boîte de dialogue modale gère automatiquement le focus — ne pas déplacer le focus dans la boîte de dialogue lorsqu’elle s’ouvre et ne pas le renvoyer à l’élément déclencheur lorsqu’elle se ferme, laissant les utilisateurs au clavier désorientés dans la page.
• Définir pointer-events: none en CSS sur un élément qui devrait être accessible au clavier, ce qui, bien que n’affectant pas directement le comportement clavier, est souvent associé à des schémas JavaScript qui bloquent également l’interaction au clavier.

Lien avec la réglementation d’accessibilité de la Turquie

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences obligatoires en matière d’accessibilité web alignées sur WCAG 2.1 niveau AA. WCAG 2.1.1 (Clavier) est un critère de niveau A, ce qui le place dans la catégorie de priorité la plus élevée en matière de conformité requise. La conformité de niveau A constitue le socle minimal absolu — si un site ne respecte pas les critères de niveau A, il est considéré comme non accessible, quels que soient les autres progrès réalisés.

En vertu de la circulaire, les délais de conformité sont différenciés selon le type d’entité : les institutions publiques et organismes gouvernementaux doivent atteindre la conformité dans un délai de un an à compter de la date de publication de la circulaire, tandis que les entités du secteur privé couvertes par la réglementation disposent de deux ans pour se mettre en conformité.

Les entités couvertes par la circulaire présidentielle 2025/10 incluent un large éventail de services numériques turcs : plateformes de commerce en ligne, institutions publiques et ministères, banques et institutions financières, hôpitaux et prestataires de soins de santé, entreprises de télécommunications comptant 200,000 abonnés ou plus, agences de voyage agréées, entreprises de transport privées et écoles privées autorisées par le ministère de l’Éducation nationale (MoNE).

Pour toutes ces entités, le non-respect de WCAG 2.1.1 signifie que les utilisateurs dépendants du clavier — y compris les citoyens avec des handicaps moteurs, les personnes âgées et les utilisateurs de lecteurs d’écran — ne peuvent pas accéder à leurs services numériques essentiels. Il s’agit d’une violation directe de la réglementation. Concrètement, un site de commerce en ligne dont le parcours de paiement ne peut pas être complété au clavier, ou un portail patient d’hôpital où la prise de rendez-vous nécessite une interaction à la souris, serait en infraction avec les exigences de la circulaire.

Les organisations soumises à la circulaire devraient réaliser un audit d’accessibilité clavier comme première étape de leur programme de remédiation en accessibilité. Parce que les défaillances de WCAG 2.1.1 sont souvent d’ordre architectural — enracinées dans le choix des éléments HTML, les schémas de liaison d’événements et les paramètres par défaut des frameworks de composants — leur correction peut nécessiter des modifications au niveau du code plutôt que de simples ajustements de configuration. Le SDK d’overlay d’Accsible peut aider à mettre en évidence et à corriger les lacunes courantes d’accessibilité clavier au niveau JavaScript, mais les équipes doivent également mettre en œuvre des corrections structurelles dans leur code source pour atteindre une conformité robuste et vérifiable qui satisfera à l’examen réglementaire.