WCAG Audit Patterns

ANÁLISE EDITORIAL

WCAG Audit Patterns é uma Skill para organizar auditorias de acessibilidade em páginas e aplicações web. Ela combina uma lista de verificação baseada na WCAG 2.2, exemplos de HTML, CSS e JavaScript, orientações para testes automatizados e pontos que exigem avaliação manual.

O material faz parte do plugin accessibility-compliance do repositório wshobson/agents. A proposta não é apertar um botão e declarar que um site está acessível. A própria orientação preserva a distinção entre sinais encontrados por ferramentas, verificação humana e correção no contexto real da interface.

O download local desta página é documental. Ele contém SKILL.md, references/details.md, LICENSE e ORIGEM.md. Não inclui navegador, axe-core, pa11y, Lighthouse, dependências, scripts executáveis, dados de usuários, tokens ou credenciais.

Imagem editorial exclusiva do Bastidores da IA. Não é captura de tela, interface real nem prova de auditoria executada.

O que esta Skill faz de verdade

A Skill organiza a revisão pelos quatro princípios da WCAG: perceptível, operável, compreensível e robusto. Em vez de reduzir acessibilidade a texto alternativo e contraste, ela cobre estrutura de títulos, tabelas, formulários, ordem de leitura, uso de cor, redimensionamento, reflow, teclado, foco, tempo de sessão, movimento, idioma, mensagens de erro, nomes acessíveis e atualização de estados.

O arquivo principal funciona como uma porta de entrada. A referência details.md contém a lista detalhada e exemplos de correção. Por isso, os dois arquivos foram preservados no pacote local. Publicar somente o SKILL.md deixaria a instrução incompleta justamente na parte prática.

A recomendação WCAG 2.2 do W3C define critérios testáveis e três níveis de conformidade, A, AA e AAA. A Skill transforma parte desse vocabulário em uma sequência operacional. Ela não substitui a norma, os documentos de entendimento nem uma avaliação feita por profissionais qualificados.

Para quem serve

Serve para desenvolvedores front-end, profissionais de qualidade, designers, responsáveis por conteúdo e equipes que precisam revisar uma interface antes de uma entrega. Também pode ajudar quem está montando um checklist de pull request ou preparando uma conversa mais objetiva com especialistas em acessibilidade.

O material é mais útil quando existe uma página, fluxo ou componente definido. “Auditar o site inteiro” é amplo demais para uma primeira execução. Um escopo melhor seria o formulário de cadastro, o checkout, a navegação principal ou uma sequência completa de recuperação de senha.

Não é uma ferramenta de certificação, uma consultoria jurídica nem um laudo. A menção a ADA, Section 508 e VPAT no arquivo original descreve cenários de uso do autor, mas as obrigações aplicáveis dependem do país, do setor, do contrato, da tecnologia e do escopo. Não use a Skill para emitir uma declaração de conformidade sem evidência adequada.

Compatibilidade e pré-requisitos

O conteúdo é Markdown e pode ser lido por agentes compatíveis com Agent Skills. O repositório publica adaptações para Codex, Claude Code, Cursor, OpenCode, Gemini CLI e GitHub Copilot. A compatibilidade do material não garante que todos os comandos auxiliares existam no seu ambiente.

Para a parte manual, você precisa de acesso à interface em um navegador, teclado, larguras de tela representativas e conhecimento do fluxo esperado. Para testes com tecnologia assistiva, planeje também o leitor de tela e o sistema operacional relevantes para seu público. Uma única combinação não representa todos os usuários.

Para automação, a referência mostra exemplos com axe-core, Playwright, pa11y e Lighthouse. Essas ferramentas são externas ao ZIP. Instale somente o que seu projeto realmente utiliza, fixe versões, revise licenças e execute em um ambiente autorizado. Nenhum desses componentes foi executado durante esta curadoria.

Instalação recomendada

O README do repositório no commit auditado documenta o marketplace para vários agentes. No Codex, a entrada publicada pelo mantenedor começa com npx codex-marketplace add wshobson/agents. Depois, selecione apenas o plugin accessibility-compliance e confira os arquivos que serão instalados.

Se seu agente aceita Skills por pasta, outra opção é copiar a pasta wcag-audit-patterns para o diretório de Skills do projeto ou do usuário. Preserve a estrutura com SKILL.md e references/details.md. O local exato varia entre ferramentas, então use a documentação do agente em vez de inventar um caminho universal.

O botão de download local oferece uma cópia auditável do texto, não um instalador automático. Compare o checksum, abra os quatro arquivos e decida conscientemente se o conteúdo atende ao seu fluxo. O botão do repositório oficial leva separadamente à fonte completa.

Configuração antes do primeiro uso

Defina o alvo, a versão da interface e o nível de conformidade que será avaliado. Registre também navegador, largura, estado de autenticação, dados de teste e tecnologia assistiva. Sem esse contexto, dois revisores podem avaliar telas diferentes e chegar a resultados incompatíveis.

Separe três tipos de evidência: falhas automáticas, itens incompletos que exigem decisão humana e observações manuais. O W3C explica que ferramentas não verificam automaticamente todos os aspectos e que julgamento humano continua necessário. Portanto, uma execução sem violações não encerra a auditoria.

