Como sair das correções pontuais e construir uma cultura em que acessibilidade faça parte do processo, das equipes e das decisões.
Quando uma empresa começa a falar sobre acessibilidade digital, uma das primeiras perguntas costuma ser: nosso site é acessível?
Com o tempo, percebi que essa pergunta é pequena diante do problema.
Uma pergunta mais interessante seria: o que acontece com a acessibilidade quando o especialista não está na sala?
Como sair das correções pontuais e construir uma cultura em que acessibilidade faça parte do processo, das equipes e das decisões.
Quando uma empresa começa a falar sobre acessibilidade digital, uma das primeiras perguntas costuma ser: nosso site é acessível?
Com o tempo, percebi que essa pergunta é pequena diante do problema.
Uma pergunta mais interessante seria: o que acontece com a acessibilidade quando o especialista não está na sala?
Se uma funcionalidade nova nasce inacessível, se o design chega ao desenvolvimento sem considerar pessoas com deficiência, se a equipe só descobre problemas durante uma auditoria ou se toda decisão depende de uma única pessoa, existe trabalho de acessibilidade acontecendo. Mas ainda existe pouca maturidade.
Essa visão encontra respaldo no próprio Accessibility Maturity Model do W3C. O modelo foi criado para ajudar organizações a avaliar sua capacidade de desenvolver, entregar e manter recursos digitais acessíveis ao longo do tempo.
Isso muda bastante a conversa.
A questão deixa de ser apenas verificar se determinado produto atende a critérios técnicos. Passamos a observar se a organização possui processos capazes de produzir acessibilidade de maneira consistente.
Acessibilidade não pode depender de uma pessoa.
É comum a jornada começar com alguém puxando o assunto.
Essa pessoa testa interfaces, encontra barreiras, explica WCAG, conversa com design, orienta desenvolvimento e começa a provocar mudanças.
Esse trabalho é necessário. O problema aparece quando a organização passa a depender dessa pessoa para tudo.
O designer pergunta se pode usar determinado componente. O desenvolvedor chama alguém para validar o código. O produto espera uma auditoria para descobrir se existem problemas.
Nesse cenário, o especialista acaba funcionando como uma espécie de controle de qualidade da acessibilidade.
O W3C recomenda justamente uma distribuição mais clara dessas responsabilidades. Em sua orientação para planejamento e gestão da acessibilidade, responsabilidades podem estar espalhadas por desenvolvimento, qualidade, marketing, compras e outras áreas da organização.
Uma organização mais madura começa a incorporar essa responsabilidade às próprias equipes.
Design conhece contraste, foco, estados, estrutura e interação.
Desenvolvimento entende HTML semântico, teclado, nomes acessíveis, estados, ARIA e comportamento com tecnologias assistivas.
Produto começa a incluir requisitos de acessibilidade nas histórias e critérios de aceite.
QA incorpora testes de acessibilidade ao processo normal de validação.
E a liderança começa a enxergar acessibilidade como parte da qualidade do produto.
Dá para perceber a maturidade observando o processo.
Eu gosto de pensar a maturidade como uma evolução.
Não necessariamente como uma sequência rígida, porque organizações podem estar mais maduras em uma área e menos maduras em outra.
O próprio Accessibility Maturity Model do W3C trabalha com dimensões organizacionais e evidências que ajudam a demonstrar progresso. O Business Disability Forum também utiliza um modelo de autoavaliação para identificar o estágio atual da organização e orientar onde concentrar os próximos esforços.
Na prática, podemos observar alguns comportamentos.
1. Reação
A empresa corrige quando aparece um problema.
Pode ser uma reclamação, uma auditoria, um cliente ou uma exigência contratual.
A acessibilidade entra depois que o produto já existe.
O esforço costuma ser maior porque corrigir decisões estruturais depois da implementação pode significar alterar design, código e até fluxos inteiros.
O W3C recomenda incorporar acessibilidade desde o início dos projetos e aponta que isso tende a exigir menos tempo e recursos do que realizar adaptações posteriormente.
2. Conformidade
A organização começa a estabelecer referências.
WCAG passa a fazer parte das discussões. Surgem auditorias, checklists, testes automatizados e validações manuais.
É um avanço significativo.
Mas existe um risco: transformar acessibilidade em uma lista de critérios que precisam receber um “atende”.
WCAG é fundamental, mas conformidade sozinha não representa toda a maturidade de uma organização.
O Accessibility Maturity Model do W3C amplia essa análise justamente porque observa a capacidade organizacional de sustentar acessibilidade, e não somente o resultado de uma avaliação técnica isolada.
2. Conformidade
A organização começa a estabelecer referências.
WCAG passa a fazer parte das discussões. Surgem auditorias, checklists, testes automatizados e validações manuais.
É um avanço significativo.
Mas existe um risco: transformar acessibilidade em uma lista de critérios que precisam receber um “atende”.
WCAG é fundamental, mas conformidade sozinha não representa toda a maturidade de uma organização.
O Accessibility Maturity Model do W3C amplia essa análise justamente porque observa a capacidade organizacional de sustentar acessibilidade, e não somente o resultado de uma avaliação técnica isolada.
3. Processo
Aqui acontece uma mudança interessante.
A acessibilidade começa a aparecer antes do código.
Requisitos são definidos no produto. Componentes são pensados no design. Desenvolvimento recebe especificações melhores. QA sabe o que precisa validar.
Os testes também ficam mais completos.
Ferramentas automatizadas continuam sendo utilizadas, mas passam a conviver com testes de teclado, leitores de tela, zoom, reflow e outras verificações manuais.
A organização deixa de procurar acessibilidade somente no produto pronto.
Essa integração ao processo está muito próxima da orientação do W3C para planejamento e gestão da acessibilidade: iniciar, planejar, implementar e sustentar. A proposta é incorporar acessibilidade ao processo de produção e continuar avaliando e melhorando essa capacidade ao longo do tempo.
4. Escala
Depois que o processo funciona, surge outro desafio: fazer isso funcionar em dezenas de produtos e equipes.
É quando design systems acessíveis, componentes reutilizáveis, documentação, padrões internos, treinamentos e critérios de aceite ganham muita importância.
Um botão acessível implementado corretamente em um componente compartilhado pode evitar que diferentes equipes recriem o mesmo problema várias vezes.
O conhecimento também precisa deixar de ficar concentrado.
Quanto mais acessibilidade fizer parte das ferramentas e processos existentes, menor será a necessidade de criar um fluxo paralelo para ela.
Essa visão também aparece no Accessibility Evolution Model desenvolvido pela Microsoft. A empresa estruturou sua abordagem considerando dimensões como pessoas e cultura, estratégia, investimentos, padrões, treinamento, ferramentas, compras e ciclo de desenvolvimento de produtos.
É uma boa demonstração de que escalar acessibilidade exige olhar para muito mais do que o código de uma interface.
5. Cultura
Esse talvez seja o estágio mais interessante.
As pessoas começam a identificar problemas antes que alguém da acessibilidade precise apontá-los.
Um designer questiona uma interação.
Um desenvolvedor percebe que determinado componente não funciona corretamente pelo teclado.
QA encontra um problema com leitor de tela.
Produto inclui requisitos de acessibilidade desde o refinamento.
Nesse ponto, acessibilidade começa a fazer parte da definição interna de qualidade.
A Microsoft descreve algo semelhante em seu modelo de evolução: acessibilidade precisa ser administrada e medida de maneira sistemática para que consiga crescer e permanecer integrada à cultura da organização.
O especialista também muda de função.
A maturidade da organização muda o trabalho do profissional de acessibilidade.
No começo, boa parte do tempo pode ser consumida encontrando e documentando barreiras.
Em estruturas mais maduras, cresce o trabalho relacionado a arquitetura, padrões, governança, capacitação e prevenção.
Isso não elimina auditorias.
Auditorias continuam sendo importantes para verificar o resultado e encontrar problemas que passaram pelas outras etapas.
A diferença está no papel que elas ocupam.
Quando a auditoria é o primeiro momento em que alguém verifica acessibilidade, provavelmente existe um problema no processo.
Quando ela funciona como uma camada adicional de garantia de qualidade, o cenário é diferente.
Como saber onde uma empresa está?
Eu observaria menos a quantidade de documentos sobre acessibilidade e mais o que acontece durante a criação de um produto.
Algumas perguntas ajudam bastante:
- A acessibilidade aparece nos requisitos antes do desenvolvimento?
- Design possui padrões acessíveis documentados?
- Os componentes reutilizáveis já foram avaliados?
- Desenvolvedores conseguem identificar problemas básicos sem depender do especialista?
- QA realiza testes manuais além das ferramentas automatizadas?
- Existem testes com tecnologias assistivas?
- Pessoas com deficiência participam de pesquisas e avaliações?
- Os problemas encontrados geram melhorias no processo ou apenas correções pontuais?
- Existe alguém responsável por acompanhar indicadores e evolução?
- A liderança conhece as principais barreiras e acompanha sua redução?
As respostas mostram muito mais sobre maturidade do que simplesmente perguntar se a empresa “segue WCAG”.
O Business Disability Forum segue uma lógica semelhante em seu Accessibility Maturity Model. A ferramenta propõe que organizações avaliem onde estão atualmente para identificar áreas que precisam evoluir e definir prioridades.
Existe outro sinal que considero especialmente importante.
Observe onde os problemas são encontrados.
Se quase todas as barreiras aparecem na auditoria final, existe espaço para melhorar as etapas anteriores.
Se problemas começam a ser encontrados durante design, desenvolvimento e testes, alguma coisa mudou.
Melhor ainda quando determinadas barreiras deixam de aparecer porque o componente, padrão ou processo que as originava foi corrigido.
É aí que a organização começa a sair da correção recorrente e entrar na prevenção.
Maturidade também significa medir
Sem algum tipo de acompanhamento, é difícil saber se a organização está evoluindo.
Quantidade de problemas encontrados pode ser um indicador, mas precisa de contexto.
Encontrar mais problemas em determinado período pode significar que a acessibilidade piorou. Também pode significar que a empresa passou a testar melhor.
- Por isso, gosto de olhar para indicadores relacionados ao processo.
- Em que etapa as barreiras estão sendo encontradas?
- Quantas chegam à produção?
- Quanto tempo levam para ser corrigidas?
- Os mesmos problemas continuam aparecendo?
- Quantos componentes do design system foram validados?
- Quantas equipes conseguem executar testes básicos sem apoio direto?
O Business Disability Forum também relaciona maturidade a medição. Sua orientação sobre métricas de acessibilidade inclui acompanhamento de progresso, marcos, satisfação de usuários e outros indicadores definidos de acordo com os objetivos da organização.
O próprio modelo de maturidade pode funcionar como instrumento periódico de benchmarking.
Isso permite uma mudança importante: em vez de perguntar apenas quantos erros existem hoje, começamos a perguntar se nossa capacidade de evitar esses erros está aumentando.
E maturidade não significa ausência de problemas.
Uma empresa madura também encontra falhas de acessibilidade.
Produtos mudam. Tecnologias mudam. Componentes são atualizados. Pessoas novas entram nas equipes.
A diferença está na capacidade de identificar, corrigir e aprender com essas falhas.
Uma organização pode ter uma excelente política de acessibilidade e ainda entregar experiências ruins.
Outra pode estar no início da jornada, mas já ter construído mecanismos consistentes para melhorar.
Por isso, eu não trataria maturidade como um selo.
Ela é uma capacidade organizacional que precisa ser desenvolvida.
Importante: se amanhã o especialista em acessibilidade não participar de um projeto, a equipe ainda saberá como construir e validar uma experiência acessível?
Quanto mais a resposta se aproxima de “sim”, mais a acessibilidade deixou de depender de esforço individual e passou a fazer parte da organização.
Para mim, esse é um dos sinais mais fortes de maturidade.
Porque acessibilidade sustentável acontece quando conhecimento, responsabilidade e processo conseguem continuar funcionando mesmo quando ninguém precisa lembrar a equipe de que acessibilidade existe.
Referências
W3C Web Accessibility Initiative (WAI). Accessibility Maturity Model. W3C Group Note, 4 de novembro de 2025. Framework para avaliar e desenvolver a maturidade de acessibilidade de organizações e acompanhar sua evolução ao longo do tempo.
W3C Web Accessibility Initiative (WAI). Planning and Managing Web Accessibility. Orientações para incorporar acessibilidade ao planejamento, implementação, monitoramento e melhoria contínua de projetos e organizações.
W3C Web Accessibility Initiative (WAI). Developing Organizational Policies on Web Accessibility. Orientações para criação de políticas organizacionais e integração da acessibilidade a padrões, processos e responsabilidades.
Business Disability Forum. Accessibility Maturity Model. Modelo de autoavaliação desenvolvido pela Technology Taskforce para avaliar maturidade organizacional em acessibilidade digital e identificar áreas de evolução.
Business Disability Forum. How to measure and report on accessibility. Orientações sobre métricas, indicadores, benchmarking e acompanhamento da evolução da acessibilidade nas organizações.
Microsoft. Accessibility Evolution Model: Creating Clarity in your Accessibility Journey. Modelo desenvolvido pela Microsoft para acompanhar a evolução da acessibilidade em dimensões como cultura, estratégia, treinamento, ferramentas, compras e desenvolvimento de produtos.