WCAG 2.1: checklist prático para desenvolvedores front-end

1. Fundamentos da WCAG 2.1 e os Quatro Princípios (POUR)

A WCAG (Web Content Accessibility Guidelines) 2.1 é a referência internacional para acessibilidade web, publicada pelo W3C. Ela estabelece critérios de sucesso que tornam o conteúdo digital acessível para pessoas com deficiências visuais, auditivas, motoras, cognitivas e de fala. A estrutura se baseia em quatro princípios fundamentais, conhecidos pela sigla POUR:

  • Perceptível: a informação deve ser apresentada de modo que todos os sentidos possam captá-la.
  • Operável: os componentes da interface devem ser operáveis por diferentes métodos de entrada.
  • Compreensível: a informação e a operação da interface devem ser compreensíveis.
  • Robusto: o conteúdo deve ser interpretado de forma confiável por tecnologias assistivas.

Os níveis de conformidade são A (mínimo), AA (recomendado) e AAA (avançado). Para a maioria dos projetos, o nível AA é o padrão adotado legalmente e tecnicamente viável.

2. Perceptível: Garantindo que o Conteúdo Seja Acessível aos Sentidos

Todo conteúdo não textual precisa de uma alternativa textual equivalente. Imagens decorativas devem usar alt="" vazio, enquanto imagens informativas exigem descrição significativa:

<img src="grafico-vendas.png" alt="Gráfico de barras mostrando aumento de 23% nas vendas do primeiro trimestre">

Para mídia baseada em tempo, como vídeos e áudios, é obrigatório fornecer legendas sincronizadas e, quando possível, audiodescrição. A estrutura semântica da página deve garantir adaptabilidade: use elementos de landmark como <nav>, <main>, <aside> e uma hierarquia de headings (h1 a h6) lógica.

<header>
  <h1>Relatório Anual</h1>
</header>
<nav aria-label="Navegação principal">
  <ul>
    <li><a href="#resumo">Resumo</a></li>
    <li><a href="#dados">Dados</a></li>
  </ul>
</nav>
<main>
  <h2>Resumo Executivo</h2>
  <p>Conteúdo do relatório...</p>
</main>

3. Operável: Navegação e Interação para Todos os Usuários

A navegação por teclado é obrigatória. Todos os elementos interativos devem receber foco visível e a ordem de tabulação deve seguir a sequência lógica de leitura. Implemente skip links para pular blocos repetitivos:

<a href="#conteudo-principal" class="skip-link">Pular para o conteúdo principal</a>

Conteúdos com limite de tempo (sliders automáticos, sessões expiráveis) precisam de controles para pausar, parar ou estender o tempo. Evite animações que piscam mais de três vezes por segundo, pois podem desencadear convulsões. Use a media query prefers-reduced-motion para respeitar as preferências do usuário:

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

4. Compreensível: Conteúdo Legível e Interfaces Previsíveis

Identifique o idioma principal da página com o atributo lang no elemento <html>:

<html lang="pt-BR">

A navegação deve ser consistente em todas as páginas: menus, botões e links com a mesma função devem ter os mesmos rótulos. Evite mudanças bruscas de contexto sem aviso prévio. Para formulários, forneça rótulos explícitos associados a cada campo:

<label for="email">Endereço de e-mail</label>
<input type="email" id="email" name="email" required aria-describedby="email-helper">
<span id="email-helper">Exemplo: usuario@dominio.com</span>

Mensagens de erro devem ser claras e sugerir correções. Use aria-live para notificar dinamicamente sobre validações:

<div aria-live="polite" role="alert">
  <p>O campo "E-mail" não contém um endereço válido. Verifique se há um @ e um domínio.</p>
</div>

5. Robusto: Compatibilidade com Tecnologias Assistivas

Use HTML semântico sempre que possível. Botões devem ser <button>, links <a>, listas <ul> ou <ol>. Evite div e span para elementos interativos. Quando o HTML nativo não for suficiente, recorra ao ARIA (Accessible Rich Internet Applications) com cautela:

<button aria-expanded="false" aria-controls="menu-mobile">
  Menu
</button>
<ul id="menu-mobile" role="navigation" aria-label="Menu principal">
  <li><a href="/">Início</a></li>
  <li><a href="/servicos">Serviços</a></li>
</ul>

Armadilhas comuns do ARIA incluem usar role="button" em um div sem adicionar suporte a teclado (Enter e Espaço) e estado foco. Prefira sempre o elemento HTML nativo.

Teste com leitores de tela como NVDA (Windows) e VoiceOver (macOS/iOS) para validar a experiência real.

6. Checklist Prático de Implementação no Front-End

Critério Como verificar
Contraste de cores Relação 4.5:1 para texto normal, 3:1 para texto grande (acima de 18px ou 14px negrito). Use ferramentas como WebAIM Contrast Checker.
Foco visível Nunca remova outline sem substituir por um estilo personalizado com :focus-visible.
Redimensionamento de texto Teste zoom de 200% no navegador sem perda de conteúdo ou funcionalidade.
Feedback acessível Use aria-live="assertive" para erros críticos e aria-live="polite" para mensagens informativas.

Exemplo de foco visível personalizado:

:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

7. Ferramentas e Fluxo de Testes para o Dia a Dia

  • Axe DevTools: extensão que analisa a página e fornece relatórios detalhados de violações WCAG.
  • WAVE: ferramenta visual que destaca elementos acessíveis e problemas na interface.
  • Lighthouse: integrado ao Chrome DevTools, gera auditoria de acessibilidade com pontuação e sugestões.
  • Testes manuais: navegue apenas com teclado (Tab, Shift+Tab, Enter, Espaço, setas) e verifique se todos os elementos são operáveis.
  • CI/CD: adicione axe-core ou pa11y ao pipeline para bloquear deploys que introduzam novas violações de acessibilidade.

Exemplo de comando para integração contínua com axe-core:

npx axe --exit --show-errors --dir ./reports

Referências