WCAG — o que é, Web Content Accessibility Guidelines e níveis AA

O que é WCAG?

WCAG (Web Content Accessibility Guidelines) é um conjunto de recomendações para garantir a acessibilidade do conteúdo web para pessoas com deficiência. O padrão tem sido desenvolvido pela W3C Web Accessibility Initiative (WAI) desde 1999. WCAG abrange cegos e pessoas com deficiência visual, surdos e pessoas com deficiência auditiva, pessoas com limitações de mobilidade, distúrbios de fala e cognitivos, bem como utilizadores idosos com alterações relacionadas com a idade.

A primeira versão WCAG 1.0 foi lançada em 1999 e continha 14 princípios orientadores. WCAG 2.0 (2008) tornou-se tecnologicamente neutra, aplicável a HTML, PDF, multimédia e aplicações móveis. WCAG 2.1 (2018) adicionou critérios para dispositivos móveis e entrada tátil. WCAG 2.2 (2023) é a versão atual com novos critérios para animação e foco. WCAG não é uma lei, mas muitos países referenciam-no na sua legislação.

GOST R 52872-2019 na Rússia, a European Accessibility Act na UE e a Secção 508 nos EUA — todos exigem conformidade WCAG AA. Para sites corporativos e governamentais, WCAG AA é um padrão obrigatório, cujo incumprimento leva a ações judiciais. Segundo a UsableNet (2024), mais de 12 000 ações judiciais de acessibilidade web foram apresentadas nos EUA.

Versões WCAG: comparação

Consequências legais do incumprimento

O incumprimento do WCAG acarreta riscos graves. Em 2025, a European Accessibility Act (EAA) entrou em vigor, exigindo WCAG 2.1 AA para todos os sites públicos e aplicações móveis na UE. As multas podem atingir até 5% do volume de negócios anual da empresa. O valor médio de acordo de ações judiciais nos EUA é de $25 000–$50 000. As auditorias de acessibilidade devem ser realizadas em cada fase do desenvolvimento, não apenas antes do lançamento.

Quatro princípios do WCAG: POUR

POUR é um acrónimo de quatro princípios WCAG: Perceivable (percetível), Operable (operável), Understandable (compreensível), Robust (robusto). Cada princípio contém diretrizes, e as diretrizes contêm critérios de sucesso testáveis. WCAG 2.2 tem 13 diretrizes e 86 critérios de sucesso. Cada critério tem nível A, AA ou AAA.

Perceivable — Percetível

O princípio Perceivable exige que o conteúdo seja apresentado de forma que o utilizador possa perceber. Diretrizes: 1.1 Text Alternatives (alternativas textuais), 1.2 Time-based Media (legendas, transcrições), 1.3 Adaptable (conteúdo sem perda ao mudar formato), 1.4 Distinguishable (contraste 4.5:1, cor, som). O critério chave 1.4.3 Contrast Minimum (AA) é o mais violado: 86% das páginas não o cumprem segundo a WebAIM.

Operable — Operável

O princípio Operable exige a operabilidade da interface. Diretrizes: 2.1 Keyboard Accessible, 2.2 Enough Time, 2.3 Seizures, 2.4 Navigable, 2.5 Input Modalities. O critério 2.1.1 Keyboard (A) é um dos mais críticos: todas as funções devem estar acessíveis através do teclado sem rato. Janelas modais que fecham apenas ao clicar, dropdowns sem navegação por teclado — violações típicas.

Understandable — Compreensível

O princípio Understandable exige a compreensibilidade do conteúdo e da interface. Diretrizes: 3.1 Readable, 3.2 Predictable, 3.3 Input Assistance. O critério 3.3.4 Error Prevention é especialmente importante para aplicações financeiras e médicas: prevenir consequências graves de erros de entrada. O critério 3.2.6 Consistent Help (novo no WCAG 2.2) exige que os botões de ajuda estejam nos mesmos locais.

Robust — Robusto

O princípio Robust exige compatibilidade com tecnologias de assistência. Diretriz 4.1 Compatible com o critério chave 4.1.2 Name, Role, Value (A): cada componente de UI deve ter nome, função e estado determináveis programaticamente. Os atributos ARIA (role, aria-label, aria-expanded) são a ferramenta principal. Sem eles, os leitores de ecrã não podem determinar se um elemento é um botão, link ou separador.

Tabela de princípios WCAG

Níveis de conformidade WCAG: A, AA, AAA

WCAG define três níveis: A (mínimo), AA (padrão) e AAA (máximo). O nível A é o mínimo obrigatório: sem ele, o conteúdo é inacessível para algumas categorias de utilizadores. AA remove as principais barreiras de acessibilidade. AAA é o padrão mais alto, mas não pode ser alcançado para todo o conteúdo (por exemplo, algumas línguas gestuais ou transcrições de áudio nem sempre são exequíveis).

Nível A (30 critérios): alternativas textuais, operabilidade por teclado, tempo suficiente, sem cintilação acima de 3 Hz. Nível AA (+24 critérios): rácio de contraste 4.5:1, legendas para vídeo, redimensionamento de texto até 200%, foco de teclado claro. Nível AAA (+32 critérios): rácio de contraste 7:1, língua gestual, desativação de animações (2.3.3), transcrição de áudio. Para sites governamentais, AA é suficiente.

