WCAG 2.2 AA

Zapewnienie dostępności cyfrowej jest kluczowe dla inkluzywnego społeczeństwa, umożliwiając wszystkim użytkownikom, niezależnie od ich możliwości, pełne korzystanie z internetu. Web Content Accessibility Guidelines (WCAG) to międzynarodowy standard opracowany przez World Wide Web Consortium (W3C), który wyznacza zasady tworzenia dostępnych stron internetowych i aplikacji. Wersja WCAG 2.2 Poziom AA rozszerza poprzednie wytyczne, wprowadzając nowe kryteria sukcesu, które jeszcze bardziej poprawiają użyteczność i dostępność dla szerokiej gamy osób z niepełnosprawnościami.

Czym jest WCAG 2.2 Poziom AA?

WCAG 2.2 Poziom AA stanowi ewolucję standardu WCAG 2.1 Poziomu AA, dodając cztery nowe kryteria sukcesu. Kryteria te koncentrują się na obszarach, które zyskały na znaczeniu w kontekście współczesnych interakcji cyfrowych, w tym poprawy widoczności fokusu dla nawigacji klawiaturą, alternatyw dla złożonych gestów dotykowych, minimalnych rozmiarów elementów interaktywnych oraz dostępnych metod uwierzytelniania. Ich celem jest usprawnienie doświadczeń użytkowników z niepełnosprawnościami wzrokowymi, ruchowymi oraz poznawczymi, a także osób korzystających z urządzeń mobilnych i alternatywnych metod wprowadzania danych. Zmiany te odzwierciedlają rosnące znaczenie dostępności w kontekście urządzeń mobilnych i inkluzywnych wzorców interakcji.

Dlaczego WCAG 2.2 Poziom AA ma znaczenie?

Wdrożenie WCAG 2.2 Poziom AA przynosi liczne korzyści, wykraczające poza samą zgodność z przepisami. Dostępność to podstawa inkluzywności i użyteczności dla wszystkich:

• Osoby słabowidzące i niewidome: Ulepszenia dotyczące fokusu i kontrastu ułatwiają nawigację klawiaturą i korzystanie z czytników ekranu.
• Osoby z niepełnosprawnościami ruchowymi: Alternatywy dla gestów przeciągania oraz odpowiednie rozmiary celów dotykowych minimalizują trudności w interakcji z interfejsem.
• Osoby z niepełnosprawnościami poznawczymi i trudnościami w uczeniu się: Uproszczone procesy uwierzytelniania zmniejszają obciążenie poznawcze i frustrację, szczególnie dla osób z dysleksją, ADHD czy zaburzeniami pamięci.
• Użytkownicy urządzeń mobilnych: Większe cele dotykowe i alternatywy dla przeciągania poprawiają doświadczenie na mniejszych ekranach i w sytuacjach, gdy precyzja jest ograniczona (np. w ruchu).
• Wszyscy użytkownicy: Lepsza widoczność fokusu, większe obszary kliknięcia i prostsze formularze uwierzytelniania poprawiają ogólną użyteczność i komfort korzystania z witryny dla każdego.

Nowe Kryteria Sukcesu w WCAG 2.2 Poziom AA

WCAG 2.2 Poziom AA wprowadza cztery nowe kryteria sukcesu, uzupełniając wymagania z WCAG 2.1. Skupimy się na ich szczegółach, wymaganiach i praktycznych sposobach implementacji.

Kryterium Sukcesu 2.4.11: Wygląd Fokusu (Poziom AA)

Kryterium to ma na celu zapewnienie, że wskaźnik fokusu jest wyraźnie widoczny, gdy element interaktywny otrzymuje fokus, co jest kluczowe dla użytkowników nawigujących za pomocą klawiatury lub alternatywnych urządzeń wskazujących, a także dla osób słabowidzących.

Wymagania i Cele

Wskaźnik fokusu musi:

