Agentes de Acessibilidade: Lições de uma Jornada

Introdução: Desvendando o Potencial dos Agentes de Acessibilidade

Na AITY, observamos a crescente popularidade e o impacto transformador dos agentes no desenvolvimento de software. A capacidade de criar e editar código de forma assistida por agentes tem se mostrado fundamental em diversas iniciativas. Inspirados por essa tendência, exploramos os aprendizados de um agente experimental de acessibilidade de propósito geral, focado em nosso compromisso com a inclusão.

Este agente experimental tem dois objetivos principais:

Fornecer aos engenheiros respostas confiáveis e just-in-time para questões de acessibilidade diretamente na CLI do GitHub Copilot e na integração do Copilot VS Code.
Identificar e corrigir automaticamente problemas de acessibilidade simples e objetivos antes que cheguem à produção, especialmente em modificações no código front-end.

Até o momento, o agente revisou 3.535 pull requests, alcançando uma taxa de resolução de 68%. Os cinco tipos de problemas mais frequentes, em ordem de ocorrência, foram:

Deixar a estrutura e os relacionamentos claros para tecnologias assistivas.
Fornecer nomes claros e concisos para controles interativos.
Garantir que os usuários estejam cientes de anúncios importantes.
Garantir alternativas de texto para conteúdo não textual.
Mover o foco do teclado através de páginas e visualizações em uma ordem lógica.

Cada um desses pontos representa uma fricção ou barreira que foi automaticamente removida, o que, de outra forma, teria inibido o uso da plataforma por pessoas que dependem de tecnologia assistiva.

A Mentalidade por Trás do Agente

O modelo social da deficiência nos ensina que barreiras de acesso podem ser criadas pela forma como um ambiente é construído, o que se aplica diretamente às experiências digitais. Com o agente de acessibilidade, nosso objetivo não é "resolver" a acessibilidade isoladamente, mas sim aumentar os esforços de nossos pares, ajudando-os a remover as barreiras que podem surgir na construção de interfaces de usuário.

É crucial entender que o agente de acessibilidade não é uma "bala de prata" capaz de resolver todos os cenários hipotéticos. Compreender e comunicar o escopo de responsabilidade do agente foi fundamental para agilizar o lançamento do experimento e gerar adesão à iniciativa.

Fundamentando o Sucesso: Aproveitando Esforços Passados

Com o European Accessibility Act já em vigor e o Título II do Americans with Disabilities Act estabelecendo o WCAG 2.1 AA como definição legal de "pronto" em abril de 2027, as organizações que não investiram em identificar e remediar manualmente problemas de acessibilidade estarão em desvantagem. Agentes LLM podem ler e agir na árvore de acessibilidade, tornando essa lacuna ainda mais evidente.

A AITY reconhece a importância de um sistema maduro para registrar problemas de acessibilidade e verificar suas correções. Isso inclui:

Um template estruturado para relatar problemas.
Passos para reproduzir o problema.
Uma rica camada de metadados sobre o nível de severidade, área de serviço e critério de sucesso WCAG aplicável.
Links cruzados para o Pull Request que abordou o problema.
Critérios de aceitação.

Todos esses problemas são centralizados em um único repositório. Embora esse esforço de registro de problemas tenha precedido a popularidade das ferramentas LLM, sua natureza altamente consistente e estruturada o tornou um corpus de conteúdo ideal para o agente de acessibilidade referenciar. Instruímos o agente a investigar esses problemas para extrapolar trechos de código e linguagem relacionados, onde o comportamento não-determinístico de "fuzzy matching" dos LLMs se torna um ativo valioso.

Otimizando o Conteúdo do Agente: O "Ouro Antigo"

Assim como em qualquer domínio especializado, instruções vagas em um arquivo de habilidade não são eficazes. Dizer a um LLM para "usar as melhores práticas de acessibilidade" com uma pequena lista de exemplos não funciona bem. LLMs, ao gerar código, têm uma tendência a produzir antipadrões de acessibilidade, pois são treinados em décadas de código inacessível.

Para neutralizar isso, o agente precisa de um conteúdo melhor para se basear. Recomendamos investir na catalogação e remediação manual de problemas de acessibilidade. Após algum progresso, esses dados podem ser incorporados ao agente. Os problemas e seus respectivos pull requests fornecem exemplos altamente contextuais para o LLM, escritos usando as convenções da organização em que está implantado. Esta coleção de problemas e código é um dos ativos mais fortes que o agente utiliza.

Consumo Eficiente de Tokens: Uma Abordagem Estruturada

