WCAG 2.1.4 : Raccourcis clavier à touche de caractère

Ce que signifie cette règle

WCAG 2.1.4 — Raccourcis clavier à touche de caractère est un critère de succès de niveau A introduit dans WCAG 2.1. Il traite d’un danger d’accessibilité spécifique mais sérieux : lorsqu’une application web assigne des raccourcis clavier constitués d’un seul caractère imprimable — une lettre, un chiffre, un signe de ponctuation ou un symbole — sans exiger de touche de modification telle que Ctrl, Alt, Meta ou Shift en combinaison.

Le critère stipule que si un raccourci clavier est implémenté dans le contenu en utilisant uniquement une touche de caractère unique, au moins une des conditions suivantes doit être vraie :

• Désactiver : Un mécanisme est disponible pour permettre à l’utilisateur de désactiver complètement le raccourci.
• Reconfigurer : Un mécanisme est disponible pour permettre à l’utilisateur de reconfigurer le raccourci afin d’utiliser une ou plusieurs touches de modification non imprimables (telles que Ctrl ou Alt).
• Actif uniquement avec le focus : Le raccourci clavier pour un composant d’interface utilisateur n’est actif que lorsque ce composant a le focus.

Un raccourci à touche de caractère unique est un raccourci activé en appuyant sur une seule touche qui produit un caractère imprimable — par exemple, appuyer sur G pour ouvrir une galerie, appuyer sur / pour placer le focus sur une barre de recherche, ou appuyer sur N pour rédiger un nouveau message. Ceux-ci diffèrent fondamentalement de raccourcis comme Ctrl+S ou Alt+F4, qui exigent une touche de modification non imprimable et sont donc en dehors du champ de ce critère.

Un raccourci respecte ce critère si l’application : (1) fournit une page de paramètres ou de préférences où les raccourcis à touche unique peuvent être désactivés ou modifiés en combinaisons multi-touches ; (2) reconfigure automatiquement les raccourcis pour utiliser des touches de modification ; ou (3) ne déclenche le raccourci que lorsque l’élément déclencheur lui-même a le focus clavier — ce qui signifie qu’appuyer sur la touche lorsque le focus est ailleurs ne fait rien.

Un raccourci échoue si une frappe à caractère unique déclenche une action globale à tout moment, quel que soit l’élément ayant le focus, et qu’il n’existe aucun moyen pour l’utilisateur de le désactiver ou de le modifier. Un exemple courant dans le monde réel est une application monopage qui déclenche une action de navigation chaque fois que l’utilisateur appuie sur une touche de lettre, même lorsqu’il remplit un champ de texte ou dicte du texte.

Le critère inclut une exception officielle importante : il ne s’applique pas lorsque le raccourci n’est actif que pendant qu’un composant spécifique a le focus. Par exemple, un widget de liste déroulante personnalisé qui écoute les touches de lettres uniquement lorsque la liste déroulante elle-même est ouverte et a le focus est acceptable, car la limitation du focus réduit le risque d’activation accidentelle.

Pourquoi c’est important

Ce critère existe principalement pour protéger deux groupes d’utilisateurs, même si ses bénéfices vont au-delà.

Les utilisateurs de saisie vocale sont les plus directement concernés. Les personnes ayant un handicap moteur contrôlent souvent leur ordinateur entièrement via des logiciels de reconnaissance vocale tels que Dragon NaturallySpeaking (désormais Dragon Professional). Lors de la dictée de texte ou de l’émission de commandes vocales, ces outils émettent des frappes qui peuvent déclencher involontairement des raccourcis à caractère unique sur la page web active. Imaginez un utilisateur dictant un formulaire médical et disant « next » — si l’application écoute globalement la lettre N, elle peut naviguer hors du formulaire, détruisant le travail de l’utilisateur. Selon le CDC, environ 61 millions d’adultes aux États-Unis vivent avec un handicap, et une proportion significative dépend de méthodes d’entrée alternatives, y compris la reconnaissance vocale.

Les utilisateurs ayant un handicap moteur qui utilisent l’accès par contacteur, des dispositifs sip-and-puff ou une navigation uniquement au clavier sont également à risque. Ces utilisateurs peuvent appuyer sur des touches par inadvertance ou passer sur plusieurs touches en essayant d’atteindre une cible. Une seule mauvaise frappe qui déclenche une action irréversible — comme archiver un e-mail, supprimer un fichier ou soumettre un formulaire — peut provoquer une grande frustration et une perte de données.

