Exemplos De Acessibilidade

O que acontece na prática quando tentamos implementar acessibilidade

A maioria dos projetos que eu vejo não consegue passar do básico porque as pessoas pensam em acessibilidade como uma checklist de ARIA labels e cores que passam no contraste. Isso é só a superfície. Eu precisei lidar com isso de verdade quando estive trabalhando num sistema de saúde digital há alguns anos, e o problema real não era seguir as regras do WCAG 2.1 AA. O problema foi que os formulários desse sistema tinham campos de data que, no safari no iOS, o teclado numérico aparecia mas não havia como confirmar a entrada se o usuário estivesse usando VoiceOver. O campo não disparava o evento blur corretamente quando navegado por touch+VoiceOver. Minha equipe gastei três dias inteiro tentando resolver isso até que descobrimos que o problema era o React tratar o evento onChange de forma diferente do onChange nativo do navegador quando o input tinha inputmode="numeric". A solução foi implementar um handler personalizado que disparava blur explicitamente após cada digitação. Isso não aparece em nenhum tutorial de acessibilidade. É aquele tipo de coisa que você só aprende quando entra em campo.

Exemplos práticos de acessibilidade que realmente funcionam

Vou dividir isso por áreas que realmente importam no dia a dia, sem entrar em definições teóricas que todo mundo já leu na W3C. O primeiro exemplo é sobre navegação por teclado, que a maioria dos desenvolvedores trata como algo que "só precisa funcionar nos links". Em projetos reais, o problema mais comum não é o foco não aparecer. É o foco sumir depois que você pressiona Enter num botão e o JavaScript dispara um redirecionamento ou troca de estado sem manter o foco visível no elemento recém-interagido. Isso quebra completamente a experiência de quem usa teclado puro ou leitor de tela. A correção simples é chamar .focus() no elemento-alvo após qualquer ação que mude o conteúdo da página. Simples, mas quase ninguém faz. Outro ponto onde muita gente erra é em formulários com erros de validação. O padrão que você vê em 80% dos sites hoje é um texto vermelho abaixo do campo dizendo "campo obrigatório". Isso é acessível pra quem enxerga. Mas para quem usa leitor de tela, esse texto muitas vezes não é anunciado porque não está associado semanticamente ao campo. O correto é usar aria-describedby apontando para o ID do elemento que contém a mensagem de erro, e aria-invalid="true" quando o campo está com erro. Isso faz com que o leitor de tela anuncie automaticamente que o campo tem um erro e leia a mensagem associada. Não é opcional. É o mínimo que você precisa ter.

Hábitos que parecem bons mas causam problema

Um dos erros mais comuns que eu vejo em revisões de código é a prática de colocar tabindex="0" em elementos div ou span para torná-los focaveis por teclado. Technicamente isso funciona, mas é uma má prática séria. Elementos sem significado semântico não devem ser tornados focáveis artificialmente. A maioria dos leitores de tela vai anunciá-los como "div" ou "span", o que é inútil para o usuário. Se você precisa de um botão customizado, use button mesmo. Se precisa de um link, use a tag a. A semântica HTML já resolve 90% dos problemas de acessibilidade. O resto é detalhes de implementação. Outro problema recorrente é o uso de cores como único indicador de informação. Um campo que fica vermelho quando está errado e verde quando está válido é uma péssima prática. Pelo menos 8% da população masculina tem alguma forma de daltonismo, e dentro disso, a protanopia e deuteranopia são as mais comuns, afetando diretamente a percepção de vermelho e verde. A solução é adicionar um ícone ou texto ao lado, não confiar apenas na cor. Eu já vi projetos inteiros sendo reprovados em auditorias por causa disso, mesmo tendo tudo o mais certo.

Há também o problema do movimento. Animações CSS que fazem elementos entrarem na tela com fade ou slide são bonitas, mas para pessoas com vestibulopatia, labirintite ou transtorno do espectro autista, essas animações podem causar desconforto físico real. A recomendação do WCAG 2.2 inclui a media query prefers-reduced-motion, que permite desativar animações para quem prefere. Mas a maioria dos projetos simplesmente não implementa isso, ou implementa de forma incompleta, cobrindo apenas as animações principais e esquecendo transições de hover ou efeitos sutis.

Exemplos de acessibilidade em componentes do dia a dia

