WCAG — co to jest, Web Content Accessibility Guidelines i poziomy AA

Czym jest WCAG?

WCAG (Web Content Accessibility Guidelines) — to zbiór zaleceń dotyczących zapewnienia dostępności treści internetowych dla osób z niepełnosprawnościami. Standard jest opracowywany przez W3C Web Accessibility Initiative (WAI) od 1999 roku. WCAG obejmuje osoby niewidome i słabowidzące, głuche i słabosłyszące, osoby z ograniczeniami ruchowymi, mowy i poznawczymi, a także starszych użytkowników ze zmianami związanymi z wiekiem.

Pierwsza wersja WCAG 1.0 została opublikowana w 1999 roku i zawierała 14 zasad przewodnich. WCAG 2.0 (2008) stała się technologicznie neutralna, stosowana do HTML, PDF, multimediów i aplikacji mobilnych. WCAG 2.1 (2018) dodała kryteria dla urządzeń mobilnych i wprowadzania dotykowego. WCAG 2.2 (2023) — aktualna wersja z nowymi kryteriami dla animacji i fokusu. WCAG nie jest prawem, ale wiele krajów odnosi się do niego w swoim ustawodawstwie.

GOST R 52872-2019 w Rosji, European Accessibility Act w UE i Section 508 w USA — wszystkie wymagają zgodności z WCAG AA. Dla witryn korporacyjnych i rządowych WCAG AA to obowiązkowy standard, którego nieprzestrzeganie prowadzi do pozwów sądowych. Według danych UsableNet (2024), w USA złożono ponad 12 000 pozwów o niedostępność stron internetowych.

Wersje WCAG: porównanie

Konsekwencje prawne niezgodności

Nieprzestrzeganie WCAG wiąże się z poważnymi ryzykami. W 2025 roku European Accessibility Act (EAA) wszedł w życie, wymagając WCAG 2.1 AA dla wszystkich publicznych stron internetowych i aplikacji mobilnych w UE. Grzywny sięgają 5% rocznego obrotu firmy. Średnia kwota ugody w USA wynosi $25 000–$50 000. Audyt accessibility powinien być przeprowadzany na każdym etapie rozwoju, a nie tylko przed wydaniem.

Cztery zasady WCAG: POUR

POUR — akronim czterech zasad WCAG: Perceivable (postrzegalność), Operable (funkcjonalność), Understandable (zrozumiałość), Robust (kompatybilność). Każda zasada zawiera wytyczne, a wytyczne — testowalne kryteria sukcesu. Łącznie WCAG 2.2 zawiera 13 wytycznych i 86 kryteriów sukcesu. Każde kryterium ma poziom A, AA lub AAA.

Perceivable — Postrzegalność

Zasada Perceivable wymaga, aby treść była przedstawiona w formie, którą użytkownik może postrzegać. Wytyczne: 1.1 Text Alternatives (alternatywy tekstowe), 1.2 Time-based Media (napisy, transkrypcje), 1.3 Adaptable (treść bez utraty przy zmianie formatu), 1.4 Distinguishable (kontrast 4,5:1, kolor, dźwięk). Kluczowe kryterium 1.4.3 Contrast Minimum (AA) — najczęściej naruszane: 86% stron nie spełnia go według danych WebAIM.

Operable — Funkcjonalność

Zasada Operable wymaga sterowania interfejsem. Wytyczne: 2.1 Keyboard Accessible, 2.2 Enough Time, 2.3 Seizures, 2.4 Navigable, 2.5 Input Modalities. Kryterium 2.1.1 Keyboard (A) — jedno z najkrytyczniejszych: wszystkie funkcje muszą być dostępne z klawiatury bez myszy. Okna modalne zamykane tylko kliknięciem, rozwijane menu bez nawigacji klawiaturowej — typowe naruszenia.

Understandable — Zrozumiałość

Zasada Understandable wymaga zrozumiałości treści i interfejsu. Wytyczne: 3.1 Readable, 3.2 Predictable, 3.3 Input Assistance. Szczególnie ważne jest kryterium 3.3.4 Error Prevention dla aplikacji finansowych i medycznych: zapobieganie poważnym konsekwencjom błędów wprowadzania. Kryterium 3.2.6 Consistent Help (nowe w WCAG 2.2) wymaga, aby przyciski pomocy znajdowały się w tych samych miejscach.

Robust — Kompatybilność

Zasada Robust wymaga kompatybilności z technologiami wspomagającymi. Wytyczna 4.1 Compatible z kluczowym kryterium 4.1.2 Name, Role, Value (A): każdy komponent UI musi mieć programowo określoną nazwę, rolę i stan. Atrybuty ARIA (role, aria-label, aria-expanded) — podstawowe narzędzie. Bez nich czytniki ekranu nie mogą określić, czy element jest przyciskiem, linkiem czy zakładką.

Tabela zasad WCAG

Poziomy zgodności WCAG: A, AA, AAA