Les utilisateurs ayant un handicap cognitif peuvent également être affectés. Les utilisateurs ayant des troubles de l’attention ou les utilisateurs qui ne sont pas familiers avec une interface peuvent appuyer sur des touches de manière expérimentale pour explorer la page, sans savoir que des raccourcis à caractère unique sont actifs. Des navigations ou changements d’état inattendus augmentent la charge cognitive et la désorientation.

Considérez ce scénario réel : une plateforme de e-commerce turque implémente des raccourcis à touche unique pour les utilisateurs avancés — appuyer sur C pour aller au panier, appuyer sur F pour aller aux favoris. Un utilisateur de saisie vocale essaie de dicter son adresse de livraison dans un champ de formulaire. Lorsqu’il dit « Caddesi » (le mot turc pour « rue »), le logiciel de reconnaissance vocale émet la lettre C avant que le focus n’entre complètement dans le champ de saisie, déclenchant la navigation vers la page du panier. L’adresse partiellement saisie est perdue. L’utilisateur doit recommencer, et si l’expérience se répète, il peut abandonner complètement le site.

Au-delà de l’accessibilité, corriger ce critère améliore l’ergonomie globale. Fournir une interface de personnalisation des raccourcis signale un produit mature qui respecte ses utilisateurs. Cela peut également réduire les tickets de support provenant d’utilisateurs frustrés qui déclenchent des raccourcis par accident.

Règles Axe-core associées

WCAG 2.1.4 nécessite un test manuel car les outils automatisés ne peuvent pas détecter de manière fiable tous les raccourcis clavier à caractère unique ni vérifier l’existence d’un mécanisme de reconfiguration/désactivation. Voici pourquoi l’automatisation est insuffisante et ce que les testeurs doivent vérifier manuellement :

• Aucune règle axe-core dédiée (vérification manuelle requise) : Axe-core et Lighthouse n’ont pas de règle automatisée qui signale spécifiquement les raccourcis clavier à caractère unique. La raison est architecturale : le comportement des raccourcis clavier est implémenté dans des écouteurs d’événements JavaScript (keydown, keyup, keypress), et une analyse statique du DOM ne peut pas déterminer quelle action une frappe donnée déclenchera, si cette action est globale ou limitée au focus, ni si un mécanisme de désactivation/reconfiguration accessible à l’utilisateur existe. Un outil devrait simuler des frappes pour tous les caractères possibles et observer les changements d’état de l’application qui en résultent — une tâche combinatoirement coûteuse et dépendante du contexte qui dépasse les capacités actuelles des tests automatisés.
• Inspection des écouteurs d’événements (automatisation partielle) : Les DevTools des navigateurs peuvent énumérer les écouteurs d’événements attachés aux éléments document, window ou body. Si un site attache un écouteur keydown à document et que l’inspection de son code source révèle une logique de correspondance sur des caractères uniques, c’est un signal fort nécessitant une vérification manuelle. Cependant, l’outil ne peut pas déterminer seul si le comportement résultant constitue un raccourci ni si un mécanisme de désactivation est présent.
• Bibliothèques de raccourcis spécifiques aux frameworks : De nombreuses applications React, Vue ou Angular utilisent des bibliothèques telles que react-hotkeys-hook, tinykeys ou Mousetrap qui enregistrent des raccourcis globaux. Un audit manuel doit rechercher ces dépendances dans le code source de la page ou dans l’onglet réseau, puis tester chaque raccourci enregistré au regard des exigences du critère.

Comment tester

