Acessibilidade não é um selo, é uma tecla

Uma auditoria automática dá-te uma pontuação. É útil, e é o primeiro filtro que corro. Mas a pontuação mede o que é possível medir com código, e a maior parte do que estraga a experiência de quem depende de teclado ou de leitor de ecrã não é mensurável assim.

Um site pode ter 100 na auditoria automática e ser impossível de usar sem rato. Já vi. Estas são as três verificações que faço à mão, por esta ordem, antes de escrever qualquer relatório.

1. Guardar o rato e percorrer a página com Tab

É a verificação mais barata que existe e é a que apanha mais coisa. Tiro a mão do rato e carrego em Tab do princípio ao fim da página. Três perguntas:

• Vejo sempre onde estou? Se o foco desaparecer em algum ponto, alguém escreveu outline: none sem pôr nada no lugar. É o problema mais comum que encontro, e o mais fácil de corrigir.
• A ordem faz sentido? A ordem de tabulação segue o DOM, não o que se vê. Um layout reordenado em CSS produz saltos absurdos — do menu para o rodapé e de volta ao meio.
• Consigo sair de onde entrei? Menus e caixas modais prendem o foco lá dentro sem forma de sair com o teclado. Um menu que abre e não fecha com Escape está partido, mesmo que a auditoria não diga nada.

Se não consegues chegar ao botão de contacto sem tocar no rato, o site não tem um problema de acessibilidade — tem um problema de vendas.

2. Medir o contraste, não o estimar

"Parece que dá" não é uma medição. Cinzento sobre cinzento escuro é o caso clássico: passa aos olhos de quem o desenhou num monitor bom, num escritório com cortinas, e desaparece num portátil ao sol.

Meço todos os pares que carregam texto e escrevo o rácio ao lado do token de cor. Os limites que uso: 4.5:1 para texto normal como mínimo legal, e 7:1 no corpo principal quando o consigo sem partir o design. Nesta página, por exemplo, o texto secundário está a 6.05:1 sobre o fundo — está escrito no CSS, para que ninguém o baixe por distracção.

O detalhe que escapa quase sempre: os estados também contam. O texto do link em hover, o placeholder do formulário, a mensagem de erro. Testa-se o estado inicial e esquece-se o resto.

3. Ler a estrutura sem ler o conteúdo

Quem usa leitor de ecrã não lê a página de cima a baixo — navega por títulos, como quem passa os olhos por um índice. Por isso a estrutura de cabeçalhos é a arquitetura real do documento, e é usada como tal.

Tiro a lista de h1 a h6 pela ordem em que aparecem e leio-a isolada. Deve dar um índice compreensível. Se der, a estrutura está certa. Se saltar de h2 para h4, ou se houver três h1, alguém escolheu a etiqueta pelo tamanho da letra em vez do nível hierárquico — e isso é CSS, não estrutura.

Faço o mesmo às regiões: cabeçalho, navegação, conteúdo principal e rodapé devem existir como elementos semânticos, com um skip link a saltar direito ao conteúdo. Sem isso, quem usa leitor de ecrã ouve o menu inteiro em cada página que abre.

Porque é que isto está numa auditoria paga

Porque nenhuma destas três coisas aparece num relatório automático, e todas as três se corrigem em horas. É a melhor relação entre esforço e resultado que conheço em trabalho de front-end.

E porque a conversa muda quando se deixa de falar em conformidade e se passa a falar em pessoas que não conseguiram marcar uma consulta. A primeira versão adia-se; a segunda arranja-se na semana seguinte.