WCAG 2.1.3 : Clavier (sans exception)

Ce que signifie cette règle

WCAG 2.1.3 — Clavier (sans exception) est un critère de succès de niveau AAA dans WCAG 2.1 et 2.2 qui étend WCAG 2.1.1 (Clavier, niveau A) en supprimant toutes les dérogations. Plus précisément, il stipule : Toutes les fonctionnalités du contenu sont utilisables au moyen d'une interface clavier sans exiger de temporisation spécifique pour les frappes individuelles. La distinction essentielle par rapport à 2.1.1 est l’absence de la clause d’exception qui exonère les fonctionnalités dont la fonction sous-jacente requiert une saisie dépendant de la trajectoire du mouvement de l’utilisateur, et pas seulement des points d’arrivée.

En vertu de 2.1.1, les développeurs peuvent légitimement exclure du support clavier des fonctionnalités comme les zones de dessin à main levée, les outils de peinture basés sur des gestes ou les interfaces de glisser sensibles au chemin, parce que la trajectoire exacte du pointeur de l’utilisateur détermine le résultat. WCAG 2.1.3 supprime entièrement cette exception. Selon ce critère, chaque fonction, sans exception—y compris le dessin, le glisser-déposer, les gestes dépendant du chemin et toute interaction qui s’est historiquement appuyée sur le mouvement du pointeur—doit être accessible au clavier. Cela signifie que les développeurs doivent fournir des mécanismes alternatifs au clavier (par exemple, une barre d’outils accessible avec des outils de formes, des modes de dessin contrôlés au clavier ou des alternatives de saisie basées sur des formulaires) même pour les tâches à main levée ou dépendantes du chemin.

Un succès exige que chaque opération sur la page puisse être initiée, parcourue et complétée en utilisant uniquement le clavier. Cela inclut la gestion du focus, les boîtes de dialogue modales, le réagencement par glisser-déposer, les curseurs personnalisés, les outils de dessin sur canvas, les interactions avec des cartes, la navigation dans les carrousels et les contrôles de lecture vidéo. Il ne doit y avoir aucun piège au clavier (également couvert par 2.1.2), aucune fonction qui ne puisse être déclenchée que par un clic, un survol ou des gestes tactiles sans chemin équivalent au clavier, et aucune dépendance aux trajectoires du pointeur de la souris.

Un échec se produit lorsque n’importe quelle fonctionnalité—quelle que soit sa niche ou son caractère secondaire apparent—ne peut pas être atteinte ou complétée uniquement au clavier. Comme ce critère ne comporte aucune exception, même une seule fonction non accessible au clavier constitue un échec complet, ce qui en fait l’une des exigences les plus contraignantes de WCAG.

Pourquoi c’est important

L’accessibilité au clavier est fondamentale pour les personnes ayant des limitations motrices qui ne peuvent pas utiliser un dispositif de pointage. Les personnes atteintes, par exemple, de la maladie de Parkinson, de tétraplégie, de paralysie cérébrale, de troubles musculo-squelettiques liés aux mouvements répétitifs ou de différences de membres s’appuient souvent exclusivement sur un clavier physique, un dispositif à contacteur, un contrôleur par souffle et aspiration ou une technologie de suivi oculaire qui émule l’entrée clavier. Selon l’Organisation mondiale de la Santé, environ 1,3 milliard de personnes dans le monde vivent avec une forme de handicap significatif, et les limitations motrices ou physiques représentent une part substantielle de cette population. Rien qu’en Turquie, les données de l’Institut turc de statistique (TÜİK) indiquent que plus de 8,5 millions de personnes déclarent au moins une forme de limitation fonctionnelle.

Au-delà du handicap moteur, l’accessibilité au clavier bénéficie aux personnes aveugles ou malvoyantes qui naviguent avec des lecteurs d’écran tels que NVDA, JAWS ou VoiceOver—tous reposant sur des commandes clavier pour parcourir et interagir avec le contenu web. Les personnes présentant des troubles photosensibles peuvent éviter les écrans tactiles, et les personnes ayant des handicaps cognitifs profitent souvent de la navigation prévisible et linéaire qu’offre l’interaction au clavier.

