Testeur d’accessibilité

Les contrôles sont exécutés depuis notre serveur ; nous récupérons l’URL saisie et ne conservons pas les résultats. This launches a metered browser audit. Stylesheets are allowed for computed accessibility checks; media and fonts are blocked. Automated checks catch only part of WCAG issues and never replace manual testing. Des compteurs anonymes de résultats par exécution peuvent servir à la recherche agrégée ; les URL, domaines, adresses IP et identifiants ne sont jamais inclus, et aucune statistique issue de moins de 100 exécutions n’est publiée.

Commentaires
Signaler un bug

Un élément ne fonctionne pas dans Testeur d’accessibilité ? Décrivez ce qui s’est passé : le signalement est envoyé directement dans une file de tri privée, pas dans une liste publique.

Données envoyées
 Les saisies de l’outil, fichiers importés, sources collées, résultats complets, paramètres de requête et fragments d’URL ne sont pas joints automatiquement. Vous pouvez modifier ou supprimer le passage sélectionné ci-dessus. Les métadonnées du navigateur et de protection contre les abus sont traitées pour prévenir le spam. 

À propos de cet outil

Lancez un contrôle axe-core rendu dans le navigateur pour repérer les problèmes WCAG 2.2 A/AA, les sélecteurs concernés et les corrections à appliquer. Les contrôles automatisés orientent l’audit, mais ne remplacent pas les essais manuels.

Fonctionnalités

  • Audit d’une URL publique avec gravité, règle axe-core et sélecteur affecté.
  • Extrait HTML, résumé de l’erreur et conseil de correction pour retrouver le composant.
  • Rapport structuré par niveaux critique, grave, modéré et mineur.
  • Résultats et données de saisie conservés dans le navigateur, sans session authentifiée.

Fonctionnement

Le navigateur métrique charge l’URL publique fournie sans votre session authentifiée ni interaction scriptée, puis applique les règles axe-core marquées WCAG 2.2 A/AA. Le rapport relie chaque violation à un sélecteur et à une réparation ciblée, en laissant la validation finale aux tests manuels.

Limites

  • Le navigateur ne voit pas les états masqués, les parcours personnalisés, les consentements ni les composants ouverts après une interaction.
  • La conformité WCAG exige aussi des tests manuels au clavier, avec lecteur d’écran, zoom, contenu, focus et parcours métier.

Questions fréquentes

La réussite des contrôles `axe` signifie-t-elle qu’une page respecte les `WCAG` ?

Non. Les vérifications automatisées ne repèrent qu’une partie des obstacles. Le respect des `WCAG` exige aussi des vérifications manuelles du clavier, du lecteur d’écran, du contenu, de l’indication de l’élément actif, des erreurs et des parcours.

Quel niveau des `WCAG` cette évaluation couvre-t-elle ?

Les règles `axe-core` exécutées portent les étiquettes `WCAG 2.2` de niveau A et AA. Le résultat recense des anomalies ; il ne constitue pas un certificat de conformité.

Pourquoi l’audit peut-il ne pas voir une fenêtre modale ou un écran réservé aux utilisateurs connectés ?

Le navigateur de mesure charge la page accessible à tous, sans authentification ni manipulation programmée. Les états ouverts ultérieurement, personnalisés ou protégés par un consentement peuvent donc échapper à l’évaluation.

Que représente le degré de gravité d’une anomalie ?

Critique, grave, modérée et mineure sont les degrés d’incidence employés par `axe` pour hiérarchiser l’examen. Ils ne remplacent ni le critère `WCAG`, ni le contexte d’utilisation, ni l’analyse technique.