Pillar 1 of 4
Accessibility that doesn't hide behind a green checkmark
We run the same axe-core engine that powers Deque's commercial tooling — and we tell you the truth about what automated testing can and can't find.
Why automated scanning is necessary but not sufficient
Accessibility lawsuits in the US increased every year from 2018 to 2024. The vast majority cited issues that an automated scanner would have caught: missing alt text, contrast failures, form labels, broken focus order. Catching those issues early — and continuously — is non-negotiable. But here's the part most vendors won't tell you: axe-core, the engine behind every credible automated accessibility scanner including ours, catches roughly 50–60% of WCAG issues. The rest require a human. We surface that limit clearly. If a vendor claims 100% coverage or an AAA badge from automated testing alone, walk away.
How findings reach your team
Every violation comes with the rule ID, severity, the offending DOM node's outerHTML, the CSS selector, and a short failure summary that tells your engineer what to change. We link to Deque's rule documentation so the developer doesn't have to context-switch. Findings are stored as JSON. You can export them, diff them between scans, or pipe them into a future GitHub Action that fails the build on regressions.
Score interpretation
Each violation is weighted by axe-core impact: critical = 10, serious = 5, moderate = 2, minor = 1. We subtract the total from 100 for the per-page score, floored at zero. A score of 90+ usually means a small handful of minor issues. 70–89 means a real backlog. Below 70 means the page has structural problems and needs a focused remediation pass.
Exemplos de achados
Elementos de formulário precisam ter rótulos
O formulário de login em /signin tem um campo de e-mail sem um <label> associado e sem aria-label. Leitores de tela anunciam o campo como "editar texto", sem contexto, e usuários com deficiência cognitiva que dependem de texto placeholder perdem a dica ao digitar.
<input type="email" placeholder="Email" class="form-input" /> Correção: adicione <label for="email">Email</label> ou aria-label="Email".
Contraste de cores insuficiente
O texto do corpo em /pricing usa #9CA3AF sobre #FFFFFF — proporção 2,84:1. O WCAG 2.1 AA exige 4,5:1 para corpo de texto. Usuários com baixa visão, monitores mais antigos ou reflexo do sol terão dificuldade para ler; alguns nem verão o texto.
Elemento : <p class="text-slate-400">Most popular plan</p> Frente : #9CA3AF Fundo : #FFFFFF Proporção : 2.84:1 (precisa 4.5:1) Correção : escureça para #6B7280 (5.85:1) ou aumente o peso da fonte para 700+ em 18.66px+ (regra de texto grande).
Hierarquia de headings pula um nível
A página /blog/post-template pula de <h1> direto para <h3>, ignorando <h2>. Leitores de tela expõem a estrutura da página pelos níveis de heading, e lacunas confundem usuários que navegam por teclado baseado em H. Crawlers também usam a hierarquia para ranquear relevância de seções.
Esboço da página:
H1: Título do artigo
H3: Heading da seção ← pulou H2
H4: Subseção
Correção: altere <h3> para <h2> ou insira um <h2> de wrapping caso o H3 seja, de fato, uma subseção.Faça o scan do seu site em 60 segundos
25 créditos grátis. Sem cartão de crédito. Achados reais na página que importa para você.