Considérons un scénario concret du monde réel : une plateforme de conception graphique qui propose un outil de dessin vectoriel à main levée. En vertu de WCAG 2.1.1, cet outil pourrait être exempté parce que la trajectoire du pointeur définit la forme. En vertu de WCAG 2.1.3, la plateforme doit fournir une alternative—par exemple une bibliothèque de formes, une série de points d’ancrage contrôlés au clavier ou un éditeur de chemin SVG basé sur du texte—afin qu’une personne ayant une limitation motrice puisse tout de même créer des illustrations vectorielles sans souris. Ne pas le faire exclut un segment significatif de professionnels de la création qui dépendent d’un accès uniquement au clavier.

Du point de vue de l’ergonomie et du SEO, les interfaces correctement accessibles au clavier présentent généralement une gestion du focus plus propre, un ordre de tabulation plus logique et des hiérarchies DOM bien structurées—autant d’éléments qui contribuent à une meilleure explorabilité par les moteurs de recherche et à une expérience utilisateur de meilleure qualité pour tout le monde, y compris les utilisateurs avancés qui préfèrent les raccourcis clavier pour gagner en rapidité.

Règles Axe-core associées

WCAG 2.1.3 nécessite des tests manuels. Contrairement à de nombreux critères WCAG, les outils automatisés ne peuvent pas détecter de manière fiable les violations de ce critère parce que :

• La détection de fonctionnalités dépendantes du chemin dépasse l’analyse statique : Axe-core et Lighthouse inspectent le DOM à la recherche de motifs structurels—tabindex manquant, attributs role absents ou gestion du focus défaillante—mais ils ne peuvent pas simuler un utilisateur essayant chaque fonction d’une page et déterminer si une alternative clavier existe. Un élément canvas peut être présent dans le DOM sans attributs ARIA, alors qu’une barre d’outils clavier accessible à proximité peut satisfaire pleinement 2.1.3. À l’inverse, un bouton apparemment normal peut déclencher une action JavaScript qui lance elle-même un composant utilisable uniquement à la souris, que les outils automatisés ne signaleront jamais. L’équivalence fonctionnelle des alternatives clavier par rapport aux parcours à la souris nécessite un jugement humain.
• Aucune règle axe-core dédiée ne correspond à 2.1.3 : Les règles axe les plus proches—telles que scrollable-region-focusable (qui vérifie si les zones de contenu défilant peuvent recevoir le focus clavier) et tabindex (qui signale les valeurs tabindex positives perturbant l’ordre naturel du focus)—traitent des préoccupations connexes mais plus restreintes relevant de 2.1.1 et 2.4.3. Elles n’évaluent pas et ne peuvent pas évaluer si toute fonctionnalité, y compris les opérations sensibles au chemin, dispose d’un équivalent clavier.
• Les audits de widgets interactifs nécessitent une interaction à l’exécution : Les composants personnalisés de glisser-déposer, les éditeurs basés sur canvas et les carrousels pilotés par gestes ne révèlent leur inaccessibilité au clavier que lorsqu’un testeur tente réellement de les utiliser sans souris. L’analyse statique du DOM par axe-core ne peut pas déclencher les écouteurs d’événements, observer la perte de focus lors d’opérations asynchrones ou évaluer si une opération de glisser peut être réalisée via les flèches du clavier et Entrée/Espace.
• Ce qu’il faut rechercher lors d’un audit manuel : Les testeurs doivent rechercher spécifiquement les éléments canvas utilisés pour le dessin ou l’interaction, les listes ou zones de dépôt par glisser-déposer, les contrôles de cartes ou de visualisation de données personnalisés, les curseurs dépendant du temps et tout composant qui répond aux événements mousemove, pointermove ou aux gestes tactiles sans gestionnaires d’événements clavier correspondants.

Comment tester