A acessibilidade é uma preocupação holística, que intersecta com código, design, copywriting e várias outras disciplinas envolvidas na criação de interfaces de usuário. Grande parte do trabalho de acessibilidade é altamente contextual, o que significa que geralmente é preciso ter uma imagem completa do problema antes de poder dar o conselho apropriado.

Devido a esses dois fatores, um agente de acessibilidade de propósito geral pode consumir uma grande quantidade de tokens ao executar seu trabalho, resultando em:

Um aumento na quantidade de saída não confiável.
Tempos de resposta mais lentos.
Custos operacionais aumentados.

É crucial ser diligente ao estruturar o agente. Veja como abordamos isso.

Usando Sub-agentes para Especialização

O agente de acessibilidade começou como um agente monolítico, mas rapidamente superou as limitações dessa abordagem. Por isso, evoluímos para uma arquitetura de sub-agentes. Em vez de uma grande suite de sub-agentes executados em paralelo, o que se mostrou ineficaz, optamos por dois sub-agentes dedicados:

O primeiro sub-agente atua como revisor e pesquisador passivo.
O segundo sub-agente atua como implementador ativo.

Os dois sub-agentes são isolados e não podem passar conteúdo diretamente um para o outro. Em vez disso, geram uma saída estruturada e baseada em templates. Essa saída é então servida ao agente orquestrador de acessibilidade pai para consumo, validação e roteamento.

Essa abordagem oferece várias vantagens:

Pontos de Verificação de Escalada: O revisor verifica áreas onde a intervenção humana provavelmente será necessária, como múltiplas falhas WCAG de alta severidade e padrões conhecidos por serem difíceis de tornar acessíveis.
Comportamento Baseado em Complexidade: O agente é instruído a operar em um modo especializado de apenas orientação se o código subjacente for considerado muito complicado. Aqui, o agente pai atua como árbitro, enquanto o agente revisor é "sem opinião", apenas relatando as descobertas conforme instruído.
Filtragem: O revisor apresenta tudo o que encontra. O agente pai então utiliza recursos e habilidades para determinar o que é relevante para a solicitação. Passar todas as descobertas do revisor para o implementador seria custoso e potencialmente o levaria a tarefas irrelevantes e contraproducentes.
Rastreabilidade: A comunicação direta entre sub-agentes removeria a capacidade de criar e revisar um registro de auditoria das decisões do usuário e do agente, crucial devido às instruções do agente em torno de padrões complexos e à natureza altamente contextual do trabalho de acessibilidade.

Executando Instruções em Ordem Linear

A eficácia do trabalho de acessibilidade digital exige uma abordagem metódica e detalhista. A preocupação em usar sub-agentes para aumentar a velocidade da resposta do LLM é contrabalançada pela necessidade de que seus resultados sejam precisos. Descobrimos que obrigar o agente a executar suas instruções de sub-agentes em uma ordem fixa era fundamental. Primeiro, estabelecemos um conjunto pai de fases ordenadas. Cada fase contém etapas filhas ordenadas de instruções, acompanhadas de recursos e habilidades relevantes. Essa ordem linear espelha a forma como abordamos pessoalmente as tarefas de auditoria, remediação e relatório.

Utilizando um Esquema de Template para Troca de Conteúdo entre Sub-agentes

Toda a operação dos sub-agentes sandboxed é construída em torno de arquivos de esquema de template. Esses arquivos criam uma consistência vital para manter o agente focado e no caminho certo. Os dois templates de esquema são:

Esquema de template do revisor: Foca no que auditar e como encontrar informações aplicáveis.
Esquema de template do implementador: Foca no que corrigir e como corrigir.

Sem os arquivos de esquema, os agentes tentariam se comunicar arbitrariamente, o que geraria maior gasto de tokens, alucinações indesejáveis, alterações de código desnecessárias e um comportamento difícil ou impossível de auditar.

Reconhecendo Limitações e Mitigando Riscos

Outro aspecto vital na criação do agente de acessibilidade é compreender as áreas onde os agentes podem falhar. Como o agente não é uma "solução" pronta para acessibilidade, queremos evitar situações em que a saída do agente, mesmo que errônea, não seja suficientemente questionada pelo usuário. Isso é especialmente relevante quando alguém não é proficiente em considerações e práticas de acessibilidade digital.

Veja o que fizemos para acomodar as limitações do agente:

Avaliar a Complexidade do Código

