Un relecteur a trouvé trois critères WCAG erronés dans mon extension d'accessibilité. J'ai vérifié, et j'en ai trouvé huit.

#wordpress #wcag #a11y #webdev

Je développe un scanner d'accessibilité pour WordPress. La semaine dernière, le
relecteur d'une place de marché l'a rejeté, et parmi les motifs figurait celui-ci :

Les règles de conformité doivent être corrigées. « Langue des passages » ne
valide que les attributs lang déjà présents et ne peut pas détecter les
passages en langue étrangère non balisés ; la règle du landmark principal est
WCAG 1.3.6 de niveau AAA mais elle est présentée comme un contrôle AA ; et les
id en double ne devraient pas être présentés comme un manquement WCAG 2.2 au
titre du 4.1.1.

Trois constats. Tous les trois justes. Ce qui suit est ce qui s'est passé quand
j'ai cessé de corriger les trois et vérifié les vingt-deux autres.

La règle qui n'existe plus

Je commence par le troisième, parce que c'est le plus facile à vérifier et le
plus largement faux.

Le critère de succès 4.1.1 Parsing a été retiré des WCAG 2.2. Ni déprécié ni
assoupli : retiré. La Recommandation du W3C le mentionne dans la
section conformité comme « Parsing (Obsolete and removed) ». Il est parti parce
que ce contre quoi il protégeait — les technologies d'assistance qui butaient sur
un balisage mal formé — a cessé d'être un mode de défaillance réel dès lors que
les navigateurs et les API d'accessibilité ont convergé sur la façon de récupérer
un HTML incorrect.

Mon scanner signalait les attributs id en double comme un manquement au WCAG
4.1.1. Au regard des WCAG 2.2, ce critère n'est plus là pour être enfreint.

Les id en double méritent toujours d'être corrigés. Ils cassent les associations
label for et les références aria-labelledby, si bien que c'est le mauvais
élément qui est annoncé, ou aucun. Mais c'est un problème de 4.1.2 lorsqu'il
casse réellement un nom accessible, et le détecter est un contrôle différent du
comptage des id en double. Ce que j'avais était un contrôle générique d'id en
double portant le numéro d'un critère retiré.

Puis j'ai vérifié le reste

Le relecteur en avait trouvé trois. J'aurais pu en corriger trois. À la place,
j'ai pris les 25 règles et vérifié chacune face à la Recommandation WCAG 2.2 et
face à la manière dont axe-core classe la règle équivalente — parce
qu'axe-core est l'implémentation de référence sur laquelle repose une grande
partie de ce secteur, et qu'elle fait une distinction que j'avais perdue.

Huit règles étaient fausses.

Règle	Annonçait	En réalité
Id en double	4.1.1	Retiré des WCAG 2.2
Un seul landmark `main`	1.3.6 AAA	1.3.6 est Identify Purpose, un critère sans rapport
Langue des passages	3.1.2 AA	3.1.2 est de niveau A — et le contrôle ne faisait pas ce que son titre promettait
Texte de lien vague	2.4.4	Le 2.4.4 est satisfait par le contexte
Niveaux de titre sautés	1.3.1	Les WCAG n'imposent pas de niveaux séquentiels
`h1` manquant	1.3.1	Bonne pratique
Titre vide	1.3.1	Bonne pratique
`tabindex` positif	2.4.3	Bonne pratique

Certaines méritent une phrase.

Texte de lien vague. Le 2.4.4 s'appelle Link Purpose (In Context). En
contexte. Un lien qui dit « en savoir plus » le satisfait si le paragraphe,
l'élément de liste ou la cellule qui l'entoure rend la destination claire — ce
qui est généralement le cas. Le critère qui exige que le texte du lien tienne
seul est le 2.4.9, et il est AAA. « En savoir plus » répété au fil d'une page est
donc un vrai problème d'utilisabilité pour qui parcourt les liens au clavier, et
ce n'est pas un manquement de niveau A.

Niveaux de titre. Aucun critère de succès n'exige qu'un h2 suive un h1.
Le 1.3.1 Info and Relationships exige que la structure véhiculée visuellement
soit disponible par programme — utiliser des titres tout court est la façon de
le satisfaire. Passer de h1 à h3 est brouillon et dégrade la navigation au
lecteur d'écran, mais ce n'est pas ce que dit le 1.3.1. axe-core classe
heading-order en bonne pratique, et ce depuis des années.

