5 vérifications d'accessibilité à effectuer avant la mise en production

Avant de livrer, effectuez cinq vérifications dans cet ordre : parcourez toute l’interface au clavier avec la touche Tab, lancez une analyse automatisée, vérifiez le HTML sémantique et les libellés, contrôlez le contraste des couleurs, puis testez à 200 % de zoom.

Quiconque a déjà mis en production une fenêtre modale qui piégeait discrètement les utilisateurs au clavier, pour ne le découvrir que des semaines plus tard via un rapport de bug, comprend pourquoi une telle liste existe. C’est typiquement le genre de problème que personne ne détecte avec une souris à la main.

Ensemble, ces vérifications prennent quelques minutes et permettent d’intercepter les défaillances d’accessibilité les plus courantes. Aucune expertise, aucun outillage coûteux, aucune semaine d’étude requise. Il s’agit d’une checklist d’accessibilité pré-livraison que vous pouvez appliquer à chaque pull request, conçue pour être rapide et honnête quant à ses propres limites. Elle ne rendra pas votre application pleinement conforme aux WCAG 2.2 (la norme actuelle, publiée comme Recommandation du W3C en octobre 2023 et adoptée sous la référence ISO/IEC 40500:2025), mais elle élimine les défaillances qui pénalisent le plus les utilisateurs réels. Faire un peu vaut nettement mieux que ne rien faire.

1. Parcourir toute l’interface au clavier avec la touche Tab

Le test le plus rapide et le plus réaliste est gratuit et prend moins d’une minute : écartez la souris, appuyez sur Tab pour parcourir la page, et vérifiez que le focus est visible, que tous les éléments interactifs sont atteignables et que vous pouvez sortir de chaque fenêtre modale sans y rester piégé. Surveillez quatre points : un indicateur de focus visible sur chaque élément, un ordre de tabulation logique, l’accessibilité de chaque bouton, lien et champ de saisie, et l’absence de piège au clavier (focus trap) dans les menus déroulants et les boîtes de dialogue.

Deux bugs sont à l’origine de la plupart des défaillances au clavier. Le premier : des contrôles personnalisés dont le contour natif a été masqué pour être restylé. Si c’est votre cas, rétablissez un style :focus (ou :focus-visible) visible :

.custom-checkbox input:focus-visible + .box {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}

Le second : une <div> cliquable. Remplacez-la par un <button>, qui reçoit le focus par défaut et intègre nativement l’activation par Entrée/Espace ainsi qu’un rôle de bouton, sans effort supplémentaire. Une <div> n’offre rien de tout cela :

// Not reachable by keyboard
<div onClick={handleClick}>Save</div>
// Focusable and operable by default
<button onClick={handleClick}>Save</button>

Votre parcours manuel à la touche Tab teste le scénario nominal que vous avez conçu. Le session replay de sessions réelles, lui, met en évidence les défaillances de clavier et de focus qui n’apparaissent qu’en conditions réelles : un utilisateur qui entre dans une modale au clavier sans pouvoir en ressortir, ou un focus qui disparaît en haut du document après la fermeture d’une boîte de dialogue, laissant l’utilisateur désorienté. Le replay révèle les endroits où le comportement réel du focus s’écarte de ce que votre analyse a validé.

2. Lancer une analyse automatisée (Lighthouse + axe DevTools)

Un outil d’analyse détecte entre un tiers et 40 % des problèmes d’accessibilité d’une page : un score au vert signifie donc que vous avez traité les corrections les plus évidentes (texte alternatif manquant, champs sans libellé, contraste insuffisant, attribut lang absent), rien de plus. Cette fourchette correspond à ce que rapportent généralement les éditeurs d’outils de test, et elle constitue un plancher plutôt qu’un plafond : l’étude de Deque publiée en 2021 soutient qu’en comptabilisant le volume de problèmes détectés plutôt que la proportion de critères de succès couverts, la couverture automatisée avoisine plutôt les 57 %. Dans tous les cas, les problèmes ainsi détectés sont les moins coûteux à corriger.

