Outil gratuit : Accessibilité
Vérificateur WCAG 2.2
Voyez où en est votre site pour chacun des 55 critères de succès WCAG 2.2 de niveau A et AA. Chaque critère reçoit l’un des quatre statuts : vous savez ainsi ce que les tests automatisés ont couvert et ce qu’une personne doit encore vérifier.
Gratuit. Teste jusqu’à cinq pages clés en une minute environ.
Ce que vérifie cet outil
Chaque critère de niveau A et AA
Les 55 critères, 31 de niveau A et 24 de niveau AA, dans l’ordre des WCAG, avec leur numéro et leur nom. Le critère 4.1.1 Analyse syntaxique est exclu, car les WCAG 2.2 le déclarent obsolète.
Les résultats automatisés rattachés aux critères
Les règles axe-core sont exécutées sur la page que vous saisissez et jusqu’à quatre pages clés, et chaque résultat est rattaché aux critères de succès que la règle teste. Un critère est en échec dès que l’une de ses règles échoue sur l’une des pages testées.
Les preuves du test au clavier
Un test de 40 appuis sur Tab sur la première page alimente le critère 2.1.2 Pas de piège au clavier et, à titre d’heuristique présentée pour examen, le critère 2.4.7 Visibilité du focus.
Les résultats incertains mis à part
Lorsqu’une règle ne peut pas se prononcer, par exemple sur un texte placé sur une image, ses critères affichent « À examiner » plutôt qu’un succès ou un échec.
Des lacunes visibles plutôt qu’un score
Les critères qu’aucune règle automatisée ne couvre sont marqués « Vérification manuelle » (Manual check). Rien n’est moyenné dans un pourcentage qui masquerait ce qui n’a pas été testé.
Ce qu’il ne peut pas vérifier
- Trancher les critères qui demandent un jugement humain, comme 1.4.10 Redistribution, 1.4.11 Contraste du contenu non textuel, les critères 1.2 sur les sous-titres et l’audiodescription, et les critères 3.3.1 à 3.3.4 sur les erreurs de formulaire.
- Transformer « Aucun échec automatisé » en succès. Une règle exécutée sans échec ne couvre que ce que cette règle teste.
- Produire une déclaration de conformité, une déclaration d’accessibilité ou un VPAT. La conformité s’évalue sur des pages entières et des processus complets, par des personnes.
- Tester le niveau AAA, ou des pages au-delà des cinq de l’analyse.
- Atteindre les étapes situées derrière une connexion ou un tunnel de paiement, où s’appliquent généralement des critères comme 3.3.7 Saisie redondante et 3.3.8 Authentification accessible (minimum).
Pourquoi c’est important
Les WCAG sont rédigées sous forme de critères de succès, et c’est ainsi que les auditeurs, les équipes achats et les déclarations d’accessibilité décrivent un site. Une liste de règles en échec vous dit quoi corriger. Une vue par critère vous dit ce que vous pouvez, ou ne pouvez pas encore, affirmer à propos du site.
Les outils automatisés couvrent moins de la moitié des critères de niveau A et AA : axe-core rattache ses règles à environ 25 des 55. Pour les autres, il n’existe pas de test automatisé fiable. Un logiciel ne peut pas dire si un message d’erreur suggère une correction (3.3.3) ni si une page fonctionne encore à 320 pixels CSS de large (1.4.10). Les présenter comme des vérifications manuelles montre où les tests doivent encore avoir lieu.
Même un critère sans échec automatisé peut échouer. Les règles du critère 1.1.1 Contenu non textuel vérifient qu’une image a un texte alternatif ; elles ne peuvent pas voir que alt="IMG_2041.jpg" n’est d’aucune utilité pour une personne qui ne peut pas voir la photo.
Comment lire les résultats
- En échec
- Au moins une règle automatisée liée à ce critère a échoué sur une page testée. C’est un problème avéré ; le test d’accessibilité montre les éléments et les pages concernés.
- À examiner
- Un contrôle automatisé a signalé un point qu’il n’a pas pu trancher, comme le contraste d’un texte sur un dégradé. Une personne doit examiner l’élément.
- Aucun échec automatisé
- Au moins une règle axe-core liée au critère a été exécutée sans échec. Ce n’est pas une preuve de conformité : les règles ne couvrent qu’une partie de ce qu’exige le critère.
- Non déclenché
- Des règles automatisées existent pour ce critère, mais rien sur les pages testées ne leur a donné matière à vérifier, par exemple aucune vidéo pour les règles sur les sous-titres ou aucun formulaire pour les règles sur les étiquettes. Testez-le manuellement si votre site comporte ce type de contenu ailleurs.
- Vérification manuelle
- Aucune règle automatisée ne couvre ce critère : l’analyse ne dit donc rien à son sujet, dans un sens comme dans l’autre. Testez-le manuellement.
- Niveau A et niveau AA
- Le niveau A est le minimum. Les politiques qui citent les WCAG visent généralement le niveau AA, qui inclut tous les critères de niveau A.
Comment corriger les problèmes les plus courants
Échec au critère 4.1.2 Nom, rôle et valeur
Les commandes personnalisées construites avec des éléments div ou span (menus, onglets, accordéons, interrupteurs) n’indiquent pas aux technologies d’assistance ce qu’elles sont ni si elles sont ouvertes. Utilisez un élément natif <button> chaque fois que possible, donnez-lui un nom et définissez aria-expanded ou aria-pressed pour que son état soit annoncé.
Échec au critère 1.3.1 Information et relations
La structure doit figurer dans le balisage, pas seulement dans la mise en forme. Utilisez de vrais éléments h2 et h3 plutôt que des paragraphes en gras, ul ou ol pour les listes, th avec scope pour les en-têtes de tableau, et des étiquettes ou un fieldset avec une legend pour les groupes de champs de formulaire.
Échec au critère 3.1.1 Langue de la page
Ajoutez un attribut lang à l’élément html, par exemple <html lang="en">. Les thèmes WordPress l’affichent normalement avec language_attributes() ; dans un thème Shopify, utilisez <html lang="{{ request.locale.iso_code }}"> dans layout/theme.liquid.
Échec au critère 2.5.8 Taille de la cible (minimum)
Les petites icônes et les liens trop serrés sont difficiles à toucher du doigt. Donnez à chaque cible au moins 24 × 24 pixels CSS, ou espacez les petites cibles de sorte qu’un cercle de 24 px centré sur chacune ne chevauche aucune autre cible. Une marge intérieure (padding) agrandit la cible sans modifier l’icône.
Mener les vérifications manuelles
Commencez par les plus rapides. Pour le critère 1.4.10 Redistribution, zoomez à 400 % une fenêtre de navigateur de 1280 px de large et vérifiez que rien ne nécessite de défilement horizontal. Pour les critères 2.4.7 et 2.4.11, parcourez la page avec Tab et vérifiez que le focus est toujours visible et jamais masqué par un en-tête fixe ou un bandeau cookies. Pour le critère 3.3.1, envoyez un formulaire comportant des erreurs et voyez si celles-ci sont clairement décrites par du texte.
Questions sur cet outil
Qu’est-ce qui a changé aux niveaux A et AA dans les WCAG 2.2 ?
Six critères ont été ajoutés : 2.4.11 Focus non masqué (minimum), 2.5.7 Mouvements de glissement, 2.5.8 Taille de la cible (minimum), 3.2.6 Aide cohérente, 3.3.7 Saisie redondante et 3.3.8 Authentification accessible (minimum). Les WCAG 2.2 ajoutent aussi trois critères de niveau AAA et suppriment le critère 4.1.1 Analyse syntaxique.
Pourquoi le critère 4.1.1 Analyse syntaxique n’apparaît-il pas ?
Les WCAG 2.2 déclarent le critère 4.1.1 Analyse syntaxique obsolète et le suppriment, car les navigateurs et les technologies d’assistance ne dépendent plus des erreurs de balisage qu’il couvrait. Le W3C précise que, pour les WCAG 2.0 et 2.1, il est désormais considéré comme toujours satisfait pour les contenus HTML.
Respecter les WCAG 2.2 permet-il aussi de respecter les WCAG 2.1 ?
Oui. Les WCAG 2.2 sont rétrocompatibles : un contenu conforme à la version 2.2 est aussi conforme aux versions 2.1 et 2.0. Tester selon la version 2.2 couvre donc les versions antérieures que de nombreuses politiques citent encore.
Puis-je m’en servir pour rédiger une déclaration d’accessibilité ou un VPAT ?
C’est un point de départ, pas un rapport de conformité. Une déclaration ou un VPAT exige l’évaluation de chaque critère, la plupart du temps par une personne ; les listes « Vérification manuelle » et « À examiner » montrent les critères pour lesquels c’est encore nécessaire.
Pourquoi tant de critères indiquent-ils « Vérification manuelle » ?
Parce qu’aucune règle automatisée n’existe pour eux. Savoir si un délai peut être prolongé, si l’aide apparaît au même endroit sur chaque page ou si une connexion exige un test de mémoire dépend de la façon dont les personnes utilisent le site, et non d’un balisage qu’une règle peut lire.
Sources
- W3C : Règles pour l’accessibilité des contenus web (WCAG) 2.2(s’ouvre dans un nouvel onglet)
- W3C WAI : les nouveautés des WCAG 2.2(s’ouvre dans un nouvel onglet)
- W3C WAI : comprendre les WCAG 2.2(s’ouvre dans un nouvel onglet)
- W3C WAI : comment satisfaire aux WCAG (référence rapide)(s’ouvre dans un nouvel onglet)
- W3C WAI : comprendre le critère 4.1.1 Analyse syntaxique (obsolète et supprimé)(s’ouvre dans un nouvel onglet)
- W3C : méthodologie d’évaluation de la conformité des sites web à l’accessibilité (WCAG-EM)(s’ouvre dans un nouvel onglet)
- Deque : descriptions des règles axe-core(s’ouvre dans un nouvel onglet)
Outils associés
- AccessibilitéTest d’accessibilité de site webTestez votre site selon les WCAG 2.2 niveaux A et AA dans un vrai navigateur et voyez chaque obstacle avec l’élément concerné, la page et pourquoi il pose problème.Ouvrir l’outil
- TechniqueAudit de site web gratuitUne seule analyse couvrant l’accessibilité, le SEO, la vitesse, la conversion, la sécurité et la configuration e-mail, avec les constats les plus importants dans chaque domaine.Ouvrir l’outil
Besoin des corrections, pas seulement des constats ?
Le Rapport Accessibilité ($174, paiement unique) part de l’analyse gratuite complète et y ajoute davantage de pages, la modification à apporter pour chaque constat, un PDF et de nouveaux tests pour vérifier vos corrections.