Como criar e testar atividade sobre acessibilidade em projetos digitais
A primeira coisa que todo mundo erra é achar que atividade sobre acessibilidade é só colocar um atributo alt em imagens e pronto. Não é. Eu passei anos vendo gente entregar projetos com essa desculpa e depois reclamar que os testes de validação reproavam. O problema não é a intenção, é a metodologia. Muita gente não sabe por onde começar e acaba fazendo uma revisão de superfície que não pega os problemas reais. Vou explicar como eu estruturo esse tipo de trabalho na prática. Começo sempre pelo auditório, não pelo código. A gente roda o site ou app com as ferramentas automáticas primeiro, porque isso dá um panorama rápido dos problemas óbvios. Mas aí eu desligo a ferramenta e uso o teclado. Navego apenas com Tab, Shift+Tab, Enter e Espaço. Se algo travar ou pular, já anoto. Depois testo com um leitor de tela. No Windows eu uso o NVDA porque é gratuito e rápido. No macOS uso o VoiceOver. A diferença entre esses dois é importante, porque às vezes um lê algo que o outro ignora, e você descobre que o problema tá no marcador HTML, não no conteúdo em si.
Montando uma atividade sobre acessibilidade do zero
O processo que eu sigo tem três fases. Na primeira, eu faço o levantamento inicial. Abro o site em questão e vou marcando cada elemento que precisar de atenção: imagens sem alt, formulários sem rótulo, links que dizem "clique aqui" sem contexto, cores com contraste abaixo do limite, tabelas sem caption ou scope, conteúdo que exige mouse e não tem alternativa via teclado. Isso leva entre 40 minutos e 2 horas, dependendo do tamanho do projeto. Um site pequeno de landing page leva menos tempo. Um sistema interno com muitos forms leva mais. Na segunda fase, eu reproduzo os problemas em um arquivo separado. Isso é útil para dois motivos. Primeiro, porque isola o erro e facilita o teste da correção. Segundo, porque serve como material de treinamento para a equipe de desenvolvimento. Eu coloco o código problemático e abaixo dele a versão corrigida, lado a lado, com explicação direta do que mudou e por quê. Sem floreio.
Na terceira fase, eu monto o checklist final. Não é um documento genérico que a gente encontra na internet. É algo específico para aquele projeto. Se o site é uma loja virtual, os problemas críticos são outros do que num site institucional. Para e-commerce, eu foco em: sucesso na finalização do carrinho via teclado, clareza dos preços e disponibilidadede estoque para leitores de tela, contraste dos botões de ação, e a ordem de tabulação nos fluxos de pagamento. Já num site institucional, eu olho mais para a hierarquia de headings, texto alternativo descritivo das imagens, e se o menu de navegação principal é acessível via teclado. Eu tenho um caso bem específico que ainda me chateia. Era um projeto de um portal de notícias com um carrossel de destaques na homepage. O carrossel usava imagens com autoplay e transição suave. Os testes automáticos passaram limpos. Aí eu apertei Tab e descobri que o carrossel capturava o foco do teclado e não havia forma de parar o autoplay. Além disso, os botões de navegar entre os slides eram divs com onclick, não botões reais. Leitor de tela dizia "div, duplo clique". Eu não consegui avançar nem voltar. A solução que eu apliquei foi simples mas ninguém gosta de ouvir: tirar o autoplay. Colocar botões de navegação visíveis sempre na tela em vez de flechas escondidas que só aparecem no hover. E substituir todas as divs com onclick por botões com aria-label descritivo. O resultado foi um carrossel que funcionava perfeitamente com teclado e leitor de tela, sem perder nenhuma funcionalidade para quem usa mouse. O cliente resistiu no início por achava que ia piorar a experiência visual. Melhorou quando mostrei os testes.
Erros que parecem resolvedos mas não são
Tem uma armadilha comum que eu vejo todo dia. As pessoas colocam aria-hidden="true" em elementos porque o leitor de tela está lendo algo que não deveria. Parece solução. Não é. Se você esconde um elemento do leitor de tela mas ele continua no fluxo de tabulação, o usuário de teclado ainda vai encontrar aquele elemento e não vai saber o que fazer com ele. A correção real é ajustar o HTML ou o CSS para que o elemento seja realmente invisível tanto para leitores de tela quanto para navegação por teclado. Usar display:none ou visibility:hidden costuma resolver, mas em alguns casos específicos de componentes customizados, eu preciso usar um combination de tabindex="-1" e aria-hidden junto com o CSS correto. Outro erro frequente é confiar cegamente em paletas de cores geradas por ferramentas online. Essas ferramentas dizem que o contraste está bom porque usam a média do fundo e do texto. Mas se o seu site tem diferentes tons de cinza, fundos com gradientes, ou imagens de fundo, a ferramenta não consegue validar tudo. Eu sempre verifico manualmente usando a extensão do axe DevTools ou o contraste do navegador mesmo. Oaxe é mais completo porque além do contraste ele também verifica problemas estruturais como missing form labels.
Quem trabalha com React ou Vue costuma ter problemas específicos com foco. Quando você navega por uma SPA e muda de rota sem recarregar a página, o foco muitas vezes fica perdido no lugar errado. A correção que eu uso é adicionar um useEffect no React que move o foco para o título principal da nova página sempre que o route muda. Um simple focus() no element correto. Isso evita que o usuário de leitor de tela fique preso no menu ou no rodapé quando a página nova carrega.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Limitações reais que ninguém admite
Atividade sobre acessibilidade tem um custo que ninguém gosta de colocar no orçamento. O tempo de teste manual com leitor de tela é significativamente mais demorado do que testes automatizados. Um teste automatizado leva cerca de 5 minutos para um site inteiro. Um teste manual completo com teclado e leitor de tela leva entre 2 e 4 horas para o mesmo site. E isso é só para um teste básico. Testes profundos com usuários reais com deficiência podem levar semanas. A maioria dos projetos não tem orçamento para isso e por isso ficam presos na camada superficial. Outra limitação séria é que ferramentas automatizadas detectam apenas cerca de 30 a 40 por cento dos problemas de acessibilidade. O restante precisa ser encontrado manualmente. Isso significa que passar em um teste de Lighthouse ou WAVE não garante que o site seja acessível. Só garante que os problemas mais óbvios foram resolvidos. Se você quer realmente garantir acessibilidade, tem que investir em teste manual e, se possível, em testes com usuários reais.
Testes com usuários reais também têm uma limitação prática: é difícil encontrar voluntários com os tipos certos de deficiência para testar o que você precisa. Eu já tentei isso em vários projetos e quase sempre caio na falta de diversidade nos testers. Ou os voluntários têm deficiência visual mas usam tecnologias assistivas diferentes das que seu público-alvo usa, ou então a pessoa testadora não consegue representar bem o cenário real de uso. Por isso eu recomendo pelo menos um ciclo de teste manual rigoroso antes de pensar em testes com usuários.
Dicas práticas que funcionam de verdade
Aqui vão coisas que eu aprendi na prática e que fazem diferença real. A primeira é sobre formulários. Sempre coloque um label visível para cada campo. Se o design não permite label visível, use aria-label ou aria-labelledby. Nunca use apenas placeholder como substituto de label. Placeholder some quando o usuário digita e desaparece da memória do leitor de tela. A segunda é sobre links. Evite textos genéricos como "saiba mais" ou "clique aqui". O texto do link deve fazer sentido fora do contexto. Se você tiver cinco links dizendo "saiba mais" na mesma página, um leitor de tela vai ler isso cinco vezes sem nenhuma informação útil. Troque por descrições específicas: "saiba mais sobre nosso política de privacidade", "ler análise completa do relatório".
A terceira é sobre order de tabulação. A ordem natural do HTML é quase sempre a correta. Forçar ordem customizada com tabindex positivo é um convite para o caos. Se você precisa rearranjar algo, reescreva a estrutura HTML em vez de usar tabindex. tabindex negativo para elementos que não devem ser foco é aceitável em casos específicos, como esconder elementos de foco em modais que já têm seu próprio ciclo de tabulação. A quarta, e talvez a mais importante: inclua acessibilidade desde o início do projeto, não no final. Correções de acessibilidade em projetos já entregues custam de três a cinco vezes mais do que construir acessível desde o protótipo. Isso vale para design, desenvolvimento e testes. Cada hora investida no início economiza dez horas de retrabalho depois.
O mais difícil sobre atividade sobre acessibilidade não é a parte técnica. É convencer as pessoas de que isso importa. As métricas de negócio raramente incluem acessibilidade. Mas quando você mostra que um site acessível tem melhor SEO, performance mais consistente e menor risco de processos, as coisas mudam de figura. Testes automatizados ajudam a justificar o investimento porque geram relatórios bonitos. O problema real é que eles não contam a história inteira. O trabalho de verdade acontece quando você coloca o dedo na ferida e aceita que a primeira versão nunca vai estar pronta.
