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 Robusto (POUR) para todos os usuários, incluindo aqueles que usam leitores de tela, controles por alternância ou navegação por teclado. Ela foca na implementação técnica dos critérios de sucesso da WCAG 2.2.

Quando Usar

• Definir especificações de componentes de interface para Web, iOS ou Android.
• Auditar código existente para barreiras de acessibilidade ou lacunas de conformidade.
• Implementar novos padrões da 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, dicas).

Conceitos Centrais

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

Como Funciona

Passo 1: Identificar o Papel do Componente

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

Passo 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 reflow responsivo (até 400% de zoom sem perda de funcionalidade).

Passo 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 acessíveis pelo teclado e possuem um indicador de foco visível (SC 2.4.11).
• Forneça alternativas de ponteiro único para movimentos de arrastar.

Passo 4: Garantir Lógica Compreensível

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

Passo 5: Verificar Compatibilidade Robusta

• Use padrões corretos de Nome, Papel, Valor.
• Implemente regiões aria-live ou regiões ativas para atualizações dinâmicas de status.

Diagrama de Arquitetura de Acessibilidade

flowchart TD
  UI["Componente de Interface"] --> Platform{Plataforma?}
  Platform -->|Web| ARIA["WAI-ARIA + HTML5"]
  Platform -->|iOS| SwiftUI["Traits + Rótulos de Acessibilidade"]
  Platform -->|Android| Compose["Semântica + ContentDesc"]

  ARIA --> AT["Tecnologia Assistiva (Leitores de Tela, Switches)"]
  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 em Tempo Real	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">Pesquisar produtos</label>
  <input type="search" id="search-input" placeholder="Pesquisar..." />
  <button type="submit" aria-label="Enviar Pesquisa">
    <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-Buttons: Usar um <div> ou <span> para um evento de clique sem adicionar um papel e suporte a teclado.
• Significado Apenas por Cor: Indicar um erro ou status apenas com uma mudança de cor (por exemplo, tornar uma borda vermelha).
• Foco Modal Não Contido: Modais que não prendem o foco, permitindo que usuários de teclado naveguem pelo conteúdo de fundo enquanto o modal está aberto. O foco deve estar contido e ser escapável através da tecla Escape ou de um botão explícito de fechar (WCAG SC 2.1.2).
• Texto Alternativo Redundante: Usar "Imagem de..." ou "Foto de..." no texto alternativo (os leitores de tela já anunciam o papel "Imagem").

Lista de Verificação de Boas Práticas

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

Referências

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

Skills Relacionadas

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