Acessibilidade Digital — Implementando WCAG 2.2 em Produtos Reais

Acessibilidade digital não é feature — é requisito de qualidade. No Brasil, a Lei Brasileira de Inclusão (LBI) estabelece obrigações legais para produtos e serviços digitais. Globalmente, a WCAG 2.2 (Web Content Accessibility Guidelines) é o padrão de referência que define critérios mensuráveis para tornar conteúdo web acessível a pessoas com deficiências visuais, auditivas, motoras e cognitivas. Este artigo examina os critérios mais impactantes da WCAG 2.2, como testá-los e como integrá-los ao processo de design e desenvolvimento sem transformar acessibilidade em um ciclo separado de auditoria e correção.

Os quatro princípios da WCAG e o que cada um exige

A WCAG organiza todos os critérios de sucesso em quatro princípios: Perceptível (o conteúdo pode ser percebido por todos os sentidos disponíveis ao usuário), Operável (a interface pode ser operada por qualquer mecanismo de entrada), Compreensível (o conteúdo e a operação da interface são compreensíveis) e Robusto (o conteúdo pode ser interpretado por tecnologias assistivas atuais e futuras).

Cada critério de sucesso tem um nível: A (mínimo), AA (recomendado para a maioria dos produtos) e AAA (mais rigoroso, geralmente para produtos específicos). A conformidade AA é o padrão legal em muitas jurisdições e o objetivo prático para a maioria dos produtos digitais.

Critérios de maior impacto que times frequentemente subestimam

Contraste de cor (1.4.3 e 1.4.11): Texto precisa de proporção mínima de 4.5:1 contra o fundo (3:1 para texto grande). Componentes de interface e gráficos informativos precisam de proporção mínima de 3:1. Ferramentas como Colour Contrast Analyser ou o plugin Stark para Figma verificam isso em design antes de codificar. Erros de contraste são a categoria mais frequente em auditorias de acessibilidade.

Foco visível (2.4.11 — novo em WCAG 2.2): O critério 2.4.11 exige que o indicador de foco do teclado tenha área mínima e contraste suficiente. Muitos produtos removem o outline padrão do browser via CSS (`outline: none`) por razões estéticas sem substituir por um indicador equivalente. O resultado: usuários que navegam por teclado perdem completamente a referência de onde estão na interface.

Tamanho mínimo de alvo de toque (2.5.8 — novo em WCAG 2.2): Componentes interativos em mobile devem ter área de toque mínima de 24x24 CSS pixels, com espaçamento suficiente entre alvos adjacentes. Ícones pequenos e links em linhas de texto densas frequentemente violam esse critério.

Ordem de foco e estrutura de heading: A ordem em que elementos recebem foco ao navegar por teclado deve ser lógica e consistente com a apresentação visual. Headings (`h1`–`h6`) devem refletir a hierarquia real do conteúdo — não ser escolhidos por tamanho visual. Usar `h3` porque tem o tamanho tipográfico desejado, pulando `h2`, quebra a estrutura semântica que leitores de tela utilizam para navegar.

Texto alternativo em imagens: `alt` em `` não deve descrever a imagem genericamente ("imagem de produto") mas transmitir a informação que a imagem carrega no contexto. Imagens decorativas devem ter `alt=""` para serem ignoradas por leitores de tela. Imagens de gráficos ou infográficos precisam de descrição longa no texto adjacente ou via `aria-describedby`.

ARIA: quando usar e quando evitar

WAI-ARIA (Accessible Rich Internet Applications) fornece atributos semânticos para HTML quando o HTML nativo não é suficiente. A regra de ouro: use HTML semântico nativo sempre que possível, ARIA apenas quando necessário.

Um botão deve ser ``, não `

`. Um link de navegação deve ser ``, não ``. Elementos HTML nativos já vêm com comportamento de teclado, semântica e estados acessíveis embutidos. Replicar isso com ARIA é mais trabalhoso e mais propenso a erros.

Quando ARIA é necessário — para componentes complexos como datepickers, comboboxes, tabs, modals e carousels — o padrão de referência são as ARIA Authoring Practices Guide (APG) do W3C, que documentam os padrões de teclado e ARIA corretos para cada widget.

Alguns erros comuns de ARIA que pioram a acessibilidade: adicionar `role="presentation"` em elementos que têm semântica necessária, usar `aria-label` em elementos que já têm texto visível (duplica a informação para leitores de tela), ou implementar `aria-expanded` sem de fato expandir/retrair o conteúdo associado.

Testes de acessibilidade: automatizados e manuais

Ferramentas automatizadas como axe-core (integrado ao Chrome DevTools, Storybook e pipelines de CI via jest-axe ou cypress-axe) detectam aproximadamente 30% dos problemas de acessibilidade verificáveis automaticamente. São essenciais mas insuficientes.

O restante requer testes manuais:

Navegação por teclado: Percorra toda a interface usando apenas Tab, Shift+Tab, Enter, Space e setas. Verifique se o foco é sempre visível, se a ordem é lógica, se modals aprisionam o foco corretamente e se componentes interativos respondem às teclas esperadas.

Leitor de tela: Teste com NVDA + Chrome (Windows) ou VoiceOver + Safari (macOS/iOS). Não é preciso se tornar especialista em leitor de tela — o objetivo inicial é verificar se a interface é utilizável: se os elementos têm nomes compreensíveis, se o estado dos componentes é anunciado e se a navegação faz sentido sem visão.

Zoom a 200%: Acesse a interface com zoom do browser a 200%. O conteúdo deve se adaptar sem perda de informação ou funcionalidade.

Integrando acessibilidade ao processo

A abordagem mais eficaz não é uma auditoria de acessibilidade no final do ciclo — é integrar verificações em cada fase.

Em design: o Figma com plugins Stark ou Able verifica contraste em tempo real. Anotações de acessibilidade nos handoffs (nomes de componentes, estados de foco, ordem de leitura) evitam que o desenvolvedor tome decisões de acessibilidade sem contexto de design.

Em desenvolvimento: checklist de acessibilidade na definition of done, axe-core no pipeline de CI para bloquear regressões, e revisão de código com foco em semântica HTML e padrões ARIA.

Em produto: incluir usuários com deficiências em sessões de teste. Não como uma etapa de "validação de acessibilidade" isolada, mas como participantes regulares do processo de UX research. Nenhuma ferramenta substitui o feedback de alguém que usa tecnologia assistiva como parte do seu dia a dia.