1. Exécuter une analyse automatisée de base : Utilisez axe DevTools (extension de navigateur ou CLI) ou Google Lighthouse sur votre page pour identifier les échecs d’accessibilité clavier évidents—éléments focalisables manquants, pièges au clavier ou éléments avec pointer-events: none qui devraient être interactifs. Bien que ces outils ne détectent pas directement les violations de 2.1.3, ils mettent en évidence des problèmes connexes et établissent une base saine avant le début des tests manuels.
2. Cataloguer toutes les fonctionnalités interactives : Avant de tester, créez un inventaire complet de chaque composant interactif de la page : boutons, liens, formulaires, modales, accordéons, carrousels, cartes, outils canvas, zones de glisser-déposer, listes déroulantes personnalisées, sélecteurs de date, lecteurs vidéo et tout widget qui répond aux événements de souris ou tactiles. Cet inventaire devient votre liste de contrôle de test.
3. Test de navigation au clavier uniquement : Débranchez ou désactivez votre souris. Utilisez Tab et Shift+Tab pour déplacer le focus, Entrée et Espace pour activer les contrôles, les flèches pour les widgets composites (menus, curseurs, onglets, groupes de boutons radio) et Échap pour fermer les boîtes de dialogue. Essayez de réaliser chaque fonction de votre liste d’inventaire. Notez toute fonction que vous ne pouvez pas initier, compléter ou quitter en utilisant uniquement le clavier.
4. Test avec lecteur d’écran NVDA + Firefox : Lancez NVDA (Windows) avec Firefox. Naviguez à l’aide du curseur virtuel (H pour les titres, B pour les boutons, F pour les champs de formulaire, Tab pour les éléments interactifs). Essayez chaque fonction. Écoutez le rôle, le nom et l’état annoncés. Identifiez toute zone interactive qui est inaccessible ou ne produit aucune annonce audible.
5. Test avec lecteur d’écran JAWS + Chrome : Utilisez JAWS sous Windows avec Chrome. Utilisez le curseur virtuel de JAWS et le mode formulaires (bascule avec Entrée). Vérifiez que toutes les fonctionnalités peuvent être actionnées et que le focus est correctement géré après chaque interaction—en particulier après l’ouverture de boîtes de dialogue modales ou le chargement de contenu AJAX.
6. Test avec lecteur d’écran VoiceOver + Safari (macOS/iOS) : Activez VoiceOver (Commande + F5 sur macOS). Utilisez Contrôle + Option + Flèche pour naviguer. Sur iOS, utilisez les gestes de balayage. Confirmez que toutes les fonctions sont atteignables et utilisables. Portez une attention particulière aux widgets tactiles personnalisés qui peuvent manquer d’équivalents clavier dans la version de bureau.
7. Audit des fonctionnalités dépendantes du chemin : Pour tout canvas de dessin, interaction cartographique ou composant piloté par gestes, vérifiez l’existence d’un mécanisme alternatif au clavier. Essayez de créer une forme, de réordonner un élément de liste ou de déplacer une carte en utilisant uniquement les contrôles clavier. S’il n’existe aucun chemin clavier, il s’agit d’un échec direct de 2.1.3.
8. Vérification de la visibilité du focus : En naviguant uniquement au clavier, confirmez que le focus est toujours visible à l’écran et ordonné de manière logique. Un focus invisible ou qui saute vers des emplacements inattendus constitue un échec d’ergonomie et viole probablement aussi 2.4.7 et 2.4.3.

Comment corriger

Outil de dessin sur canvas — Incorrect

<!-- Freehand canvas with no keyboard alternative -->
<canvas id='drawingBoard' width='800' height='600'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'>
</canvas>

Outil de dessin sur canvas — Correct

<!-- Canvas with keyboard-accessible shape toolbar as alternative -->
<div role='toolbar' aria-label='Drawing tools'>
  <button id='addRect' onclick='insertShape("rectangle")'>Add Rectangle</button>
  <button id='addCircle' onclick='insertShape("circle")'>Add Circle</button>
  <button id='addLine' onclick='insertShape("line")'>Add Line</button>
  <label for='shapeColor'>Color</label>
  <input type='color' id='shapeColor' value='#000000'>
</div>
<canvas id='drawingBoard' width='800' height='600'
  aria-label='Drawing canvas — use toolbar above to add shapes'
  tabindex='0'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'
  onkeydown='handleCanvasKey(event)'>
</canvas>
<!-- handleCanvasKey enables arrow-key movement and Enter to place shapes -->