Lancez l’analyse depuis le panneau Lighthouse des Chrome DevTools : ouvrez les DevTools, sélectionnez le panneau Lighthouse, cochez Accessibility, puis générez le rapport. Une exécution limitée à l’accessibilité se termine rapidement. L’audit d’accessibilité de Lighthouse repose sur le jeu de règles open source axe-core de Deque, mais il n’en exécute qu’une partie : ajoutez donc l’extension axe DevTools, qui applique l’intégralité des règles et se concentre exclusivement sur l’accessibilité. Corrigez d’abord les problèmes Critical et Serious.

3. Vérifier le HTML sémantique et les libellés

Les lecteurs d’écran transmettent la structure via la sémantique : utilisez donc l’élément adapté à chaque usage : <button> pour les actions, <a href> pour la navigation, <ul>/<li> pour les listes, <nav> et <main> pour les points de repère, et des titres dans l’ordre (h1 → h2 → h3, sans jamais sauter de niveau). Lorsque tout est une <div>, un lecteur d’écran annonce « groupe, groupe, groupe » et la page perd toute structure.

Chaque champ de saisie doit être associé à un <label> ; les boutons composés uniquement d’une icône ont besoin d’un aria-label pour ne pas être simplement annoncés comme « bouton » :

<label htmlFor="email">Email</label>
<input id="email" type="email" />

<button aria-label="Copy to clipboard" onClick={copy}>
  <ClipboardIcon />
</button>

Un mode de défaillance courant en production : une bibliothèque de composants tierce soignée livre un balisage inaccessible, par exemple un accordéon ou une combobox dont l’<input> n’a pas de <label>, si bien que le lecteur d’écran n’annonce rien. Un composant esthétique n’est pas une garantie. Inspectez le DOM généré par la bibliothèque et vérifiez que les libellés sont réellement présents.

4. Contrôler le contraste des couleurs et ne pas se reposer sur la couleur seule

Pour le niveau AA, le texte doit présenter un rapport de contraste d’au moins 4,5:1 pour le texte normal et 3:1 pour le texte de grande taille (18 pt/24 px, ou 14 pt/18,66 px en gras), conformément au critère de succès WCAG 1.4.3. Considérez ces deux valeurs comme des seuils stricts. Aucun arrondi vers le haut n’est admis : une mesure à 4,499:1 échoue. Les composants d’interface et les icônes porteuses de sens relèvent d’un seuil distinct et plus bas, de 3:1 par rapport aux couleurs adjacentes (SC 1.4.11 Contraste des éléments non textuels), ce qui signifie qu’une couleur de texte conforme ne garantit en rien la conformité de vos boutons et bordures de formulaire.

Lighthouse signale de nombreux défauts de contraste textuel ; le WebAIM Contrast Checker confirme les rapports exacts. Concrètement : #999999 sur fond blanc donne 2,85:1 et échoue ; #595959 sur fond blanc donne 7:1 et réussit.

Le contraste ne fait pas tout. Ne signalez jamais une erreur par la couleur seule. Une bordure rouge est invisible pour de nombreux utilisateurs daltoniens : associez-la donc à une icône et à un texte pour que le sens subsiste sans la couleur. Ajoutez un message « ⚠ L’adresse e-mail est obligatoire » à côté du champ, et pas seulement un contour rouge.

5. Zoomer à 200 % et respecter la réduction des animations

À 200 % de zoom navigateur, rien ne doit se chevaucher, être tronqué ni imposer un défilement horizontal. Maintenez Ctrl/Cmd et appuyez sur + jusqu’à atteindre 200 %, puis naviguez dans l’interface : les conteneurs à largeur fixe et les dimensionnements en pixels sont les coupables habituels. Un dimensionnement en rem et l’ajout d’overflow-wrap maintiennent la fluidité des mises en page :

.container { max-width: 60rem; padding: 1rem; }
p { overflow-wrap: break-word; }

