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.

Feedback
Report a bug

Found something broken in Accessibility Checker? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 

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.hero<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

  1. Enter a public page URL and run the metered browser audit.
  2. Start with critical and serious violations, but review every rule and affected selector.
  3. Use the HTML excerpt, error summary, and targeted repair guidance to locate the component.
  4. Retest after fixing, then complete manual keyboard, screen-reader, zoom, content, and task-flow checks.

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.

Loading…

➕ Request a feature

New requests are reviewed before they appear here.

Sobre a ferramenta

Execute uma verificação WCAG 2.2 A/AA com axe-core em uma página renderizada no navegador, com a gravidade, os seletores afetados e orientações de correção.

Como usar: informe a URL de uma página pública e execute a auditoria no navegador com limite de uso. Comece pelas violações críticas e graves, mas analise todas as regras e todos os seletores afetados. Use o trecho de HTML, o resumo do erro e as orientações de correção específicas para localizar o componente. Teste novamente após corrigir e, depois, conclua as verificações manuais de teclado, leitor de tela, zoom, conteúdo e fluxos de tarefas.

Recursos

  • A execução no navegador usa regras do axe-core marcadas para os níveis A e AA da WCAG 2.2. O resultado é um relatório de violações de regras, não um certificado de conformidade.
  • Crítico, grave, moderado e leve são níveis de impacto do axe usados para priorizar a análise. O impacto não substitui o critério WCAG associado, o contexto do usuário nem a investigação de engenharia.
  • O navegador com limite de uso carrega a URL pública informada sem a sua sessão autenticada nem interações automatizadas. Estados ocultos, fluxos personalizados, escolhas de consentimento e componentes abertos posteriormente podem não ser avaliados.
  • Não. As verificações automatizadas detectam apenas parte das barreiras de acessibilidade. A conformidade com a WCAG também exige testes manuais de teclado, leitor de tela, conteúdo, foco, erros e fluxos de tarefas.

Como funciona

Como usar: informe a URL de uma página pública e execute a auditoria no navegador com limite de uso. Comece pelas violações críticas e graves, mas analise todas as regras e todos os seletores afetados. Use o trecho de HTML, o resumo do erro e as orientações de correção específicas para localizar o componente. Teste novamente após corrigir e, depois, conclua as verificações manuais de teclado, leitor de tela, zoom, conteúdo e fluxos de tarefas.

Limitações

  • O navegador com limite de uso carrega a URL pública informada sem a sua sessão autenticada nem interações automatizadas. Estados ocultos, fluxos personalizados, escolhas de consentimento e componentes abertos posteriormente podem não ser avaliados.
  • Não. As verificações automatizadas detectam apenas parte das barreiras de acessibilidade. A conformidade com a WCAG também exige testes manuais de teclado, leitor de tela, conteúdo, foco, erros e fluxos de tarefas.

Perguntas frequentes

Uma página aprovada pelo axe está em conformidade com a WCAG?

Não. As verificações automatizadas detectam apenas parte das barreiras de acessibilidade. A conformidade com a WCAG também exige testes manuais de teclado, leitor de tela, conteúdo, foco, erros e fluxos de tarefas.

Quais níveis da WCAG este teste verifica?

A execução no navegador usa regras do axe-core marcadas para os níveis A e AA da WCAG 2.2. O resultado é um relatório de violações de regras, não um certificado de conformidade.

Por que a auditoria pode não detectar um modal ou uma tela que exige login?

O navegador com limite de uso carrega a URL pública informada sem a sua sessão autenticada nem interações automatizadas. Estados ocultos, fluxos personalizados, escolhas de consentimento e componentes abertos posteriormente podem não ser avaliados.

O que significa a gravidade de uma violação?

Crítico, grave, moderado e leve são níveis de impacto do axe usados para priorizar a análise. O impacto não substitui o critério WCAG associado, o contexto do usuário nem a investigação de engenharia.