Como testar a acessibilidade de um site: o que a ferramenta automática não pega

Combine duas verificações. O avaliador automático acha as falhas objetivas: imagem sem alternativa em texto, contraste insuficiente, campo sem rótulo. O roteiro manual, em cinco etapas (teclado, leitor de tela, zoom, contraste e texto alternativo), mostra o resto: se dá para usar o site só com o teclado, se o leitor de tela anuncia cada coisa de forma compreensível, se a página aguenta zoom, se o contraste se mantém nos estados e se a descrição da imagem serve a quem não a vê. O avaliador diz o que falta; só o uso mostra o que não funciona.

O limite do teste automático

Avaliador de acessibilidade é uma ferramenta que lê o código da página e aponta o que viola uma regra. Ele é rápido, roda a cada mudança e merece um lugar fixo no processo. O problema é tratar o relatório limpo como sinal de que o site está acessível.

Uma parte dos problemas de acessibilidade não aparece em nenhum relatório automático. Não há um percentual confiável para dar aqui: as faixas que circulam variam conforme a fonte e o método. O que vale é a lógica: a máquina confere o que tem resposta objetiva.

O que um avaliador consegue conferir

• imagem sem atributo de texto alternativo;
• cor de texto e de fundo abaixo do contraste mínimo;
• campo de formulário sem rótulo associado;
• página sem idioma declarado ou sem título;
• botão e link sem nome acessível;
• níveis de título que pulam, como um H2 seguido de um H4.

São falhas de presença e de medida. Corrigi-las é barato, e por isso o avaliador entra primeiro.

Exemplos de avaliadores automáticos: o axe, da Deque, o WAVE, do WebAIM, e o Lighthouse, que acompanha o Chrome. Cada um tem cobertura própria, e um relatório limpo em qualquer deles não atesta que o site é acessível.

O que só uma pessoa julga

O avaliador sabe se a imagem tem texto alternativo. Não sabe se ele descreve a imagem. Sabe que existe um botão, mas não se o nome dele faz sentido fora do contexto. Sabe que há um menu, mas não se dá para abri-lo e fechá-lo sem mouse.

O mesmo vale para a ordem de leitura, a clareza do aviso de erro e o texto de um link. Essa divisão aparece também no que é o eMAG: o próprio modelo trata a validação manual como essencial.

Roteiro manual com teclado e leitor de tela

O roteiro a seguir é curto de propósito. Qualquer pessoa da equipe consegue repeti-lo a cada mudança relevante, e a repetição é o que o torna útil.

Navegação por teclado

Deixe o mouse de lado e percorra a página com o teclado. Quem usa leitor de tela, quem tem limitação motora e quem prefere o teclado navegam assim.

As teclas básicas:

• Tab avança para o próximo elemento interativo; Shift+Tab volta;
• Enter ativa links e botões; Espaço ativa botões e marca caixas de seleção;
• Esc fecha janelas, menus e caixas de diálogo.

Em cada tela, confira quatro coisas.

1. O foco está sempre visível. Foco é o destaque que mostra qual elemento está selecionado. Se você se perde na tela, o usuário também se perde. A WCAG 2.2 trata disso no critério 2.4.7, Focus Visible (nível AA).
2. A ordem faz sentido. O foco deve seguir a ordem em que a página é lida, e não pular de um canto a outro.
3. Não há armadilha. Se o foco entra num menu, num mapa ou numa janela e não sai pelo teclado, a pessoa fica presa. É o critério 2.1.2, No Keyboard Trap (nível A).
4. Tudo que o mouse faz, o teclado faz. É o critério 2.1.1, Keyboard (nível A). Abra menus, envie formulários, use filtros e feche janelas sem tocar no mouse.

Há ainda um teste simples: logo no primeiro Tab, deve aparecer um link para pular direto ao conteúdo. Sem ele, quem usa teclado atravessa o cabeçalho e o menu inteiros em todas as páginas. O critério é o 2.4.1, Bypass Blocks (nível A).

Teste com leitor de tela

Leitor de tela é um programa que lê em voz alta o que está na tela e permite navegar sem vê-la. Há opções gratuitas e, em alguns sistemas, já embutidas. O NVDA é gratuito e de código aberto, para Windows. O TalkBack já vem no Android. Os atalhos variam entre elas, então consulte a documentação do leitor que você escolher.

