Outils de vérification ARIA

Aucun outil automatique ne peut vérifier l’accessibilité ARIA complètement. Les études convergent vers un chiffre : les outils automatiques détectent entre 30 et 40% des erreurs d’accessibilité. Le reste nécessite un test manuel : navigation au clavier, lecteur d’écran, ou simple lecture du code.

Cet article présente les outils utiles organisés par ce qu’ils font réellement, et documente ce qu’ils ne peuvent pas détecter.

Catégorie 1 : L’arbre d’accessibilité dans les DevTools

C’est le premier outil à consulter, avant tout test avec un lecteur d’écran. L’arbre d’accessibilité montre ce que le navigateur transmet aux technologies d’assistance (AT) après calcul de tous les attributs HTML et ARIA.

Chrome DevTools

Accès : F12 → onglet Elements → sélectionner un élément → panneau latéral Accessibility

Ce qu’il affiche :

button
  role:         button
  name:         "Fermer la fenêtre"     ← nom calculé (pas l'attribut brut)
  description:  "Action irréversible"  ← vient de aria-describedby
  state:        focusable, focused
  properties:
    expanded:   false                   ← vient de aria-expanded
    haspopup:   menu

La colonne “name” est la plus importante, c’est le nom que le lecteur d’écran annoncera. Il est calculé selon l’algorithme de nommage accessible (voir article Propriétés et états ). Un nom vide signifie un élément muet pour les AT.

Raccourci utile : dans l’onglet Elements, la case “Show user agent shadow DOM” permet de voir les éléments natifs des composants web, utile pour les plugins WordPress qui utilisent des web components.

Firefox DevTools

Accès : F12 → onglet Accessibilité → activer si nécessaire

Firefox affiche deux informations supplémentaires utiles :

Les problèmes détectés : une liste d’erreurs directement dans l’arbre (contraste, nom manquant, ordre de focus…) avec lien vers l’élément concerné.

Le calcul du contraste : en cliquant sur un élément texte, Firefox affiche le ratio de contraste calculé avec la couleur de fond réelle, en tenant compte des couches CSS superposées.

Comparaison Chrome vs Firefox

Chrome est plus précis sur le nom calculé des composants complexes. Firefox est plus proche du comportement NVDA. Consulter les deux quand le nom affiché diffère, si Firefox et Chrome ne sont pas d’accord, tester avec NVDA pour trancher.

Catégorie 2 : Extensions de navigateur

axe DevTools (Deque)

Installation via une extension Chrome, Firefox, Edge : Axe DevTools ↗ lien externe qui s'ouvre dans un nouvel onglet

Version gratuite : audit automatique de la page entière, intégration dans les DevTools (F12 → onglet axe DevTools).

Ce qu’axe fait bien :

• Zéro faux positif revendiqué : axe ne signale que ce dont il est certain. Un rapport “0 erreur” ne signifie pas “accessible”, mais signifie que les erreurs détectables automatiquement sont absentes.
• Règles WCAG 2.1 et 2.2, organisées par niveau (A, AA, AAA)
• Lien vers la documentation de chaque règle
• Sélection de l’élément concerné dans le DOM

Ce qu’axe ne détecte pas :

• La pertinence d’un alt (il vérifie sa présence, pas sa qualité)
• Les erreurs de comportement clavier
• Les live regions qui ne s’annoncent pas correctement
• L’ordre de tabulation illogique
• Les labels de formulaire présents mais non pertinents

Utilisation recommandée : lancer axe en début d’audit pour identifier les erreurs de structure évidentes, puis passer au test manuel.

WAVE (WebAIM)

Installation via une extension Chrome et Firefox : WAVE ↗ lien externe qui s'ouvre dans un nouvel onglet

Ce que WAVE fait différemment d’axe : au lieu d’un rapport séparé, WAVE affiche une couche d’overlay visuel directement sur la page. Des icônes colorées signalent les erreurs, alertes et bonnes pratiques directement à l’endroit du problème.

Icône rouge  = erreur (alt manquant, lien vide, label absent…)
Icône jaune  = alerte (à vérifier manuellement)
Icône verte  = bonne pratique détectée
Icône bleue  = élément structurel (titre, landmark, liste)

Ce que WAVE fait particulièrement bien :

• Visualisation des landmarks ARIA directement sur la page
• Affichage de la structure des titres (H1, H2, H3…) en overlay
• Détection des contrastes insuffisants avec les couleurs exactes
• Affichage du texte alternatif des images en overlay

Limitation principale : l’overlay modifie le rendu de la page, ce qui peut décaler les éléments et rendre l’interaction difficile sur les pages complexes.

ARC Toolkit (TPGi)

Installation via une extension Chrome : ARC Toolkit ↗ lien externe qui s'ouvre dans un nouvel onglet

ARC Toolkit est moins connu qu’axe ou WAVE mais propose des fonctionnalités spécifiques utiles en audit ARIA :

Ce qu’ARC fait que les autres ne font pas :

• Live regions : identifie et liste toutes les live regions de la page avec leur configuration (aria-live, aria-atomic, aria-relevant)
• Focus order : visualise l’ordre de tabulation avec des numéros sur chaque élément focusable
• Colour contrast : mesure les contrastes sur les éléments texte ET les composants d’interface (bordures, icônes)
• Keyboard navigation : mode de test clavier intégré avec visualisation du focus

Utilisation recommandée : en complément d’axe, spécifiquement pour vérifier les live regions et l’ordre de tabulation.

Un mot sur Lighthouse

Lighthouse (intégré dans Chrome DevTools, onglet “Lighthouse”) génère un score d’accessibilité en pourcentage. Ce score est trompeur : un site à 95/100 peut avoir plus de dix violations WCAG réelles. Le score mesure le pourcentage de vérifications automatiques réussies, pas le pourcentage d’accessibilité réelle. Ne jamais utiliser ce score comme indicateur de conformité.

Catégorie 3 : Mesure du contraste

Colour Contrast Analyser (TPGi)

Téléchargement via une application desktop Windows et macOS : Colour Contrast Analyser ↗ lien externe qui s'ouvre dans un nouvel onglet

C’est l’outil de référence pour la mesure manuelle du contraste. Indispensable car les outils automatiques ne peuvent pas toujours mesurer le contraste en contexte réel (texte sur image, dégradé, couleur calculée par CSS).

Fonctionnement :

• Pipette pour sélectionner les couleurs directement sur l’écran
• Calcul instantané du ratio (WCAG AA : 4,5:1 pour le texte normal, 3:1 pour le texte grand et les composants)
• Indication pass/fail par niveau WCAG

Cas d’usage typique en audit :

1. Ouvrir la page à auditer
2. Ouvrir Colour Contrast Analyser
3. Pipette sur la couleur du texte → pipette sur la couleur du fond
4. Lire le ratio et le verdict WCAG

Indispensable pour :

• Texte sur image de fond (hero, carrousel)
• Texte sur fond dégradé
• Icônes et bordures de composants interactifs (critère 3.3 RGAA)
• Couleurs définies par des variables CSS que les outils automatiques ne résolvent pas

Catégorie 4 : Bookmarklets

Les bookmarklets s’exécutent dans n’importe quel navigateur sans installation d’extension. Utiles pour des vérifications rapides sur un site en production auquel on n’a pas accès en développement.

tota11y (Khan Academy)

Ajout : glisser le lien bookmarklet depuis tota11y ↗ lien externe qui s'ouvre dans un nouvel onglet dans la barre de favoris.

Affiche un overlay visuel sur la page avec :

• Hiérarchie des titres
• Labels des éléments de formulaire
• Contrastes
• Liens sans intitulé

ANDI (Social Security Administration)

Ajout : bookmarklet depuis ANDI ↗ lien externe qui s'ouvre dans un nouvel onglet

Outil développé par l’administration américaine de la sécurité sociale. Particulièrement précis sur l’analyse des éléments interactifs et leurs attributs ARIA. Affiche le nom accessible calculé pour chaque élément sélectionné, similaire à l’arbre d’accessibilité des DevTools mais avec une interface plus orientée audit.

Catégorie 5 : Le lecteur d’écran (NVDA)

Aucun outil de cette liste ne remplace un test avec un vrai lecteur d’écran. L’arbre d’accessibilité dit ce que le navigateur transmet. NVDA dit ce que l’utilisateur entend, ce n’est pas toujours la même chose.

Installation et configuration minimale

1. Télécharger NVDA ↗ lien externe qui s'ouvre dans un nouvel onglet
2. Installation standard
3. Au premier lancement, activer le mode “Voix synthétique” (eSpeak NG par défaut)
4. Réduire la vitesse de lecture : Insert+Ctrl+↓ (ralentir), la valeur par défaut est difficile à suivre en audit

Configuration recommandée pour l’audit :

• Vitesse de lecture : 50-60% (réglage dans les préférences vocales)
• Ponctuation : “some” annonce les signes importants sans tout lire
• Désactiver “Dire tout” automatique au chargement de page

Les 5 vérifications essentielles avec NVDA

1. Navigation par titres (H)

Parcourir la page en sautant de titre en titre. Vérifier que la hiérarchie est logique et que tous les contenus importants sont précédés d’un titre accessible.

2. Navigation par landmarks (D)

Vérifier que les grandes zones de la page sont identifiables : en-tête, navigation, contenu principal, pied de page. Chaque <nav> doit avoir un label distinct.

3. Liste des liens (Insert+F7)

Affiche tous les liens de la page dans une liste. Vérifier que chaque lien a un intitulé pertinent hors contexte. “En savoir plus” répété 5 fois est une erreur détectable ici.

4. Navigation dans les formulaires (F)

Parcourir les champs de formulaire. Vérifier que chaque champ est annoncé avec son label et, le cas échéant, ses contraintes (requis, format attendu).

5. Test d’un composant dynamique

Interagir avec un accordéon, un menu, une modale. Vérifier que :

• aria-expanded est annoncé au focus et mis à jour au clic
• Le focus se déplace correctement (modale : focus piégé à l’ouverture)
• La fermeture retourne le focus au bon endroit

Ce que les outils automatiques ne peuvent pas détecter

C’est la partie la plus importante de cet article. Un audit “vert” chez axe + WAVE ne signifie pas un site accessible. Voici ce que seul un test manuel révèle.

Pertinence des textes alternatifs

Les outils vérifient que alt est présent sur les images. Ils ne peuvent pas évaluer si le texte est pertinent.

<!-- axe : ✓ alt présent -->
<img src="reunion-conseil.jpg" alt="photo">

<!-- axe : ✓ alt présent -->
<img src="reunion-conseil.jpg" alt="Vue de la salle des réunions avec les conseillers municipaux lors de la séance du 15 mars 2025">

Seul un auditeur humain peut dire lequel est correct dans ce contexte.

Logique de navigation au clavier

L’ordre de tabulation peut être numériquement correct (tous les éléments sont focusables) mais logiquement incohérent (le focus saute du header au footer avant d’atteindre le contenu principal).

<!-- Ordre DOM incorrect — les outils ne le détectent pas -->
<footer><!-- footer en premier dans le DOM, affiché en bas par CSS --></footer>
<main><!-- main après, mais affiché en haut --></main>

Comportement des live regions

Un outil peut vérifier qu’une zone a aria-live="polite". Il ne peut pas vérifier que le message est effectivement annoncé, si la zone est créée et remplie simultanément ( anti-pattern 5 ), aucun outil ne le détecte.

Focus dans les composants complexes

La gestion du focus dans une modale (piège, déplacement à l’ouverture, retour à la fermeture) ne peut être testée qu’en interagissant avec le composant.

Pertinence des labels hors contexte

<!-- axe : ✓ le lien a un intitulé -->
<a href="/pdf-budget-2025.pdf">Télécharger</a>

<!-- axe : ✓ le lien a un intitulé -->
<a href="/pdf-budget-2025.pdf">Télécharger le budget primitif 2025 (PDF, 2 Mo)</a>

Dans la liste des liens (Insert+F7 dans NVDA), 12 liens “Télécharger” sont impossibles à distinguer. Seul un test manuel révèle le problème.

Erreurs de sémantique logique

<!-- aria-expanded présent — axe ne signale rien -->
<button aria-expanded="false">Voir les tarifs</button>
<!-- Mais aria-expanded n'est jamais mis à jour au clic -->
<!-- → erreur fonctionnelle, non détectable automatiquement -->

L’IA comme outil d’analyse, promesses et limites

Fournir le HTML rendu d’une page à un Large Language Model (LLM) (Claude, GPT-5) permet d’identifier des problèmes que les outils automatiques manquent : structure de titres incohérente, landmarks manquants, liens non descriptifs hors contexte, etc.

Les résultats sont souvent pertinents, mais vérifier chaque signalement reste indispensable, les LLM peuvent interpréter incorrectement certains patterns ou produire des faux positifs. Autre coût souvent sous-estimé : lire, trier et vérifier les résultats d’une analyse IA prend presque autant de temps qu’une vérification manuelle rapide. L’IA est un filet supplémentaire, pas un raccourci.

Récapitulatif : Quel outil pour quel besoin

Les limites à connaître avant de conclure

Un audit “vert” chez axe + WAVE couvre ~35% des critères WCAG. Les 65% restants nécessitent un test manuel. C’est le chiffre qu’il faut citer quand un client demande “est-ce qu’on peut juste lancer un outil automatique ?”

Les outils automatiques ont des faux négatifs, pas de faux positifs (pour axe). Ce qu’ils signalent est une erreur. Ce qu’ils ne signalent pas peut quand même être une erreur.

L’arbre d’accessibilité est plus fiable que le code HTML pour comprendre ce que le lecteur d’écran voit. Si le HTML est compliqué, lire l’arbre d’abord.

NVDA annonce parfois différemment de l’arbre d’accessibilité : en cas de doute, NVDA a le dernier mot. C’est lui qui représente l’expérience réelle de l’utilisateur.