O que é atividade sobre acessibilidade e por que a maioria das pessoas faz errado
Vou começar com algo que aprendi na marra: colocar um texto alternativo em uma imagem já é acessibilidade não. A maioria dos guias que você vê por aí começa com definições bonitas e termina com checklists que parecem de museu. Na prática, atividade sobre acessibilidade é sobre verificar se o conteúdo realmente funciona para quem usa leitores de tela, navegação por teclado ou contraste reduzido. E aí que a coisa fica interesting. Eu trabalhei em um projeto interno há dois anos onde a equipe inteira achava que tinha feito acessibilidade porque adicionou alt em todas as imagens. Quando eu rodei o NVDA no final de semana, descobri que três quartos desses textos alt eram descrições do que a imagem mostrava, não do que ela fazia na página. O usuário do leitor de tela precisava ouvir "foto de pessoa sorrindo" quando a função real era um botão de ação. Isso não é acessibilidade, é enfeite.
Atividade sobre acessibilidade: teste prático em 30 minutos
Aqui está a atividade que eu uso com frequência e que funciona de verdade. Você precisa de um computador com Windows ou Mac, um leitor de tela gratuito (NVDA para Windows ou VoiceOver para Mac), e uma página web qualquer — pode ser o site da sua empresa, um portal governamental, ou até uma landing page que você mesmo fez. O passo zero é desligar o mouse. Não brinca. Se você não consegue completar uma tarefa só usando Tab, Shift+Tab, Enter e as setas, então a página já falhou antes de testar o leitor de tela. Eu geralmente começo com o formulário de contato ou checkout. Se o foco visual não aparece claramente quando você navega por teclado, anota isso. Um outline de foco com apenas 1px de espessura e cor idêntica ao background é invisível para pessoas com baixa visão.
Depois liga o leitor de tela e navega pela mesma página. Anota tudo que parece redundante, confuso ou ausente. Texto alternativo duplicado? Botão sem label? Link que diz "clique aqui" sem contexto? São problemas reais que levam segundos para corrigir mas geram frustração enorme no dia a dia. Eu costumava fazer essa atividade em projetos grandes e descobrir que o problema mais frequente não era técnico — era de conteúdo. A pessoa que escreveu o texto alt pensou em descrever a imagem para quem não podia vê-la, mas esqueceu que o leitor de tela lê em voz alta e o contexto da página já estava dizendo o que era. Resultado: o usuário ouvia "imagem de logotipo da empresa X" quando ele já sabia que estava na home page. Isso é barulho, não informação.
Dicas que ninguém conta sobre acessibilidade web
Vou listar três insights que eu aprendi depois de ver gente chorar em sprints apertados. Primeiro: atributos ARIA não resolvem tudo. role="button" em uma div que não responde a Enter é pior que nada — dá a ilusão de que funciona e quebra na hora H. Sempre prefira elementos semânticos nativos. Botão é button, link é a, input é input. ARIA é para quando o HTML não basta, não para substituir o HTML. Segundo: contraste não é só sobre texto preto em fundo branco. Cores de feedback, bordas de campos ativos, estados hover — tudo isso precisa passar no teste de contraste 4.5:1 para texto normal e 3:1 para texto grande. Eu costumava usar azul claro para links visitados e descobrir que pessoas com daltonismo não conseguiam distinguir do background. A solução foi adicionar underline e aumentar a saturação, não mudar a cor inteira.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Terceiro: testes automatizados cobrem cerca de 30% dos problemas. O resto é qualitativo — contexto, ordem de leitura, redundância, clareza. Eu já vi ferramentas como axe-core e WAVE apontarem zero erros em uma página que era impossível de navegar por teclado. O segredo é combinar automação com teste humano, idealmente com usuários reais de tecnologias assistivas, não só especialistas que sabem onde procurar.
O problema que eu nunca esperava encontrar em atividade sobre acessibilidade
Em um projeto de e-commerce, a equipe de design fez um carrossel de produtos com autoplay. Lindo. Funcionava perfeitamente com mouse e teclado. Até o momento em que eu liguei o NVDA e o leitor de tela tentou ler todos os slides simultaneamente. O usuário ouviu uma sopa de nomes de produtos, preços e descrições sem conseguir pausar — o botão de pausa era um ícone sem label, invisível para quem não via o mouse passando. A correção foi simples na teoria: adicionar aria-live="polite" no container do carrossel e garantir que o autoplay pause quando o foco sair da página. Na prática, levou três reuniões e uma discussão acalorada com o desenvolvedor frontend que jurava que "funcionava". Às vezes a solução não é técnica — é comunicação.
Outro caso que ficou gravado: um formulário de cadastro com validação em tempo real que mostrava mensagens de erro em vermelho. Para a maioria dos usuários, perfeito. Para quem usa tela ampliada ou tem baixa visão, as mensagens de erro desapareciam quando o foco mudava para o próximo campo. A correção foi manter a mensagem visível até o campo ser preenchido corretamente ou o usuário clicar fora do formulário.
Quando acessibilidade não é a prioridade (e o que fazer nessa hora)
Vou ser honesto: existem cenários em que acessibilidade completa é inviável no prazo ou orçamento. Projetos legacy com código embarcado em Flash, interfaces 3D interativas sem fallback, ou sistemas legados que nunca tiveram documentação de acessibilidade — nessas situações, a escolha não é entre fazer certo ou errado, é entre fazer algo ou nada. Eu costumava recomendar uma abordagem pragmática nesses casos: identificar as barreiras críticas que impedem o uso completo, documentar cada uma com reprodução passo a passo, e propor mitigações mesmo que temporárias. Um texto descritivo ao lado de um vídeo sem legenda, um link alternativo para quem não consegue usar o formulário principal, um fallback em texto para gráficos interativos. Isso não é accessibilidade perfeita, mas é melhor que nada.
O pior cenário não é fazer mal — é não fazer nada e fingir que o problema não existe. Eu já vi relatórios de conformidade WCAG preenchidos com checkboxes marcados que não correspondiam à realidade da página. Isso gera falsidade de segurança, e quando ocorre uma ação judicial ou uma reclamação formal, a diferença entre "tentamos" e "fizemos" é a diferença entre resolver e perder. Se você está começando com atividade sobre acessibilidade, não tente cobrir tudo de uma vez. Escolha uma página crítica, faça o teste completo com leitor de tela e navegação por teclado, e corrija os problemas mais graves primeiro. Depois repita. Acessibilidade é processo, não produto final.
