Faire auditer l'accessibilité d'une page

1Demander des mesures, jamais des impressions

La différence entre un audit utile et une impression tient à la formulation du prompt. Compare :

Cette page est-elle accessible ?

et :

Ouvre [URL]. Pour chaque element de texte visible, releve la couleur du
texte, la couleur de fond effective, la taille en px et la graisse.
Calcule le rapport de contraste. Rends-moi un tableau : selecteur, texte,
ratio, seuil applicable (4,5:1 ou 3:1 selon la taille), conforme ou non.
Ne me donne aucune appreciation generale.

Le second te rend un tableau que tu peux contester ligne par ligne. Le premier te rend un avis.

2Relever l'ordre de tabulation

L'ordre du focus doit suivre l'ordre de lecture. Il s'en écarte dès qu'on déplace visuellement un bloc en CSS sans toucher au HTML.

Ouvre [URL]. Simule des appuis successifs sur Tab depuis le haut de la
page. Apres chaque appui, rends-moi : le rang, la balise, le nom
accessible de l'element focalise, et sa position (x, y) a l'ecran.
Arrete-toi apres 30 appuis ou en fin de page.

Ce que tu cherches dans le tableau obtenu :

• Un saut de position qui remonte. L'ordre visuel et l'ordre du focus divergent.
• Un nom accessible vide. Un bouton sans libellé, souvent une icône seule.
• Un élément focalisable invisible. Un menu fermé dont les liens restent dans l'ordre de tabulation.
• Un piège. Le focus qui ne sort plus d'une zone, typiquement une fenêtre modale mal fermée.

3Vérifier les libellés et les noms accessibles

Un champ sans libellé associé n'est pas utilisable au lecteur d'écran, même si un texte est posé juste à côté visuellement.

Ouvre [URL]. Pour chaque champ de formulaire, bouton et lien, rends-moi :
la balise, le nom accessible calcule, et d'ou il vient (element label,
aria-label, aria-labelledby, ou contenu textuel). Signale ceux dont le nom
est vide, ou vaut « Lire la suite », « Cliquez ici », « En savoir plus ».

Les noms génériques ne sont pas un défaut de style : un lecteur d'écran peut lister les liens d'une page hors de leur contexte, et douze liens « En savoir plus » y deviennent indiscernables.

Même travail pour les images :

Liste toutes les images de la page avec leur attribut alt. Signale celles
sans attribut alt, celles dont le alt reprend le nom de fichier, et celles
dont le alt est vide alors que l'image porte de l'information.

Un alt vide est correct et même recommandé pour une image décorative. C'est l'absence d'attribut qui pose problème.

4Regarder le focus visible

Le critère 2.4.7 demande que l'indicateur de focus clavier soit visible. La règle outline: none posée sans remplacement le supprime, et c'est un des défauts les plus fréquents.

Cherche dans le CSS du projet toutes les regles qui mettent outline a
none ou a 0. Pour chacune, dis-moi si une alternative visible est definie
sur le meme selecteur (bordure, ombre portee, changement de fond).

Puis en visuel :

Ouvre [URL]. Pour les cinq premiers elements focalisables, prends une
capture avec le focus dessus. Dis-moi pour chacun si un indicateur est
visible et decris-le.

5Ajouter un contrôle automatique

Deux outils en ligne de commande, tous deux installables depuis npm.

npm install -g @axe-core/cli
axe https://ton-site.fr

La commande s'appelle axe. Elle accepte notamment --tags pour restreindre à un jeu de règles, --include et --exclude pour cibler une zone par sélecteur, --save pour écrire le résultat en JSON, et --exit pour renvoyer un code d'échec en cas de violation, ce qui la rend utilisable dans une intégration continue.

npm install -g lighthouse
lighthouse https://ton-site.fr --only-categories=accessibility --output=json

L'option --only-categories accepte accessibility, best-practices, performance et seo.