WCAG 5.2.3: Pełne procesy

Kryterium „Pełne procesy” (wcag523) podkreśla fundamentalną zasadę dostępności: aby proces składający się z wielu kroków był w pełni dostępny, wszystkie jego etapy muszą być zgodne z wytycznymi WCAG. Nie wystarczy, że tylko początkowe lub kluczowe kroki spełniają standardy dostępności. Każdy element interakcji, od pierwszego kliknięcia do ostatniego potwierdzenia, musi być zaprojektowany i zaimplementowany w sposób umożliwiający wszystkim użytkownikom, w tym osobom z niepełnosprawnościami, skuteczne i niezależne ukończenie zadania.

Dlaczego to jest ważne?

Zasada „Pełnych procesów” ma kluczowe znaczenie dla rzeczywistego doświadczenia użytkownika i skuteczności dostępności. Pominięcie dostępności choćby jednego kroku w procesie może uniemożliwić użytkownikowi ukończenie zadania, czyniąc cały wysiłek włożony w dostępność pozostałych części procesu bezcelowym. Wyobraźmy sobie, że osoba korzystająca z czytnika ekranu bez problemu przechodzi przez pierwsze trzy etapy formularza rejestracyjnego, ale na czwartym etapie napotyka na nieetykietowane pola lub nieczytelne komunikaty o błędach, które uniemożliwiają jej dalsze działanie.

Wpływ na grupy użytkowników:

• Osoby z niepełnosprawnością wzroku (np. korzystające z czytników ekranu): Potrzebują, aby wszystkie elementy interfejsu były prawidłowo oznaczone, nawigowalne i zrozumiałe w każdej części procesu.
• Osoby z niepełnosprawnością ruchową (np. korzystające z klawiatury): Muszą mieć możliwość nawigacji i interakcji z każdym elementem procesu wyłącznie za pomocą klawiatury, bez „uwięzienia” w żadnym kroku.
• Osoby z niepełnosprawnościami poznawczymi: Wymagają spójności, jasności i przewidywalności na każdym etapie, aby utrzymać koncentrację i zrozumienie procesu.
• Osoby z niepełnosprawnościami słuchu: Wszelkie treści multimedialne w procesie (np. wideo instruktażowe) muszą posiadać napisy lub transkrypcje, niezależnie od tego, na którym etapie się pojawiają.

Zapewnienie dostępności każdego kroku procesu jest również zgodne z ogólną ideą WCAG, która dąży do usunięcia barier dla jak najszerszego grona odbiorców. Brak pełnej zgodności w procesach wieloetapowych może prowadzić do frustracji, utraty potencjalnych klientów i niezadowolenia użytkowników, a w niektórych jurysdykcjach nawet do konsekwencji prawnych.

Wymagania i kryteria sukcesu

Chociaż „Pełne procesy” nie jest bezpośrednim kryterium sukcesu WCAG 2.0 lub 2.1 z numerem w formacie X.Y.Z, stanowi ono fundamentalną zasadę zgodności, która wynika z wymagań dotyczących zgodności WCAG, w szczególności z punktu 4: „Tylko treści spełniające kryteria sukcesu WCAG 2.1 na określonym poziomie zgodności mogą być uznane za zgodne”. Oznacza to, że jeśli strona lub aplikacja oferuje proces (np. zakup, rejestracja, składanie wniosku), który rozciąga się na wiele stron lub widoków, to każda z tych stron/widoków musi spełniać wszystkie odpowiednie kryteria sukcesu WCAG na deklarowanym poziomie zgodności.

Kluczowe wymagania to:

• Kompleksowa zgodność: Każdy pojedynczy krok procesu musi spełniać wszystkie kryteria sukcesu WCAG na deklarowanym poziomie (np. A, AA lub AAA). Nie ma możliwości deklarowania zgodności, jeśli choć jeden krok procesu nie spełnia tych kryteriów.
• Spójność dostępności: Standardy dostępności muszą być utrzymywane konsekwentnie w całym procesie, zapewniając spójne i przewidywalne doświadczenie użytkownika.
• Brak „ścian” niedostępności: Żaden krok nie może blokować użytkownika ani uniemożliwiać mu postępu, niezależnie od używanej technologii wspomagającej.

Praktyczne wskazówki dla zgodności

Aby zapewnić, że wszystkie procesy są w pełni dostępne, należy wdrożyć następujące praktyki:

• Projektuj z myślą o dostępności od początku (Shift Left): Włącz zasady dostępności do każdego etapu cyklu życia projektu, od koncepcji i projektowania UX/UI, przez rozwój, aż po testowanie i wdrożenie.
• Przeprowadzaj kompleksowe audyty: Nie testuj tylko pierwszej strony. Przeprowadzaj szczegółowe audyty dostępności dla każdej unikalnej strony, widoku lub modułu wchodzącego w skład procesu.
• Używaj spójnych wzorców: Stosuj ustandaryzowane i dostępne komponenty oraz wzorce projektowe w całym procesie. Upewnij się, że biblioteka komponentów jest zgodna z WCAG.
• Testuj przepływ użytkownika: Przeprowadzaj testy z udziałem prawdziwych użytkowników z niepełnosprawnościami, aby upewnić się, że mogą oni bez przeszkód przejść przez cały proces. Symuluj różne scenariusze i technologie wspomagające.
• Dokumentuj wymagania dostępności: Wymagania dotyczące dostępności powinny być jasno określone w specyfikacjach funkcjonalnych i projektowych dla każdego kroku procesu.
• Szkól zespoły: Upewnij się, że wszyscy członkowie zespołu deweloperskiego, projektowego i QA są świadomi zasad dostępności i wiedzą, jak je stosować.

