---
id: accessibility-wcag-checklist
agent: ux-design-expert
title: Auditoria de acessibilidade WCAG (AA/AAA)
inputs: [componente-ou-tela, nivel-wcag]
outputs: [veredito PASS/FAIL, lista de violações, relatório de a11y]
elicit: false
modes: [interactive, yolo]
---

# Auditoria de acessibilidade WCAG (AA/AAA)

**Objetivo:** auditar um componente ou tela contra os critérios WCAG e emitir um veredito objetivo —
WCAG AA é o piso inegociável; AAA quando a story exigir. Reprovado bloqueia a entrega.

**Pré-condições:**
- O alvo (componente ou tela) está renderizável/inspecionável. Se não roda, **pare** — não audito o
  que não consigo observar.
- O nível-alvo está definido (AA por padrão; AAA só se a story/spec pedir). Sem definição, assumo AA.

## Passos — checklist (verifico item a item)

1. **Contraste de cor**
   - [ ] Texto normal ≥ 4.5:1 (AA) / ≥ 7:1 (AAA)
   - [ ] Texto grande (≥ 18.66px bold ou 24px) ≥ 3:1 (AA) / ≥ 4.5:1 (AAA)
   - [ ] Componentes de UI e estados (borda, foco, ícone informativo) ≥ 3:1
2. **Navegação por teclado**
   - [ ] Todo elemento interativo é alcançável por `Tab` na ordem lógica
   - [ ] Nada vira "armadilha de teclado" (dá pra entrar e sair)
   - [ ] Ações de mouse têm equivalente por teclado (`Enter`/`Space`/setas)
3. **Foco visível**
   - [ ] Indicador de foco visível e com contraste suficiente em cada elemento focável
   - [ ] Ordem de foco segue a ordem visual/lógica
4. **Semântica e estrutura**
   - [ ] HTML semântico ou `role` correto (botão é botão, não `div` clicável)
   - [ ] Hierarquia de headings coerente; landmarks onde fizer sentido
   - [ ] Estados expostos via ARIA quando necessário (`aria-expanded`, `aria-checked`, `aria-invalid`)
5. **Texto alternativo e rótulos**
   - [ ] Imagens informativas têm `alt` descritivo; decorativas têm `alt=""`
   - [ ] Todo campo de formulário tem `label` associado
   - [ ] Ícone-só-clicável tem `aria-label`
6. **Conteúdo e movimento**
   - [ ] Informação não depende só de cor (estado/erro tem texto ou ícone também)
   - [ ] Animação/auto-play respeita `prefers-reduced-motion`
   - [ ] Mensagens de erro são programaticamente associadas e anunciadas
7. **Emito o veredito** consolidando os itens:
   - **PASS** — todos os itens do nível-alvo verdes.
   - **FAIL** — qualquer item do nível-alvo reprovado, com a lista exata de violações e onde corrigir.
8. **Registro o relatório de a11y** (itens, veredito, violações) e o anexo à story. Se FAIL, **bloqueio
   a entrega** e devolvo a correção ao dono do componente (a mim no `*build`/`*extend`, ou ao @dev se
   for integração na app).

## Critério de pronto (DoD)

- [ ] Todos os 6 grupos do checklist avaliados item a item
- [ ] Veredito explícito: PASS ou FAIL
- [ ] Se FAIL, lista de violações com localização e correção sugerida
- [ ] Relatório de a11y anexado à story
- [ ] Entrega bloqueada enquanto houver violação de nível AA aberta

## Falha / recuperação

- **Item reprova no nível AA** → veredito FAIL automático; a11y AA é piso, não negocio. Bloqueio a
  entrega e devolvo para correção.
- **Não consigo medir um critério** (ex.: contraste de estado dinâmico) → registro como "não
  verificável", trato como risco aberto e não declaro PASS no escuro.
- **Violação exige mudança de arquitetura/stack** (ex.: trocar lib inacessível) → reporto e escalo para
  @architect; não decido stack sozinha.
- **Correção está fora do design system (integração na app)** → delego ao @dev; eu audito, ele integra.