Connexion

Accessibilité clavier : comment rendre votre site web entièrement navigable au clavier

20 min read
ClavierWcagAccessibilité

L’accessibilité clavier est l’un des aspects les plus critiques — et les plus négligés — de l’accessibilité web, des études montrant que 85% des sites web ne parviennent toujours pas à offrir une navigation clavier adéquate. Ce guide couvre les exigences WCAG, les schémas d’échec courants et des techniques pratiques au niveau du code pour aider les développeurs et les responsables de la conformité à créer des expériences véritablement navigables au clavier.

Imaginez que vous essayiez de remplir une candidature à un emploi, de prendre un rendez-vous médical ou de finaliser un achat en ligne — et que votre souris ne fonctionne pas. Non pas qu’elle soit cassée, mais qu’elle soit simplement sans objet : vous naviguez uniquement avec Tab, Entrée et les flèches du clavier. Pour des millions de personnes dans le monde, ce n’est pas une expérience de pensée. Les personnes ayant des handicaps moteurs, des troubles musculo-squelettiques, des déficiences visuelles, ainsi que celles qui utilisent des lecteurs d’écran, dépendent toutes de la navigation au clavier comme principale interface avec le web. Pourtant, les recherches montrent de façon constante que 85% des sites web ne fournissent pas une navigation au clavier adéquate, excluant ces personnes de tâches numériques de base chaque jour. Si votre site fait partie de cette majorité, ce guide est pour vous.

Qui dépend de la navigation au clavier — et pourquoi c’est plus important que vous ne le pensez

L’accessibilité clavier n’est pas une préoccupation de niche pour une petite fraction d’utilisateurs. La population qui en dépend est plus large et plus variée que ce que la plupart des développeurs imaginent. Les personnes ayant des handicaps physiques qui ne peuvent pas utiliser une souris, les personnes aveugles qui ne peuvent pas voir le pointeur de la souris à l’écran, et les personnes souffrant de troubles chroniques comme les blessures de stress répétitif qui doivent limiter l’usage de la souris, s’appuient toutes sur la navigation au clavier comme porte d’entrée vers le web. Au-delà du handicap, de nombreux utilisateurs avancés — développeurs, rédacteurs, professionnels de la saisie de données — préfèrent les raccourcis clavier pour la rapidité et l’efficacité.

Les utilisateurs de lecteurs d’écran représentent un autre groupe majeur. Les lecteurs d’écran interprètent et annoncent les éléments de la page en fonction du focus et de la structure sémantique, et les utilisateurs se déplacent dans le contenu à l’aide de frappes clavier. Si un site web ne maintient pas le focus clavier ou ne prend pas en charge un ordre de focus logique, la navigation au lecteur d’écran se désagrège complètement. Les logiciels de reconnaissance vocale comme Dragon NaturallySpeaking génèrent également des événements clavier, ce qui signifie qu’un mauvais support clavier casse aussi la navigation contrôlée par la voix.

L’argument commercial est tout aussi convaincant. Selon les données disponibles, les personnes handicapées aux États-Unis disposent de près d’un demi-billion de dollars de revenu disponible. Lorsque votre site web n’est pas accessible au clavier, vous écartez activement une part significative de ce marché. Le risque juridique est également réel : l’accessibilité clavier est essentielle pour la conformité aux WCAG, qui constituent la référence pour la conformité à l’ADA, à la Section 508, à l’European Accessibility Act et à la norme EN 301 549 dans le monde. Les pièges clavier — où un utilisateur reste bloqué dans un élément de page sans possibilité d’en sortir — sont cités comme des échecs évidents des WCAG qui ont été au cœur de poursuites liées à l’accessibilité.

Peut-être le plus révélateur : 71% des utilisateurs handicapés abandonnent tout simplement un site web qu’ils trouvent difficile à utiliser. Ils ne se plaignent pas. Ils partent. Et comme les problèmes d’accessibilité clavier ont tendance à se concentrer autour des points d’interaction les plus critiques — formulaires, modales, menus de navigation et parcours de paiement — l’impact se répercute directement sur vos taux de conversion.

Le cadre WCAG : ce que les règles exigent réellement

Les Web Content Accessibility Guidelines (WCAG) organisent les exigences liées au clavier principalement sous la Règle 2.1 — « Rendre toutes les fonctionnalités disponibles au clavier ». Comprendre ce qui est exigé ou non est la première étape vers la conformité. WCAG 2.2, qui est devenu la norme officielle du W3C le 5 octobre 2023 et a ajouté neuf nouveaux critères de succès au cadre existant, est désormais la norme recommandée pour l’ADA, la Section 508 et l’European Accessibility Act.