1. Passer en revue l’application pour identifier les raccourcis à caractère unique connus : Lisez toute documentation disponible, les pages d’aide ou les boîtes de dialogue de référence des raccourcis clavier (souvent ouvertes avec ? ou accessibles via un menu Aide). Dressez la liste de tous les raccourcis documentés qui utilisent un caractère unique sans touche de modification.
2. Inspecter les écouteurs d’événements JavaScript : Ouvrez Chrome DevTools ou Firefox DevTools, accédez au panneau Elements ou Sources, et utilisez l’onglet Event Listeners pour inspecter les écouteurs sur document, window et body. Recherchez les gestionnaires keydown, keyup ou keypress. Développez et lisez le code source du gestionnaire pour voir si des touches de caractère unique sont testées sans vérification des touches de modification (c’est-à-dire si le code vérifie event.key === 'n' sans vérifier également event.ctrlKey || event.metaKey || event.altKey).
3. Tester les raccourcis clavier lorsque le focus est dans un champ de texte : Cliquez dans un champ de texte, une boîte de recherche ou une zone de texte. Appuyez ensuite sur chaque raccourci à caractère unique que vous avez identifié. Si le raccourci se déclenche (navigation, action, changement d’état), c’est un échec — le raccourci n’est pas limité au focus et est actif même lorsque l’utilisateur saisit du texte.
4. Tester avec NVDA + Firefox : Activez le mode Parcourir de NVDA (Insert+Espace pour basculer). En mode Parcourir, NVDA utilise des touches de navigation à lettre unique (H pour les titres, B pour les boutons, etc.). Lancez l’application web testée. Passez en mode Focus (Insert+Espace) et dictez ou saisissez du texte. Vérifiez que les raccourcis à caractère unique de la page n’entrent pas en conflit avec les frappes du mode Parcourir de NVDA et qu’aucune action non souhaitée n’est déclenchée.
5. Tester avec JAWS + Chrome : De même, JAWS utilise une navigation rapide à lettre unique. Lancez l’application, naviguez via le curseur virtuel de JAWS et vérifiez que les raccourcis de l’application ne se déclenchent pas de manière inattendue pendant que JAWS traite les frappes.
6. Tester avec VoiceOver + Safari (macOS) : Activez VoiceOver (Cmd+F5). Utilisez VO+Shift+Flèche bas pour interagir avec les zones de contenu. Vérifiez que les raccourcis par lettre sur la page n’interfèrent pas avec les commandes de navigation de VoiceOver.
7. Simuler la saisie vocale : Si Dragon NaturallySpeaking ou Windows Speech Recognition est disponible, dictez du texte dans un champ de formulaire pendant que l’application est ouverte. Prononcez des mots et expressions courants qui commencent par des lettres utilisées comme raccourcis. Vérifiez qu’aucune action non souhaitée n’est déclenchée.
8. Vérifier le mécanisme de désactivation ou de reconfiguration : Si des raccourcis à caractère unique existent, localisez l’interface de paramètres ou de préférences qui permet de les désactiver ou de les reconfigurer. Confirmez qu’elle est accessible uniquement au clavier et qu’elle fonctionne correctement. Testez qu’après avoir désactivé un raccourci, l’appui sur le caractère ne déclenche plus l’action.

Comment corriger

Raccourci global à caractère unique sans vérification de touche de modification — Incorrect

<!-- JavaScript attaché à document, déclenché sur toute pression de la touche 'n' globalement -->
<script>
document.addEventListener('keydown', function(event) {
  if (event.key === 'n') {
    // Naviguer vers la fenêtre de rédaction d’un nouveau message
    openComposeWindow();
  }
});
</script>

Raccourci global à caractère unique — Correct : ajouter une exigence de touche de modification et un bouton de désactivation

<!-- Approche correcte 1 : exiger une touche de modification (Ctrl+N) pour éviter les déclenchements accidentels -->
<script>
document.addEventListener('keydown', function(event) {
  // Ne déclencher que lorsque Ctrl ou Meta (Cmd sur Mac) est également enfoncée
  if ((event.ctrlKey || event.metaKey) && event.key === 'n') {
    openComposeWindow();
  }
});
</script>

<!-- Approche correcte 2 : si un raccourci à caractère unique est nécessaire, fournir un bouton de désactivation -->
<button type='button' id='toggle-shortcuts' aria-pressed='true'>
  Keyboard shortcuts enabled
</button>
<script>
let shortcutsEnabled = true;
document.getElementById('toggle-shortcuts').addEventListener('click', function() {
  shortcutsEnabled = !shortcutsEnabled;
  this.setAttribute('aria-pressed', shortcutsEnabled.toString());
  this.textContent = shortcutsEnabled ? 'Keyboard shortcuts enabled' : 'Keyboard shortcuts disabled';
});

document.addEventListener('keydown', function(event) {
  if (!shortcutsEnabled) return; // Respecter la préférence de l’utilisateur
  if (event.key === 'n') {
    openComposeWindow();
  }
});
</script>

Raccourci actif à l’intérieur d’un widget focalisé — Incorrect

<!-- Le raccourci écoute sur l’ensemble du document, pas limité au widget -->
<div id='autocomplete-list' role='listbox'>
  <div role='option'>Istanbul</div>
  <div role='option'>Ankara</div>
</div>
<script>
// BUG : attaché à document, se déclenche même lorsque l’autocomplétion n’a pas le focus
document.addEventListener('keydown', function(e) {
  if (e.key === 'Enter') selectHighlightedOption();
});
</script>

Raccourci actif à l’intérieur d’un widget focalisé — Correct : limiter l’écouteur au widget