Langue des passages. Celle-ci était fausse deux fois. Le 3.1.2 est de niveau
A, pas AA — je m'étais trompé de niveau. Et le contrôle s'intitulait « Les
passages en langue étrangère doivent déclarer leur langue », ce qui promettait
une chose qu'aucun contrôle automatique ne peut faire : savoir qu'un passage est
dans une autre langue quand rien ne le signale. Ce que le code faisait vraiment,
c'était valider les attributs lang déjà présents. C'est un contrôle utile. Ce
n'est pas le contrôle qu'annonçait le titre.

Quels sont donc les vrais chiffres

25 contrôles. Dix-huit correspondent à un critère de succès WCAG 2.2,
répartis sur quatorze critères distincts de niveaux A et AA : 1.1.1, 1.3.1,
1.3.5, 1.4.2, 1.4.3, 1.4.4, 2.4.1, 2.4.2, 2.4.4, 2.5.8, 3.1.1, 3.1.2, 3.3.2 et
4.1.2.

Sept relèvent des bonnes pratiques. À corriger, mais pas des manquements à la
conformité.

Avant l'audit, la page produit annonçait « 25 contrôles automatisés sur les
niveaux A et AA des WCAG 2.2 » et listait le 4.1.1 parmi les critères couverts.
Les deux affirmations étaient fausses, et la seconde était vérifiablement fausse
par quiconque avait lu la Recommandation 2.2.

Pourquoi ce n'est pas du pinaillage

Voici la partie qui m'a fait cesser de traiter cela comme un problème
d'étiquettes.

L'extension comporte un générateur pour les informations d'accessibilité
qu'exige l'Acte européen sur l'accessibilité. Il pré-remplit la section des
« obstacles connus » à partir de la dernière analyse et — c'était l'argument de
vente — associe à chaque obstacle son critère de succès WCAG.

Huit règles citant des critères erronés, obsolètes ou sans rapport écrivaient
donc ces numéros dans un document que le propriétaire du site publie comme une
déclaration juridique sur son propre service.

Une déclaration de conformité n'est pas un rapport. Un rapport qui exagère vous
gâche l'après-midi. Une déclaration publiée qui cite un critère inexistant, dans
un document que vous êtes légalement tenu de maintenir, relève d'une autre
catégorie d'erreur — et de celles que découvre votre client, pas vous.

C'est l'argument en faveur de la distinction, et c'est le seul qui compte. Un
outil qui présente chaque signalement comme un manquement WCAG gonfle deux
chiffres : le sien — 25 contrôles WCAG se lit mieux que 18 — et le vôtre. Et
c'est votre chiffre gonflé qui devient public.

Ce que j'ai changé

Chaque règle déclare désormais ce qu'elle est :

{
    id: 'heading_order',
    wcag: '',
    level: '',
    standard: 'best-practice',
    ...
}

Le rapport affiche le critère là où il en existe un, et Bonne pratique là où
il n'y en a pas, au lieu d'un WCAG () vide.

Le générateur exige maintenant deux conditions indépendantes avant d'écrire
un critère dans un document juridique : la règle doit être marquée comme
rattachée aux WCAG, et sa valeur doit correspondre à ^\d+\.\d+\.\d+$. L'une
ou l'autre aurait suffi à empêcher ce qui s'est produit. Je voulais celle qui
survit à quelqu'un modifiant l'autre.

Et les textes commerciaux disent désormais 18 et 7, dans le readme, la
documentation et la fiche de la place de marché. Ce fut le commit le moins
agréable de la semaine, et celui que je referais.

Si vous construisez ou achetez l'un de ces outils

Trois questions qui valent la peine, dont aucune n'exige de me croire.

Signale-t-il encore le 4.1.1 ? Trente secondes de vérification, et cela vous
dit quand le jeu de règles a été lu face à la norme plutôt que copié d'un autre
outil.

Distingue-t-il les critères de succès des bonnes pratiques ? Si chaque
signalement porte un numéro de critère, une partie au moins de ces numéros est
décorative. L'implémentation de référence sur laquelle tourne ce secteur classe
environ un quart de ses règles en bonne pratique. Un outil qui n'en a aucune
n'est pas plus strict : il est moins rigoureux.

Où va le critère après le rapport ? S'il alimente une déclaration, un badge,
un PDF ou quoi que ce soit qu'un client publie, son exactitude cesse d'être une
affaire de qualité interne.

Ce qui n'a pas changé

Les tests automatisés trouvent environ un tiers des obstacles réels
d'accessibilité. Corriger les étiquettes ne déplace pas ce chiffre. Un rapport
propre est bon signe, pas une déclaration de conformité, et les tests au clavier
et au lecteur d'écran par une personne restent le seul moyen de savoir.

Ce que l'audit a changé est plus étroit et valait, je crois, la semaine :
quand mon outil dit WCAG, désormais, il le pense.