Accessibility Tester
Free, no signup. Audit a rendered page with axe-core for WCAG 2.2 A/AA patterns, then turn each finding into a targeted engineering fix.
Checks run from our server; we fetch the URL you enter and don't keep the results. 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. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Sample report
Illustrative example — axe rule output for fixed markup
CRITICAL · Images must have alternate text (1)
Add a meaningful alt value when the image conveys information, or alt="" when it is decorative.
<img class="hero" src="product.jpg">Element does not have an alt attribute.
The example shows an automated rule result, not a judgment about what the correct alternative text should say.
How to use it
- Enter a public page URL and run the metered browser audit.
- Start with critical and serious violations, but review every rule and affected selector.
- Use the HTML excerpt, error summary, and targeted repair guidance to locate the component.
- Retest after fixing, then complete manual keyboard, screen-reader, zoom, content, and task-flow checks.
+ saves the current site or page. Use ☆ beside any saved site, page, or list to favorite it. Recent check history appears below.
Create a named list
Target filled from your local choices.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Rate this tool
What the results mean
Each card is one axe rule with an impact level and affected-node count. Selectors identify elements in the audited DOM; HTML and error summaries explain the observed pattern. A zero-violation run only means no enabled automated rule fired.
How it works
A metered browser loads the public page with stylesheets enabled for computed checks while media and fonts are blocked. It runs axe-core against WCAG 2.2 A/AA-tagged rules and returns bounded violations and nodes. The page formats severity and adds rule-specific repair guidance.
Features
- Rendered-browser axe-core audit.
- WCAG 2.2 A/AA rule selection.
- Impact, selectors, HTML excerpts, and error summaries.
- Targeted repair guidance for supported axe rules.
- Explicit not-evaluated state when the browser audit cannot complete.
Limitations
Automation catches only part of accessibility. The audit does not use your login, perform interactions, cover every application state, judge meaningful alt text, or replace testing with disabled users and assistive technologies. Blocked media/fonts and dynamic timing can also change the rendered state.
Frequently asked questions
Does passing axe mean a page is WCAG compliant?
No. Automated checks detect only a portion of accessibility barriers. WCAG conformance requires manual keyboard, screen-reader, content, focus, error, and task-flow testing in addition to automation.
Which WCAG level does this test?
The browser run uses axe-core rules tagged for WCAG 2.2 Level A and AA. The result is a rule-violation report, not a conformance certificate.
Why might the audit miss a modal or logged-in screen?
The metered browser loads the supplied public URL without your authenticated session or scripted interaction. Hidden states, personalized flows, consent choices, and components opened later may not be evaluated.
What does a violation severity mean?
Critical, serious, moderate, and minor are axe impact levels used to prioritize review. Impact does not replace the associated WCAG criterion, user context, or engineering investigation.
Feature requests for Accessibility Checker
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
À propos de l’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
Réussir axe signifie-t-il qu’une page est conforme à WCAG ?
Non. Les contrôles automatisés ne détectent qu’une partie des obstacles. La conformité WCAG demande également des tests manuels du clavier, du lecteur d’écran, du contenu, du focus, des erreurs et des parcours.
Quel niveau WCAG ce test couvre-t-il ?
Les règles axe-core exécutées sont étiquetées WCAG 2.2 niveau A et AA. Le résultat est un rapport de violations, pas un certificat de conformité.
Pourquoi l’audit peut-il manquer une fenêtre modale ou un écran connecté ?
Le navigateur métrique charge la page publique sans session ni interaction scriptée. Les états ouverts plus tard, personnalisés ou protégés par un consentement peuvent donc ne pas être évalués.
Que signifie la gravité d’une violation ?
Critique, grave, modérée et mineure sont les niveaux d’impact axe utilisés pour prioriser l’examen. Ils ne remplacent ni le critère WCAG, ni le contexte utilisateur, ni l’enquête technique.