• Mieć minimalny obszar: Musi być wystarczająco duży, aby był łatwo zauważalny. Oznacza to, że ma co najmniej 2 piksele CSS grubości wokół komponentu (cała obwiednia) lub 4 piksele CSS grubości na jednej stronie (np. podkreślenie), albo zmianę obszaru, który ma grubość co najmniej 1 piksela CSS i pokrywa całą obwiednię komponentu interfejsu użytkownika.
• Mieć minimalny kontrast: Musi mieć kontrast co najmniej 3:1 w stosunku do sąsiednich niefokusowanych pikseli, co odróżnia go od otoczenia. Alternatywnie, obszar zmiany (np. gruby obrys) powinien mieć kontrast 3:1 w stosunku do koloru tła komponentu lub sąsiedniego koloru tła interfejsu użytkownika.
• Być widoczny: Zmiana wyglądu musi być wyraźna i nie może być niewidoczna po otrzymaniu fokusu.

Praktyczne Wskazówki

• Nie usuwaj domyślnych stylów fokusu (np. za pomocą outline: none;), chyba że zapewnisz lepsze, niestandardowe style.
• Używaj wyraźnych obrysów (outline), cieni (box-shadow) lub grubych obramowań (border).
• Zadbaj o to, aby kolor fokusu był dobrze widoczny zarówno na jasnym, jak i ciemnym tle.
• Upewnij się, że fokus jest widoczny na wszystkich interaktywnych elementach: linkach, przyciskach, polach formularzy, niestandardowych kontrolkach, elementach z atrybutem tabindex.

Przykłady Implementacji

a:focus,
button:focus,
input[type="text"]:focus,
textarea:focus,
select:focus {
  outline: 3px solid #0056b3; /* Grubszy obrys */
  outline-offset: 2px; /* Odstęp od elementu dla lepszej widoczności */
  box-shadow: 0 0 0 5px rgba(0, 86, 179, 0.5); /* Dodatkowy cień dla lepszej widoczności */
}

/* Alternatywny fokus z użyciem tła i podkreślenia dla linków tekstowych */
.text-link:focus {
  background-color: #e0f2ff; /* Zmiana tła z wystarczającym kontrastem */
  color: #000000; /* Zapewnienie kontrastu tekstu */
  border-bottom: 2px solid #0056b3; /* Dodatkowe podkreślenie */
}

a:focus,
button:focus,
input:focus {
  outline: none; /* Całkowite usunięcie fokusu, brak alternatywy */
}

.my-button:focus {
  border: 1px solid transparent; /* Zmiana, która nie jest wystarczająco widoczna */
}

Kryterium Sukcesu 2.5.7: Ruchy Przeciągania (Poziom AA)

To kryterium wymaga, aby funkcje interfejsu użytkownika, które opierają się na złożonych ruchach przeciągania (np. drag-and-drop), miały dostępną alternatywę, która nie wymaga precyzyjnego ruchu przeciągania, chyba że samo przeciąganie jest niezbędne dla funkcji lub czynność jest obsługiwana przez agenta użytkownika.

Wymagania i Cele

• Jeśli funkcjonalność wymaga od użytkownika wykonywania ruchów przeciągania (np. przy sortowaniu elementów, zmianie rozmiaru komponentów), musi istnieć co najmniej jedna alternatywna metoda obsługi tej samej funkcjonalności, która nie wymaga ruchów przeciągania.
• Alternatywa może być na przykład oparta na kliknięciu, naciśnięciu klawiszy strzałek lub innych prostych akcjach, które nie wymagają ciągłej kontroli ruchu.
• Wyjątki obejmują sytuacje, gdy przeciąganie jest niezbędne (np. rysowanie odręczne) lub funkcjonalność jest w pełni obsługiwana przez agenta użytkownika (np. natywne przeciąganie plików w systemie operacyjnym).

Praktyczne Wskazówki

