Toda equipe com que trabalhei em quinze anos disse que a acessibilidade importa. As que realmente sustentaram isso sob pressão de prazo tinham uma coisa em comum: a acessibilidade vivia em código e ferramentas, não em intenções. Aqui está a configuração que uso, e onde a IA ajuda e atrapalha.
HTML semântico é 80% do trabalho
Antes do ARIA, antes das auditorias: use o elemento que significa a coisa. Um button para ações, a para navegação, elementos label de verdade nos inputs, headings em ordem. A maioria das falhas de acessibilidade que vejo em SaaS B2B não é exótica — é sopa de div com manipuladores de clique. Quando reviso componentes gerados por IA, isso é a primeira coisa que verifico, porque LLMs treinados na web aberta absorveram bastante sopa de div. Eles produzem marcação semântica se o seu prompt e sua base de código modelam isso, e reproduzem lixo se é isso que os cerca. Seu código existente é um prompt.
Decisões de design que são decisões de acessibilidade
Três que aparecem o tempo todo no meu trabalho de fintech e marketplace:
- Contraste no nível do token. Não audite contraste tela por tela; valide uma vez, na paleta. Cada combinação de cor do design system é verificada quando o token é definido. Depois disso, qualquer tela construída com tokens herda a conformidade. Esse é todo o argumento a favor de tokens com dentes.
- Estados de foco são projetados, não deixados no padrão. Usuários de teclado em software corporativo não são um caso raro — power users de ferramentas B2B densas vivem no teclado. Eu projeto o anel de foco com o mesmo cuidado que o estado de hover, e faço um percurso só de teclado em cada fluxo antes de considerá-lo pronto. Leva dez minutos e sempre encontra algo.
- Mensagens de erro que dizem o que fazer. "Entrada inválida" falha com todo mundo, e falha ainda mais com usuários de leitor de tela, porque eles não conseguem olhar ao redor em busca de contexto. Vincule o erro ao campo de forma programática (
aria-describedby) e escreva-o como uma instrução: o que estava errado, o que digitar em vez disso.
Onde a IA realmente ajuda
Fluxos de trabalho acelerados por IA tornaram minha prática de acessibilidade melhor, não pior — mas só de formas específicas:
- Auditar em escala. Consigo rodar uma revisão orientada a WCAG em toda uma biblioteca de componentes em uma tarde: um modelo sinaliza candidatos, eu verifico cada um. O recall do modelo é ótimo; a precisão dele exige o meu julgamento.
- Padrões ARIA sob demanda. Acertar de memória um combobox ou um padrão de disclosure é sujeito a erro. Gerá-lo a partir do padrão documentado nas ARIA Authoring Practices e depois testá-lo com um leitor de tela de verdade é melhor do que fazer isso à mão.
- Revisão cross-model. Minha regra fixa — quem escreve não revisa — pega regressões de acessibilidade para as quais o modelo autor é cego. Um segundo modelo revisando código gerado já detectou labels ausentes, ordem de foco quebrada e botões só-ícone sem nome acessível.
O inegociável
Nenhuma passada automatizada, com ou sem IA, substitui usar a interface como os usuários afetados usam. Navegue com Tab. Ative o VoiceOver. Dê zoom para 200%. Evidência acima de intenções: um checklist que diz "acessível" é uma alegação; uma gravação de percurso com teclado é prova.
Acessibilidade não é uma camada de conformidade que você adiciona. É o que "funciona" significa, dito por completo.