Pular para o conteúdo
LHCX
Integrações

Acessibilidade Web: Guia Completo de WCAG, ARIA e Testes Automatizados

Admin4 min de leitura
Acessibilidade Web: Guia Completo de WCAG, ARIA e Testes Automatizados

Acessibilidade Web: Guia Completo de WCAG, ARIA e Testes Automatizados

“A tecnologia só é inovadora quando todos podem usá‑la.” – Tim Berners‑Lee

Introdução

A acessibilidade digital deixou de ser um diferencial e se tornou um requisito legal e de mercado. Usuários com deficiência visual, auditiva, motora ou cognitiva esperam que aplicações web ofereçam a mesma funcionalidade que os demais visitantes.

Este artigo traz um panorama abrangente para desenvolvedores que desejam construir produtos inclusivos:

  • Entendimento das diretrizes WCAG 2.2 – o padrão internacional que define requisitos de acessibilidade.
  • Uso correto de atributos ARIA – como melhorar a semântica de componentes customizados.
  • Estratégias de teste – combinação de ferramentas automatizadas (axe, Lighthouse, pa11y) e auditoria manual.
  • Exemplo prático – implementação de um formulário totalmente acessível, com código funcional e testes integrados.

    • Acompanhe as imagens, tabelas e snippets de código que ilustram cada passo.

    Tecnologia e Inovação

    1. Entendendo as Diretrizes WCAG 2.2

    A Web Content Accessibility Guidelines (WCAG) são organizadas em quatro princípios: Perceptível, Operável, Compreensível e Robusto (POUR). Cada princípio contém critérios de sucesso distribuídos em três níveis de conformidade: A, AA e AAA.

    PrincípioExemplo de CritérioNível
    PerceptívelTexto alternativo para imagensA
    OperávelNavegação por tecladoAA
    CompreensívelMensagens de erro clarasAA
    RobustoCompatibilidade com leitores de telaAA

    1.1. Foco nos Níveis A e AA

    A maioria das legislações (ex.: Lei Brasileira de Inclusão) exige conformidade nível AA. Alguns requisitos críticos:

    • Contraste de cores: razão mínima de 4,5:1 para texto normal, 3:1 para texto grande.
    • Tamanho de alvo: áreas de clique devem ter pelo menos 44 × 44 px.
    • Rótulos de formulário: cada campo precisa de um associado.
    • Ordem de foco: a navegação por tecla Tab deve seguir a lógica visual.

    1.2. Ferramentas de Medição de Contraste

    # Exemplo usando a CLI do "color-contrast-checker"

    
npm i -g color-contrast-checker
color-contrast-checker "#0066cc" "#ffffff"

    O comando retorna a razão de contraste e indica se atende aos requisitos AA ou AAA.

    2. Implementando ARIA de Forma Correta

    Accessible Rich Internet Applications (ARIA) complementa a semântica HTML quando elementos nativos não são suficientes (por exemplo, componentes React ou Vue customizados). Contudo, ARIA deve ser usada apenas quando necessário; o ideal é sempre preferir elementos nativos.

    2.1. Principais atributos ARIA

    AtributoFunçãoQuando usar
    roleDefine o papel do elemento (ex.: button, dialog)Componentes customizados
    aria-labelRótulo textual invisívelÍcones sem texto
    aria-labelledbyReferência a um elemento que rotulaDiálogos complexos
    aria-describedbyReferência a descrição adicionalMensagens de erro
    aria-liveIndica que o conteúdo muda dinamicamenteNotificações

    2.2. Exemplo de Botão Customizado

    <!-- Botão estilizado com <div>, mas ainda acessível -->

    
<div role="button"
     tabindex="0"
     aria-pressed="false"
     class="toggle-btn">
  Ativar modo escuro
</div>

    

    
<script>
  const btn = document.querySelector('.toggle-btn');
  btn.addEventListener('click', toggle);
  btn.addEventListener('keydown', e => {
    if (e.key === 'Enter' || e.key === ' ') toggle();
  });

    

    
  function toggle() {
    const pressed = btn.getAttribute('aria-pressed') === 'true';
    btn.setAttribute('aria-pressed', String(!pressed));
    document.body.classList.toggle('dark-mode', !pressed);
  }
</script>

    • role="button" informa ao leitor de tela que o
      funciona como botão.
    • tabindex="0" permite foco via teclado.
    • aria-pressed comunica o estado ativo/inativo.

    3. Estratégias de Teste de Acessibilidade

    A validação deve ser contínua: desde o desenvolvimento até a fase de release. A combinação de testes automatizados e auditoria manual oferece a cobertura mais robusta.

    3.1. Ferramentas Automatizadas

    FerramentaTipoIntegração CIPrincipais Métricas
    axe-coreBiblioteca JavaScriptJest, Cypress1 800+ regras, relatórios detalhados
    LighthouseAuditar páginas completasChrome DevTools, CLIPerformance, SEO, Acessibilidade
    pa11yCLI simplesGitHub ActionsRelatórios em HTML/JSON

    3.1.1. Configurando axe-core com Jest

    npm i --save-dev jest axe-core @axe-core/webdriverjs
    // __tests__/accessibility.test.js

    
const { AxePuppeteer } = require('@axe-core/webdriverjs');
const puppeteer = require('puppeteer');

    

    
test('Página de exemplo deve ser acessível', async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('http://localhost:3000/form');

    

    
  const results = await new AxePuppeteer(page).analyze();
  expect(results.violations).toHaveLength(0);

    

    
  await browser.close();
});

    O teste falha se houver qualquer violação de acessibilidade, garantindo que novos commits não introduzam regressões.

    3.2. Auditoria Manual

    Nenhuma ferramenta substitui a experiência humana. Recomenda‑se:

    • Teste com leitores de tela (NVDA, VoiceOver, TalkBack).
    • Navegação por teclado: Tab, Shift+Tab, Enter, Space, Arrow keys.
    • Verificação de contraste usando extensões como WCAG Contrast Checker.
    • Revisão de texto alternativo: todas as imagens devem ter descrição significativa.

    4. Exemplo Prático: Formulário Acessível

    Vamos construir um formulário de contato que cumpre WCAG AA, utiliza ARIA quando necessário e possui testes automatizados.

    4.1. Estrutura HTML

    ```html Formulário de Contato Acessível

    Fale conosco