Acessibilidade (WCAG 2.2)

O que Acessibilidade (WCAG 2.2) faz?

Esta skill garante que interfaces digitais sejam Perceptíveis, Operáveis, Compreensíveis e Robustas (POUR) para todos os usuários, incluindo aqueles que utilizam leitores de tela, controles por interruptor ou navegação por teclado. Ela foca na implementação técnica dos critérios de sucesso do WCAG 2.2.

Quando Usar

• Definir especificações de componentes de UI para Web, iOS ou Android.
• Auditar código existente para barreiras de acessibilidade ou lacunas de conformidade.
• Implementar novos padrões do WCAG 2.2 como Tamanho do Alvo (Mínimo) e Aparência do Foco.
• Mapear requisitos de design de alto nível para atributos técnicos (papéis ARIA, traits, hints).

Conceitos Principais

• Princípios POUR: A base do WCAG (Perceptível, Operável, Compreensível, Robusto).
• Mapeamento Semântico: Usar elementos nativos em vez de contêineres genéricos para obter acessibilidade integrada.
• Árvore de Acessibilidade: A representação da UI que as tecnologias assistivas realmente "leem".
• Gerenciamento de Foco: Controlar a ordem e a visibilidade do cursor do teclado/leitor de tela.
• Rotulagem e Dicas: Fornecer contexto por meio de aria-label, accessibilityLabel e contentDescription.

Como Funciona

Etapa 1: Identificar o Papel do Componente

Determine a finalidade funcional (ex.: Isso é um botão, um link ou uma aba?). Use o elemento nativo mais semântico disponível antes de recorrer a papéis personalizados.

Etapa 2: Definir Atributos Perceptíveis

• Garanta que o contraste do texto atenda a 4.5:1 (normal) ou 3:1 (grande/UI).
• Adicione alternativas textuais para conteúdo não textual (imagens, ícones).
• Implemente redimensionamento responsivo (até 400% de zoom sem perda de função).

Etapa 3: Implementar Controles Operáveis

• Garanta um tamanho de alvo mínimo de 24x24 pixels CSS (WCAG 2.2 SC 2.5.8).
• Verifique se todos os elementos interativos são alcançáveis via teclado e possuem um indicador de foco visível (SC 2.4.11).
• Forneça alternativas de ponteiro único para movimentos de arrastar.

Etapa 4: Garantir Lógica Compreensível

• Use padrões de navegação consistentes.
• Forneça mensagens de erro descritivas e sugestões para correção (SC 3.3.3).
• Implemente "Entrada Redundante" (SC 3.3.7) para evitar solicitar os mesmos dados duas vezes.

Etapa 5: Verificar Compatibilidade Robusta

• Use padrões corretos de Name, Role, Value.
• Implemente regiões aria-live ou ao vivo para atualizações dinâmicas de status.

Diagrama da Arquitetura de Acessibilidade

flowchart TD
  UI["Componente de UI"] --> Platform{Plataforma?}
  Platform -->|Web| ARIA["WAI-ARIA + HTML5"]
  Platform -->|iOS| SwiftUI["Traits de Acessibilidade + Rótulos"]
  Platform -->|Android| Compose["Semântica + Descrição de Conteúdo"]

  ARIA --> AT["Tecnologia Assistiva (Leitores de Tela, Interruptores)"]
  SwiftUI --> AT
  Compose --> AT

Mapeamento Entre Plataformas

Funcionalidade	Web (HTML/ARIA)	iOS (SwiftUI)	Android (Compose)
Rótulo Principal	aria-label / <label>	.accessibilityLabel()	contentDescription
Dica Secundária	aria-describedby	.accessibilityHint()	Modifier.semantics { stateDescription = ... }
Papel de Ação	role="button"	.accessibilityAddTraits(.isButton)	Modifier.semantics { role = Role.Button }
Atualizações Ao Vivo	aria-live="polite"	.accessibilityLiveRegion(.polite)	Modifier.semantics { liveRegion = LiveRegionMode.Polite }

Exemplos

Web: Busca Acessível

<form role="search">
  <label for="search-input" class="sr-only">Buscar produtos</label>
  <input type="search" id="search-input" placeholder="Buscar..." />
  <button type="submit" aria-label="Enviar Busca">
    <svg aria-hidden="true">...</svg>
  </button>
</form>

iOS: Botão de Ação Acessível

Button(action: deleteItem) {
    Image(systemName: "trash")
}
.accessibilityLabel("Excluir item")
.accessibilityHint("Remove permanentemente este item da sua lista")
.accessibilityAddTraits(.isButton)

Android: Alternância Acessível

Switch(
    checked = isEnabled,
    onCheckedChange = { onToggle() },
    modifier = Modifier.semantics {
        contentDescription = "Ativar notificações"
    }
)

Antipadrões a Evitar

• Div-Botões: Usar um <div> ou <span> para um evento de clique sem adicionar um papel e suporte por teclado.
• Significado Apenas por Cor: Indicar um erro ou status apenas com uma mudança de cor (ex.: tornar uma borda vermelha).
• Foco Modal Não Contido: Modais que não retêm o foco, permitindo que usuários de teclado naveguem pelo conteúdo de fundo enquanto o modal está aberto. O foco deve ser contido e escapável através da tecla Escape ou de um botão explícito de fechar (WCAG SC 2.1.2).
• Texto Alt Redundante: Usar "Imagem de..." ou "Foto de..." no texto alt (leitores de tela já anunciam o papel "Imagem").

Lista de Verificação de Boas Práticas

• Elementos interativos atendem ao tamanho de alvo 24x24px (Web) ou 44x44pt (Nativo).
• Indicadores de foco são claramente visíveis e de alto contraste.
• Modais retêm o foco enquanto abertos e o liberam corretamente ao fechar (tecla Escape ou botão de fechar).
• Dropdowns e menus restauram o foco para o elemento gatilho ao fechar.
• Formulários fornecem sugestões de erro baseadas em texto.
• Botões somente com ícone têm um rótulo de texto descritivo.
• O conteúdo é redimensionado corretamente quando o texto é ampliado.

Referências

• Diretrizes WCAG 2.2
• Práticas de Autoria WAI-ARIA
• Guia de Programação de Acessibilidade do iOS
• Diretrizes de Interface Humana do iOS - Acessibilidade
• Guia do Desenvolvedor de Acessibilidade do Android

Skills Relacionadas

• frontend-patterns
• design-system
• liquid-glass-design
• swiftui-patterns