Przykłady implementacji

Przykład poprawnej implementacji: Dostępny proces składania zamówienia

W poprawnie zaimplementowanym procesie każda strona sklepu internetowego (wybór produktu, koszyk, dane dostawy, płatność, potwierdzenie) jest dostępna. Oznacza to, że:

• Wszystkie pola formularzy mają etykiety (<label>) i odpowiednie atrybuty ARIA (np. aria-describedby, aria-required).
• Kontrast kolorów tekstu i interfejsu jest wystarczający.
• Nawigacja klawiaturą jest możliwa na każdej stronie, a focus jest zawsze widoczny.
• Komunikaty o błędach są jasne, zrozumiałe i dostępne dla czytników ekranu (np. poprzez aria-live).
• Ikony i grafiki posiadają alternatywne opisy tekstowe (alt).

<button type="button" class="add-to-cart" aria-label="Dodaj produkt do koszyka">
  <span class="icon-cart" aria-hidden="true"></span> Dodaj do koszyka
</button>

<div class="form-group">
  <label for="firstName">Imię:<span aria-hidden="true">*</span></label>
  <input type="text" id="firstName" name="firstName" required aria-required="true">
  <span id="firstNameError" class="error-message" role="alert" aria-live="polite"></span>
</div>

<script>
  // Przykład prostej walidacji JavaScript
  document.getElementById('firstName').addEventListener('blur', function() {
    const errorSpan = document.getElementById('firstNameError');
    if (this.value.trim() === '') {
      errorSpan.textContent = 'Imię jest wymagane.';
    } else {
      errorSpan.textContent = '';
    }
  });
</script>

Przykład niepoprawnej implementacji: Proces, który „łamie się” w środku

Poniżej przedstawiono przykłady, w których proces staje się niedostępny na późniejszych etapach, uniemożliwiając użytkownikowi dokończenie zadania.

<div class="delivery-options-custom">
  <div class="option" onclick="selectDelivery('standard')">Dostawa standardowa</div>
  <div class="option" onclick="selectDelivery('express')">Dostawa ekspresowa</div>
  <!-- Brak atrybutów role, tabin_dex, aria-selected; nie reaguje na klawisze strzałek -->
</div>
<!-- Użytkownicy klawiatury lub czytników ekranu nie mogą wybrać opcji. -->

<p style="color: #AAAAAA; background-color: #FFFFFF;">Twój koszyk zawiera...</p>
<button type="submit" style="background-color: #E0E0E0; color: #777777;">Potwierdź zamówienie</button>
<!-- Kontrast kolorów jest poniżej wymagań WCAG 2.1 AA (np. 4.5:1 dla tekstu normalnego). -->

Najlepsze praktyki i typowe pułapki

Najlepsze praktyki:

• Zautomatyzowane testy: Włącz narzędzia do automatycznego testowania dostępności (np. Lighthouse, AXE) do CI/CD, aby wykrywać problemy na wczesnym etapie na wszystkich stronach procesu.
• Testy manualne i z użytkownikami: Regularnie przeprowadzaj manualne testy dostępności, szczególnie w obszarach interaktywnych i dynamicznych. Testuj z rzeczywistymi użytkownikami korzystającymi z technologii wspomagających.
• Dostępne systemy projektowe: Inwestuj w systemy projektowe (Design Systems), które domyślnie zawierają dostępne komponenty i wytyczne, aby zapewnić spójność w całym procesie.
• Jasne ścieżki błędów: Zapewnij, że komunikaty o błędach są jasne, sugerują rozwiązanie i są dostępne dla wszystkich użytkowników (np. wizualnie, tekstowo, programowo).

Typowe pułapki:

• Zaniedbanie późniejszych etapów: Często deweloperzy skupiają się na dostępności pierwszej strony, zapominając o późniejszych krokach, które mogą zawierać bardziej złożone interakcje.
• Niedostępne komponenty stron trzecich: Integracja z zewnętrznymi komponentami (np. bramki płatności, widżety map) może wprowadzać bariery, jeśli nie są one dostępne.
• Brak spójności w zespole: Jeśli różne części procesu są rozwijane przez różne zespoły bez spójnych wytycznych dostępności, łatwo o niezgodności.
• Dynamiczna treść i aktualizacje: Treści ładowane dynamicznie lub zmiany w interfejsie w trakcie procesu (np. komunikaty sukcesu/błędu, aktualizacje koszyka) mogą być łatwo przeoczone pod kątem dostępności.

Podsumowanie

Kryterium „Pełne procesy” przypomina, że prawdziwa dostępność to podróż, a nie pojedynczy cel. Aby aplikacja lub strona internetowa była w pełni użyteczna dla wszystkich, każdy element każdej interakcji w procesie wieloetapowym musi być dostępny. To kompleksowe podejście nie tylko zapewnia zgodność z WCAG, ale przede wszystkim tworzy lepsze, bardziej inkluzywne doświadczenie dla każdego użytkownika.