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.

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.

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.