accessibility

Visão geral da skill de acessibilidade

O que a skill de acessibilidade faz

A skill de acessibilidade ajuda você a desenhar, implementar e auditar interfaces acessíveis de acordo com WCAG 2.2 Nível AA. Ela foi pensada para transformar a intenção do produto em escolhas semânticas concretas: elementos nativos, papéis ARIA, rótulos, dicas, comportamento de foco e atributos de acessibilidade específicos de plataforma para Web, iOS e Android.

Quem deve instalar esta skill de acessibilidade

Esta skill de acessibilidade é ideal para engenheiros de frontend, times de design system, auditores de UX e designers de produto que precisam de orientação pronta para implementação, e não de uma checklist genérica de acessibilidade. Ela é especialmente útil quando você está fazendo acessibilidade para trabalho de UX Audit e precisa sair de “este fluxo parece arriscado” para correções específicas.

Que trabalho ela ajuda você a concluir

O trabalho real aqui não é só “tornar tudo conforme”. É mapear corretamente um componente ou fluxo para a árvore de acessibilidade, para que usuários de tecnologias assistivas recebam o papel, nome, estado, ordem e modelo de interação corretos. A skill enfatiza mapeamento semântico, gerenciamento de foco, rotulagem e os princípios POUR, em vez de resumos amplos de políticas.

Por que escolher isso em vez de um prompt comum

Um prompt comum costuma gerar orientações vagas de acessibilidade. Esta skill é mais útil quando você precisa de raciocínio estruturado, como: identificar primeiro o papel do componente, preferir semântica nativa e depois definir rótulos, estados, comportamento de teclado e tratamento de foco. Isso torna o uso de acessibilidade mais acionável em revisões de implementação e auditorias.

Como usar a skill de acessibilidade

Contexto de instalação e o que ler primeiro

Instale a skill pelo seu fluxo de skills e, em seguida, abra primeiro skills/accessibility/SKILL.md. Não há scripts extras nem arquivos de referência nesta skill, então quase toda a orientação útil está nesse único documento. Leia estas seções nesta ordem:

1. When to Use
2. Core Concepts
3. How It Works
4. o passo sobre identificar o papel do componente

Esta é uma instalação leve de acessibilidade: pouca fricção de configuração, mas você deve esperar fornecer o contexto de produto que estiver faltando.

Entradas que a skill de acessibilidade precisa

A skill de acessibilidade funciona melhor quando você informa:

• plataforma: Web, iOS ou Android
• componente ou fluxo: botão, modal, formulário, abas, menu, carrossel etc.
• objetivo do usuário: o que a pessoa está tentando fazer
• implementação atual: HTML, JSX, SwiftUI/UIKit, Jetpack Compose/View XML, ou screenshots com notas de comportamento
• restrições: limites do design system, markup legado, widgets de terceiros
• alvo da auditoria: WCAG 2.2 AA, suporte a teclado, comportamento de leitor de tela, ordem de foco, tamanho de alvo ou problemas de nome/estado

Entrada fraca: “Torne isso acessível.”
Entrada forte: “Audite este modal em React para WCAG 2.2 AA. Verifique papel semântico, nome acessível, focus trap, comportamento com Escape, foco inicial, retorno de foco e anúncio no leitor de tela. Sugira JSX corrigido.”

Transforme uma meta vaga em um prompt forte

Use uma estrutura de prompt como esta para obter um uso melhor da skill de acessibilidade:

• Identifique o papel da interface e se um elemento nativo deve substituir o atual.
• Descreva a árvore de acessibilidade esperada.
• Liste as informações obrigatórias de label, role, state, value e hint.
• Defina o comportamento de teclado e foco.
• Aponte riscos de WCAG 2.2 AA.
• Retorne o código corrigido junto com um resumo curto da auditoria.