Processo de auditoria WCAG

Uma auditoria de acessibilidade WCAG inclui: teste automatizado (axe DevTools, WAVE, Lighthouse — encontra 30–40% dos erros), teste manual de teclado e leitores de ecrã (VoiceOver, TalkBack, NVDA), auditoria especializada para critérios complexos e teste com utilizadores com deficiência. O relatório de auditoria deve conter o nível de conformidade e uma lista de não conformidades para cada critério.

Novidades no WCAG 2.2

WCAG 2.2 adicionou 9 novos critérios. Principais: 2.4.11 Focus Appearance (AA) — indicador de foco >= 2px com contraste 3:1, 2.5.8 Target Size Minimum (AA) — alvo tátil de pelo menos 24x24 pixels, 3.3.7 Accessible Authentication (AA) — autenticação sem CAPTCHA. Critério 2.3.3 Animation from Interactions (AAA) — animação desativável ou não mais de 5 segundos.

Focus Appearance é a mudança mais importante. Anteriormente, outline: none sem substituição era uma violação, mas não havia requisitos claros. WCAG 2.2 estabeleceu: espessura >= 2px, contraste 3:1 com o fundo, área do indicador pelo menos a área do elemento. Para botões personalizados com border-radius, use box-shadow em vez de outline.

Focus Appearance em CSS

/* WCAG 2.2 Focus Appearance (2.4.11 AA) */
:focus-visible {
    outline: 3px solid #0066CC;
    outline-offset: 2px;
}

.button:focus-visible {
    outline: none;
    box-shadow:
        0 0 0 3px #FFFFFF,
        0 0 0 6px #0066CC;
}

@media (prefers-color-scheme: dark) {
    :focus-visible { outline-color: #66B2FF; }
}

@media (prefers-contrast: more) {
    :focus-visible { outline: 4px solid #000; outline-offset: 3px; }
}

A estilização de :focus-visible garante conformidade com o critério Focus Appearance. Uma alternativa através de box-shadow funciona para elementos com border-radius. O tema escuro e High Contrast adaptam as cores de foco.

Accessible Authentication

O critério 3.3.7 Accessible Authentication (AA) é uma das inovações mais discutidas. CAPTCHA com reconhecimento de objetos, puzzles, arrastar de deslizadores — agora é uma violação se não houver alternativa. Métodos aceitáveis: OTP por email/SMS, biometria (Face ID, Touch ID), códigos QR, Magic link. Isto facilita a vida não só a pessoas com deficiências cognitivas, mas também a todos os utilizadores.

WCAG para aplicações móveis

WCAG aplica-se a aplicações nativas iOS e Android. Os quatro princípios POUR cobrem completamente as interfaces móveis. Critérios específicos: 2.5.1 Pointer Gestures (gestos sem alta precisão), 2.5.2 Pointer Cancellation (cancelamento de toque acidental), 2.5.3 Label in Name (o texto do botão corresponde ao rótulo de acessibilidade). iOS usa UIKit/UIAccessibility, Android usa AccessibilityService e ContentDescription.

Os mais violados em aplicações móveis: 1.1.1 Non-text Content — ícones sem contentDescription, 2.4.3 Focus Order — ordem de navegação incorreta, 2.5.8 Target Size — botões menores que 24x24dp, 1.4.3 Contrast — texto em imagens de fundo. iOS fornece Accessibility Inspector no Xcode, Android fornece Accessibility Scanner para auditoria automatizada.

Código SwiftUI conforme WCAG

import SwiftUI

struct AccessibleButton: View {
    let action: () -> Void
    let title: String
    let icon: String

    var body: some View {
        Button(action: action) {
            HStack {
                Image(systemName: icon)
                Text(title)
            }
            .padding(16)
            .background(Color.blue)
            .foregroundColor(.white)
            .cornerRadius(12)
            .frame(minWidth: 48, minHeight: 48)
        }
        .accessibilityLabel(title)
        .accessibilityHint("Clique para ação")
        .accessibilityAddTraits(.isButton)
    }
}

struct AccessibleForm: View {
    @State private var email = ""

    var body: some View {
        VStack(spacing: 16) {
            VStack(alignment: .leading) {
                Text("Email")
                TextField("Digite email", text: $email)
                    .textContentType(.emailAddress)
                    .keyboardType(.emailAddress)
                    .autocapitalization(.none)
                    .accessibilityLabel("Campo de entrada de email")
                    .accessibilityHint("Digite endereço de email")
            }
            AccessibleButton(
                action: { },
                title: "Enviar",
                icon: "paperplane.fill"
            )
        }
        .padding()
    }
}

Componentes SwiftUI com accessibilityLabel, accessibilityHint e minWidth/minHeight >= 48pt garantem conformidade com WCAG 2.5.8 (Target Size) e 2.5.3 (Label in Name). Use o Xcode Accessibility Inspector para verificar o foco do VoiceOver, a ordem de navegação e os tamanhos dos alvos táteis. Requisitos semelhantes aplicam-se ao Jetpack Compose através de Modifier.semantics.