Vamos falar de um dropdown. A maioria dos desenvolvedores constrói dropdowns que funcionam perfeitamente com mouse. Com teclado, o usuário precisa abrir o menu, navegar com as setas e fechar com Escape. Muitos implementations falham em capturar o Escape ou o foco não volta para o botão que abriu o menu após o fechamento. O correto é: seta para baixo abre o menu e foca no primeiro item. Setas para cima e para baixo navegam pelos itens. Enter ou espaço seleciona e fecha, devolvendo o foco ao botão disparador. Escape fecha sem selecionar, devolvendo o foco ao botão. Isso parece simples, mas em testes reais com leitores de tela, muitos dropdowns customizados falham em todos esses pontos simultaneamente. Modais são outro campo minado. Quando um modal abre, o foco deve ir para o primeiro elemento interativo dentro dele. Quando fecha, o foco deve voltar para o elemento que o abriu. Além disso, tudo atrás do modal deve estar bloqueado do acesso por teclado. A técnica correta é usar tabindex="-1" em todos os elementos fora do modal e rastrear quais elementos precisam ser re-focados. Também é essencial que o modal não seja acessível por leitores de tela se ele estiver fechado, usando aria-hidden="true" no conteúdo de fundo. Se você pula qualquer um desses passos, a experiência para quem usa tecnologia assistiva fica completamente quebrada.

Para imagens, o atributo alt é o mais óbvio, mas o que poucos entendem é quando usar alt vazio versus descrições longas. Uma imagem decorativa, sem informação, deve ter alt="". Uma imagem que transmite informação importante, como um gráfico ou diagrama, precisa de alt conciso E de uma descrição completa em outro lugar, como um figura com figcaption ou um elemento aria-describedby apontando para o texto expandido. Colocar uma descrição de 200 palavras no alt é pior do que colocar alt="imagem", porque o leitor de tela lê tudo aquilo antes de deixar o usuário seguir em frente.

A parte que ninguém conta

Acessibilidade não é algo que se implementa no final do projeto. Se você tentar adicionar acessibilidade depois que o design e o desenvolvimento já estão prontos, vai gastar entre três e cinco vezes mais tempo do que se tivesse pensado nisso desde o início. Isso é uma regra prática que eu aprendi na prática e repito sempre. Um projeto típico de e-commerce que decide implementar acessibilidade na fase de testes gasta cerca de quatro semanas. O mesmo projeto, pensado desde o wireframe, leva cerca de cinco dias de ajustes pontuais. A diferença não é a quantidade de trabalho técnico. É a quantidade de retrabalho. Também é importante entender que acessibilidade não é sinônimo de usabilidade. Um site pode ser perfeitamente acessível e ter uma experiência terrível para todos os usuários. O inverso também é verdadeiro. O objetivo deve ser acessibilidade como fundamento, não como complemento. Quando você pensa em acessibilidade desde o início, a tendência natural é criar interfaces mais limpas, com hierarquia clara, cores consistentes e navegação previsível. Isso beneficia todo mundo, não só pessoas com deficiência. Mas isso só acontece se a acessibilidade for integrada ao processo de design, não testada isoladamente no final.

Existem ferramentas que ajudam muito nesse processo. O axe DevTools é um dos mais completos para testes automatizados no navegador. O Lighthouse também tem uma aba de acessibilidade que dá um overview rápido. Mas nenhuma ferramenta automática encontra mais de 50% dos problemas de acessibilidade. O restante precisa de revisão manual com teclado, leitor de tela e, idealmente, testes com usuários reais. Eu recomendo começar com as ferramentas automatizadas para capturar o óbvio, depois fazer testes manuais focados em navegação por teclado e, se possível, contratar um especialista para testes com pessoas que realmente usam tecnologia assistiva no dia a dia. Outro ponto que vale a pena mencionar é a diferença entre conformidade técnica e experiência real. Um site pode passar em todos os testes automatizados do axe e ainda assim ser impossível de usar para alguém com daltonismo severo, ou para alguém que só consegue navegar por teclado, ou para alguém que depende de um leitor de tela que lê o idioma errado porque o atributo lang está incorreto. A conformidade com as diretrizes WCAG é um piso, não um teto. E o piso muitas vezes não está bem definido.

Se você está começando agora, o caminho mais eficiente é focar em três coisas primeiro: navegação por teclado funcionando corretamente, textos alternativos semanticamente corretos, e contrastes de cor que passam no teste de 4.5:1. Depois desses três pilares, o resto vem como refinamento. Tentar fazer tudo de uma vez geralmente resulta em nada feito direito. Comece pelos fundamentos. O resto é detalhe.