<!-- Correct : l’écouteur est sur l’élément du widget ; le raccourci ne se déclenche que lorsqu’il a le focus -->
<div id='autocomplete-list' role='listbox' tabindex='0'>
  <div role='option'>Istanbul</div>
  <div role='option'>Ankara</div>
</div>
<script>
var widget = document.getElementById('autocomplete-list');
// Écouteur sur le widget lui-même : Enter ne se déclenche que lorsque la listbox a le focus
widget.addEventListener('keydown', function(e) {
  if (e.key === 'Enter') selectHighlightedOption();
});
</script>

Aucune interface de reconfiguration accessible à l’utilisateur — Incorrect

<!-- L’application enregistre des raccourcis avec une bibliothèque mais ne propose aucune page de paramètres -->
<!-- L’utilisateur n’a aucun moyen de modifier ou de désactiver 'g' (aller à la galerie) ou 'c' (aller au panier) -->
<script src='hotkeys.min.js'></script>
<script>
hotkeys('g', function() { goToGallery(); });
hotkeys('c', function() { goToCart(); });
</script>

Aucune interface de reconfiguration accessible à l’utilisateur — Correct : ajouter un panneau de paramètres accessible

<!-- Panneau de paramètres accessible au clavier ; permet à l’utilisateur d’activer/désactiver tous les raccourcis à caractère unique -->
<nav aria-label='Accessibility settings'>
  <button type='button' id='open-shortcut-settings'>Keyboard shortcut settings</button>
</nav>

<dialog id='shortcut-settings-dialog' aria-labelledby='dialog-title'>
  <h2 id='dialog-title'>Keyboard Shortcuts</h2>
  <label>
    <input type='checkbox' id='enable-single-char' checked />
    Enable single-character keyboard shortcuts (G, C, N...)
  </label>
  <p>Disable this if you use speech recognition software or experience accidental activations.</p>
  <button type='button' id='close-dialog'>Save and close</button>
</dialog>

<script src='hotkeys.min.js'></script>
<script>
var checkbox = document.getElementById('enable-single-char');

function applyShortcuts() {
  if (checkbox.checked) {
    hotkeys('g', function() { goToGallery(); });
    hotkeys('c', function() { goToCart(); });
  } else {
    hotkeys.unbind('g');
    hotkeys.unbind('c');
  }
}

applyShortcuts();
checkbox.addEventListener('change', applyShortcuts);

document.getElementById('open-shortcut-settings').addEventListener('click', function() {
  document.getElementById('shortcut-settings-dialog').showModal();
});
document.getElementById('close-dialog').addEventListener('click', function() {
  document.getElementById('shortcut-settings-dialog').close();
});
</script>

Erreurs courantes