• Dla funkcji „przeciągnij i upuść” (drag-and-drop) zawsze udostępniaj alternatywę, taką jak przyciski „Przenieś w górę”, „Przenieś w dół”, „Wybierz i przenieś” lub opcje menu kontekstowego.
• Zapewnij, że alternatywne metody są w pełni dostępne za pomocą klawiatury i dla technologii wspomagających.
• Dla suwaków lub innych kontrolek zmieniających wartości poprzez przeciąganie, upewnij się, że można je obsługiwać również za pomocą klawiszy strzałek.

Przykłady Implementacji

<ul id="sortableList" aria-label="Lista do sortowania">
  <li draggable="true" tabindex="0">
    Element 1
    <button aria-label="Przenieś Element 1 w górę">▲</button>
    <button aria-label="Przenieś Element 1 w dół">▼</button>
  </li>
  <li draggable="true" tabindex="0">
    Element 2
    <button aria-label="Przenieś Element 2 w górę">▲</button>
    <button aria-label="Przenieś Element 2 w dół">▼</button>
  </li>
</ul>

<script>
  // Dodatkowo, logika JavaScript dla przycisków i ewentualnie obsługi klawiatury dla draggable
  const list = document.getElementById('sortableList');
  list.addEventListener('keydown', (e) => {
    if (e.key === 'ArrowUp' || e.key === 'ArrowDown') {
      const focusedItem = document.activeElement.closest('li');
      if (focusedItem) {
        e.preventDefault();
        // Implementacja logiki przenoszenia elementu za pomocą strzałek
        // (np. zmiana kolejności w DOM lub aktualizacja danych)
        console.log(`Element ${focusedItem.textContent.trim()} przeniesiony ${e.key === 'ArrowUp' ? 'w górę' : 'w dół'}`);
      }
    }
  });
</script>

<div id="draggableArea">
  <!-- Elementy, które można przesuwać tylko za pomocą przeciągania -->
  <div class="draggable-item">Plik do przeniesienia</div>
  <div class="drop-zone">Folder docelowy</div>
</div>

Kryterium Sukcesu 2.5.8: Minimalny Rozmiar Celu (Poziom AA)

To kryterium ma na celu ułatwienie interakcji użytkownikom z niepełnosprawnościami ruchowymi (np. drżeniami, niedokładnością ruchów), tym, którzy korzystają z urządzeń mobilnych oraz osobom z niską precyzją, zapewniając, że interaktywne elementy są wystarczająco duże, aby można je było łatwo aktywować.

Wymagania i Cele

• Aktywny obszar interfejsu użytkownika (np. przycisk, link, pole formularza, ikonka) musi mieć co najmniej 24 na 24 piksele CSS.
• Istnieją wyjątki od tej zasady:
• Równoważny cel: Taki sam cel jest dostępny poprzez inny link/przycisk, który spełnia wymaganie minimalnego rozmiaru.
• Odstęp: Cel jest otoczony odstępem co najmniej 24 pikseli CSS od każdego sąsiadującego celu. Oznacza to, że każdy cel ma wokół siebie niewidoczny „bezpieczny margines” o szerokości co najmniej 12 pikseli CSS.
• Tekstowy link: Cel jest częścią tekstu lub jest linkiem w bloku tekstu (np. link w akapicie).
• Krytyczne: Prezentacja celu jest niezbędna do informacji, a zmiana rozmiaru spowodowałaby, że cel byłby bezużyteczny (np. ikona w menu, która musi być mała, ale ma alternatywę w postaci dużego przycisku).
• Agent użytkownika: Rozmiar celu jest określany przez agenta użytkownika, a autor nie zmodyfikował jego rozmiaru (np. domyślne pola wyboru w przeglądarce).

Praktyczne Wskazówki

