Acessibilidade de verdade: o agente audita, a pessoa confirma
Um agente varre WCAG em minutos, contraste, alt text, ordem de foco, papel ARIA, cobrindo em escala o que checklist manual levaria dias. Só que aprovado técnico não é experiência real: carga cognitiva, ordem de leitura e confusão de rótulo só a pessoa sente. Acessibilidade de verdade é a soma dos dois.
Uma prefeitura manda inspecionar a rampa de acesso de um prédio público. O fiscal chega, mede a inclinação com o instrumento certo, confere a largura mínima, olha o corrimão, tudo dentro da norma técnica. Carimba aprovado. Só que ninguém empurrou uma cadeira de rodas de verdade por aquela rampa: o piso é liso demais quando chove, a porta no topo é pesada e não tem barra de apoio, e uma pessoa numa cadeira de rodas de verdade não consegue abrir sozinha depois de subir. A rampa passou na medição. A experiência real de quem precisa dela continua impossível.
Um sistema de conciliação bancária confere automaticamente todas as transações do mês e marca "conciliado", porque cada lançamento bateu com um registro correspondente. Passa na régua técnica. Só que um auditor humano, olhando os valores com atenção, repara que três transações "conciliadas" foram pareadas com o registro errado, valores parecidos mas de contas diferentes, algo que a régua automática não tinha como perceber porque ela só confere se existe par, não se o par faz sentido de negócio.
Uma ferramenta de revisão de contrato confere, cláusula por cláusula, se cada uma bate com o modelo padrão do escritório. Todas passam na checagem individual. Só que um advogado lendo o contrato inteiro, do início ao fim, percebe que a cláusula 4.2 de rescisão, sozinha correta, contradiz a cláusula 9 de multa quando lidas juntas, um problema que só aparece na leitura contínua, não na checagem isolada de cada cláusula.
Um verificador automático de marca confere se toda peça de uma campanha usa a cor certa, a fonte certa, o logo no tamanho certo. Cem por cento de conformidade técnica. Só que um revisor humano, lendo a peça como o cliente vai ler, percebe que a frase de abertura soa condescendente pro público daquela região, algo que nenhuma checagem de cor ou fonte jamais capturaria, porque é sobre tom, não sobre forma.
Um sistema de triagem automática aprova um candidato porque o currículo bate com as palavras-chave da vaga: as certificações certas, os anos de experiência certos. Passa no filtro. Só que o entrevistador humano, na conversa, percebe que o candidato nunca liderou um time em crise de verdade, só documentou isso no papel, uma diferença que nenhuma palavra-chave capturaria, porque exige julgamento humano sobre a experiência real por trás do texto.
Uma suíte de testes automatizados roda antes de cada deploy e aprova a build inteira, todos os testes verdes. Passa na régua técnica. Só que num teste com usuário real, uma pessoa trava no segundo passo do onboarding porque não entende o que o botão "continuar" vai fazer, um problema que nenhum teste automatizado pegaria, porque ele testa se o código funciona, não se a pessoa entende o que está na tela.
Um CRM valida automaticamente que um negócio está pronto pra avançar de fase, todos os campos obrigatórios preenchidos, checklist verde. Passa na régua do sistema. Só que o vendedor, na call de verdade, sente que o cliente está hesitante e o negócio corre risco real de esfriar, algo que nenhum campo de formulário capturaria, porque é leitura humana de tom de voz e hesitação, não dado estruturado.
Um painel de SLA mostra o atendimento nível 2 dentro da meta, cem por cento verde no mês. Aprovado no painel. Só que um atendente da linha de frente sabe que, em um tipo específico de chamado, a equipe sempre estica o prazo até o limite e disfarça no relatório, um problema que o painel de média mensal não revela, porque ele mede o agregado, não o caso específico que quase sempre falha.
Um checklist automático confere se a política de privacidade cita todos os itens exigidos pela LGPD, e ela cita, item por item. Aprovado tecnicamente. Só que um revisor humano, lendo o fluxo de consentimento como o usuário realmente vive, percebe que o botão de aceitar é grande e destacado enquanto o de recusar é um link cinza quase invisível, uma prática que passa na checagem de texto e falha completamente no espírito da lei.
Um pipeline de CI roda a suíte de testes unitários e de integração antes do merge, tudo verde, cobertura de código acima da meta. Aprovado tecnicamente. Só que em produção, sob carga real, um engenheiro humano descobre que uma race condition rara derruba o serviço uma vez por semana, algo que nenhum teste automatizado capturou porque a condição só aparece na concorrência real de usuários, não no ambiente controlado do teste.
Você roda um scanner de acessibilidade no fluxo de checkout do seu produto e ele aprova em minutos: contraste dentro do mínimo exigido, toda imagem com texto alternativo, ordem de foco no teclado sem furo, papéis ARIA presentes onde deveriam estar. Cem por cento verde na régua técnica. Só que quando você mesmo navega esse mesmo fluxo de olhos fechados, usando um leitor de tela de verdade, descobre que o botão "Finalizar" é lido antes do resumo do pedido, então quem usa o leitor de tela ouve "finalizar" sem saber ainda o que está finalizando. Tecnicamente, cada elemento passou na checagem isolada. Na experiência real de quem depende do leitor de tela pra comprar, o fluxo inteiro não faz sentido.
Um painel de OKR mostra todos os indicadores do trimestre em verde, cada meta numérica batida dentro do prazo. Aprovado no painel. Só que um executivo revisando o plano com calma percebe que as metas verdes não tocam de fato a ameaça competitiva que motivou o plano, o time bateu número, mas o problema real que o board queria resolver continua de pé, invisível pro painel que só mede o que foi definido como métrica.
Putz, deixa eu te contar a cena que mais engana gente boa nesta trilha. Você roda um scanner de acessibilidade no seu checkout, ele devolve tudo verde, contraste ok, alt text ok, foco ok, ARIA ok, e você respira aliviado achando que resolveu. Só que quando você mesmo navega aquele fluxo com um leitor de tela de verdade, sem trapacear usando o mouse, descobre que a ordem de leitura não faz sentido nenhum: o botão de finalizar é lido antes do resumo do pedido. Aprovado técnico e inutilizável na prática, ao mesmo tempo, no mesmo fluxo. Esta aula é sobre entender por que isso acontece, e sobre a régua certa pra não cair nessa cilada.
A ideia central desta aula. Um agente de IA consegue auditar WCAG (contraste de cor, texto alternativo em imagem, ordem de foco no teclado, papel ARIA) em escala e em minutos, cobrindo o que um checklist manual levaria dias pra revisar em todo o produto. Isso resolve a conformidade técnica. Não resolve, sozinho, a experiência real de quem usa leitor de tela, navega só por teclado ou tem baixa visão: carga cognitiva, ordem de leitura que faz sentido, um rótulo que tecnicamente passa no contraste mas confunde na prática, são coisas que o agente não sente, só a pessoa sente. A régua desta aula é simples de enunciar: o agente faz a varredura ampla e cobre o volume que ninguém tem tempo de checar manual em tudo; a pessoa, idealmente alguém que de fato usa tecnologia assistiva, ou um teste guiado por heurística humana, confirma o que importa de verdade na experiência. Acessibilidade de verdade é a soma dos dois. Nunca só a varredura automática, que pode dar aprovado numa tela ainda assim inutilizável.
Por que carga cognitiva e ordem de leitura que faz sentido são difíceis de auditar só com ferramenta automática?
Não conta nota. É para você ver o que já pensa — a aula responde logo abaixo.
01O que o agente resolve rápido: a varredura em escala
Comeca pelo que a IA faz genuinamente bem, e é bastante coisa. Um agente com acesso ao seu produto consegue rodar, em minutos, uma auditoria contra a régua técnica objetiva da acessibilidade, o WCAG 2.2, o padrão do W3C que define critérios mensuráveis: será que o contraste entre texto e fundo está acima do mínimo, será que toda imagem tem um texto alternativo descrevendo o que ela mostra, será que a ordem de foco ao navegar por teclado segue uma sequência lógica, será que os elementos interativos têm o papel ARIA correto pra tecnologia assistiva entender o que são.
Isso é volume que checklist manual não dá conta de cobrir em todo o produto, toda tela, todo componente, toda vez que algo muda. Um agente faz essa varredura de novo a cada mudança, sem cansar e sem pular tela. É exatamente o tipo de trabalho mecânico e repetitivo que vale a pena tirar da mão humana, pra sobrar tempo pro que só a mão humana consegue avaliar.
02O que só a pessoa sente: carga cognitiva, ordem que faz sentido, confusão real
Agora o outro lado, que é onde a cilada mora. Um elemento pode passar em todos os critérios técnicos, isoladamente, e o fluxo inteiro ainda assim não fazer sentido pra quem usa tecnologia assistiva. O caso do exemplo que abriu a aula é exatamente esse: cada elemento do checkout, sozinho, batia com o WCAG. O botão tinha contraste correto. A imagem tinha texto alternativo. O papel ARIA estava presente. Só que a ordem em que o leitor de tela lia esses elementos não seguia a lógica do que uma pessoa precisa saber antes de decidir: ouvir "finalizar" antes de ouvir o que está sendo finalizado quebra a experiência inteira, mesmo com todos os critérios técnicos aprovados um por um.
Isso acontece porque existem dimensões de acessibilidade que não se resumem a uma regra binária de passa ou não passa. Carga cognitiva, é fácil entender o que essa tela pede de mim, ou preciso reler três vezes. Ordem de leitura, o que vem primeiro faz sentido pra decisão que eu preciso tomar. Clareza de rótulo, "clique aqui" tecnicamente tem contraste bom, mas não diz nada sobre o que vai acontecer quando eu clicar. Nenhuma dessas três coisas é medida por uma ferramenta automática, porque elas não são propriedades do código, são propriedades da experiência vivida por uma pessoa navegando aquele fluxo de um jeito específico. Só quem de fato depende de leitor de tela, ou navega o dia inteiro só de teclado, sente esse tipo de atrito na pele.
03A régua da aula: o agente cobre o volume, a pessoa confirma a experiência
Chegamos na divisão de trabalho que resolve o problema sem descartar nenhum dos dois lados. O agente entra primeiro, e faz a varredura ampla: todo o produto, todo componente, contra a régua objetiva do WCAG 2.2. Isso já elimina uma quantidade grande de problema real, porque muita barreira de acessibilidade é, sim, técnica e mecânica, contraste ruim, imagem sem descrição, elemento sem papel ARIA, coisas que a varredura pega direto e que representam boa parte dos problemas mais comuns na web hoje.
Só que a literatura do setor é honesta sobre o limite: menos da metade dos problemas reais de acessibilidade costuma ser detectável só por ferramenta automática, o resto exige avaliação humana, com julgamento sobre experiência de uso. Por isso a régua certa não é escolher entre agente ou pessoa, é usar os dois em sequência: o agente varre tudo, rápido e barato, cobrindo o volume que nenhum time teria tempo de revisar manualmente em cada tela. A pessoa, depois, testa o fluxo de verdade, de preferência alguém que usa tecnologia assistiva no cotidiano, ou pelo menos um teste guiado por heurística humana (navegar só de teclado, ouvir o fluxo inteiro com leitor de tela ligado, sem trapacear olhando a tela). O que a pessoa encontra ali é exatamente o que o agente, por natureza, não consegue sentir.
Por que "aprovado técnico" não é sinônimo de acessível
Vale entender a raiz do problema pra não cair nele de novo em outro contexto. O WCAG 2.2 é escrito como um conjunto de critérios de sucesso, cada um pensado pra ser verificável, contraste mínimo de 4,5 pra 1, presença de texto alternativo, e isso é uma virtude do padrão, porque permite auditoria objetiva em escala. Mas verificável não é o mesmo que suficiente. Um critério isolado pode passar e a combinação dos critérios, na ordem em que a pessoa realmente encontra os elementos, ainda falhar. É o mesmo raciocínio de qualquer sistema de regras: você pode cumprir cada regra individual e ainda assim produzir um resultado que ninguém queria, porque a regra não capturou a intenção por trás dela. O relatório anual da WebAIM, que varre milhões de páginas reais, encontra ano após ano uma quantidade enorme de erros técnicos básicos ainda presentes na web mais usada, o que mostra que nem a parte fácil, a auditoria automática, está sendo feita na maioria dos produtos. Ou seja: antes de discutir se a auditoria automática é suficiente, a maior parte do mercado ainda nem está rodando ela. Faça as duas etapas, na ordem certa, e você já estará à frente da maioria.
Agora construa
Escolha um fluxo real de a sua tarefa real, de preferência um que envolva decisão do usuário, um checkout, um cadastro, uma etapa de aprovação. Faça as duas etapas, em sequência, sem pular nenhuma.
ETAPA 1 · O AGENTE VARRE
- Peça a uma IA com acesso ao seu produto (ou cole o HTML da tela) pra auditar esse fluxo contra o WCAG 2.2: contraste, texto alternativo, ordem de foco, papel ARIA.
- Liste os problemas que ela encontrou, um por um, com o critério técnico que cada um viola.
ETAPA 2 · A PESSOA CONFIRMA
- Agora navegue esse MESMO fluxo você mesmo, só de teclado, sem tocar no mouse, do início ao fim. Anote onde travou, onde o foco pulou pra um lugar que não fazia sentido, onde você não sabia mais em que campo estava.
- Se tiver como, ligue o leitor de tela nativo do seu sistema (VoiceOver no Mac, Narrador no Windows) e ouça o fluxo inteiro de olhos fechados. Anote o que soou confuso, fora de ordem, ou incompleto, mesmo que a ferramenta automática tenha aprovado aquele mesmo trecho.
Compare as duas listas. A primeira é o seu porão técnico resolvido rápido. A segunda é o que só apareceu porque uma pessoa, não uma ferramenta, viveu o fluxo de verdade. Se a segunda lista tiver qualquer item que a primeira não pegou, você acabou de confirmar, na prática, por que acessibilidade de verdade nunca é só a varredura automática.
Pratique
1. Um scanner de acessibilidade aprova o checkout com contraste, alt text, foco e ARIA todos corretos, mas um usuário de leitor de tela não consegue completar a compra. O que isso revela?
2. Qual é o papel correto do WCAG 2.2 nesta divisão de trabalho entre agente e pessoa?
3. Qual é a régua correta desta aula para dividir o trabalho de acessibilidade entre agente de IA e pessoa?
Beleza? Fecha comigo o recado desta aula. Um agente com acesso ao seu produto audita WCAG 2.2 em escala, contraste, texto alternativo, ordem de foco, papel ARIA, em minutos, cobrindo o volume que checklist manual nunca daria conta de revisar em todo lugar. Isso resolve a conformidade técnica, e resolve rápido. Mas carga cognitiva, ordem de leitura que faz sentido e clareza de rótulo são coisas que só uma pessoa navegando o fluxo de verdade consegue sentir, e nenhuma varredura automática substitui isso. A régua que fica: o agente cobre o volume, a pessoa confirma a experiência. Acessibilidade de verdade é a soma dos dois, nunca a metade sozinha se fazendo passar pelo todo. Próxima.
Para o quadro
Sobre o verde do scannercada elemento pode passar sozinho e a sequência inteira ainda confundir quem depende do leitor de tela.
Sobre a divisãoo agente cobre o volume técnico. A pessoa confirma a experiência vivida.
Sobre o que não se medecontraste vira número. Carga cognitiva e ordem que faz sentido dependem de alguém viver o fluxo.
Valeu pelo feedback. Isso ajuda a afiar a próxima aula.