Acessibilidade web: guia prático de WCAG 2.2

A acessibilidade é quase sempre tratada como uma fase: constrói-se o produto e, no fim, alguém passa um validador e abre vinte incidências. É essa ordem que a torna cara. Quando o foco do teclado está partido porque o sistema de componentes nunca o contemplou, corrigir não é uma incidência — é reescrever a camada de interação.

Este guia trata do contrário: que decisões tomar enquanto constrói, para que o validador, no fim, não tenha nada a dizer.

Os quatro princípios: POUR

A WCAG organiza tudo à volta de quatro ideias. Não são categorias burocráticas: são quatro maneiras distintas de alguém não conseguir usar o seu site.

Percetível. O conteúdo tem de chegar por mais do que um canal. Uma imagem precisa de texto alternativo, um vídeo precisa de legendas, e a cor não pode ser o único portador de informação — se o campo obrigatório só se distingue por estar a vermelho, cerca de uma em cada doze pessoas com visão masculina não o verá.

Operável. Tudo o que se faz com rato tem de se poder fazer com teclado. Sem armadilhas de foco, sem limites de tempo impossíveis, sem animações que desencadeiem crises vestibulares.

Compreensível. Idioma declarado, comportamento previsível e erros que expliquem o que falhou e como corrigir. «Erro no formulário» não é uma mensagem: é uma rendição.

Robusto. A marcação tem de ser interpretável por tecnologias de apoio. É aqui que o HTML semântico ganha sempre às div com onclick.

Níveis A, AA e AAA

Três níveis de exigência. Na prática só um importa.

• A é o mínimo absoluto. Cumprir apenas A deixa muita gente de fora e não satisfaz praticamente nenhuma regulamentação.
• AA é o padrão real. É o que a regulamentação europeia exige, o que os concursos públicos pedem e o que é auditado.
• AAA é aspiracional. A própria W3C diz que não é realista exigi-lo para todo o conteúdo de um site.

Trabalhe sempre contra AA. Se alguém lhe pedir «acessibilidade» sem especificar nível, está a pedir AA.

O que a WCAG 2.2 acrescenta

A WCAG 2.2 é Recomendação da W3C desde outubro de 2023. É aditiva: mantém tudo o da 2.1 e acrescenta nove critérios (um critério da 2.1, o 4.1.1 sobre parsing, ficou obsoleto). Seis dos novos são de nível AA. Estes são os que vemos incumpridos com mais frequência:

2.4.11 — Foco não obscurecido. Ao navegar com tabulador, o elemento com foco não pode ficar tapado. O culpado habitual é um cabeçalho fixo: tabula, o foco avança para uma ligação que está mesmo por baixo do header sticky, e visualmente desaparece. Corrige-se com scroll-margin-top nos elementos focáveis.

2.5.7 — Movimentos de arrastar. Qualquer funcionalidade que dependa de arrastar precisa de alternativa de ponteiro único. Um reordenador de listas por drag and drop precisa também de botões de subir e descer. Um slider de preço precisa de campos numéricos.

2.5.8 — Tamanho do alvo (mínimo). Os alvos táteis devem ter pelo menos 24×24 píxeis CSS, com exceções para ligações em linha dentro de texto corrido. O infrator clássico é o ícone de fechar de um modal: 16 píxeis e encostado ao canto.

3.3.8 — Autenticação acessível. Não pode exigir uma prova cognitiva para iniciar sessão. Isto significa permitir colar no campo de palavra-passe, não bloquear os gestores de palavras-passe e não obrigar a resolver um puzzle. Um CAPTCHA de «selecione os semáforos» sem alternativa incumpre este critério.

3.2.6 — Ajuda consistente e 3.3.7 — Entrada redundante. O acesso à ajuda deve estar no mesmo sítio em todas as páginas, e não se pode pedir duas vezes o mesmo dado num mesmo processo salvo se for imprescindível.

As cinco falhas que aparecem em quase todas as auditorias

1. Contraste insuficiente. Texto cinzento claro sobre branco. O mínimo AA é 4,5:1 para texto normal e 3:1 para texto grande. O cinzento #999 sobre branco dá 2,85:1 — não passa.
2. Imagens sem alternativa útil. alt="imagem" é pior do que não pôr nada. Se a imagem é decorativa, alt="" é a resposta correta.
3. Formulários sem etiqueta associada. O placeholder não é uma etiqueta: desaparece ao escrever e muitos leitores de ecrã não o anunciam.
4. Foco invisível. Alguém pôs outline: none no CSS base e ninguém o repôs. Navegar com teclado passa a ser adivinhar.
5. Cabeçalhos usados por tamanho. Um h4 escolhido porque «ficava bem» quebra o índice com que quem usa leitor de ecrã navega a página.

Como auditar a sério

Comece pelo automático porque é barato: axe DevTools ou Lighthouse dão-lhe num minuto os problemas de contraste, atributos ausentes e hierarquia. Mas tenha clara a limitação: as ferramentas automáticas detetam cerca de um terço dos problemas reais. Não conseguem saber se o seu alt descreve a imagem ou se a ordem de tabulação faz sentido.

O que encontra o resto:

• Percorra a página inteira com o tabulador. Sem tocar no rato. Vê-se sempre onde está? Consegue sair de todos os modais? A ordem segue a leitura visual?
• Ligue um leitor de ecrã. O VoiceOver vem no macOS e iOS, o NVDA é gratuito no Windows. Meia hora a navegar o seu próprio produto às cegas ensina mais do que qualquer relatório.
• Suba o zoom para 200%. É um critério AA e parte mais maquetas do que parece.

A ordem correta

A acessibilidade sai barata quando é decidida na camada de componentes e cara quando é remendada ecrã a ecrã. Se tem um botão, um campo de formulário e um modal bem resolvidos, já resolveu 80% dos ecrãs que construir por cima. É exatamente o argumento a favor de ter um sistema de design: o acessível por omissão herda-se.

E há mais um motivo para não deixar isto para o fim: desde junho de 2025 boa parte do comércio e dos serviços digitais na UE está obrigada por lei. O European Accessibility Act fixa o piso e remete para a norma EN 301 549, que por sua vez aponta para a WCAG em nível AA — o mesmo nível de que trata este artigo.

Quer saber em que ponto está o seu site? Em desenvolvimento web trabalhamos a acessibilidade como parte do processo, não como uma auditoria de última hora.