5 Verificações de Acessibilidade para Executar Antes do Deploy

Antes de fazer o deploy, execute cinco verificações nesta ordem: navegue por toda a interface com o teclado usando Tab, rode uma varredura automatizada, valide o HTML semântico e os labels, confira o contraste de cores e teste com zoom em 200%.

Quem já publicou um modal que silenciosamente prendia usuários de teclado, e só descobriu semanas depois por um relato de bug, sabe exatamente por que uma lista como esta existe. É o tipo de problema que ninguém percebe com o mouse na mão.

Juntas, essas verificações levam poucos minutos e capturam as falhas de acessibilidade mais comuns. Sem necessidade de especialização, ferramentas caras ou semanas de estudo. Este é um checklist de acessibilidade pré-deploy que você pode executar em cada pull request, feito para ser rápido e honesto sobre seus próprios limites. Ele não deixará sua aplicação totalmente conforme com a WCAG 2.2 (o padrão atual, publicado como Recomendação do W3C em outubro de 2023 e adotado como ISO/IEC 40500:2025), mas elimina as falhas que mais prejudicam usuários reais. Fazer um pouco é significativamente melhor do que não fazer nada.

1. Navegue por toda a interface com o teclado usando Tab

O teste real mais rápido é gratuito e leva menos de um minuto: deixe o mouse de lado, pressione Tab pela página e confirme que você consegue ver o foco, alcançar todos os elementos interativos e sair de cada modal sem ficar preso. Fique atento a quatro pontos: um indicador de foco visível em cada elemento, uma ordem de tabulação lógica, todo botão/link/input alcançável, e nenhuma armadilha de foco (focus trap) em dropdowns ou diálogos.

Dois bugs causam a maioria das falhas de teclado. O primeiro: controles customizados que esconderam o outline nativo para aplicar um estilo próprio. Se você fez isso, adicione de volta um estilo :focus (ou :focus-visible) visível:

.custom-checkbox input:focus-visible + .box {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}

O segundo: uma <div> clicável. Troque por um <button>, que recebe foco por padrão e já vem com ativação por Enter/Espaço e o papel (role) de botão, sem custo algum. Uma <div> não tem nada disso:

// Not reachable by keyboard
<div onClick={handleClick}>Save</div>
// Focusable and operable by default
<button onClick={handleClick}>Save</button>

Sua navegação manual por Tab testa o caminho ideal que você projetou. O session replay de sessões reais revela as falhas de teclado e foco que só aparecem em produção: um usuário que entra em um modal com Tab e não consegue sair, ou o foco que desaparece para o topo do documento depois que um diálogo fecha, deixando o usuário de teclado perdido. O replay mostra onde o comportamento real do foco divergiu daquilo que sua varredura aprovou.

2. Rode uma varredura automatizada (Lighthouse + axe DevTools)

Um scanner encontrará entre um terço e 40% dos problemas de acessibilidade de uma página, então uma pontuação verde significa que você resolveu os ganhos fáceis (texto alternativo ausente, inputs sem label, contraste baixo, atributo lang ausente) e nada além disso. Essa faixa é o que os fornecedores de ferramentas de teste geralmente reportam, e representa um piso, não um teto: o estudo de 2021 da Deque argumenta que, ao contar o volume de problemas encontrados em vez da proporção de critérios de sucesso cobertos, a cobertura automatizada chega perto de 57%. De qualquer forma, os problemas capturados são os mais baratos de corrigir.

Execute a varredura pelo painel Lighthouse no Chrome DevTools: abra o DevTools, selecione o painel Lighthouse, marque Accessibility e gere o relatório. Uma execução voltada apenas para acessibilidade termina rapidamente. A auditoria de acessibilidade do Lighthouse é construída sobre o conjunto de regras open-source axe-core da Deque, mas roda apenas parte desse conjunto. Por isso, adicione a extensão axe DevTools, que executa as regras completas e olha exclusivamente para acessibilidade. Corrija primeiro os problemas Critical e Serious.

3. Valide o HTML semântico e os labels

Leitores de tela transmitem estrutura através da semântica, então use o elemento adequado para cada função: <button> para ações, <a href> para navegação, <ul>/<li> para listas, <nav> e <main> para landmarks, e cabeçalhos em ordem (h1 → h2 → h3, nunca pulando níveis). Quando tudo é uma <div>, o leitor de tela anuncia “grupo, grupo, grupo” e a página perde sua estrutura.

Todo input precisa de um <label> associado; botões somente com ícone precisam de um aria-label para não serem anunciados apenas como “botão”:

<label htmlFor="email">Email</label>
<input id="email" type="email" />

<button aria-label="Copy to clipboard" onClick={copy}>
  <ClipboardIcon />
</button>

Um modo de falha comum em produção: uma biblioteca de componentes de terceiros bem polida entrega markup inacessível, como um accordion ou combobox cujo <input> não tem <label>, fazendo com que o leitor de tela não anuncie nada. Um componente bonito não é garantia de nada. Inspecione o DOM que a biblioteca renderiza e verifique se os labels estão realmente lá.

4. Confira o contraste de cores e não dependa apenas da cor

