Acessibilidade (WCAG 2.2)

O que Acessibilidade (WCAG 2.2) faz?

Esta habilidade 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 de switch ou navegação por teclado. Ela foca na implementação técnica dos critérios de sucesso WCAG 2.2.

Quando Usar

• Definir especificações de componentes de UI para Web, iOS ou Android.
• Auditar código existente em busca de barreiras de acessibilidade ou lacunas de conformidade.
• Implementar novos padrões 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 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 fornecer acessibilidade embutida.
• Á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.
• Rótulos e Dicas: Fornecer contexto através de aria-label, accessibilityLabel e contentDescription.

Como Funciona

Etapa 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.

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 reflow responsivo (até 400% de zoom sem perda de função).

Etapa 3: Implementar Controles Operáveis

• Garanta um tamanho mínimo de alvo de 24x24 pixels CSS (WCAG 2.2 SC 2.5.8).
• Verifique se todos os elementos interativos são acessíveis via teclado e possuem um indicador de foco visível (SC 2.4.11).
• Forneça alternativas de clique ú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 Nome, Papel, Valor.
• Implemente regiões aria-live ou regiões ao vivo para atualizações dinâmicas de status.

Diagrama de Arquitetura de Acessibilidade

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

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

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: Pesquisa 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-Botões: 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 escapável pela tecla Escape ou um botão de fechar explícito (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 Melhores Práticas

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

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

Habilidades Relacionadas

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