Exemplo:
“Use a skill de acessibilidade para revisar este dropdown customizado na Web. Primeiro decida se ele deve ser um select nativo, um botão com listbox ou outro padrão. Depois forneça o ARIA esperado, as interações de teclado, o movimento de foco, os requisitos de foco visível, preocupações com tamanho de alvo e o código revisado.”

Fluxo recomendado para auditorias e implementação

Em acessibilidade para UX Audit, comece pelo nível do fluxo e depois aprofunde nos componentes:

1. nomeie a tarefa e o risco de falha
2. identifique o papel real de cada elemento interativo
3. verifique primeiro alternativas semânticas nativas
4. valide labels, names, values e states
5. revise a ordem do teclado e a visibilidade do foco
6. teste mentalmente os anúncios do leitor de tela
7. solicite código ou especificações remediadas

Se você estiver implementando em vez de auditar, peça à skill critérios de aceite que possam ser entregues para engenharia e QA, e não apenas texto explicativo.

FAQ da skill de acessibilidade

Esta skill de acessibilidade é boa para iniciantes?

Sim, se você já entende o básico de construção de UI. A skill explica as ideias centrais de acessibilidade de forma clara, mas não é um curso completo de WCAG para iniciantes. Ela funciona melhor como apoio guiado de implementação do que como sua única fonte de aprendizado.

Ela é suficiente para decidir instalar a acessibilidade skill?

Na maioria dos casos, sim. A skill tem escopo claro, fluxo concreto e foco técnico prático. A principal limitação é a profundidade do material empacotado: não há exemplos complementares, scripts de teste nem arquivos de referência específicos por plataforma. Se você quer muitos assets reutilizáveis, ela parece enxuta; se você quer orientação rápida, é fácil de adotar.

Em que ela é diferente de um prompt genérico de acessibilidade?

A diferença está no enquadramento. Este guia de acessibilidade enfatiza identificação de papel, mapeamento semântico, raciocínio sobre a árvore de acessibilidade, labels e gerenciamento de foco. Prompts genéricos muitas vezes pulam direto para atributos ARIA, o que pode levar a excesso de engenharia ou padrões errados.

Quando não devo usar esta skill?

Não confie nesta skill de acessibilidade sozinha para validação jurídica, testes complexos de compatibilidade com tecnologias assistivas ou casos extremos muito específicos de plataforma nativa. Ela é mais forte para raciocínio de design e código, não como substituta de testes manuais com dispositivos reais, leitores de tela e fluxos apenas com teclado.

Como melhorar a skill de acessibilidade

Dê contexto mais rico da interface, não só trechos de código

A maior alavanca de qualidade é o contexto. Inclua a tarefa do usuário, se o controle altera estado ou navega, o que aparece visualmente e o que está quebrando hoje. As recomendações de acessibilidade dependem do comportamento, não apenas do markup. Um div pode representar vários padrões; a skill funciona melhor quando você define a interação pretendida.

Peça a seleção de padrão antes de pedir ARIA

Um modo comum de falha é forçar ARIA no componente errado. Melhore a saída da skill de acessibilidade perguntando: “Que padrão isso realmente segue?” Por exemplo, peça uma decisão entre botão nativo, link, disclosure, tab, dialog ou listbox antes da correção. Isso muitas vezes evita widgets customizados desnecessários.

Peça a saída em seções prontas para implementação

Para um uso mais forte da skill de acessibilidade, peça uma resposta estruturada:

• problema encontrado
• impacto para o usuário
• preocupação de WCAG 2.2
• padrão semântico recomendado
• alteração exata no código
• passos de teste

Esse formato é melhor para repasse a engenharia, QA ou owners de design system do que uma resposta em ensaio único.

Itere com evidências reais da falha

Depois da primeira análise, melhore a saída da skill de acessibilidade trazendo detalhes concretos de volta: texto anunciado pelo leitor de tela, traps de teclado, foco visível ausente ou medidas de target touch. A skill fica muito mais valiosa quando você a usa como um ciclo de iteração para achados de UX Audit, e não como uma checagem de conformidade de uma única rodada.