Para evitar o retrabalho custoso de revisitar uma solução inacessível que o agente "pensa" ser acessível, o agente de acessibilidade utiliza um pequeno script de shell para analisar o código em que vai trabalhar. O script é simples, usando um pequeno conjunto de heurísticas básicas para avaliar a complexidade relativa e destilá-la em uma pontuação.

Se essa pontuação exceder um limite definido, o agente é instruído a não executar alterações no código. Em vez disso, informará a pessoa que usa o LLM que deve entrar em contato com a equipe de acessibilidade para consulta.

Identificar Padrões de Alto Risco

É sutil, mas é totalmente possível ter um código que passa nas verificações de acessibilidade automatizadas, mas é funcionalmente inutilizável. Como complemento à complexidade do código, o agente de acessibilidade é instruído a evitar a tentativa de geração de código para padrões que a equipe de acessibilidade identificou como de alto risco. Isso inclui, mas não se limita a: drag and drop, toasts, editores de rich text, tree views e data grids.

Esses padrões exigem muita atenção e detalhe focados e atualmente estão fora das capacidades atuais de um LLM para produzir de uma forma que realmente funcione com a tecnologia assistiva. Não proibir padrões de alto risco e ambientes de código de alta complexidade levaria a demandas desnecessárias do tempo de todos para reavaliar, e também representa risco reputacional para a equipe de acessibilidade. Evitamos isso desativando a capacidade do LLM de seguir por esse caminho.

Reduzir o Viés para a Ação

Embora eu não goste de antropomorfizar LLMs, uma qualidade que todos parecem compartilhar é o desejo desesperado de produzir conteúdo. Para o Copilot, isso muitas vezes significa gerar código. Tivemos que criar instruções anti-jogo para evitar que o LLM criasse maneiras sorrateiras de contornar suas instruções de não gerar código quando a expertise humana é necessária. Isso o impediu de violar suas próprias instruções de intervenção.

Saber que Problemas Determináveis Programaticamente Não Cobrem Tudo

As métricas de sucesso do agente vivem em um contexto maior. Dos 55 Critérios de Sucesso WCAG nível A e AA, apenas 35 podem ser detectados por verificadores de código automatizados determinísticos. Isso significa que cerca de 36% dos Critérios de Sucesso nível A e AA não podem ser descobertos automaticamente.

A operação de agentes baseados em LLM está avançando nessa lacuna de ~36%, mas não é uma ciência perfeita. Por isso, torna-se importante identificar manualmente as barreiras de acessibilidade mais cedo durante os esforços de design e prototipagem – a área onde a maioria dos problemas de acessibilidade se origina. Esse pensamento também se reflete na lógica de escalada do agente, onde os membros da equipe de Acessibilidade podem trabalhar com designers para ajudar a considerar abordagens alternativas e brainstorm de soluções que alcancem os objetivos de negócios sem comprometer a acessibilidade. Essa intervenção e assistência são feitas para evitar potenciais problemas a jusante – e redesenhos caros e demorados – antes que tenham a chance de começar.

Avaliar Manualmente a Saída do Agente e Ajustar o que Não Funciona como Esperado

Realizamos periodicamente uma revisão manual da saída do agente para determinar sua precisão e eficácia. Além disso, temos ferramentas em vigor para capturar o sentimento do revisor do pull request. Ambos servem como fortes sinais para áreas onde o agente precisa de melhores instruções, bem como novos recursos e habilidades.

Lições Práticas e Caminhos Futuros

Nesta jornada de construção de um agente de acessibilidade, aprendemos que o agente:

É usado para auxiliar e aumentar os esforços de acessibilidade existentes, não para substituí-los.
É significativamente mais eficaz quando treinado em problemas de acessibilidade auditados e remediados manualmente para sua experiência específica.
É muito mais eficiente no consumo de tokens ao utilizar sub-agentes.
É mais preciso e eficaz ao executar instruções de forma metódica e linear.
É mais consistente quando configurado para usar templates pré-formatados para passar informações.
É configurado para entender suas limitações e direcionar as pessoas para sistemas de suporte alternativos.
É aprimorado quando sua saída é revisada periodicamente para identificar áreas que precisam de melhores instruções.

Esta jornada ainda não está completa. O agente de acessibilidade continua sendo aprimorado com a esperança de ajudar a garantir que a AITY construa plataformas acessíveis e inclusivas para todos os desenvolvedores. Ao compartilhar nossos aprendizados, esperamos que outras equipes possam ter um recurso para suas próprias iniciativas de acessibilidade, contribuindo para a remoção de barreiras e a promoção de uma experiência digital verdadeiramente inclusiva em escala.