Les tests d'accessibilité vérifient que votre application fonctionne pour les utilisateurs qui naviguent au clavier, utilisent des lecteurs d'écran, ou s'appuient sur des logiciels d'agrandissement et de contrôle vocal.
Pourquoi les tests d'accessibilité comptent en 2026
Environ 15% de la population mondiale vit avec une forme de handicap. Ce n'est pas un cas limite marginal ; c'est un segment d'utilisateurs plus large que la plupart des principaux groupes démographiques des entreprises. Pourtant, l'accessibilité était traitée comme une option de design ou une case à cocher légale réservée aux sites gouvernementaux. C'est en train de changer.
La date limite du European Accessibility Act (EAA) est passée en juin 2025. Les entreprises du secteur privé qui vendent des produits ou services dans l'UE doivent désormais respecter les exigences d'accessibilité, sous peine de sanctions réglementaires et d'amendes. Le Royaume-Uni, le Canada et l'Australie ont leurs propres cadres. Aux États-Unis, l'ADA s'applique aux produits numériques depuis des années via des contentieux. WCAG 2.1 AA est le référentiel international que la plupart de ces cadres citent.
Le risque légal est réel, mais ce n'est pas la seule raison d'agir. Les applications inaccessibles affichent des taux de rebond plus élevés, génèrent plus de demandes de support, et exposent les entreprises à des atteintes à leur réputation. Un tunnel de paiement qu'on ne peut pas compléter au clavier exclut les utilisateurs qui ne peuvent pas utiliser de souris. Un formulaire avec des champs non étiquetés est inutile pour un utilisateur de lecteur d'écran. Ces situations ne sont pas théoriques. Ce sont des schémas qui apparaissent en production tous les jours, parfois pendant des années avant que quelqu'un ne s'en aperçoive.
Les ingénieurs QA capables de détecter ces problèmes avant la livraison sont réellement précieux. Les outils existent. Les techniques s'apprennent. Ce qui manque, c'est la connaissance.
Les bases de WCAG 2.1 pour les testeurs : ce que signifie POUR en pratique
WCAG 2.1 (Web Content Accessibility Guidelines) est organisé autour de quatre principes, abrégés en POUR : Perceivable (perceptible), Operable (utilisable), Understandable (compréhensible) et Robust (robuste).
Perceivable (perceptible) signifie que les utilisateurs peuvent percevoir tout le contenu via au moins un sens. Les images ont besoin de textes alternatifs. Les vidéos ont besoin de sous-titres. Le contenu ne peut pas s'appuyer sur la couleur seule pour transmettre une information ("les champs obligatoires sont en rouge" est un échec si le rouge est le seul indicateur). Operable (utilisable) signifie que toutes les fonctionnalités sont accessibles sans souris. La navigation au clavier doit atteindre chaque élément interactif. Les utilisateurs doivent avoir suffisamment de temps pour accomplir les tâches (pas de sessions qui expirent automatiquement sans avertissement). Rien ne clignote plus de trois fois par seconde (risque d'épilepsie). Understandable (compréhensible) signifie que l'interface se comporte de façon prévisible et que les messages d'erreur expliquent ce qui s'est mal passé. Un formulaire qui dit "Saisie invalide" est un échec. "L'email doit contenir un symbole @" n'en est pas un. Robust (robuste) signifie que le contenu peut être interprété par un large éventail de technologies d'assistance. C'est là que le HTML sémantique compte : un stylisé pour ressembler à un bouton ne l'est généralement pas.
La conformité AA, le standard requis par l'EAA et la plupart des cadres légaux, signifie que tous les critères de succès Niveau A et Niveau AA sont respectés. Ensemble, A et AA imposent notamment plusieurs garanties : les images ont un texte alternatif (A), la couleur n'est pas le seul indicateur visuel (A), le rapport de contraste atteint au moins 4,5:1 pour le texte normal (AA). Toutes les fonctionnalités sont accessibles au clavier (A), les indicateurs de focus sont visibles (AA), et les champs de formulaire ont des labels associés programmatiquement (A).
En tant que testeur, vous n'avez pas besoin de mémoriser la spécification complète. Vous avez besoin de connaître les critères les plus fréquemment violés et comment les tester.
Tests a11y manuels : navigation au clavier et lecteurs d'écran
Aucun outil automatisé ne détectera toutes les défaillances d'accessibilité. Les tests manuels, en particulier avec un clavier et un lecteur d'écran, sont irremplaçables.
La navigation au clavier est la première chose à tester. Débranchez votre souris (ou désactivez les événements pointeur dans DevTools) et naviguez dans votre application uniquement avec Tab, Shift+Tab, Entrée, Espace, et les touches fléchées. Chaque élément interactif (liens, boutons, champs de formulaire, menus déroulants, modales, sélecteurs de date) doit être atteignable et utilisable. L'ordre de tabulation doit suivre une séquence de lecture logique, généralement de gauche à droite et de haut en bas. Le focus ne doit jamais être piégé, sauf intentionnellement à l'intérieur d'une modale où il doit être contraint jusqu'à la fermeture de la modale.
Le schéma d'échec clavier le plus courant : un développeur crée une boîte de dialogue modale, mais quand vous appuyez sur Tab à l'intérieur, le focus s'échappe vers la page d'arrière-plan. La modale est visuellement présente, mais l'utilisateur au clavier interagit désormais avec le contenu en dessous sans le savoir.
Les indicateurs de focus font partie de ce test. Chaque élément focalisé doit avoir un indicateur visible : le contour par défaut du navigateur, un style personnalisé, n'importe quoi. Les designs qui suppriment les styles :focus avec outline: none en CSS créent un focus invisible, rendant la navigation au clavier complètement inutilisable. Cherchez ça dans chaque sprint review.
Les tests avec lecteur d'écran sont plus difficiles et demandent de la pratique, mais même une familiarité de base est extrêmement précieuse. Les deux lecteurs d'écran gratuits les plus courants sont NVDA (Windows, gratuit) et VoiceOver (macOS et iOS, intégré). JAWS est courant en environnement d'entreprise mais est payant.
Installez NVDA et ouvrez votre application. Éteignez votre écran si vous voulez vivre la vraie expérience. Naviguez avec Tab pour atteindre les éléments interactifs, et utilisez le mode navigation de NVDA (touches fléchées) pour lire le contenu statique. Écoutez ce que le lecteur d'écran annonce. Un bouton qui dit "Cliquez ici" ne dit rien à l'utilisateur. Un bouton qui dit "Valider le paiement" lui dit exactement ce qui va se passer. Un bouton icône sans aria-label annonce son rôle comme "bouton" mais rien sur sa fonction. Un champ de formulaire non étiqueté est annoncé comme "éditer" sans contexte sur ce qu'il faut saisir.
Vous n'avez pas besoin de devenir expert en lecteur d'écran pour trouver des bugs significatifs. Passez 30 minutes à naviguer dans vos principaux flux utilisateur avec NVDA. Les problèmes qui rendent l'expérience cassée ou confuse apparaîtront rapidement.
La combinaison des tests clavier et d'une utilisation basique du lecteur d'écran détectera la majorité des bugs a11y graves qui existent dans une application web typique.
Tests a11y automatisés avec axe-core et Playwright
Les outils automatisés ne remplacent pas les tests manuels. Mais ils détectent de façon fiable un sous-ensemble de problèmes à grande échelle : texte alternatif manquant, contraste de couleur insuffisant, labels de formulaire absents, usage ARIA incorrect. Les intégrer en CI permet de détecter les régressions avant qu'elles n'atteignent les testeurs.
Le moteur le plus utilisé est axe-core, maintenu par Deque Systems. Il alimente les extensions de navigateur (axe DevTools), Lighthouse, et diverses intégrations de frameworks. Pour les équipes qui utilisent déjà Playwright, le package @axe-core/playwright ajoute des scans a11y avec une configuration minimale.
Voici un test Playwright de base qui scanne une page pour détecter les violations d'accessibilité :
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
test("la page d'accueil ne doit pas avoir de violations d'accessibilité détectables automatiquement", async ({ page }) => {
await page.goto('/');
const accessibilityScanResults = await new AxeBuilder({ page }).analyze();
expect(accessibilityScanResults.violations).toEqual([]);
});
Ce test échoue si axe trouve des violations. En pratique, notamment sur une base de code existante, mieux vaut commencer par tagguer plutôt que bloquer. Logguez les violations, corrigez de façon incrémentale, et ajoutez des assertions au fur et à mesure que le backlog se vide.
Pour un scan plus ciblé, vous pouvez analyser des composants spécifiques et filtrer selon un niveau WCAG particulier :
test('le formulaire de checkout respecte WCAG 2.1 AA', async ({ page }) => {
await page.goto('/checkout');
const results = await new AxeBuilder({ page })
.include('#checkout-form')
.withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
.analyze();
if (results.violations.length > 0) {
const violationDetails = results.violations.map(v => ({
id: v.id,
impact: v.impact,
description: v.description,
nodes: v.nodes.map(n => n.html),
}));
console.log('Violations:', JSON.stringify(violationDetails, null, 2));
}
expect(results.violations).toEqual([]);
});
Le filtre .withTags() limite le scan à des critères WCAG spécifiques. wcag2a, wcag2aa et wcag21aa ensemble couvrent le niveau de conformité AA. Ajoutez ces tests à votre pipeline CI aux côtés de vos tests fonctionnels existants.
axe-core détecte environ 30 à 40% des problèmes WCAG automatiquement. Ce n'est pas une raison de ne pas l'utiliser ; détecter un tiers des problèmes automatiquement à grande échelle est réellement utile. Mais un scan axe au vert n'est pas une certification d'accessibilité. C'est un plancher, pas un plafond.
Ce que les outils automatisés ne détectent pas
C'est là que vivent les problèmes a11y les plus critiques, et c'est pourquoi les tests manuels sont non négociables.
Le texte alternatif significatif est l'exemple le plus clair. Un outil automatisé peut détecter qu'un élément ![]()
alt. C'est un contrôle pass/fail. Il ne peut pas déterminer si le texte alternatif est précis ou significatif. Une image d'un graphique linéaire montrant une baisse de chiffre d'affaires décrite comme alt="graphique" passe le contrôle automatisé. L'utilisateur de lecteur d'écran entend "graphique" et n'a aucune information. L'échec est sémantique, pas structurel.
L'ordre de lecture logique est un autre exemple. L'ordre du DOM détermine comment les lecteurs d'écran traversent la page. Le style visuel peut faire apparaître des éléments dans un ordre complètement différent de leur ordre dans le DOM. Un utilisateur voyant lit le bouton "Ajouter au panier" après la description du produit parce qu'il est positionné en dessous. Si l'ordre du DOM place le bouton avant le titre du produit, l'utilisateur de lecteur d'écran entend le bouton avant de comprendre quel produit il regarde. Les outils automatisés peuvent signaler certains réordonnements, mais les mises en page complexes nécessitent un humain pour évaluer l'expérience d'écoute réelle.
Le contraste de couleur en contexte est partiellement automatisable mais peut produire de faux résultats. axe scanne les styles calculés, mais les éléments superposés, les images de fond et les arrière-plans en dégradé peuvent tromper le scanner. Testez le contraste manuellement avec le vérificateur de contraste du navigateur ou des outils comme WebAIM Contrast Checker pour les designs visuels complexes.
Les noms accessibles pour les boutons icônes sont une défaillance récurrente que les outils détectent partiellement. Un Bugs a11y courants que les ingénieurs QA trouvent
Ces schémas apparaissent régulièrement dans des produits de toutes tailles. Les connaître permet de les reconnaître immédiatement.
Labels de formulaire manquants : le plus courant. Un placeholder visible dans un champ n'est pas un label accessible. Quand l'utilisateur commence à taper, le placeholder disparaît, et un utilisateur de lecteur d'écran qui revient sur le champ n'entend que "éditer" sans contexte. Le correctif est un élément for/id, ou un attribut aria-label ou aria-labelledby. Trouvez-les en tabbant vers chaque champ de formulaire et en écoutant dans NVDA.
Éléments interactifs non sémantiques : apparaissent quand un développeur crée un ou role, tabindex et de gestionnaires d'événements clavier explicites pour être accessible. Ce sont des corrections coûteuses ; les trouver tôt évite une refactorisation significative.
Mauvaise gestion du focus dans les modales et les panneaux latéraux : apparaît dans presque tous les composants de dialogue construits sur mesure. La modale s'ouvre, mais le focus reste sur le bouton qui l'a déclenchée (maintenant derrière l'overlay). L'ordre de tabulation fuit vers la page d'arrière-plan. Quand la modale se ferme, le focus tombe en haut du document au lieu de retourner au déclencheur. Testez chaque modale en l'ouvrant avec Tab+Entrée et en naviguant entièrement au clavier.
Mises à jour de contenu dynamique sans annonce : touche fortement les applications single-page. Un utilisateur soumet un formulaire, la page affiche un message de succès, mais le message apparaît dans une autre partie du DOM sans changement de focus ni région en direct. L'utilisateur de lecteur d'écran n'a aucune idée que la soumission a fonctionné. Les régions ARIA en direct (role="status" ou aria-live="polite") résolvent ça, mais seulement si quelqu'un a pensé à les ajouter.
Pièges clavier dans les widgets personnalisés : les menus déroulants, sélecteurs de date et éditeurs de texte enrichi personnalisés piègent fréquemment le focus clavier. Ils n'implémentent pas non plus les interactions clavier standard (touches fléchées pour la navigation dans un menu déroulant, Échap pour fermer). Testez chaque composant interactif personnalisé avec le clavier uniquement.
Comment rédiger des rapports de bugs a11y
Les rapports de bugs d'accessibilité ont besoin de plus de contexte que les bugs UI standards. L'impact dépend de la technologie d'assistance concernée et du critère de succès WCAG violé. Un rapport vague ("le lecteur d'écran ne fonctionne pas ici") ne donne rien d'exploitable aux développeurs.
Un bon rapport de bug a11y inclut :
Le critère WCAG violé. Chaque défaillance correspond à un critère. Un label manquant viole WCAG 1.3.1 (Information et relations) et 4.1.2 (Nom, rôle, valeur). Un indicateur de focus manquant viole WCAG 2.4.7 (Focus visible). Incluez l'identifiant et le nom du critère. Ça indique au développeur exactement quelle est l'exigence, et ça documente la lacune de conformité pour tout audit.
La technologie d'assistance et le navigateur utilisés. "NVDA 2024.1 + Chrome 124 sur Windows 11" est exploitable. "Lecteur d'écran" ne l'est pas. Les combinaisons AT/navigateur se comportent différemment, et les développeurs ont besoin de la pile spécifique pour reproduire le problème.
L'annonce attendue vs. réelle. Pour les bugs de lecteur d'écran, écrivez ce que l'AT a annoncé et ce qu'il aurait dû annoncer. "Annoncé : 'bouton'. Attendu : 'Valider le paiement, bouton'." C'est la description réelle de l'échec.
Des étapes de reproduction utilisant l'AT, pas la souris. "Taber jusqu'au champ email, écouter l'annonce de NVDA", pas "cliquer sur le champ email." Les étapes doivent être reproductibles en utilisant uniquement la méthode d'interaction concernée.
Une évaluation d'impact. Utilisez les niveaux d'impact WCAG : critique (bloquant pour les utilisateurs AT), sérieux (difficulté majeure), modéré (quelques difficultés), mineur. Un label de modale manquant est critique. Une structure de titre sous-optimale est mineure à modérée. L'impact guide la priorité de correction.
Ne marquez pas les bugs a11y comme "nice to have" sauf s'ils sont vraiment mineurs. Un formulaire qu'on ne peut pas soumettre au clavier est un bloquant pour les utilisateurs qui n'utilisent que le clavier. La même sévérité s'applique qu'un bouton de checkout qui ne fonctionne pas pour les utilisateurs souris. Appliquez les mêmes critères de sévérité que pour tout autre défaut fonctionnel.
Comment appliquer ça dès maintenant
Pas besoin d'auditer tout votre produit en un sprint. Commencez petit et construisez l'habitude.
Cette semaine : Installez NVDA (gratuit, Windows) ou activez VoiceOver (Cmd+F5 sur macOS). Ouvrez une page de votre application, idéalement un formulaire ou un flux de modale. Tabbez à travers. Écoutez ce que NVDA annonce pour chaque élément. Signalez tout ce qui est confus ou silencieux.
Ce sprint : Ajoutez le package @axe-core/playwright à votre projet. Écrivez un test qui scanne votre page la plus critique, par exemple la connexion, le checkout, ou l'onboarding. Lancez-le en CI. Ne bloquez pas encore le build ; commencez par loguer les violations pour que l'équipe voie la ligne de base.
Sur le mois suivant : Ajoutez les vérifications de navigation clavier à votre definition of done pour les nouvelles fonctionnalités. Incluez "testé avec le clavier uniquement" dans votre checklist de PR. Pour chaque fonctionnalité avec des formulaires ou des modales, passez dix minutes à tester l'ordre de tabulation et la gestion du focus.
Pour vos rapports de bugs a11y : Créez un template dans votre outil de suivi avec des champs pour le critère WCAG, l'AT concerné, et l'annonce attendue. Utiliser le template prend trente secondes. Avoir ces informations dans le rapport économise une heure d'échanges avec le développeur.
La deadline de l'EAA est passée. Les entreprises qui n'ont pas traité l'accessibilité opèrent désormais sous une exposition légale. Les ingénieurs QA capables d'identifier, documenter et suivre les défaillances d'accessibilité réduisent directement ce risque. Surtout, les défauts que vous détectez avant la production atteignent les utilisateurs qui en ont besoin. Un utilisateur de lecteur d'écran qui complète un checkout sans assistance, un utilisateur au clavier qui navigue dans un formulaire sans se retrouver piégé : c'est le résultat concret.
Commencez par un test clavier. Construisez à partir de là.
→ See also: Tests d'Accessibilité avec Playwright: Vérifications a11y Automatisées | Événements Clavier et Souris dans Playwright | Bases des Tests d'Utilisabilité: Ce que les Ingénieurs QA Doivent Savoir