Les principaux critères de succès liés au clavier que vous devez connaître sont :

  • SC 2.1.1 Keyboard (Niveau A) : Toutes les fonctionnalités doivent être utilisables via une interface clavier sans exiger de timing spécifique pour chaque frappe, sauf lorsque la fonction sous-jacente nécessite une saisie dépendante d’un tracé (comme le dessin à main levée). C’est le socle de base — chaque élément interactif doit être atteignable et utilisable au clavier.
  • SC 2.1.2 No Keyboard Trap (Niveau A) : Si le focus clavier peut être déplacé sur un composant à l’aide du clavier, le focus doit aussi pouvoir en être déplacé en utilisant uniquement le clavier. Si une méthode non standard est nécessaire pour en sortir, les utilisateurs doivent en être informés. Les pièges clavier sont un blocage absolu pour les utilisateurs de clavier.
  • SC 2.4.3 Focus Order (Niveau A) : Si une page web peut être parcourue de manière séquentielle, l’ordre de focus doit préserver le sens et l’opérabilité. Un ordre de tabulation logique et prévisible est non négociable.
  • SC 2.4.7 Focus Visible (Niveau AA) : Toute interface utilisateur utilisable au clavier doit disposer d’un mode dans lequel l’indicateur de focus clavier est visible. Les utilisateurs doivent toujours pouvoir voir où ils se trouvent sur la page.
  • SC 2.4.11 Focus Not Obscured (Minimum) (Niveau AA — nouveau dans WCAG 2.2) : Lorsqu’un élément focalisable au clavier reçoit le focus, il ne doit pas être complètement masqué par du contenu créé par l’auteur, comme des en-têtes fixes ou des bannières de cookies.
  • SC 2.4.12 Focus Not Obscured (Enhanced) (Niveau AAA) : Une version plus stricte exigeant qu’aucune partie du composant focalisé ne soit masquée par du contenu créé par l’auteur.
  • SC 2.5.8 Target Size (Minimum) (Niveau AA — nouveau dans WCAG 2.2) : Les cibles interactives doivent mesurer au moins 24x24 pixels CSS, afin de réduire les erreurs pour les utilisateurs ayant un contrôle moteur limité.
  • SC 2.5.7 Dragging Movements (Niveau AA — nouveau dans WCAG 2.2) : Toute fonctionnalité nécessitant un glisser doit disposer d’une alternative à pointeur unique — ce qui, par extension, bénéficie aux utilisateurs de clavier qui ne peuvent pas effectuer d’opérations de glisser.

WCAG 2.2 est entièrement rétrocompatible avec WCAG 2.1 — elle ajoute des critères mais n’en supprime aucun (à l’exception du désormais obsolète 4.1.1 Parsing). Si votre site respecte déjà WCAG 2.1 AA, vous n’avez qu’à implémenter les six nouveaux critères de Niveau AA. Pour l’accessibilité clavier en particulier, la grande nouveauté est de garantir que les éléments focalisés ne soient jamais entièrement masqués par des éléments fixes de la page — un problème très courant dans la pratique que WCAG 2.1 n’abordait pas explicitement.

Le principe des WCAG est simple à énoncer, exigeant à mettre en œuvre : si toutes les fonctionnalités peuvent être réalisées au clavier, elles peuvent être utilisées par les personnes qui se servent du clavier, de la saisie vocale, de claviers virtuels et d’une grande variété de technologies d’assistance qui génèrent des frappes simulées. Aucun autre mode d’entrée n’offre cette flexibilité ni n’est pris en charge de manière aussi universelle.

Les échecs d’accessibilité clavier les plus courants (et ce qui les provoque)

Les audits manuels montrent de façon constante que les problèmes d’accessibilité clavier comptent parmi les obstacles d’accessibilité les plus fréquents et les plus perturbateurs sur le web. Dans une étude à grande échelle, 54% des pages contenant des formulaires présentaient des problèmes d’accessibilité clavier affectant des actions critiques comme la tabulation entre les champs, la fermeture des fenêtres pop-up ou l’activation des boutons de soumission. Les testeurs ont souvent été contraints d’abandonner des paniers d’achat ou de rafraîchir des pages après être restés bloqués sur des éléments qu’ils ne pouvaient pas contrôler uniquement au clavier.

