Ir para o guia de uso
Accessibility Auditpor Alireza Rezvani

Accessibility Audit Skill.

Mantenha cada achado de acessibilidade conectado ao elemento afetado, à correção proposta e ao resultado da verificação.

  • Acessibilidade
  • Revisão de design
  • Front-end
Revisão do código-fonte · Accessibility AuditSKILL.md
Tarefa Acessibilidade Produz • Um relatório de achados de acessibilidade ordenado por severidade • Correções de código com antes e depois, adequadas ao framework do projeto • Uma comparação com os achados iniciais e uma lista das verificações manuais restantes Antes de começar Python para as ferramentas incluídas, acesso ao código-fonte e um navegador ou configuração de tecnologia assistiva para validação em contexto.
Resumo editorial · fonte revisada em 2026-10-07 · não é um exemplo gerado

01 Funcionalidades

Transforme achados de acessibilidade em correções verificáveis

Um fluxo de acessibilidade de varredura, correção e verificação, com utilitários em Python, referências por framework e modelos de relatório.

Fluxo baseado na fonteNão é um benchmark de execução

A abordagem de trabalho

O A11y Audit organiza o trabalho de acessibilidade em fases de varredura, correção e verificação. A fonte inclui interfaces de scanner e de verificador de contraste em Python, categorias de severidade e referências de correção específicas por framework. Ele pode ajudar a transformar um pedido vago de melhorar a acessibilidade em uma lista delimitada de elementos e alterações de código.

A fonte descreve ampla cobertura das WCAG, mas uma varredura de código não deve ser apresentada como certificação completa de conformidade. Fluxos de teclado, comportamento de leitores de tela, conteúdo dinâmico e a utilidade do texto alternativo ainda exigem revisão contextual. O valor prático é a rastreabilidade: preservar os achados iniciais, aplicar semântica nativa ou ajustes de estilo adequados, executar as verificações novamente e testar a interação real.

Entregas esperadas

  • Um relatório de achados de acessibilidade ordenado por severidade
  • Correções de código com antes e depois, adequadas ao framework do projeto
  • Uma comparação com os achados iniciais e uma lista das verificações manuais restantes
Ver o briefing de exemplo

Do briefing à revisão

  1. 01
    Varra um escopo definido

    Identifique o framework e os caminhos relevantes do código-fonte. Registre achados no nível do elemento e distinga o que o scanner detectou das observações manuais.

  2. 02
    Corrija a interação de fundo

    Prefira controles nativos, rótulos significativos e foco visível em vez de adicionar atributos ARIA indiscriminadamente.

  3. 03
    Verifique em contexto

    Compare com a linha de base, verifique o contraste no estado renderizado e exercite caminhos de teclado e de tecnologia assistiva que a análise estática não consegue confirmar.

02 Quando usar

Quando usar

Python para as ferramentas incluídas, acesso ao código-fonte e um navegador ou configuração de tecnologia assistiva para validação em contexto.

Bom encaixe

  • Planejamento de correçõesÚtil para converter um conjunto de problemas no nível do código-fonte em alterações de código priorizadas e revisáveis.
  • Verificações de regressãoServe para projetos que querem adicionar verificações de acessibilidade repetíveis a um processo de testes existente.

Limites a considerar

  • Não é um certificado de conformidadePassar pelas ferramentas incluídas não prova que todos os requisitos de acessibilidade aplicáveis são atendidos em todo o produto.
  • A severidade depende de contextoOs rótulos de severidade da fonte são um apoio à triagem. O impacto real para o usuário depende do elemento, da tarefa e das alternativas disponíveis.

Traga estas entradas

  • Escopo da auditoriaIndique as páginas, os componentes ou o diretório de código-fonte e a jornada do usuário que será revisada.
  • Estados renderizadosForneça acesso a formulários, erros, diálogos e outros estados que não existem em uma página estática simples.
  • Linha de base existenteInclua achados ou resultados de testes anteriores para separar problemas resolvidos de regressões.