WCAG określa trzy poziomy: A (minimalny), AA (standardowy) i AAA (maksymalny). Poziom A — obowiązkowe minimum: bez niego treść jest niedostępna dla niektórych kategorii użytkowników. AA usuwa główne bariery dostępności. AAA — najwyższy standard, ale nie może być osiągnięty dla wszystkich treści (na przykład niektóre języki migowe lub transkrypcje audio nie zawsze są wykonalne).

Poziom A (30 kryteriów): text alternatives, obsługa klawiatury, wystarczający czas, brak migotania powyżej 3 Hz. Poziom AA (+24 kryteria): contrast ratio 4,5:1, napisy dla wideo, resize tekstu do 200%, wyraźny fokus klawiatury. Poziom AAA (+32 kryteria): contrast ratio 7:1, język migowy, wyłączenie animacji (2.3.3), transkrypcja audio. Dla witryn rządowych wystarczy AA.

Proces audytu WCAG

Audyt accessibility według WCAG obejmuje: automatyczne testowanie (axe DevTools, WAVE, Lighthouse — znajduje 30–40% błędów), ręczne testowanie klawiatury i czytników ekranu (VoiceOver, TalkBack, NVDA), ekspercki audyt dla złożonych kryteriów oraz testowanie użytkowników z niepełnosprawnościami. Raport audytu powinien zawierać poziom zgodności i listę niezgodności dla każdego kryterium.

Co nowego w WCAG 2.2

WCAG 2.2 dodał 9 nowych kryteriów. Kluczowe: 2.4.11 Focus Appearance (AA) — wskaźnik fokusu >= 2px z kontrastem 3:1, 2.5.8 Target Size Minimum (AA) — cel dotykowy minimum 24x24 piksele, 3.3.7 Accessible Authentication (AA) — uwierzytelnianie bez CAPTCHA. Kryterium 2.3.3 Animation from Interactions (AAA) — wyłączalna animacja lub nie więcej niż 5 sekund.

Focus Appearance — najważniejsza zmiana. Wcześniej outline: none bez zamiennika było naruszeniem, ale nie było jasnych wymagań. WCAG 2.2 ustalił: grubość >= 2px, kontrast 3:1 z tłem, powierzchnia wskaźnika nie mniejsza niż powierzchnia elementu. Dla niestandardowych przycisków z border-radius używaj box-shadow zamiast outline.

Focus Appearance w 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; }
}

Stylizacja :focus-visible zapewnia zgodność z kryterium Focus Appearance. Alternatywa przez box-shadow nadaje się dla elementów z border-radius. Tryb ciemny i High Contrast dostosowują kolory fokusu.

Accessible Authentication

Kryterium 3.3.7 Accessible Authentication (AA) — jedna z najczęściej dyskutowanych nowości. CAPTCHA z rozpoznawaniem obiektów, łamigłówki, przeciąganie suwaków — to teraz naruszenie, jeśli nie ma alternatywy. Dopuszczalne sposoby: OTP przez email/SMS, biometria (Face ID, Touch ID), kody QR, Magic link. Upraszcza to życie nie tylko osobom z zaburzeniami poznawczymi, ale także wszystkim użytkownikom.

WCAG dla aplikacji mobilnych

WCAG ma zastosowanie do natywnych aplikacji iOS i Android. Cztery zasady POUR w pełni pokrywają interfejsy mobilne. Specyficzne kryteria: 2.5.1 Pointer Gestures (gesty bez wysokiej precyzji), 2.5.2 Pointer Cancellation (anulowanie przypadkowego dotknięcia), 2.5.3 Label in Name (tekst przycisku zgodny z accessibility-labelem). Dla iOS używane jest UIKit/UIAccessibility, dla Android — AccessibilityService i ContentDescription.

Najczęściej w aplikacjach mobilnych naruszane są: 1.1.1 Non-text Content — ikony bez contentDescription, 2.4.3 Focus Order — nieprawidłowa kolejność nawigacji, 2.5.8 Target Size — przyciski mniejsze niż 24x24dp, 1.4.3 Contrast — tekst na obrazach tła. iOS udostępnia Accessibility Inspector w Xcode, Android — Accessibility Scanner do automatycznego audytu.

Kod SwiftUI zgodny z 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("Kliknij, aby wykonać")
        .accessibilityAddTraits(.isButton)
    }
}

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

    var body: some View {
        VStack(spacing: 16) {
            VStack(alignment: .leading) {
                Text("Email")
                TextField("Wpisz email", text: $email)
                    .textContentType(.emailAddress)
                    .keyboardType(.emailAddress)
                    .autocapitalization(.none)
                    .accessibilityLabel("Pole do wpisania email")
                    .accessibilityHint("Wpisz adres email")
            }
            AccessibleButton(
                action: { },
                title: "Wyślij",
                icon: "paperplane.fill"
            )
        }
        .padding()
    }
}

Komponenty SwiftUI z accessibilityLabel, accessibilityHint i minWidth/minHeight >= 48pt zapewniają zgodność z WCAG 2.5.8 (Target Size) i 2.5.3 (Label in Name). Używaj Xcode Accessibility Inspector do sprawdzania fokusu VoiceOver, kolejności nawigacji i rozmiarów touch targets. Podobne wymagania dotyczą Jetpack Compose przez Modifier.semantics.