A Corrente Quebrada
Vinte anos depois: o que aprendi reabrindo um livro que eu achava que conhecia
Em 2009, escrevi um livro sobre acessibilidade web. Foi o primeiro publicado no Brasil sobre o assunto, pelo menos que eu saiba. Na época, eu estava terminando a graduação, e o tema caiu no meu colo quase por acaso: um capítulo do meu trabalho de conclusão de curso sobre tecnologias web tinha chamado a atenção do meu orientador. Decidimos transformar aquilo em algo maior.
Lembro da reunião que começou tudo. Estávamos na sala da diretora da Edufal, a editora da Universidade Federal de Alagoas, pra conversar sobre um possível projeto envolvendo padrões web. Ela mencionou, quase de passagem, um e-mail que tinha recebido alguns dias antes. Um leitor cego reclamava de não conseguir acessar o site que apresentava a nova coleção de livros em braille da editora. Ele nem conseguia ler os títulos das obras que eram feitas pra ele.
Não precisei ouvir mais nada. Saí daquela reunião com um acordo pra escrever o livro, e um projeto concreto pra tornar aquele site acessível.
Vinte anos depois, reabri esse livro.
A decisão de recomeçar
A ideia inicial era modesta: atualizar algumas referências, incorporar o WCAG 2.2, adicionar design patterns mais recentes. Uma revisão, não uma reescrita. Mas ao reler os primeiros capítulos, percebi que o problema não era a idade dos dados. Era o próprio arcabouço conceitual.
Em 2009, a acessibilidade web era apresentada, no meu livro como na maioria dos materiais da época, como uma lista de recomendações a seguir. Um conjunto de critérios técnicos pra marcar como cumpridos e ser “conforme”. A pergunta implícita era: como tornar um site acessível? A pergunta mais profunda, por que tantos sites continuam não sendo acessíveis, ficava sem resposta.
Então recomecei. Não uma atualização. Uma reescrita completa, em francês dessa vez, como uma forma de devolver o que aprendi no Quebec. E, voltando às fontes, descobri algo desconfortável.
Os números que não se movem
Todo ano, desde 2019, a organização WebAIM publica o WebAIM Million: uma análise automatizada da acessibilidade do milhão de páginas iniciais mais visitadas do mundo. É um dos indicadores mais confiáveis do setor.
Em 2019, 97,8% das páginas apresentavam erros de acessibilidade detectáveis.
Em 2026, esse número é 95,9%. Com uma média de 56,1 erros por página, um aumento de 10,1% em relação ao ano anterior.
Sete anos de relatórios. Uma melhora de 2 pontos percentuais. E um aumento no número médio de erros por página.
Isso não é uma falha técnica. As ferramentas existem. As diretrizes são públicas, gratuitas, bem documentadas. As seis categorias de erro que representam 96% de todas as falhas detectadas são as mesmas há sete anos consecutivos: textos alternativos ausentes, contraste insuficiente, rótulos de formulário faltando, links sem texto descritivo. Problemas elementares. Problemas conhecidos.
Então por quê?
O que entendi buscando a resposta
Vasculhando a literatura recente, encontrei um dado que me parou: 62% dos desenvolvedores franceses desconhecem as normas de acessibilidade. Não os detalhes técnicos: as próprias normas.
E mesmo entre quem as conhece, a acessibilidade é tratada como uma verificação de fim de projeto. Uma auditoria feita depois de pronto. Uma caixinha pra marcar antes de publicar. Essa abordagem tem um nome no setor: bolt-on accessibility, a acessibilidade aparafusada depois, como um acessório colado num produto já finalizado.
Foi exatamente isso que meu primeiro livro incentivava, sem dizer isso explicitamente. Ao apresentar a acessibilidade como uma lista de critérios pra validar, eu reproduzia, sem perceber, o mesmo arcabouço que mantém o problema no lugar.
A pergunta, então, não é: como tornar um site acessível? A pergunta é: por que continuamos construindo sites inacessíveis apesar de quinze anos de legislação, ferramentas e diretrizes?
Uma ruptura na cadeia, não um erro de código
O que mais me chamou atenção ao retomar esse assunto foi que a inacessibilidade quase nunca é resultado de um erro isolado. É resultado de uma ruptura numa cadeia.
A Web funciona como um ecossistema de componentes interdependentes: quem cria o conteúdo, as ferramentas que usam, os navegadores que interpretam o código, e as tecnologias assistivas que entregam tudo isso ao usuário. Quando um elo dessa cadeia cede, a experiência inteira desmorona, mesmo que todos os outros elos estejam sólidos.
Um desenvolvedor pode produzir um vídeo perfeitamente legendado. Se o player de vídeo embutido no site não oferece um botão acessível via teclado pra ativar essas legendas, o esforço é anulado. Um autor pode estruturar seu conteúdo com uma hierarquia de títulos impecável. Se o CMS gera automaticamente um código que sobrescreve essa estrutura, o trabalho desaparece.
A inacessibilidade, na grande maioria dos casos, não é um esquecimento. É uma consequência previsível de um design que não incorporou acessibilidade desde o início.
O que este livro tenta fazer diferente
A nova edição que estou escrevendo parte dessa constatação. Ela não propõe uma lista de critérios a cumprir. Propõe uma abordagem de engenharia: design patterns, métodos, formas de pensar que permitem incorporar acessibilidade ao processo de design, não depois dele.
O WCAG 2.2 tem seu lugar aqui, não como uma checklist burocrática, mas como uma base técnica pra entender por que certas decisões de design excluem usuários, e como corrigir isso de forma estrutural.
O livro é pra desenvolvedores, designers, criadores de conteúdo, gerentes de projeto, e qualquer pessoa que publica algo na Web e quer entender pra quem seu conteúdo está realmente chegando.
Vou documentar essa escrita aqui, aos poucos. As pesquisas, as dúvidas, as decisões editoriais, as surpresas.
A primeira surpresa você já leu: vinte anos depois, o problema quase não se moveu. Mas as razões mudaram. E é aí que fica interessante.