• Projektuj przyciski, ikony i inne elementy interaktywne tak, aby ich obszar kliknięcia/dotknięcia był co najmniej 24×24 piksele CSS.
• Używaj padding w CSS, aby powiększyć obszar dotykowy/kliknięcia bez konieczności zwiększania rozmiaru samej ikony czy tekstu.
• Testuj interfejs na urządzeniach mobilnych i za pomocą narzędzi symulujących kliknięcia, aby upewnić się, że małe cele są łatwe do trafienia.
• Dla celów mniejszych niż 24x24px, upewnij się, że są otoczone wystarczającym odstępem lub mają alternatywny, większy cel.

Przykłady Implementacji

.menu-item {
  display: inline-block;
  padding: 8px 12px; /* Zwiększa obszar kliknięcia, przekraczając 24x24px */
  min-width: 24px;
  min-height: 24px;
  line-height: 1; /* Pomaga w obliczeniach wysokości */
}

.icon-button {
  width: 32px;
  height: 32px;
  padding: 0; /* Sam element jest już wystarczająco duży */
  box-sizing: border-box;
}

/* Alternatywa dla małych ikon - otoczenie odstępem */
.small-icon-wrapper {
  padding: 12px; /* Daje ikonę w środku obszaru 24x24px */
  display: inline-block;
}

<a href="#"><img src="tiny-icon.png" alt="Udostępnij" style="width:16px; height:16px;"></a>

/* Przycisk o zbyt małym obszarze dotyku bez paddingu */
.small-button {
  width: 18px;
  height: 18px;
  padding: 0;
  margin: 0;
}

Kryterium Sukcesu 3.3.8: Dostępne Uwierzytelnianie (Minimum) (Poziom AA)

To kryterium ma na celu ułatwienie procesów logowania i uwierzytelniania dla osób z niepełnosprawnościami poznawczymi, pamięciowymi i trudnościami w uczeniu się, eliminując lub oferując alternatywy dla testów poznawczych. Dotyczy to metod uwierzytelniania, które wymagają od użytkownika zapamiętywania, transkrypcji lub przetwarzania informacji.

Wymagania i Cele

Proces uwierzytelniania (np. logowanie do konta, weryfikacja tożsamości) nie może wymagać od użytkownika wykonania testu poznawczego, takiego jak zapamiętywanie ciągu znaków (hasła), przepisanie tekstu, rozwiązanie prostych zagadek matematycznych czy identyfikacja obiektów na obrazkach (CAPTCHA), chyba że:

• Dostępna jest alternatywa: Dostępna jest inna metoda uwierzytelniania, która nie wymaga testu poznawczego (np. menedżer haseł, uwierzytelnianie dwuskładnikowe oparte na kodzie z wiadomości SMS lub aplikacji, biometria).
• Mechanizm jest wspierany przez agenta użytkownika: Test poznawczy jest obsługiwany przez platformę lub przeglądarkę (np. natywny menedżer haseł przeglądarki).
• Rozpoznawanie obiektów nieludzkich: Rozpoznawanie obiektów jest odgórnie wymagane i nie dotyczy identyfikacji ludzkich cech lub procesów.
• Osobisty kontent: Test opiera się na treści stworzonej przez użytkownika (np. odpowiedzi na pytania bezpieczeństwa, które użytkownik sam zdefiniował).
• Zabezpieczenie przed atakami: Test poznawczy jest niezbędny, aby zapobiec konkretnym, znaczącym i zidentyfikowanym zagrożeniom bezpieczeństwa (np. w bankowości online), a zrezygnowanie z niego stworzyłoby znaczące ryzyko bezpieczeństwa, a żadna alternatywa bez testu poznawczego nie jest dostępna.

Praktyczne Wskazówki