Réorganisation de liste par glisser-déposer — Incorrect

<!-- List that only supports mouse drag for reordering -->
<ul id='sortableList'>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item One</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Two</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Three</li>
</ul>

Réorganisation de liste par glisser-déposer — Correct

<!-- List with ARIA listbox pattern and keyboard reordering via arrow keys -->
<p id='reorderInstructions'>Tab to an item, press Space to grab it, use Up/Down arrows to move, press Space again to drop.</p>
<ul id='sortableList' role='listbox' aria-labelledby='reorderInstructions'>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item One</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Two</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Three</li>
</ul>
<!-- handleReorderKey: Space = grab/drop, ArrowUp/Down = move, Escape = cancel -->

Contrôles de carte interactive — Incorrect

<!-- Map that only responds to mouse pan and scroll-to-zoom -->
<div id='mapContainer' style='width:100%;height:400px;'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'>
</div>

Contrôles de carte interactive — Correct

<!-- Map with keyboard controls and accessible zoom/pan buttons -->
<div id='mapContainer' tabindex='0'
  role='application'
  aria-label='Interactive map. Use arrow keys to pan, plus and minus to zoom.'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'
  onkeydown='handleMapKey(event)'>
</div>
<div role='group' aria-label='Map controls'>
  <button onclick='zoomIn()'>Zoom In</button>
  <button onclick='zoomOut()'>Zoom Out</button>
  <button onclick='panMap("north")'>Pan North</button>
  <button onclick='panMap("south")'>Pan South</button>
  <button onclick='panMap("east")'>Pan East</button>
  <button onclick='panMap("west")'>Pan West</button>
</div>
<!-- Arrow keys pan, + / - zoom, handleMapKey dispatches these actions -->

Erreurs courantes

• Supposer que l’exception de dépendance au chemin de WCAG 2.1.1 s’applique toujours : Les développeurs familiers du niveau A créent parfois des outils de dessin à main levée ou basés sur des gestes sans alternatives clavier, sans réaliser que 2.1.3 supprime explicitement cette exception. Chaque fonction, y compris celles sensibles au chemin, doit avoir un équivalent clavier à ce niveau.
• N’attacher que des gestionnaires onclick et onmousedown aux éléments interactifs personnalisés : Les widgets personnalisés construits avec des éléments <div> ou <span> qui n’écoutent que les événements de souris sont totalement inaccessibles au clavier. Ajoutez toujours des gestionnaires onkeydown ou onkeyup en plus des écouteurs d’événements de souris, et assurez-vous que l’élément possède tabindex='0' et un rôle ARIA approprié.
• Utiliser tabindex='-1' sur des éléments qui devraient être dans l’ordre de tabulation : Définir tabindex='-1' retire un élément de l’ordre de tabulation séquentiel. Cela n’est approprié que pour les éléments gérés par programmation (par exemple, dans un widget composite utilisant un tabindex itinérant). L’appliquer à des contrôles interactifs autonomes les rend inaccessibles au clavier.
• Implémenter le glisser-déposer sans mécanisme de réorganisation au clavier : Les bibliothèques comme SortableJS ou les implémentations personnalisées de glisser-déposer ne fournissent souvent aucune alternative clavier par défaut. Les développeurs doivent implémenter le modèle ARIA de glisser-déposer ou fournir une réorganisation via les flèches Haut/Bas afin que le réagencement de liste soit entièrement utilisable au clavier.
• Se reposer sur le CSS :hover pour révéler des contrôles interactifs : Les sous-menus déroulants, les boutons d’action dans des info-bulles ou les contrôles révélés uniquement au survol sont inaccessibles aux utilisateurs clavier, sauf si les états :focus et :focus-within sont également gérés. Un utilisateur clavier ne peut jamais survoler, donc le contenu accessible uniquement au survol lui est de fait caché.
• Ne pas gérer le focus après des changements de contenu dynamiques : Lorsqu’une modale s’ouvre, qu’une alerte en ligne apparaît ou qu’un widget chargé en AJAX remplace du contenu existant, le focus doit être déplacé par programmation vers le nouveau contenu à l’aide de element.focus(). Ne pas le faire laisse les utilisateurs clavier bloqués à l’endroit où ils ont déclenché le changement, sans conscience de l’existence du nouveau contenu.
• Construire des curseurs personnalisés uniquement avec onmousemove : Les curseurs de type plage construits à partir d’éléments <div> qui suivent la position de la souris pour les changements de valeur doivent également implémenter la gestion des touches ArrowLeft, ArrowRight, Home et End conformément au modèle ARIA de curseur, et exposer la valeur actuelle via aria-valuenow, aria-valuemin et aria-valuemax.
• Placer le focus clavier à l’intérieur d’iframes sans fournir de moyen d’en sortir : Les iframes intégrées—en particulier celles contenant des widgets tiers comme des cartes, des formulaires de paiement ou des outils de chat—peuvent piéger le focus clavier si le contenu intégré lui-même n’est pas accessible au clavier et ne prend pas en charge la touche Échap pour renvoyer le focus au document parent.
• Omettre le support clavier pour les visualisations de données basées sur canvas : Les graphiques et diagrammes rendus sur <canvas> sont invisibles pour le clavier et les lecteurs d’écran, à moins qu’une alternative accessible (un tableau de données, un équivalent SVG avec ARIA ou des points de données navigables au clavier) ne soit fournie en complément de l’élément canvas.
• Tester l’accessibilité clavier uniquement avec Tab et Entrée, en ignorant les modèles de touches des widgets composites : De nombreux modèles de widgets ARIA—menus, arbres, grilles, panneaux à onglets, boîtes de liste—requièrent une navigation aux flèches à l’intérieur du widget, avec un seul point de tabulation pour l’ensemble du composant (tabindex itinérant). Tester uniquement Tab et Entrée ne révélera pas les échecs dans ces modèles composites et donnera une fausse impression de conformité.

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

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit un cadre complet d’accessibilité web et mobile pour un large éventail d’entités publiques et privées opérant en Turquie. La circulaire impose la conformité à des normes alignées sur WCAG 2.1 et 2.2, exigeant des organisations concernées qu’elles garantissent que leurs services numériques soient perceptibles, utilisables, compréhensibles et robustes pour tous les utilisateurs, y compris les personnes handicapées.