Les causes profondes se regroupent autour d’un petit nombre de schémas récurrents qui méritent d’être examinés en détail.

1. Gestionnaires d’événements réservés à la souris. L’utilisation de onmouseover, onmouseout ou onclick sur des éléments <div> sans gestionnaires d’événements clavier équivalents est l’un des échecs les plus courants. Un <div> avec un gestionnaire de clic n’est pas un bouton — il n’a pas de rôle clavier implicite, ne reçoit pas le focus via Tab et ne répond pas à Entrée ou Espace. Ajouter role='button' via ARIA aide les lecteurs d’écran mais vous oblige tout de même à ajouter manuellement tabindex='0', onkeydown et onkeyup. La bonne solution est presque toujours d’utiliser un véritable élément <button>.

2. Suppression des contours de focus. L’un des problèmes les plus répandus est la règle CSS outline: none ou outline: 0 appliquée globalement ou aux éléments focalisés. Les designers suppriment souvent l’anneau de focus par défaut du navigateur parce qu’il paraît inesthétique dans certains thèmes. Le résultat est que les utilisateurs de clavier n’ont aucune idée de l’endroit où ils se trouvent sur la page. C’est une violation directe du SC 2.4.7 des WCAG et l’un des problèmes les plus faciles à créer — et à corriger.

3. Pièges clavier dans les modales, widgets et iframes. Les boîtes de dialogue modales qui ne contraignent pas correctement le focus laissent Tab continuer au-delà de la modale vers du contenu d’arrière-plan masqué, rendant la modale impossible à fermer au clavier. Les widgets tiers — outils de chat, lecteurs vidéo, sélecteurs de date, intégrations de cartes — y sont particulièrement sujets parce que leur gestion interne du clavier vous est opaque.

4. Ordre de tabulation illogique. L’ordre de navigation clavier par défaut est déterminé par l’ordre des éléments dans le DOM. Lorsque les développeurs utilisent CSS Grid, Flexbox ou le positionnement CSS pour réorganiser la présentation visuelle indépendamment de l’ordre du DOM, le focus Tab saute sur l’écran d’une manière complètement déconnectée de la mise en page visuelle. Les valeurs positives de tabindex (par exemple tabindex='2') utilisées pour forcer un ordre spécifique aggravent considérablement ce problème dans la plupart des cas réels.

5. Menus déroulants déclenchés uniquement au survol. Les menus de navigation qui ne s’ouvrent qu’au survol de la souris, sans déclencheur clavier, laissent les utilisateurs de clavier sur le carreau. C’est un schéma extrêmement courant dans les menus déroulants uniquement en CSS, où les sous-menus apparaissent sur :hover mais ne sont jamais exposés à la navigation basée sur le focus.

6. Focus non restitué après des interactions dynamiques. Lorsqu’une modale, un tiroir ou un panneau volant est fermé, le focus doit revenir à l’élément qui l’a déclenché. Si ce n’est pas le cas — s’il revient en haut de la page ou disparaît dans un emplacement indéterminé — l’utilisateur est complètement perdu. Les applications monopage dynamiques sont particulièrement vulnérables à ce problème.

Construire une accessibilité clavier correcte : mise en œuvre pratique

En gardant à l’esprit ces schémas d’échec, voici à quoi ressemble une mise en œuvre correcte dans les zones les plus importantes d’un site typique.

Utiliser d’abord le HTML sémantique

Les éléments HTML natifs sont accessibles au clavier par défaut. Les liens (<a href>), les boutons (<button>), les champs de formulaire, les listes déroulantes et les zones de texte participent tous à l’ordre de tabulation, répondent aux frappes standard et communiquent leur rôle aux technologies d’assistance — sans une ligne de JavaScript supplémentaire. Un élément <button> possède automatiquement le bon rôle, est accessible au clavier, répond à Entrée et Espace, et dispose d’une gestion de focus intégrée. Ajouter role='button' à un <div> donne le bon rôle mais vous oblige toujours à implémenter manuellement le support clavier et la gestion du focus. Préférez toujours le HTML sémantique.

<!-- À éviter : div non sémantique qui se fait passer pour un bouton -->
<div onclick='doSomething()' class='btn'>Submit</div>

<!-- Correct : véritable élément button -->
<button type='button' onclick='doSomething()'>Submit</button>

Corriger vos indicateurs de focus