03 Decisões importantes

Decisões que importam

  1. As correções permanecem rastreáveis

    Exemplos de antes e depois conectam um achado a uma implementação concreta, em vez de deixar apenas uma referência a um padrão.

  2. A automação tem um limite

    Um relatório útil informa o que foi varrido, o que foi testado manualmente e o que continua sem verificação.

04 Exemplo de briefing

Experimente um briefing focado

O briefing de exemplo abaixo não foi testado. Confira a configuração da skill antes de usá-lo.

Revise a configuração

Mantenha os scripts e os padrões de referência. Revise a cobertura do scanner antes de usar os resultados como critério de liberação.

Arquivo de origem upstream
https://github.com/alirezarezvani/claude-skills/blob/19392f7a08264ed00486a251f5b2098321771f94/engineering-team/a11y-audit/skills/a11y-audit/SKILL.md

Python para as ferramentas incluídas, acesso ao código-fonte e um navegador ou configuração de tecnologia assistiva para validação em contexto.

Comece com uma entrega

Adapte o escopo, o material de origem e as restrições deste briefing antes de executar a skill.

Briefing de exemplo
Use a11y-audit para revisar nosso formulário de checkout e o modal. Comece com um relatório de achados somente leitura, incluindo os elementos afetados e a justificativa da severidade. Verifique rótulos, controles nativos, visibilidade do foco e contraste, e depois liste as verificações manuais de teclado e leitor de tela. Não declare a página em conformidade com as WCAG apenas com base no scanner e não aplique correções até eu aprovar.

Inspecione o resultado

Compare a saída real com estes critérios observáveis.

  • Cada achado identifica um elemento real e uma correção acionável.
  • Os problemas resolvidos são verificados novamente em relação à linha de base original.
  • O comportamento de teclado, de leitor de tela e de estados dinâmicos que não foi testado permanece explicitamente como não verificado.

O OpenDesign oferece um espaço de trabalho de design local para agentes de programação. Esta listagem não significa que a skill esteja incluída no pacote nem que suas ferramentas externas, credenciais e dependências de software estejam incluídas.

05 Fonte e licença

Fonte e licença

Esta página descreve a revisão fixada da fonte vinculada abaixo. O comportamento e os requisitos do upstream podem mudar.

Responsável pela fonte
Alireza Rezvani
Licença
MIT
Versão revisada
2026-10-07 · 19392f7a0826
Resumo editorial da fonte
Um fluxo de acessibilidade de varredura, correção e verificação, com utilitários em Python, referências por framework e modelos de relatório.

Resumo original do OpenDesign, com base na fonte vinculada. As estrelas do repositório são um sinal de popularidade datado, não indicam uso da skill nem uma nota de qualidade.

06 Perguntas antes de começar

Dúvidas antes de começar

O scanner pode comprovar a conformidade com as WCAG?

Não. A skill pode apoiar uma auditoria, mas verificações automatizadas do código-fonte não cobrem todos os requisitos contextuais ou de interação.

Ela funciona só com React?

A fonte inclui padrões para vários frameworks web e para HTML puro. Verifique o suporte real do scanner e das referências para a versão usada no projeto.

Todo elemento clicável deve receber uma função ARIA?

Não automaticamente. A fonte em geral prefere controles semânticos nativos, que oferecem comportamento que uma função ARIA, por si só, não adiciona.

OpenDesign

Abra espaço para a próxima iteração de design.

Mantenha seu briefing, o material de origem e o trabalho de design juntos em um espaço de trabalho local. Confira a configuração da própria skill antes de adicioná-la ao seu fluxo de trabalho.

Arquivo de origem upstream
https://github.com/alirezarezvani/claude-skills/blob/19392f7a08264ed00486a251f5b2098321771f94/engineering-team/a11y-audit/skills/a11y-audit/SKILL.md