"Estamos em conformidade com a lei."
É uma afirmação comum e, para muitos decisores, tranquilizadora. Significa que o tema foi endereçado, houve preocupação, e que, em caso de auditoria, existe uma resposta.
Mas há uma questão que raramente entra na discussão: estar compliant garante que o seu produto é utilizável por todos?
Na maioria dos casos, não. E é nessa diferença - entre cumprir e ser efetivamente acessível - que reside o verdadeiro risco. Não o risco legal imediato, mas o risco silencioso: perda de utilizadores, abandono, exclusão e impacto reputacional.
Conformidade não é o mesmo que acessibilidade
A acessibilidade não é um ponto de chegada. É um processo contínuo. Um produto pode cumprir todos os critérios formais e, ainda assim, falhar sistematicamente para quem depende de tecnologias de apoio, porque conformidade mede o que foi construído, não se funciona.
O equívoco começa nos próprios indicadores. Scores elevados em ferramentas como axe DevTools ou Lighthouse criam uma sensação de controlo, mas cobrem apenas uma fração do problema, e quase sempre a parte mais fácil de medir. Um exemplo concreto: um componente de modal pode passar a 100% numa auditoria automática e ainda assim ser completamente inutilizável com leitor de ecrã, se o foco não for gerido corretamente ou se o conteúdo de fundo não for bloqueado. As ferramentas não testam isso. Testam presença de atributos, não comportamento real.
O que fica de fora é precisamente o mais crítico: se o utilizador consegue compreender o que está a fazer, navegar sem rato, completar uma tarefa sem ficar preso.
O custo invisível de assumir que está resolvido
Para um decisor, o problema não são erros técnicos. São as consequências que esses erros têm no negócio: um utilizador que não consegue completar uma compra, um cidadão que não consegue aceder a um serviço, um potencial cliente que desiste antes de converter. Tudo isto em produtos que, internamente, são considerados conformes.
A entrada em vigor do Ato Europeu de Acessibilidade veio reforçar a importância da conformidade, mas também expôs uma realidade: cumprir requisitos mínimos não protege contra más experiências, nem contra risco reputacional. Os utilizadores não distinguem entre "não cumpre" e "cumpre mal". Distinguem apenas entre conseguir usar ou não conseguir usar.
A raiz do problema está na forma como a acessibilidade é integrada - ou não - no processo de desenvolvimento. Quando é validada apenas no fim, ou delegada exclusivamente a equipas técnicas, deixa de ser uma garantia e passa a ser uma suposição. Sem validação contínua, os problemas acumulam-se silenciosamente de sprint em sprint. Quando são detectados, o custo de correção é substancialmente mais elevado.
Da monitorização contínua à especialização humana
Uma das mudanças mais práticas que uma equipa pode fazer é introduzir monitorização de acessibilidade ao longo de todo o ciclo de desenvolvimento, não apenas em auditorias pontuais. Ferramentas integradas nos pipelines de CI/CD permitem detectar regressões à medida que o código evolui, reportar novos problemas automaticamente e garantir que a equipa reage antes que os erros cheguem à produção.
Mas há um limite claro no que as ferramentas conseguem fazer. Nenhuma ferramenta substitui o conhecimento humano. Os testes automáticos cobrem entre 20 a 30% dos problemas reais de acessibilidade, dependendo do tipo de produto e das ferramentas usadas. O restante exige avaliação humana.
É aqui que a presença de especialistas faz a diferença, não apenas para corrigir, mas para prevenir. Para formar as equipas, integrar critérios de acessibilidade nas decisões de design e desenvolvimento, e garantir que os testes manuais são feitos de forma recorrente e com rigor.
Na Mediaweb, trabalhamos acessibilidade como um espectro contínuo, não como um serviço pontual. Isso significa auditorias WCAG detalhadas que vão além do score automático; desenvolvimento acessível integrado desde o início dos projetos; monitorização contínua com ferramentas que detectam regressões em cada ciclo; testes manuais recorrentes com leitores de ecrã e navegação por teclado; e formação das equipas para que acessibilidade seja uma decisão de design e desenvolvimento, não uma correção de último minuto.
O objetivo não é passar numa auditoria. É garantir que o produto funciona para todos, em qualquer momento do seu ciclo de vida. Se a sua organização está a questionar se conformidade é suficiente, podemos ajudar a perceber onde estão as lacunas reais.
Cumprir não chega
Há uma forma simples de validar tudo isto. Quando foi a última vez que alguém, fora da equipa, tentou completar uma tarefa crítica no seu produto em condições reais de acessibilidade? Sem rato. Com leitor de ecrã. Com limitações visuais ou cognitivas.
Se a resposta não for clara, a conformidade pode existir, mas a acessibilidade continua por validar.
A questão não é se a sua organização está compliant. É se está a garantir que o produto funciona para todos. Essa resposta não se assume. Valida-se - com utilizadores reais, em cenários reais, de forma contínua. Porque a diferença entre cumprir e ser acessível não é técnica. É estratégica. E, cada vez mais, é negócio.