Outil gratuit : Accessibilité

Test d’accessibilité de site web

Saisissez votre adresse : nous testons cette page et jusqu’à quatre pages clés dans un vrai navigateur selon les règles WCAG 2.2 de niveau A et AA. Chaque obstacle est présenté avec l’élément, la page, une capture d’écran et une explication des personnes qu’il pénalise.

Gratuit. Teste jusqu’à cinq pages clés en une minute environ.

Ce que vérifie cet outil

  • Cinq pages représentatives de votre site

    La page que vous saisissez, plus jusqu’à quatre pages choisies parmi ses liens selon le type de site. Sur une boutique, il s’agit d’une collection, d’une fiche produit, du panier et d’une page de contenu ; ailleurs, de pages comme les tarifs, le contact, un article ou les services. Les modèles se répètent : une seule fiche produit révèle donc généralement les problèmes de toutes les autres.

  • Les règles WCAG sur la page rendue

    Chaque page est chargée dans Chromium en 1366 × 900, puis axe-core, le moteur de règles open source de Deque, exécute ses règles WCAG 2.0, 2.1 et 2.2 de niveau A et AA une fois les scripts de la page exécutés. Cela permet de détecter les problèmes qu’un thème ou une application ne crée qu’au moment où la page est construite dans le navigateur.

  • Impact et critères de succès

    Chaque règle en échec indique son impact (critique, grave, modéré ou mineur), les critères de succès WCAG auxquels elle correspond et le nombre d’éléments et de pages concernés.

  • L’élément en échec, encadré

    Le code HTML d’un élément représentatif et une capture d’écran de la page où cet élément est encadré, pour que vous ou votre développeur le retrouviez dans le modèle sans avoir à deviner.

  • Les points qu’une personne doit trancher

    Quand axe-core trouve un point qu’il ne peut pas trancher, comme un texte sur une image de fond dont il ne peut pas mesurer le contraste, ce point est classé « À examiner ». Il n’est jamais compté comme un échec.

  • Un test au clavier

    Sur la première page, nous appuyons 40 fois sur Tab et notons où va le focus : s’il se déplace, s’il reste bloqué dans une boucle (souvent dans un bandeau cookies), si le premier arrêt est un lien d’évitement, et quels éléments ayant le focus n’affichent aucun indicateur de focus visible. Ce dernier contrôle est une heuristique : il apparaît donc comme « À examiner ».

Ce qu’il ne peut pas vérifier

  • Entendre ce qu’annonce un lecteur d’écran. Un logiciel peut confirmer qu’un bouton a un nom, pas que ce nom a du sens une fois lu à voix haute.
  • Évaluer les sous-titres, les transcriptions ou l’audiodescription des contenus vidéo et audio.
  • Évaluer les critères cognitifs et de contenu, par exemple si les instructions sont claires ou si les messages d’erreur aident les personnes à corriger leur saisie.
  • Tester les pages protégées par une connexion, un mot de passe ou un dispositif anti-bots, ni parcourir un tunnel de paiement.
  • Vous dire si votre site est conforme aux WCAG ou respecte une loi. Les règles automatisées détectent une partie des problèmes ; le reste nécessite des personnes.

Pourquoi c’est important

Les obstacles à l’accessibilité sont souvent de petites erreurs de modèle aux effets importants. Un bouton panier composé d’une seule icône, sans nom accessible, est annoncé simplement comme « bouton » : un utilisateur de lecteur d’écran ne peut pas savoir à quoi il sert. Un texte gris sur fond blanc qui n’atteint pas le rapport de contraste de 4,5:1 est difficile à lire pour de nombreuses personnes malvoyantes, et pour quiconque utilise son téléphone en plein soleil.

Comme le même en-tête, la même carte produit et le même pied de page apparaissent sur chaque page, une seule correction dans un modèle peut éliminer des centaines d’échecs d’un coup. C’est pourquoi les résultats sont regroupés par règle, avec le nombre d’éléments et de pages concernés, au lieu de présenter chaque occurrence comme un problème distinct.

Dans de nombreux pays, l’accessibilité a aussi une dimension juridique. Une analyse ne peut pas vous dire si une loi s’applique à vous, ni si vous la respectez. Elle vous donne une liste datée des obstacles réels présents sur vos propres pages, ce qui reste, dans tous les cas, le point de départ concret.

Comment lire les résultats

Critique
L’obstacle peut empêcher certaines personnes d’utiliser l’élément, par exemple un champ de formulaire sans étiquette ou un bouton sans nom. Corrigez ces points en premier.
Grave
L’obstacle rend une tâche beaucoup plus difficile pour certaines personnes, comme un texte courant qui n’atteint pas le rapport de contraste requis.
Modéré
L’obstacle crée des difficultés ou de la confusion, mais les personnes parviennent généralement à le contourner.
Mineur
Un petit problème ou une gêne. Il vaut tout de même la peine de le corriger la prochaine fois que vous modifierez ce modèle.
Critères de succès WCAG
Les numéros affichés à côté d’une règle, comme 1.1.1 ou 1.4.3, sont les critères qu’elle teste. Une règle sans critère associé relève des bonnes pratiques et non d’une exigence WCAG.
Éléments et pages
Le nombre d’éléments en échec pour la règle, et sur combien des pages testées. Une règle qui échoue sur toutes les pages se trouve généralement dans une partie commune comme l’en-tête, le menu ou le pied de page.
À examiner
axe-core a trouvé un point qu’il n’a pas pu trancher. Examinez l’élément vous-même : il peut être conforme ou non. Ces points ne sont pas comptés comme des échecs.
Piège au focus
La touche Tab parcourait en boucle les mêmes quelques éléments. S’ils appartiennent à un bandeau cookies, les utilisateurs du clavier risquent de ne pas pouvoir atteindre le reste de la page.
Le focus ne se déplace pas
Appuyer sur Tab ne donnait le focus à aucun élément. Les liens et les boutons sont peut-être construits avec des éléments div ou span, ou un script intercepte peut-être la touche.
Lien d’évitement
Si le premier arrêt de la touche Tab est un lien « Aller au contenu ». Sans ce lien, les utilisateurs du clavier doivent parcourir tout l’en-tête sur chaque page. Les régions (landmarks) et les titres peuvent aussi satisfaire le critère WCAG 2.4.1 Contourner des blocs.
Aucun indicateur de focus visible
Les éléments ayant le focus sur lesquels nous n’avons vu ni contour, ni ombre portée, ni soulignement. Un autre style, comme un changement de couleur, peut tout de même être visible : parcourez ces éléments avec Tab pour le confirmer.