• Enregistrer des raccourcis sur document ou window sans vérifier si un élément de saisie a actuellement le focus : Même si un mécanisme de désactivation existe, de nombreuses implémentations oublient de vérifier document.activeElement et de supprimer le raccourci lorsque l’utilisateur se trouve dans un élément <input>, <textarea> ou contenteditable, ce qui entraîne une interférence avec la saisie normale.
• Considérer le raccourci ? (ouvrir l’aide) comme exempt : Le point d’interrogation est un caractère imprimable et un raccourci à caractère unique. Il n’est pas exempt de ce critère, sauf s’il est limité au focus ou si un mécanisme de désactivation/reconfiguration existe.
• Ne désactiver les raccourcis que dans les champs de texte mais pas dans les régions contenteditable ou les éditeurs de texte enrichi : Les utilisateurs de saisie vocale dictent souvent dans des éléments contenteditable utilisés par des éditeurs de texte enrichi (comme ceux des plateformes CMS). Ne pas supprimer les raccourcis globaux dans ces contextes viole toujours le critère.
• Stocker la préférence de raccourci de l’utilisateur uniquement en mémoire de session : Si l’utilisateur désactive les raccourcis puis actualise la page, la préférence doit être conservée (dans le localStorage ou un paramètre de profil utilisateur) afin qu’il n’ait pas à désactiver les raccourcis à chaque visite.
• Rendre l’interface de paramètres des raccourcis elle-même inaccessible : Placer l’option de désactivation/reconfiguration au fond d’un menu qui n’est pas accessible au clavier, ou utiliser un widget de bascule personnalisé sans un role='switch' approprié et sans aria-checked, signifie que le mécanisme de correction est inutilisable par les utilisateurs mêmes qu’il est censé aider.
• Supposer que seules les touches de lettres sont concernées : Les touches numériques (1–9), les touches de ponctuation (/, ., virgule, point-virgule) et les touches de symboles (#, @, !) sont toutes des caractères imprimables. Les raccourcis à touche unique utilisant ces caractères sont tout autant soumis au critère.
• Ne pas documenter les raccourcis existants : Même si un mécanisme de désactivation est présent, les utilisateurs ne peuvent pas l’utiliser efficacement s’ils ne savent pas quels raccourcis sont actifs. Il est fortement recommandé de fournir une référence visible et accessible au clavier des raccourcis (par exemple une boîte de dialogue ouverte via un bouton Aide).
• Utiliser une configuration par défaut de bibliothèque de raccourcis qui se lie globalement sans lire sa documentation : Des bibliothèques comme Mousetrap, Hotkeys.js et tinykeys se lient à la portée globale par défaut. Les développeurs les utilisent souvent sans lire la documentation sur la restriction de portée ou les exigences de touches de modification, créant involontairement des violations du critère à grande échelle.
• Ne pas tester avec la reconnaissance vocale avant le lancement : Les équipes qui n’ont pas Dragon NaturallySpeaking dans leur boîte à outils QA découvrent souvent les conflits de raccourcis à caractère unique seulement après le déploiement, lorsque les utilisateurs de saisie vocale signalent des problèmes.
• Penser que parce que le raccourci est « optionnel » ou « pour utilisateurs avancés » il est exempt : Le critère s’applique à tous les raccourcis à caractère unique, qu’ils soient ou non présentés comme des fonctionnalités avancées. Le caractère optionnel de la fonctionnalité ne l’exempte pas de l’exigence de conformité.

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 d’accessibilité web et mobile alignées sur WCAG 2.2. WCAG 2.1.4 — Raccourcis clavier à touche de caractère est un critère de succès de niveau A, ce qui le place dans le niveau d’obligations le plus prioritaire au titre de la circulaire.

La circulaire couvre un large éventail d’entités opérant en Turquie. Les institutions publiques — y compris les ministères, les municipalités, les universités d’État, les hôpitaux publics et les agences gouvernementales — doivent atteindre une conformité complète de niveau A dans un délai de un an à compter de la date de publication de la circulaire. Les entités du secteur privé dans les catégories couvertes disposent d’une fenêtre de conformité de deux ans. Les entités privées couvertes comprennent les plateformes de e-commerce, les banques et institutions financières, les hôpitaux et prestataires de soins 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 autorisation du ministère de l’Éducation nationale (MoNE).

Pour ces organisations, ne pas se conformer à WCAG 2.1.4 n’est pas seulement une question de bonnes pratiques — c’est une obligation légale. Un site de e-commerce turc qui implémente des raccourcis de navigation produits à caractère unique sans mécanisme de désactivation, ou le portail en ligne d’une banque turque qui utilise des raccourcis par lettre dans son flux de transaction, serait en violation directe des exigences de la circulaire.

Concrètement, les équipes de conformité des entités couvertes devraient auditer leurs bases de code JavaScript et toute bibliothèque de widget tierce pour détecter les raccourcis à caractère unique enregistrés globalement, en tant que tâche distincte dans le cadre de leurs projets de remédiation WCAG 2.2 niveau A. Étant donné que ce critère nécessite des tests manuels, les analyses d’accessibilité automatisées seules ne feront pas remonter les violations — une phase dédiée de tests au clavier et à la saisie vocale est nécessaire. Les organisations utilisant des systèmes de gestion de contenu ou des frameworks front-end devraient examiner les implémentations de raccourcis au niveau de la plateforme (par exemple, les raccourcis clavier d’administration CMS par défaut exposés sur les pages destinées aux clients) en plus du code applicatif personnalisé.

Le SDK d’overlay d’Accsible aide les entités couvertes en fournissant un panneau de préférences d’accessibilité accessible à l’utilisateur qui peut exposer un bouton de désactivation des raccourcis aux utilisateurs finaux, aidant les organisations à satisfaire à l’exigence de « mécanisme de désactivation » de WCAG 2.1.4 sans nécessiter une refonte complète de la base de code. Cela est particulièrement précieux pour les organisations gérant des applications héritées où la modification de la logique JavaScript sous-jacente des raccourcis est gourmande en ressources. Cependant, les organisations doivent noter que s’appuyer uniquement sur un overlay pour la conformité ne remplace pas le traitement des implémentations de raccourcis sous-jacentes, et qu’une approche en couches combinant des outils d’overlay avec une remédiation au niveau du code source offre la voie la plus robuste vers la conformité au titre de la circulaire présidentielle.