Accessibilité

Comment le balisage est audité

L’audit ne repose plus sur une relecture de code, mais sur une vérification automatique rejouée à chaque exécution des tests.

1. tests/php/Unit/Accessibility/MarkupFixtureTest.php demande à chaque type de champ de se rendre, dans son état normal puis en erreur, et écrit le résultat dans tests/js/fixtures/a11y/.
2. tests/js/accessibility.test.js charge ces documents dans jsdom et les soumet à axe-core.

Le point important est que le balisage audité est produit par le code de rendu, jamais retranscrit à la main dans le test. Une transcription resterait conforme pendant que le vrai balisage dérive ; une sortie réelle fait échouer l’audit dès qu’un champ perd son étiquette ou son association ARIA.

Les simulacres d’échappement du bootstrap unitaire (esc_attr, esc_html, checked, selected) reproduisent exactement ceux de WordPress — deux appels à htmlspecialchars et deux comparaisons. Le balisage examiné est donc celui qui serait effectivement servi.

Pour rejouer l’audit :

composer test:unit          # régénère les documents
npm run test:unit:js        # les audite

Ce que l’audit a corrigé

Sa mise en place a révélé deux défauts réels, tous deux invisibles à la lecture :

• aria-required sur un fieldset (violation critique, cinq types de champs). Le rôle implicite d’un fieldset est group, qui n’admet pas cet attribut : il était donc invalide et purement ignoré par les lecteurs d’écran, alors même qu’on croyait signaler l’obligation. Les groupes de boutons radio et de notation déclarent désormais role="radiogroup", qui l’admet ; les groupes de cases à cocher et les champs composites ne l’écrivent plus, l’obligation étant portée par l’astérisque visible, par l’attribut required de chaque sous-champ et par la validation serveur.
• Case de consentement sans intitulé (violation critique). Le texte du consentement étant configurable, l’effacer produisait une étiquette vide, donc une case muette. Le rendu retombe maintenant sur la formule par défaut.

Limites assumées

• Contraste des couleurs. La règle color-contrast d’axe-core est désactivée dans cet audit, pour deux raisons cumulées : jsdom n’implémente pas le canevas dont axe se sert pour mesurer les couleurs, et les documents examinés ne chargent aucune feuille de style — il n’y aurait donc rien à mesurer. Le contraste des feuilles publiques reste vérifié manuellement.
• Règle region. Désactivée également : les documents audités sont des fragments de formulaire isolés, sans en-tête ni navigation. La règle jugerait l’échafaudage du test, non le champ.
• Comportement au clavier. axe-core analyse un arbre statique. La navigation entre étapes, l’ajout de ligne dans un répéteur et le déplacement du focus après erreur relèvent de tests d’interaction, non de cet audit.
• Balisage de page. Le rendu complet — barre de progression, pagination multi-étapes — n’est pas couvert ici : il exige un WordPress réel, donc la suite d’intégration.