Web e frontend · Misto

Acessibilidade: o mínimo que não dá para pular

Em uma linha: A maior parte da acessibilidade vem de escrever HTML correto, e a maioria das falhas vem de substituir elementos padrão por algo desenhado para se parecer com eles.

Quatro coisas que cobrem quase tudo

Elementos corretos. Um botão é um botão, um link é um link, cabeçalhos em ordem decrescente. Um div com um manipulador de clique não é acessível por teclado nem é anunciado por leitor de tela.

Contraste e tamanho. Texto cinza claro sobre branco é o problema mais comum, e se resolve mudando uma variável de cor.

Teclado. Percorra todo o fluxo só com Tab. Se você não consegue fechar um popup ou chegar a um botão, isso é um bloqueio.

Texto alternativo e formulários rotulados. Uma descrição para cada imagem com significado, um rótulo vinculado para cada campo.

O que verificar e como

Uma ferramenta automática captura cerca de um terço dos problemas e vale a pena rodar em cada build. O resto você pega em duas verificações manuais curtas: uma passagem pelo teclado e fazer uma página central ser lida por um leitor de tela.

A verificação manual leva quinze minutos por página e revela coisas que nenhuma ferramenta vai ver — por exemplo, que a ordem de tabulação pula entre áreas.

Por que também compensa comercialmente

As mesmas correções melhoram o uso no celular, ao sol e com conexão lenta. E em muitos lugares, a acessibilidade de sites também é uma exigência regulatória — vale verificar sua situação com quem é qualificado.

Indo mais fundo

Construa os componentes de base uma vez — botão, campo, diálogo, menu — com gestão de foco e funções corretas, e não permita que sejam reescritos em cada tela. Acessibilidade se consegue no nível do sistema, não no ponto da correção isolada.