• Umożliwij użytkownikom wklejanie haseł z menedżerów haseł, nie blokuj tej funkcji.
• Zapewnij opcje uwierzytelniania bezhasłowego (np. logowanie za pomocą maila/SMS z jednorazowym kodem, biometryka, logowanie przez usługi społecznościowe).
• Jeśli konieczne jest użycie CAPTCHA, wybieraj te, które oferują alternatywy (np. audio CAPTCHA, proste równania matematyczne z możliwością odświeżenia) i są łatwe do rozwiązania, lub rozważ rozwiązania bez interakcji (np. reCAPTCHA v3).
• Nie wymagaj od użytkowników odtwarzania skomplikowanych gestów lub rysunków w procesie uwierzytelniania.
• Używaj atrybutu autocomplete w polach formularzy, aby wspierać menedżery haseł i autouzupełnianie.

Przykłady Implementacji

<form action="/login" method="post">
  <label for="username">Nazwa użytkownika / E-mail:</label>
  <input type="text" id="username" name="username" autocomplete="username" required><br><br>
  
  <label for="password">Hasło:</label>
  <input type="password" id="password" name="password" autocomplete="current-password" required><br><br>
  
  <input type="submit" value="Zaloguj się">

  <p>Lub <a href="/login-with-magic-link">zaloguj się za pomocą jednorazowego linku</a>.</p>
</form>

<form action="/login" method="post">
  <label for="password">Wpisz hasło:</label>
  <input type="password" id="password" name="password" onpaste="return false;"><br><br>
  
  <label>Wpisz kod z obrazka:</label>
  <img src="complex-captcha.png" alt="Obrazek CAPTCHA, tekst trudny do odczytania"><br>
  <input type="text" id="captcha" name="captcha"><br><br>
  
  <input type="submit" value="Zaloguj się">
</form>

Najlepsze Praktyki i Typowe Pułapki

• Testuj z klawiaturą: Regularnie sprawdzaj całą witrynę, używając wyłącznie klawiatury (klawiszy Tab, Shift+Tab, Enter, Spacja, Strzałki), aby upewnić się, że wszystkie interaktywne elementy są dostępne i mają widoczny fokus.
• Używaj semantycznego HTML: Prawidłowe użycie elementów HTML (np. <button>, <a>, <input>) często automatycznie zapewnia dostępność klawiatury i fokusu. W przypadku niestandardowych kontrolek, stosuj ARIA.
• Nie polegaj wyłącznie na kolorze: Zawsze upewnij się, że informacje są przekazywane również za pomocą innych środków niż tylko kolor (np. dla fokusu, użyj obrysu lub cienia, nie tylko zmiany koloru, aby uwzględnić użytkowników z daltonizmem).
• Pamiętaj o urządzeniach mobilnych: Projektuj z myślą o dotyku. Większe cele dotykowe i alternatywy dla przeciągania są kluczowe dla użytkowników mobilnych i osób, które mogą mieć trudności z precyzją.
• Uważaj na niestandardowe kontrolki: Jeśli tworzysz niestandardowe komponenty UI, upewnij się, że dziedziczą one lub implementują wszystkie niezbędne atrybuty dostępności (ARIA) i obsługę zdarzeń (fokus, klawiatura, interakcje dotykowe).
• Weryfikacja procesów uwierzytelniania: Zawsze sprawdzaj, czy procesy logowania i rejestracji są przyjazne dla użytkowników z różnymi potrzebami poznawczymi. Unikaj zbędnych przeszkód.
• Używaj walidatorów i testów automatycznych: Narzędzia takie jak Lighthouse, AXE DevTools mogą pomóc w identyfikacji podstawowych problemów z dostępnością, ale zawsze uzupełniaj je testami manualnymi.

Podsumowanie

WCAG 2.2 Poziom AA jest istotnym krokiem w kierunku bardziej inkluzywnego internetu. Wdrożenie jego nowych kryteriów sukcesu nie tylko pomaga spełnić wymogi prawne, ale przede wszystkim tworzy lepsze i bardziej dostępne doświadczenia dla wszystkich użytkowników. Pamiętając o tych wytycznych od początku procesu projektowania i rozwoju, możemy budować strony internetowe, które są naprawdę dostępne dla każdego, promując równość i uczestnictwo w cyfrowym świecie.