Plutôt que de supprimer l’outline par défaut du navigateur, remplacez-le par un indicateur de focus personnalisé stylé. Le SC 2.4.11 de WCAG 2.2 exige que la zone de l’indicateur de focus soit au moins aussi grande qu’un périmètre de 2 pixels CSS d’épaisseur autour du composant non focalisé, avec un ratio de contraste d’au moins 3:1 entre les états focalisé et non focalisé. Utilisez la pseudo-classe :focus-visible plutôt que :focus pour afficher les indicateurs de focus uniquement pour les utilisateurs de clavier, sans affecter l’esthétique de l’interaction à la souris.

/* Supprimer le défaut uniquement pour le remplacer par un meilleur indicateur */
*:focus {
  outline: none;
}

*:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
  border-radius: 2px;
}

Cette approche vous donne un contrôle visuel complet tout en maintenant la conformité aux WCAG. Assurez-vous que la couleur de focus présente un contraste suffisant avec l’arrière-plan et avec le composant lui-même, en particulier sur les sites à thème sombre ou au-dessus d’images.

Gérer le focus dans les interactions dynamiques

Lorsque le contenu change dynamiquement — ouverture d’une modale, chargement de nouveau contenu, suppression d’un élément — vous devez gérer le focus par programmation. Lors de l’ouverture d’une modale, déplacez le focus vers le premier élément focalisable qu’elle contient. Lors de la fermeture, renvoyez le focus à l’élément déclencheur. Utilisez la méthode JavaScript .focus() pour cela. Pour piéger correctement le focus à l’intérieur d’une modale, interceptez les événements de touches Tab et Shift+Tab et faites circuler le focus entre le premier et le dernier élément focalisable dans la boîte de dialogue.

// Ouverture d’une modale : déplacer le focus à l’intérieur
function openModal(modalEl, triggerEl) {
  modalEl.removeAttribute('hidden');
  const firstFocusable = modalEl.querySelector(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  if (firstFocusable) firstFocusable.focus();
}

// Fermeture d’une modale : renvoyer le focus au déclencheur
function closeModal(modalEl, triggerEl) {
  modalEl.setAttribute('hidden', '');
  triggerEl.focus();
}

Implémenter des liens d’évitement de navigation

Les utilisateurs de clavier doivent appuyer sur Tab pour parcourir chaque élément interactif avant le contenu principal — en-têtes, menus de navigation, barres de recherche — à chaque chargement de page. Les liens d’évitement sont la solution : un lien visuellement masqué tout en haut de la page qui devient visible au focus et amène directement les utilisateurs au contenu principal. Ils constituent une exigence de Niveau A des WCAG et l’un des gains rapides les plus impactants.

<!-- À placer comme premier élément dans <body> -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- Ancre cible sur le conteneur du contenu principal -->
<main id='main-content' tabindex='-1'>
  <!-- page content -->
</main>
/* Afficher le lien d’évitement uniquement au focus clavier */
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px 16px;
  z-index: 100;
  transition: top 0.2s;
}

.skip-link:focus {
  top: 0;
}

Construire des menus de navigation accessibles

Les menus de navigation avec sous-menus déroulants nécessitent une attention particulière. Le schéma d’interaction clavier correct pour un menu de navigation est le suivant : Tab se déplace entre les éléments de premier niveau ; Entrée ou Espace ouvre un sous-menu ; les flèches naviguent à l’intérieur du sous-menu ; et Échap ferme le sous-menu et renvoie le focus au déclencheur. Utilisez les attributs ARIA pour communiquer l’état. Les menus qui ne s’ouvrent qu’au survol, sans déclencheur clavier, sont inaccessibles et doivent être corrigés.

<nav aria-label='Main navigation'>
  <ul role='menubar'>
    <li role='none'>
      <button
        aria-haspopup='true'
        aria-expanded='false'
        aria-controls='products-menu'>
        Products
      </button>
      <ul role='menu' id='products-menu' hidden>
        <li role='none'>
          <a role='menuitem' href='/software'>Software</a>
        </li>
        <li role='none'>
          <a role='menuitem' href='/hardware'>Hardware</a>
        </li>
      </ul>
    </li>
  </ul>
</nav>

Utilisez aria-expanded='false' et aria-expanded='true' basculés via JavaScript pour communiquer l’état ouvert/fermé. Utilisez aria-haspopup='true' pour signaler que l’activation du bouton révèle un sous-menu. Assurez-vous que la touche Échap ferme le sous-menu et renvoie le focus au bouton déclencheur.

Gérer correctement tabindex

