O que você realmente precisa saber antes de começar
A maioria dos projetos de acessibilidade que vejo sendo entregues falha não por falta de intenção, mas por má interpretação das diretrizes WCAG. Eu já passei por isso na prática. O problema é que as diretrizes existem num documento PDF de 400 páginas e a realidade do desenvolvimento é bem mais suja. Quando eu falo de projetos de acessibilidade, estou me referindo ao processo completo de integrar usabilidade para pessoas com deficiência em qualquer produto digital. Isso envolve design, desenvolvimento frontend, testes com usuários reais e documentação técnica. Mas o que a maioria dos times esquece é que acessibilidade não é um checklist — é uma cultura de desenvolvimento que precisa existir desde o primeiro wireframe.
projetos de acessibilidade na prática
Vou ser direto sobre como isso funciona no dia a dia. Eu comecei a trabalhar com acessibilidade em 2016, quando uma empresa contratou meu time para revisar o site institucional deles. O relatório que entregamos tinha 47 problemas críticos identificados. 47. A maioria eram problemas de semântica HTML mal aplicada, contraste de cores abaixo do mínimo e navegação por teclado completamente quebrada em formulários. O que ninguém te conta é que corrigir esses problemas custa tempo e dinheiro. E o tempo gasto em acessibilidade durante o desenvolvimento é cerca de 15% a 20% a mais do que o tempo padrão do projeto. Isso é real. Não tem como fugir. Mas o custo de não fazer é muito maior quando você considera multas, processos judiciais e a perda de acesso de uma fatia significativa da população.
No Brasil, a Lei Brasileira de Inclusão (Lei 13.146/2015) e o Decreto 10.177/2019 estabelecem requisitos legais claros. Projetos digitais do governo precisam seguir o eMAG — modelo de acessibilidade governamental — que se baseia nas WCAG 2.1 nível AA. Isso não é opcional para órgãos públicos. Para o setor privado, a obrigação existe principalmente quando há ação judicial ou quando a empresa recebe verba pública.
Passo a passo real para implementar
Aqui vai o método que eu uso quando inicio um projeto de acessibilidade do zero. Ele funciona porque é incremental e não tenta resolver tudo de uma vez. O primeiro passo é fazer um auditoria automatizada. Você roda ferramentas como axe-core, Lighthouse ou WAVE no produto existente e gera um relatório. Isso cobre cerca de 30% a 40% dos problemas. O resto precisa de revisão manual. Nunca confie cegamente nessas ferramentas — elas falham em detectar problemas de ordem semântica, lógica de tabindex e experiências de navegação por teclado que só um humano percebe.
O segundo passo é priorizar por impacto. Eu costumo usar esta tabela de priorização: Crítico — problemas que impedem completamente o uso do produto por pessoas com deficiência. Isso inclui falta de alternativas de texto em imagens funcionais, formulários sem labels associados, links sem texto descritivo. Resolva isso primeiro.
Alto — problemas que dificultam significativamente o uso. Contraste de cor abaixo de 4.5:1 para texto normal, estado de foco invisível em elementos interativos, transições que causam movimento excessivo. Esses problemas causam frustração constante. Médio — problemas que criam atrito mas não bloqueiam. Ordem de tabulação incorreta em grupos complexos, timestamps sem formatação ARIA apropriada, cabeçalhos hierárquicos desorganizados. Resolve-se depois dos críticos.
O terceiro passo é corrigir usando HTML semântico como base. A maior parte dos problemas de acessibilidade existe porque os desenvolvedores usam divs e spans onde deveriam usar elementos semânticos apropriados. Um botão que é uma div com um evento de clique não é acessível. Um link que é uma span com JavaScript também não é. Use <button> para ações, <a> para navegação, <nav> para menus, <main> para o conteúdo principal. Isso sozinho resolve uma quantidade enorme de problemas sem precisar de muito trabalho adicional.
O problema que ninguém espera
Em 2019, enquanto trabalhava na modernização de um sistema de e-commerce, nos deparamos com um problema específico que não estava em nenhuma guideline. O sistema usava um carrossel de produtos que ia automaticamente a cada 3 segundos. Para usuários de leitores de tela, isso era devastador. O leitor de tela entrava em loop, lê o conteúdo do carrossel repetidamente sem conseguir pausar de forma confiável. Os usuários com deficiência visual simplesmente desistiam de usar a funcionalidade. A solução que implementamos foi duplamente complicada. Primeiro, adicionamos um botão de pausa visível que também era detectável por teclado e leitores de tela. Segundo, reescrevemos o carrossel para usar ARIA roles apropriados (aria-roledescription="carousel", aria-live="polite") e implementamos um debounce de 5 segundos entre as faixas de conteúdo anunciadas pelo leitor de tela. O desenvolvedor que herdou esse código depois ficou três dias tentando entender por que o carrossel continuava se movendo mesmo após o botão de pausa ser ativado. O problema era que tínhamos dois setInterval rodando — um no JavaScript puro e outro numa biblioteca de terceiros. Removemos o setInterval do JavaScript e mantemos apenas o da biblioteca, controlado pelo estado do botão.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Isso ilustra algo importante: acessibilidade não é uma camada que se adiciona por cima. É uma característica estrutural do produto. Quando você tenta adicionar depois, o custo explode exponencialmente.
Ferramentas que realmente funcionam
Eu recomendo estas ferramentas no meu fluxo de trabalho, mas com ressalvas importantes sobre cada uma. axe DevTools — Extensão para Chrome e Firefox. É a mais precisa entre as ferramentas automatizadas. Consegue identificar problemas de contraste, ordem de tabulação, labels faltantes e questões de ARIA com boa precisão. Porém, ela não testa navegação por teclado real. Você precisa testar isso manualmente com a tecla Tab. O tempo estimado para uma auditoria completa com axe é de 30 minutos a 1 hora para uma página padrão.
Lighthouse — Integrado ao Chrome DevTools. Ótimo para uma visão geral rápida, especialmente em projetos React ou Angular onde o acesso ao DOM pode ser mais complicado. A pontuação de acessibilidade do Lighthouse é útil para tracking ao longo do tempo, mas não é suficiente para garantir conformidade real. O Lighthouse também tem falsos positivos e não consegue detectar problemas de conteúdo dinâmico gerado por JavaScript assíncrono. WAVE — Ferramenta online e extensão de navegador. Boa para uma segunda validação, especialmente para problemas visuais de contraste. Porém, ela processa o HTML renderizado e não o código-fonte, então problemas de ARIA dinâmica podem passar despercebidos.
Navegação por teclado manual — Esta é a ferramenta mais subestimada e mais importante. Abra seu site, pressione Tab do início ao fim e anote tudo que estiver fora de ordem, tudo que não tiver foco visível, tudo que for inacessível. Leva 20 minutos para uma página simples e revela problemas que nenhuma ferramenta automatizada consegue encontrar.
O erro mais comum que eu vejo
Desenvolvedores frequentemente colocam atributos ARIA em elementos que já são semanticamente corretos. Isso é o que chamamos de ARIA override e é pior do que não fazer nada. Se você tem um <button>, não precisa adicionar role="button". O navegador já sabe que é um botão. O atributo extra só cria ruído para leitores de tela e aumenta o risco de inconsistência quando o markup muda. A regra de ouro da acessibilidade em CSS é simples: nunca use display: none ou visibility: hidden para esconder elementos interativos quando você quer que sejam acessíveis via teclado. A única exceção legítima é o pseudo-elemento :focus-visible do CSS, que permite esconder outlines de foco quando o usuário está navegando com mouse mas mostrá-los quando navega com teclado. Isso reduz o ruído visual sem comprometer a acessibilidade.
A parte que os clientes não gostam de ouvir
Acessibilidade não é um feature que se entrega num sprint. É um atributo transversal. Quando você contrata alguém para fazer "acessibilidade" no final do projeto, está fazendo algo muito mais caro do que se tivesse integrado acessibilidade desde o início. Eu vi Orçamentos de consultoria de acessibilidade pós-desenvolvimento variarem de R$ 8.000 a R$ 50.000 para sites que poderiam ter sido construídos com acessibilidade nativa por uma fração desse valor. O custo de manutenção também é subestimado. Cada novo componente adicionado ao sistema precisa ser testado quanto a acessibilidade. Se você tem um design system, cada componente novo deve passar por um checklist de acessibilidade antes de ser mergeado. Isso adiciona talvez 15 minutos por componente novo, mas evita que problemas se acumulem ao longo do tempo.
Também preciso ser honesto sobre o que não funciona. Ferramentas de testes automatizados nunca vão substituir testes com usuários reais com deficiência. Um usuário com baixa visão testando seu site com zoom de 400% vai encontrar problemas que nenhuma ferramenta automatizada detecta. Um usuário com dano motor testando com teclado só vai encontrar problemas de ordem de tabulação e estados de foco que passam despercebidos em testes manuais apressados. Invista em testes com usuários reais sempre que possível. O custo varia entre R$ 500 e R$ 2.000 por sessão, dependendo da complexidade e do perfil do participante. Outro ponto importante: a conformidade com WCAG não garante que o produto seja acessível para todas as pessoas com deficiência. Uma pessoa com daltonismo, uma com baixa visão, uma com mobilidade reduzida, uma com deficiência cognitiva — todas têm necessidades diferentes. O nível AA atende à maioria, mas existem lacunas. O nível AAA exige muito mais trabalho e pode não ser viável para todos os casos. A prática recomendada é visar o AA e documentar abertamente as exceções e limitações encontradas.
Se você está começando agora, o caminho mais eficiente é: auditar o produto atual, priorizar os problemas críticos, corrigir com HTML semântico primeiro, implementar o checklist de componentes no design system e agendar testes com usuários reais. Leva tempo, mas o retorno é mensurável tanto em termos de redução de risco legal quanto em expansão real do público alcançado pelo produto.