Comment corriger les problèmes les plus courants

  • Texte qui n’atteint pas le rapport de contraste

    Le texte normal doit présenter un rapport d’au moins 4,5:1 avec son arrière-plan, et le gros texte (environ 24 px, ou environ 18,7 px en gras) un rapport de 3:1. Modifiez la couleur dans les paramètres de votre thème ou dans vos design tokens plutôt qu’élément par élément, puis vérifiez à nouveau le texte indicatif (placeholder), les états de survol et le texte sur les images.

  • Images sans texte alternatif

    Donnez à chaque image porteuse de sens un attribut alt qui indique ce qu’elle montre ou ce qu’elle permet de faire, comme le nom et la couleur du produit. Les images décoratives reçoivent un alt vide (alt="") pour que les lecteurs d’écran les ignorent. Sur Shopify, vous ajoutez le texte alternatif depuis l’image, dans la section Media du produit ; sur WordPress, dans le champ Texte alternatif de la Médiathèque.

  • Champs de formulaire sans étiquette

    Associez une étiquette à chaque champ avec un <label for> qui correspond à l’id du champ, ou utilisez aria-label lorsqu’il n’y a pas de texte visible. Ne comptez pas sur le texte indicatif comme seule étiquette : il disparaît dès que l’on commence à taper. Les champs d’inscription à la newsletter et les champs de recherche de l’en-tête sont les coupables habituels.

  • Boutons et liens sans nom accessible

    Les commandes à icône pour le panier, la recherche, le menu ou les réseaux sociaux ne contiennent souvent qu’un SVG. Ajoutez un texte visible ou un aria-label qui indique ce que fait la commande (« Ouvrir le panier », et non « icône »), et ajoutez aria-hidden="true" au SVG lui-même.

  • Un bandeau cookies qui piège le focus

    Assurez-vous que chaque bouton du bandeau est accessible avec Tab et utilisable avec Entrée ou Espace, que la fermeture du bandeau replace le focus dans la page, et qu’un bandeau qui ne bloque pas la page ne retient pas du tout le focus. Vérifiez les paramètres de votre outil de gestion du consentement et mettez-le à jour si son script est ancien.

  • Contours de focus supprimés dans le CSS

    Recherchez outline: none ou outline: 0 sur les liens, les boutons et :focus dans vos feuilles de style. Remplacez-les par un style visible, comme :focus-visible { outline: 2px solid currentColor; outline-offset: 2px; }.

Questions sur cet outil

Ce test d’accessibilité est-il gratuit ?

Oui. Aucune inscription n’est nécessaire : vous confirmez seulement que vous possédez ou gérez le site. Le Rapport Accessibilité payant ajoute jusqu’à 20 pages supplémentaires de votre sitemap, un parcours au clavier seul, une vérification de la redistribution à 320 px, du code avant/après construit à partir de votre balisage en échec, des prompts IA, un PDF et 5 nouveaux tests.

Quelle part des WCAG un outil automatisé peut-il tester ?

Une partie seulement. Une règle peut vérifier qu’une image a un texte alternatif, pas que ce texte décrit l’image, et qu’un champ a une étiquette, pas que cette étiquette est claire. Considérez les résultats comme une liste de problèmes avérés, puis testez le reste au clavier et avec un lecteur d’écran.

Si l’analyse ne trouve rien, mon site est-il conforme à l’ADA ou aux WCAG ?

Non. Aucun test automatisé ne peut démontrer qu’un site est conforme aux WCAG, ni qu’il respecte l’ADA, l’Acte européen sur l’accessibilité ou toute autre loi. Un résultat sans erreur signifie que les règles automatisées n’ont trouvé aucun échec sur les pages testées.

Puis-je tester un site de préproduction ou des pages protégées par une connexion ?

Les pages protégées par une connexion, un mot de passe ou un dispositif anti-bots ne peuvent pas être testées. Si votre protection anti-bots bloque l’analyse, autorisez le user agent FixReportsScanner ou testez une copie publique de préproduction.

J’ai corrigé un problème. Pourquoi le résultat ne change-t-il pas ?

Les résultats d’une même adresse peuvent être repris d’une analyse effectuée au cours de la dernière heure. Attendez que cette heure soit écoulée, et videz le cache de vos pages ou de votre CDN, avant de tester à nouveau.

Sources

Outils associés

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.

À propos du Rapport Accessibilité