Il existe trois valeurs significatives de tabindex et chacune a un objectif distinct. tabindex='0' ajoute un élément non interactif dans l’ordre de tabulation naturel — utilisez-le lorsque vous avez réellement besoin qu’un élément normalement non focalisable (comme le conteneur d’un widget personnalisé) reçoive le focus. tabindex='-1' retire un élément de l’ordre de tabulation mais lui permet de recevoir le focus par programmation via .focus() — essentiel pour les cibles de modales et les destinations de liens d’évitement. Les valeurs positives de tabindex (comme tabindex='1' ou tabindex='5') remplacent l’ordre naturel d’une manière qui cause presque toujours plus de problèmes qu’elle n’en résout ; évitez-les complètement et corrigez plutôt l’ordre du DOM.

ARIA : un outil puissant, pas une solution miracle

Les attributs Accessible Rich Internet Applications (ARIA) étendent la sémantique du HTML pour aider les technologies d’assistance à comprendre les composants personnalisés que le HTML natif ne couvre pas — onglets, accordéons, vues arborescentes, carrousels, listes déroulantes complexes. Les attributs ARIA peuvent fournir un contexte supplémentaire, mais ils doivent compléter — et non remplacer — le HTML sémantique. Une erreur fréquente et dangereuse consiste à recourir à ARIA avant de se demander si un élément HTML natif pourrait faire l’affaire.

La première règle d’ARIA est : n’utilisez pas ARIA si un élément ou un attribut HTML natif peut faire le même travail. La deuxième règle : pas d’ARIA vaut mieux qu’une mauvaise ARIA. Un balisage ARIA incorrect — par exemple, appliquer role='menu' sans la hiérarchie appropriée d’enfants role='menuitem', ou utiliser aria-hidden='true' sur un élément qui reçoit le focus — peut nuire activement à l’accessibilité plutôt que de l’améliorer.

Lorsque ARIA est réellement nécessaire, les attributs les plus utiles pour les interactions clavier sont : aria-expanded pour communiquer l’état ouvert/fermé des éléments repliables ; aria-controls pour lier un déclencheur au contenu qu’il contrôle ; aria-haspopup pour signaler qu’un bouton ouvre un menu ou une boîte de dialogue ; aria-modal='true' sur les éléments de dialogue pour signaler que le contenu d’arrière-plan est inerte ; et les régions aria-live (polite pour les messages d’état, assertive pour les alertes urgentes) pour annoncer les changements de contenu dynamiques aux utilisateurs de lecteurs d’écran sans déplacer le focus.

Un point subtil mais important : les lecteurs d’écran comme NVDA et JAWS utilisent leurs propres raccourcis clavier — par exemple, appuyer sur H dans NVDA déplace l’utilisateur vers le titre suivant de la page. Les développeurs doivent éviter de créer des raccourcis applicatifs personnalisés qui entrent en conflit avec ces commandes de technologies d’assistance.

Tester l’accessibilité clavier

Le test le plus efficace que vous puissiez effectuer immédiatement ne nécessite aucun outil : débranchez votre souris et naviguez sur votre site en utilisant uniquement le clavier. Appuyez sur Tab pour avancer à travers les éléments interactifs, Shift+Tab pour revenir en arrière, Entrée pour activer les liens et les boutons, Espace pour cocher les cases et activer les boutons, Échap pour fermer les modales et les menus, et les flèches pour naviguer à l’intérieur des composants. Demandez-vous : pouvez-vous atteindre chaque élément interactif ? Pouvez-vous voir en permanence où vous vous trouvez ? Pouvez-vous accomplir chaque parcours utilisateur critique sans rester bloqué ?

Les outils automatisés peuvent détecter une partie significative des problèmes d’accessibilité clavier — en particulier les libellés manquants, les boutons vides et certains problèmes de gestion du focus. Des outils comme axe DevTools, WAVE et Lighthouse constituent de bons premiers filtres. Cependant, les outils automatisés ne détectent qu’environ 40% des problèmes WCAG. La visibilité du focus, l’ordre logique du focus et la gestion correcte de l’état ARIA nécessitent tous une évaluation humaine manuelle. Pour l’évaluation la plus complète, combinez l’analyse automatisée avec des tests manuels au clavier seul sur plusieurs navigateurs, et incluez des tests avec lecteurs d’écran comme NVDA (Windows), JAWS (Windows) ou VoiceOver (macOS/iOS).