Se você nunca usou um, faça pelo menos esta sequência, de preferência com a tela apagada ou desviando o olhar:

1. Abra a página e ouça o título. Ele diz onde você está?
2. Navegue pelos títulos. Eles formam um resumo do conteúdo?
3. Passe pelos links e botões. Cada nome diz o que faz, sem depender do que vem em volta? "Clique aqui" falha nesse teste.
4. Preencha um formulário. Cada campo é anunciado com seu rótulo?
5. Provoque um erro de propósito. O aviso é anunciado, ou aparece só como um texto vermelho que ninguém ouve?

No começo você vai errar o atalho e se sentir lento. Faz parte. O que importa é perceber onde a página deixa de fazer sentido sem imagem.

Zoom, contraste e texto alternativo

Ampliação e redimensionamento

Amplie a página até 200% no zoom do navegador. O texto deve continuar legível, sem sobreposição e sem sumir atrás de outro elemento. É o critério 1.4.4, Resize Text (nível AA).

Depois aumente ainda mais, até uma tela estreita, como a de um celular. O conteúdo deve se reorganizar em uma coluna, sem exigir rolagem horizontal para ler cada linha. O critério 1.4.10, Reflow (nível AA) fala em uma largura equivalente a 320 pixels CSS, o que corresponde a 400% de zoom numa janela de 1280 pixels.

Um menu que cobre o conteúdo ao ser ampliado, um botão que fica fora da tela ou um texto cortado são problemas que nenhum avaliador mostra.

Contraste na prática

O avaliador mede o contraste de texto comum. Costuma deixar passar o que muda com o estado: o botão ao passar o mouse, o campo com foco, o link já visitado, o texto sobre imagem. Passe por esses estados à mão.

Dois critérios se aplicam: o 1.4.3, Contrast (Minimum) pede razão de contraste de pelo menos 4,5:1 para texto comum (3:1 para texto grande), e o 1.4.11, Non-text Contrast pede 3:1 para componentes de interface, como a borda de um campo.

Os valores mínimos e a forma de fixá-los na origem estão no texto sobre tokens de design. Corrigir a cor no token vale para todas as telas de uma vez, e é mais seguro que ajustar tela por tela.

Conferir se a descrição da imagem serve

Para cada imagem de conteúdo, pergunte: se eu não visse esta imagem, o texto alternativo me daria o que ela acrescenta à página? Para ver como o eMAG trata a alternativa em texto, leia o modelo do governo para sites acessíveis.

Testar com quem usa tecnologia assistiva

O teste da equipe é necessário, mas tem um limite: quem conhece o site sabe onde clicar. Uma pessoa que usa leitor de tela todos os dias tem atalhos, hábitos e expectativas que quem testa de vez em quando não tem. Ela encontra problemas que o roteiro não prevê.

Incluir esse teste no processo não exige um laboratório. Convide pessoas com deficiência e usuários de tecnologia assistiva, remunere o tempo delas e dê tarefas reais, como achar um serviço ou preencher um formulário. Observe onde elas travam, sem explicar o caminho. Registre o que descobriu e leve para a próxima mudança.

Faça isso antes de grandes mudanças e depois dos ajustes, não só no fim do projeto. E ouça o que for dito sobre a experiência, não só sobre as regras.

Já navegou pelo seu site só com o teclado?

Comece por aí, agora. Abra seu site, deixe o mouse de lado e aperte Tab até chegar ao fim da página. Se o foco sumir, travar ou fizer um caminho sem lógica, você já tem a primeira correção. Depois rode o avaliador automático, repita com o leitor de tela e amplie a página.

Este texto é um guia de verificação. Ele não substitui uma avaliação especializada nem um parecer jurídico, e um teste feito por você não atesta conformidade.

Acessibilidade que se mantém mora no componente: botão, campo e menu construídos com foco, rótulo e contraste corretos, e reaproveitados em todas as telas. É o que um design system organiza. A Evo Tech trabalha com criação de sites e portais institucionais e pode ajudar a ver o que, no seu site, vem do tema e o que vem da rotina de quem publica.