Les entités couvertes par cette réglementation incluent les institutions et agences publiques à tous les niveaux de gouvernement, les plateformes de commerce électronique, les banques et prestataires de services financiers, les hôpitaux et établissements de santé, les entreprises de télécommunications comptant 200 000 abonnés ou plus, les agences de voyage, les entreprises de transport privé et les écoles privées opérant sous l’autorisation du ministère de l’Éducation nationale (MoNE). Pour ces organisations, le respect des critères de succès de niveau A et de niveau AA constitue le minimum légal.

WCAG 2.1.3 — Clavier (sans exception) est un critère de niveau AAA et n’est donc pas explicitement imposé comme exigence légale de base par la circulaire. Cependant, l’esprit de la réglementation—garantir un accès numérique équitable pour les millions d’utilisateurs handicapés en Turquie—s’aligne fortement sur l’intention de ce critère. Les organisations des secteurs concernés qui offrent des services spécialisés aux personnes ayant des limitations motrices, ou qui exploitent des portails gouvernementaux utilisés par des citoyens dépendant de technologies d’assistance, ont tout intérêt à viser la conformité AAA pour l’accès au clavier.

Atteindre la conformité à WCAG 2.1.3 témoigne d’un engagement exemplaire en matière d’accessibilité, allant au-delà des exigences réglementaires minimales. Pour les organisations turques qui cherchent à servir la base d’utilisateurs la plus large possible, à démontrer leur responsabilité sociale ou à participer aux marchés numériques de l’Union européenne où des normes d’accessibilité plus élevées peuvent s’appliquer, la mise en œuvre d’une opérabilité complète au clavier sans exception constitue à la fois un avantage concurrentiel et éthique. À mesure que le paysage réglementaire turc évolue et que les mécanismes d’application se renforcent, les premiers adoptants de critères de niveau AAA tels que 2.1.3 seront bien placés pour répondre à tout durcissement futur de la réglementation sans avoir à engager de coûteuses opérations de remédiation.