Quelques scénarios spécifiques à tester manuellement à chaque fois que vous livrez un nouveau composant ou une nouvelle page : pouvez-vous ouvrir et fermer chaque menu déroulant, modale et accordéon en utilisant uniquement Tab, Entrée et Échap ? Lorsqu’une modale se ferme, le focus revient-il au déclencheur ? Le lien d’évitement de navigation apparaît-il et fonctionne-t-il dès la première pression sur Tab ? Y a-t-il des points où le focus Tab disparaît dans un élément sans indicateur visible ? Des en-têtes fixes ou des bannières de cookies masquent-ils les éléments focalisés lorsque vous tabulez à travers la page ?

Pour les équipes qui construisent des bibliothèques de composants, le WAI-ARIA Authoring Practices Guide (APG) publié par le W3C est la référence définitive pour les schémas d’interaction clavier sur des dizaines de types de widgets — des accordéons et carrousels aux sélecteurs de date et vues arborescentes. Chaque schéma précise exactement quelles touches doivent être prises en charge et quel comportement est attendu.

En-têtes fixes, pieds de page fixes et focus masqué

L’une des nouvelles exigences les plus pertinentes dans la pratique dans WCAG 2.2 est le Critère de succès 2.4.11 : Focus Not Obscured. Il traite d’un problème si courant qu’il définit pratiquement le web moderne : barres de navigation fixes, bannières de consentement aux cookies, widgets de chat et pieds de page fixes qui se superposent au contenu de la page. Lorsqu’un utilisateur de clavier tabule vers un élément qui défile derrière l’une de ces couches fixes, l’élément focalisé devient invisible — l’utilisateur ne peut pas voir avec quoi il interagit.

La correction nécessite une coordination entre CSS et JavaScript. Lorsqu’un élément reçoit le focus, le navigateur doit le faire défiler dans une zone visible. Mais un en-tête fixe avec position: fixed et une hauteur de, disons, 80px signifie que les 80px supérieurs de la fenêtre d’affichage sont occupés en permanence. Le scroll padding CSS peut compenser cela :

html {
  /* Hauteur de votre en-tête fixe + une petite marge */
  scroll-padding-top: 96px;
}

Cela indique au navigateur de décaler l’ancrage de défilement de la valeur spécifiée, de sorte que lorsqu’il fait défiler automatiquement un élément focalisé dans la vue, il tienne compte de l’en-tête fixe. Vous pouvez également avoir besoin d’un scroll-padding-bottom équivalent si vous avez un pied de page fixe. Pour les bannières de cookies ou les superpositions qui apparaissent et disparaissent, assurez-vous qu’elles ont des valeurs de z-index qui ne recouvrent pas l’élément focalisé, ou ajustez dynamiquement le scroll padding lorsque la bannière est visible.

Points clés à retenir

  • Le HTML sémantique est votre meilleur premier levier. Les éléments natifs comme <button>, <a> et les contrôles de formulaire sont accessibles au clavier par défaut. Chaque widget personnalisé construit à partir de div vous fait perdre de l’accessibilité que vous devrez ensuite reconstruire manuellement avec ARIA et JavaScript.
  • Ne supprimez jamais les indicateurs de focus sans les remplacer. La règle globale outline: none est l’une des choses les plus dommageables que vous puissiez mettre dans une feuille de style. Utilisez :focus-visible pour fournir un anneau de focus stylé et à fort contraste qui satisfait aux exigences minimales de taille et de contraste de WCAG 2.2.
  • Gérez le focus par programmation pour chaque interaction dynamique. Les modales, tiroirs, notifications toast et changements de contenu dynamiques nécessitent tous une gestion explicite du focus — déplacer le focus à l’intérieur, puis le restituer à la fermeture. Sans cela, les utilisateurs de clavier perdent leur position à chaque changement d’interface.
  • Ajoutez un lien d’évitement de navigation en haut de chaque page. Cela prend moins de 20 lignes de code et améliore considérablement l’expérience des utilisateurs de clavier qui, autrement, devraient tabuler à travers tout votre en-tête et votre navigation à chaque chargement de page.
  • Testez avec votre clavier avant de livrer. Les outils automatisés ne détectent qu’une fraction des problèmes d’accessibilité clavier. Un passage de dix minutes au clavier seul sur vos parcours utilisateurs les plus critiques fera ressortir de vrais blocages qu’aucun scanner ne trouvera — et peut être réalisé par n’importe quel développeur de l’équipe sans formation spécialisée.