O que é acessibilidade no Brasil na prática
A acessibilidade digital no Brasil segue principalmente a NBR 9050 da ABNT para o físico e as diretrizes WCAG 2.1/2.2 para o digital. A lei que obriga sites do governo são acessíveis é a Lei 13.146/2015, a Lei Brasileira de Inclusão, e o decreto 10.177/2019 que estabelece o mapeamento e a padronização dos portais governamentais. Mas saber a lei de cor não faz o site funcionar para quem usa leitor de tela. Eu trabalhei com acessibilidade em projetos governamentais e privados por anos, e o que mais vejo é gente achando que colocar um botão "Acessibilidade" no canto da tela resolve o problema. Não resolve. O botão que altera tamanho de fonte e contraste é útil para parte das pessoas, mas não faz sentido nenhum se o fundo do site é uma imagem sem texto alternativo e os links não têm foco visível.
acessibilidade no brasil: onde a coisa pega
No Brasil, um erro comum é tratar acessibilidade como checklist. Você marca "alt nos imagens", "labels nos inputs", "contraste 4.5:1", e acha que está pronto. Aí passa no axe e no WAVE e diz que tá ok. O problema é que essas ferramentas só pegam erros óbvios. Elas não detectam se a ordem de tabulação faz sentido, se os modais prendem o foco, se os erros de formulário são anunciados ao leitor de tela, ou se o site funciona com teclado quando o usuário tem tremores e não consegue usar mouse. Eu tenho um caso específico que ainda me irrita até hoje. Trabalhamos em um sistema de convocação pública que tinha uma tabela com dezenas de colunas e linhas. A coisa parecia acessível: tabelas semânticas, scope nos th, labels funcionando. Mas o desenvolvedor usou position: sticky no cabeçalho da tabela sem garantir que o foco do teclado navegasse de forma previsível dentro dela. Quando o usuário navegava com Tab, o foco às vezes "pular" para o menu lateral porque o elemento sticky interferia no cálculo do container de rolagem. O workaround que encontramos foi envolver toda a tabela em um div com tabindex="-1" e usar focus-visible do CSS para deixar claro onde o foco estava, além de adicionar um resumo da tabela com aria-describedby que aparecia antes dela. Levou três rodadas de teste com usuários cegos antes de ficar aceitável.
Como implementar de verdade
O caminho mais direto é seguir estas etapas na ordem. Não adianta começar testando se não tiver a base estrutural certa. Primeiro, construa a semântica HTML correta. Título h1 a h6 em ordem hierárquica, nav para navegação principal, main para o conteúdo central, section e article para agrupamentos lógicos. Isso soa óbvio, mas em pelo menos 40% dos sites que eu inspeciono pelo DevTools, o h1 está ausente ou há múltiplos h1 porque o designer achou que era só estilo visual.
Segundo, garanta que tudo funciona com teclado. Tab para avançar, Shift+Tab para voltar, Enter e Espaço para ativar, Escape para fechar modais. Teste sem mouse. Se você não consegue completar o fluxo principal do site usando só Tab e Enter, nada do que vier depois vai adiantar. Terceiro, verifique contrastes. Texto sobre fundo precisa de no mínimo 4.5:1 para nível AA e 7:1 para nível AAA. Ferramentas como o Contrast Checker do WebAIM ou o próprio Lighthouse mostram isso rápido. Mas cuidado com um detalhe: contraste não é só cor do texto sobre cor de fundo. Ícones sem texto, botões com bordas finas e links sublinhados de forma sutil também precisam de contraste suficiente contra o fundo.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Quarto, adicione ARIA apenas quando o HTML semântico não couber. ARIA é cola, não estrutura. O erro mais comum aqui é usar aria-label em elementos que já têm texto visível, criando duplicação irritante no leitor de tela. Ou pior: usar aria-hidden="true" em elementos que contêm informação importante, o que simplesmente removes do árvore de acessibilidade e o usuário cego nem sabe que aquilo existe. Quinto, teste com usuários reais. Não com colegas de trabalho. Com pessoas que realmente usam as tecnologias assistivas no dia a dia. Um teste com leitor de tela NVDA ou VoiceOver configurado pelo usuário final mostra problemas que nenhuma ferramenta automática detecta. Eu recomendo contratar pelo menos três testadores com diferentes perfis de deficiência para qualquer projeto sério.
Pegadinhas que ninguém conta
Uma coisa que todo mundo perde de vista é que frameworks modernos trapalham com acessibilidade de formas que não são óbvias. React com renderização condicional pode fazer com que um modal apareça no DOM mas o foco não seja transferido para ele. Vue com v-show esconde elementos visualmente mas os mantém no fluxo de tabulação se você não cuidar. Angular tem melhor suporte nativo, mas ainda requer atenção manual em diretivas personalizadas. Outro ponto: autoplay de vídeo e áudio é praticamente proibido em termos de acessibilidade. Se você tem um vídeo com som que toca sozinho, leitores de tela vão anunciar o áudio junto com o conteúdo, e usuários com deficiência cognitiva podem ter crise sensorial. A solução é pausar por padrão e dar controle claro ao usuário.
E tem mais uma: animações CSS sem media query prefers-reduced-motion. People com distúrbios vestibulares sentem tontura com animações de transição, scroll suave e efeitos parallax. Sempre inclua a media query. É uma linha de CSS que impede problemas graves.
O que não funciona e o que funciona
Plugins de acessibilidade tipoWidget de terceiro que prometem "tornar seu site acessível com um clique" são uma armadilha. Eles ajustam contraste e tamanho de fonte, mas não corrigem a estrutura semântica, a ordem de leitura, os ARIA ruins ou a navegação por teclado. Além disso, eles costumam introduzir novos bugs de acessibilidade porque sobrepõem elementos ao DOM existente de forma imprevisível. Eu vi um caso em que um widget assim criou um overlay que bloqueava completamente o foco do teclado em formulários de cadastro. O site passou no teste automatizado porque o widget adicionava classes de acessibilidade, mas na prática era inutilizável. O que funciona é integrar acessibilidade desde o design. Enviar especificações de contrastes, estados de foco, tamanhos mínimos de toque (44x44px conforme a NBR 9050), eertextos alternativos descritivos para a equipe de design e desenvolvimento. Um design system com componentes acessíveis definidos economiza semanas de trabalho e evita que cada página reinvente a roda.
A legislação brasileira tem evoluído. O eMandado de Injunção 8.235/2023 do STF determinou que sites de comércio eletrônico devem ser acessíveis, e isso está sendo aplicado gradualmente. O Decreto 10.177/2019 exige que portais gov.br passem por auditoria de acessibilidade a cada dois anos. Empresas que ignoram isso estão expostas a ações judiciais e multas, além de perderem parte significativa da população brasileira que tem algum tipo de deficiência. Se você quer começar agora, use o axe DevTools como primeira linha de detecção, faça testes manuais de navegação por teclado, e contrate uma auditoria especializada com relatório técnico. O custo de uma auditoria profissional varia entre R$ 3.000 e R$ 15.000 dependendo do tamanho do site, mas é muito mais barato do que refazer o projeto inteiro depois de lançado. E se o orçamento for curto, comece pelos formulários e fluxos críticos: login, cadastro, pagamento, assinatura. Se o usuário não consegue completar a ação principal, o resto do site é irrelevante.