Respectez ensuite prefers-reduced-motion : encapsulez les animations non essentielles dans une media query afin que les utilisateurs ayant demandé à leur système d’exploitation de réduire les animations n’en subissent pas les effets. Ce réglage vous demande de supprimer les animations purement décoratives, et non de retirer toute animation : laissez donc fonctionner tout ce qui porte du sens (un indicateur de chargement, une barre de progression).

@media (prefers-reduced-motion: reduce) {
  /* Target the decorative motion, not every animation on the page.
     Loading spinners and other essential feedback should keep moving. */
  .parallax,
  .carousel-autoplay,
  .hero-animation {
    animation: none;
    transition: none;
  }
}

Bonus, 60 secondes : activez un lecteur d’écran et écoutez. Sur macOS, appuyez sur Cmd + F5 pour VoiceOver ; sur Windows, installez NVDA, gratuit. Parcourez la page avec Tab et vérifiez que les titres, les libellés et les champs sont annoncés de manière réellement intelligible.

Livrez, puis approfondissez

Ces cinq vérifications constituent un plancher, pas un plafond. Elles laissent de côté les motifs ARIA complexes, la gestion du focus dans les applications monopages et les tableaux de données accessibles : autant de chantiers bien réels, pour une prochaine fois. Choisissez votre prochaine fonctionnalité, effectuez ces cinq vérifications avant d’ouvrir la PR, et corrigez les problèmes critiques que vous y trouverez. Lorsque vous serez prêt à aller plus loin, les WCAG 2.2, WebAIM et la documentation accessibilité de MDN sont les sources de référence qui méritent votre temps. L’accessibilité est une direction dans laquelle on avance, et livrer ces cinq vérifications vous y fait progresser dès aujourd’hui.

FAQ

Quel rapport de contraste faut-il respecter pour l'accessibilité ?

Pour le niveau AA des WCAG 2.2, le texte normal doit présenter un rapport de contraste d'au moins 4,5:1 avec son arrière-plan, et le texte de grande taille (18 pt/24 px, ou 14 pt/18,66 px en gras) au moins 3:1, conformément au critère de succès 1.4.3. Les composants d'interface et les icônes porteuses de sens relèvent d'un critère distinct, le 1.4.11, qui exige 3:1 par rapport aux couleurs adjacentes. Aucun arrondi vers le haut n'est admis pour ces valeurs : une mesure à 4,499:1 échoue.

Les outils d'accessibilité automatisés détectent-ils tout ?

Non. Lighthouse et axe détectent entre un tiers et 40 % des problèmes d'accessibilité, essentiellement les corrections les plus évidentes : texte alternatif manquant, champs sans libellé, contraste insuffisant et attribut lang absent. Ils ne peuvent pas juger de la pertinence d'un texte alternatif, de la logique de l'ordre de tabulation, ni de la bonne gestion du focus après une interaction. Un score Lighthouse au vert valide les corrections faciles, pas l'ensemble de la page : associez donc chaque analyse à des tests au clavier et au lecteur d'écran.

Quelle est la différence entre Lighthouse et axe DevTools ?

L'audit d'accessibilité de Lighthouse repose sur le jeu de règles axe-core de Deque, dont il n'exécute qu'une partie, aux côtés des audits de performance, de SEO et de bonnes pratiques, le tout depuis le panneau Lighthouse des Chrome DevTools. L'extension navigateur axe DevTools exécute l'intégralité du jeu de règles axe-core et se concentre exclusivement sur l'accessibilité. Utilisez Lighthouse pour un premier passage rapide, puis axe DevTools pour une couverture plus approfondie, dédiée à l'accessibilité.

Quelle version des WCAG suivre en 2026 ?

Suivez les WCAG 2.2, la norme actuelle. Elles sont devenues Recommandation du W3C en octobre 2023, ont été mises à jour en décembre 2024 et correspondent désormais aussi à la norme ISO/IEC 40500:2025, identique à la version d'octobre 2023. Les WCAG 3.0 n'existent qu'à l'état de Working Draft, que le W3C révise périodiquement, avec une Candidate Recommendation prévue pour la fin 2027 et une Recommandation finale qui n'est pas attendue avant 2028. Les WCAG 3.0 n'ont aucune valeur normative à ce jour.