Desenvolvedor cego ensina agente de IA a não inventar erros de acessibilidade no código

Imagine: um agente de IA verifica um formulário e informa com confiança que um campo não tem aria-describedby. Você abre o código e descobre que o componente de formulário da biblioteca há muito tempo cria a associação com a dica. Falsos positivos como esse destroem a confiança em uma auditoria mais rapidamente do que bugs não detectados. Um programador cego que usa leitor de tela enfrentou esse problema ao desenvolver o Accessibility Auditor Skill, um conjunto de instruções para um agente que verifica a acessibilidade no código-fonte e em sites em funcionamento.

Olhar para a implementação, não para o ponto de chamada

A principal mudança na habilidade é que, antes de classificar algo como um problema, o agente segue o caminho do ponto de uso até a implementação. Ele identifica qual elemento recebe o foco, de onde vem seu nome acessível, onde são criados o rótulo, a dica e a mensagem de erro, como os identificadores são transmitidos e o que a versão instalada da biblioteca realmente faz. Também verifica se o arquivo encontrado participa de fato do fluxo relevante: repositórios frequentemente contêm componentes antigos com nomes parecidos, e alterar um arquivo desses não muda nada para o usuário.

Se a associação realmente estiver ausente em um componente compartilhado, é ali que ela deve ser corrigida, com a verificação de todos os campos afetados. Se ela já existir, não é necessário duplicá-la.

Lições de pull requests específicos

Em um pull request para o RTL, o agente analisou mensagens de autenticação e carregamento. As funções status e alert já determinam o modo de anúncio, portanto um assertive adicional ou role="alert" pode interromper a fala do leitor de tela. Para um indicador de carregamento ao lado de um texto, a regra é a seguinte: se a mensagem já estiver presente como texto, o indicador decorativo não deve receber o mesmo nome acessível, mas ser ocultado com aria-hidden. Esse pull request foi fechado sem merge, portanto o trecho mostra apenas a alteração proposta; o anúncio real precisa ser verificado no aplicativo em funcionamento.

No Vets-Who-Code, a propriedade feedbackId foi adicionada de maneira ampla demais a uma interface compartilhada e ficou disponível para componentes que não a processavam. Daí surgiu outra regra: ao adicionar uma propriedade, é preciso descobrir quem oferece suporte a ela e se ela acabará como um atributo HTML desnecessário. Os identificadores são verificados em duas variantes: gerados internamente e fornecidos externamente. Caso contrário, o exemplo padrão funciona, mas um formulário com seu próprio ID perde a associação com o erro.

No suitenumerique/docs, a correção dependia de um elemento interno do Cunningham Select. A biblioteca pode alterar a marcação e quebrar o seletor. Agora, a habilidade dá preferência à API pública e, quando é necessário recorrer a detalhes internos, exige um teste de regressão para os valores finais de aria-hidden e tabindex. Naquela iteração, essas verificações foram adicionadas a um teste do Playwright, mas a execução completa de ponta a ponta não foi realizada.

Um resultado aceito e limitações reconhecidas

O único pull request aceito citado é o Nextcloud iOS #4111, aceito em 28 de maio de 2026. As linhas de pastas na janela de seleção do local de salvamento não tinham um nome acessível: o VoiceOver focava o elemento, mas não anunciava o nome da pasta. O agente compôs o nome a partir do título e das informações já exibidas na célula, descartou valores vazios e atribuiu à linha a característica de botão. Somente o código-fonte foi verificado: não houve build para iOS nem teste com o VoiceOver porque o ambiente não tinha o Xcode.

O autor afirma explicitamente que não dispõe de uma medição da taxa de falsos positivos antes e depois das alterações. O que existe são as regras e os casos que levaram à sua criação. Por isso, no relatório, o agente deve informar exatamente o que fez: analisou o código, executou testes ou ouviu o leitor de tela. Esses são níveis diferentes de confiança.

Principais conclusões

Se você desenvolve agentes para revisão de código, não os limite a um único arquivo. Faça o agente acompanhar a cadeia desde o ponto de chamada até a biblioteca e verificar os consumidores de componentes compartilhados. Registre diretamente nas instruções as lições extraídas de pull requests reais, para não precisar explicá-las novamente em cada projeto. E exija que o agente indique com honestidade o tipo de verificação: ler o código não substitui um teste com leitor de tela em um dispositivo.