O WebAIM Million de 2025 examinou o milhão de homepages mais acessadas do mundo e encontrou 94,8% delas em não conformidade com WCAG 2 nível A ou AA, com média de 51 erros detectáveis por página. A distribuição dos erros é concentrada: contraste insuficiente, alt text ausente, labels de formulário vinculadas incorretamente e links sem texto acessível respondem pela maior parte dos defeitos, e todos eles são detectáveis por automação em segundos. Pra mim, o dado relevante não está em uma suposta dificuldade técnica de acessibilidade. A maioria das organizações opera com a premissa implícita de que os 15% de usuários com alguma deficiência funcional não movem a agulha de receita o suficiente pra justificar o investimento, e essa premissa se sustenta enquanto ninguém mede o que está sendo deixado na mesa.
Na minha experiência, o padrão recorrente é o tratamento de acessibilidade como camada posterior, algo que entra no backlog depois que o produto já foi desenhado, construído e lançado. O time de produto define fluxos assumindo usuário com visão, motricidade fina e cognição típica, engenharia implementa sobre essa premissa e QA valida comportamento funcional sem considerar tecnologia assistiva. Alguém lembra de acessibilidade durante uma auditoria ou quando uma ação judicial bate à porta, e aí o retrabalho é dimensionado como projeto de correção, tipicamente custando múltiplos do que teria custado se os critérios WCAG tivessem sido incorporados na especificação. A dívida técnica de acessibilidade acumula juros de forma particularmente cruel porque cada componente novo construído sobre fundações inacessíveis herda o problema e o propaga.
Na minha avaliação, acessibilidade opera como propriedade arquitetural que precisa ser decidida no momento em que a semântica do HTML, a ordem do DOM e a hierarquia de navegação por teclado são definidas, e não como camada de qualidade aplicada ao produto pronto. Uma vez que o produto foi construído assumindo divs clicáveis, modais sem foco gerenciado e formulários sem associação explícita entre label e input, a correção posterior exige tocar em praticamente cada componente implementado. O custo marginal de construir acessível desde o início é mensurável e pequeno. O custo marginal de retrofitar acessibilidade em um produto maduro é consistentemente alto o suficiente pra que a maioria das empresas acabe fazendo apenas o mínimo pra evitar passivo jurídico.
Os critérios WCAG 2.2 nível AA são o patamar operacionalmente relevante. São 87 critérios de sucesso no total, e a adesão ao nível AA cobre os requisitos exigidos pela maioria das legislações vigentes, incluindo o European Accessibility Act, exigível desde junho de 2025 pra produtos e serviços digitais comercializados na União Europeia. Pra empresas brasileiras com ambição de operar em mercados europeus ou norte-americanos, acessibilidade deixa de ser uma discussão sobre ética e vira um pré-requisito de acesso ao mercado. A LBI, no Brasil, já estabelece obrigação análoga desde 2015, mas a fiscalização historicamente frouxa criou a ilusão de que o requisito era opcional. Essa ilusão tende a se dissipar à medida que ações judiciais por exclusão digital se multiplicam e o custo reputacional entra na equação.
O trade-off operacional aparece no desenho de componentes. Implementar um select customizado que se comporta corretamente com NVDA, VoiceOver e navegação por teclado exige mais código, mais testes e mais manutenção do que usar o elemento nativo do HTML. A tentação de reinventar primitivos pra atender requisitos estéticos específicos é recorrente e compreensível, mas cada primitivo reinventado assume o ônus integral de replicar comportamento que o navegador oferece gratuitamente. Times que internalizam esse custo passam a tratar o HTML semântico como default, reservando a customização pra casos onde o ganho de experiência é mensurável e o custo de acessibilidade foi explicitamente orçado.
A instrumentação mínima pra tratar acessibilidade como propriedade contínua do produto começa por verificação automatizada no pipeline, com ferramentas como axe-core ou Lighthouse rodando em cada pull request e bloqueando merges que introduzam regressões em critérios automatizáveis. Isso cobre cerca de 30% a 40% dos problemas reais. Os 60% restantes envolvem julgamentos sobre clareza semântica, ordem lógica e previsibilidade que nenhuma ferramenta detecta, e exigem teste manual com tecnologia assistiva. E ainda assim sobra uma camada que escapa tanto de automação quanto de especialistas: a validação com usuários com deficiência, que é onde aparece a fricção que ninguém antecipou no projeto.
Em organizações que tratam acessibilidade como propriedade arquitetural, a base de usuários alcançável se expande de forma concreta e captura uma parcela do mercado que a concorrência descartou por negligência. Junto disso, a qualidade do código tende a melhorar, porque as práticas que tornam uma interface acessível (HTML semântico, hierarquia clara de headings, contraste adequado, navegação previsível por teclado) são as mesmas que a tornam robusta e testável, resistindo melhor a mudanças. Acessibilidade, na minha análise, funciona como indicador indireto de maturidade de engenharia. Quando uma empresa ignora WCAG, raramente o problema se resume à exclusão de usuários com deficiência: o processo de desenvolvimento está operando sem disciplina semântica, e essa sinalização costuma se confirmar nas outras dimensões do produto.