Para o Nível AA, o texto precisa de uma taxa de contraste de no mínimo 4.5:1 para texto normal e 3:1 para texto grande (18pt/24px, ou 14pt/18.66px em negrito), conforme o Critério de Sucesso 1.4.3 da WCAG. Trate ambos os números como pisos rígidos. Nada é arredondado para cima até eles, portanto uma medição de 4.499:1 falha. Componentes de interface e ícones significativos ficam sob um critério separado e mais baixo, de 3:1 em relação às cores adjacentes (SC 1.4.11 Contraste de Não-Texto), o que significa que uma cor de texto aprovada não garante que seus botões e bordas de formulário passem.

O Lighthouse sinaliza muitas falhas de contraste de texto; o WebAIM Contrast Checker confirma as taxas exatas. Concretamente: #999999 sobre branco dá 2.85:1 e falha; #595959 sobre branco dá 7:1 e passa.

Contraste não é a história completa. Nunca sinalize um erro apenas com cor. Uma borda vermelha é invisível para muitos usuários com daltonismo, então combine-a com um ícone e texto para que o significado sobreviva sem a cor. Adicione uma mensagem ”⚠ E-mail é obrigatório” ao lado do campo, não apenas um contorno vermelho.

5. Aplique zoom de 200% e respeite o movimento reduzido

Com zoom de 200% no navegador, nada deve se sobrepor, ser cortado ou forçar rolagem horizontal. Segure Ctrl/Cmd e pressione + até o zoom atingir 200%, então navegue pela interface: containers de largura fixa e dimensionamento baseado em pixels são os culpados de sempre. Dimensionar em rem e adicionar overflow-wrap mantém os layouts fluidos:

.container { max-width: 60rem; padding: 1rem; }
p { overflow-wrap: break-word; }

Depois, respeite prefers-reduced-motion: envolva animações não essenciais em uma media query para que usuários que pediram ao sistema operacional para reduzir movimento não sejam afetados. A configuração pede que você corte o movimento que existe por decoração, não que remova toda animação, então mantenha em funcionamento tudo que carrega significado (um spinner de carregamento, um indicador de progresso).

@media (prefers-reduced-motion: reduce) {
  /* Target the decorative motion, not every animation on the page.
     Loading spinners and other essential feedback should keep moving. */
  .parallax,
  .carousel-autoplay,
  .hero-animation {
    animation: none;
    transition: none;
  }
}

Bônus, 60 segundos: ligue um leitor de tela e escute. No macOS, pressione Cmd + F5 para o VoiceOver; no Windows, instale o NVDA gratuitamente. Navegue com Tab e confirme que cabeçalhos, labels e inputs são anunciados com significado real.

Faça o deploy, depois vá mais fundo

Estas cinco verificações são um piso, não um teto. Elas deixam de fora padrões ARIA complexos, gerenciamento de foco em single-page apps e tabelas de dados acessíveis, todos trabalhos reais para outro dia. Escolha sua próxima feature, execute as cinco antes de abrir o PR e corrija os problemas Critical que encontrar. Quando estiver pronto para ir além, a WCAG 2.2, o WebAIM e a documentação de acessibilidade do MDN são as fontes primárias que valem seu tempo. Acessibilidade é uma direção na qual você se move, e entregar estas cinco verificações te move nessa direção hoje.

Perguntas Frequentes

Qual taxa de contraste eu preciso para acessibilidade?

Para o Nível AA da WCAG 2.2, texto normal precisa de uma taxa de contraste de no mínimo 4.5:1 em relação ao fundo, e texto grande (18pt/24px, ou 14pt/18.66px em negrito) precisa de no mínimo 3:1, conforme o Critério de Sucesso 1.4.3. Componentes de interface e ícones significativos se enquadram em um critério separado, o 1.4.11, que exige 3:1 em relação às cores adjacentes. Nenhum dos dois números pode ser arredondado para cima, portanto uma medição de 4.499:1 falha.

As ferramentas automatizadas de acessibilidade detectam tudo?

Não. Lighthouse e axe revelam entre um terço e 40 por cento dos problemas de acessibilidade, na maioria os ganhos fáceis, como texto alternativo ausente, inputs sem label, contraste baixo e atributo lang ausente. Elas não conseguem julgar se o texto alternativo é significativo, se a ordem de tabulação é lógica, ou se o foco é gerenciado após a interação. Uma pontuação verde no Lighthouse resolve as correções baratas, não a página inteira, então combine cada varredura com testes de teclado e de leitor de tela.

Qual é a diferença entre Lighthouse e axe DevTools?

A auditoria de acessibilidade do Lighthouse é construída sobre o conjunto de regras axe-core da Deque, embora execute apenas parte dele, ao lado de auditorias de performance, SEO e boas práticas, todas a partir do painel Lighthouse no Chrome DevTools. A extensão de navegador axe DevTools executa o conjunto completo de regras axe-core e foca exclusivamente em acessibilidade. Use o Lighthouse para uma passagem rápida e, depois, o axe DevTools para uma cobertura mais profunda, voltada só para acessibilidade.

Qual versão da WCAG devo seguir em 2026?

Siga a WCAG 2.2, o padrão atual. Ela se tornou Recomendação do W3C em outubro de 2023, foi atualizada em dezembro de 2024 e agora também é a ISO/IEC 40500:2025, idêntica à versão de outubro de 2023. A WCAG 3.0 existe apenas como Working Draft, que o W3C revisa periodicamente, com uma Candidate Recommendation projetada para o final de 2027 e uma Recomendação final não esperada antes de 2028. A WCAG 3.0 não regula nada hoje.