Escolha um formato para cada achado: critério WCAG relacionado, página ou componente, estado reproduzível, elemento afetado, impacto percebido, evidência e sugestão de correção. Evite usar apenas uma pontuação. Ela é difícil de comparar quando o escopo, o conteúdo ou a configuração mudam.

Primeiro uso seguro

1. Escolha um fluxo pequeno e importante, como cadastro ou busca.
2. Registre a URL, a versão, o navegador e os dados de teste.
3. Navegue somente com teclado e observe ordem de foco, foco visível e armadilhas.
4. Confira títulos, landmarks, rótulos, mensagens de erro e nomes acessíveis.
5. Teste aumento de texto, reflow e largura reduzida sem perder conteúdo ou ação.
6. Execute a ferramenta automática aprovada pelo projeto e guarde o resultado bruto.
7. Revise itens marcados como incompletos e confirme cada achado no contexto da tela.
8. Corrija um grupo, repita o fluxo e registre o que ainda depende de avaliação humana.

Se houver dados pessoais, ambiente de produção ou autenticação, reduza o escopo e use contas de teste. Relatórios podem conter URLs internas, seletores, textos de erro e trechos de conteúdo. Trate essa saída como informação técnica que pode ser sensível.

Resultado esperado

O resultado útil é uma lista reproduzível de achados, não um selo. Cada item deve permitir que outra pessoa abra o mesmo estado, encontre o elemento, entenda o problema e confirme a correção. Quando a verificação automática não consegue decidir, o relatório deve manter essa incerteza.

A integração sugerida com axe-core separa violações, verificações aprovadas e resultados incompletos. O repositório oficial do axe-core reforça que os itens incompletos precisam de revisão manual. Isso é importante em conteúdo dinâmico, componentes que aparecem após interação, iframes e estados de erro.

Uma rodada pode terminar com correções em HTML semântico, ordem do DOM, estilos de foco, contraste, rótulos, mensagens ou controle de movimento. Nem todo achado deve resultar em ARIA. A Skill recomenda usar HTML nativo primeiro e recorrer a ARIA quando a semântica necessária não existe no elemento escolhido.

Permissões e riscos

A leitura documental não exige permissão especial. A execução real pode abrir páginas autenticadas, ler conteúdo visível, carregar scripts de teste, produzir logs e acionar fluxos se a automação clicar ou preencher controles. Limite o agente ao ambiente e às páginas autorizadas.

Não rode uma auditoria agressiva em produção sem combinar o escopo. Formulários podem criar contas, enviar mensagens, disparar cobranças ou alterar dados. Testes de teclado também podem ativar botões. Use dados fictícios, bloqueie ações destrutivas e confirme antes de transmitir qualquer informação.

Há ainda o risco de confiança excessiva. O guia de avaliação do W3C afirma que nenhuma ferramenta isolada determina se um site atende aos padrões. Testes com pessoas com deficiência e avaliação competente continuam sendo evidências essenciais.

Erros comuns

• Declarar conformidade após um scan: a automação cobre apenas parte da avaliação.
• Testar só a página inicial: fluxos completos e estados alternativos também importam.
• Ignorar conteúdo oculto que aparece depois: abra menus, modais, validações e mensagens.
• Corrigir tudo com ARIA: prefira elementos HTML com comportamento nativo.
• Remover o contorno de foco: personalize sem apagar a indicação visível.
• Usar cor como único sinal: mantenha texto, ícone ou outra indicação compreensível.
• Guardar apenas a nota final: preserve escopo, evidência, ferramenta e versão.
• Publicar relatório sensível: revise URLs, conteúdo, seletores e dados antes de compartilhar.

Versão auditada, licença e download local

A curadoria foi realizada em 15 de agosto de 2026 sobre o commit c4b82b0ad771190355eb8e204b1329732a18449a do repositório wshobson/agents. O GitHub mostrava 38.833 estrelas no momento da consulta.

O repositório usa licença MIT, que permite redistribuição com preservação do aviso de copyright e da licença. O ZIP local tem quatro arquivos, 14.913 bytes e SHA-256 2dde182b80bec3aba1e1b2f3394c4d045b810b5aa96ef0df4d1fed138893928b.

Foram excluídos agentes, comandos, adaptadores, ferramentas, dependências, executáveis, dados de auditoria, cookies, tokens e credenciais. A análise foi somente estática. O pacote não foi usado para testar nenhum site.

Limite final

WCAG Audit Patterns é útil como roteiro para não esquecer áreas importantes e para transformar uma revisão difusa em evidência rastreável. Ela ajuda a combinar inspeção de estrutura, navegação por teclado, comportamento visual, mensagens e automação.

O limite é igualmente importante: o material não garante acessibilidade, não emite VPAT, não interpreta obrigações legais e não substitui pessoas com experiência real de uso. Use a Skill como apoio a um processo contínuo, com correção, repetição, avaliação humana e participação de usuários.

Fontes primárias

• WCAG Audit Patterns no commit auditado.
• SKILL.md oficial.
• Padrões detalhados e exemplos.
• WCAG 2.2, recomendação do W3C.
• Visão geral de avaliação de acessibilidade do W3C.
• Limites e seleção de ferramentas de avaliação.
• Documentação oficial do axe-core.