WCAG accessibility in UX/UI: jak przełożyć zasady na interfejs

WCAG określa kryteria dostępności treści internetowych, a UX i UI zamieniają je w decyzje o ścieżkach, treściach i komponentach. UX, czyli projektowanie doświadczenia użytkownika, porządkuje zadania i przepływ informacji; UI, czyli projektowanie interfejsu, opisuje wygląd, etykiety oraz stany elementów. Zgodność makiety z wybranymi kryteriami nie jest formalną oceną dostępności wdrożonej strony.

WCAG 2.2 grupuje kryteria wokół czterech zasad: postrzegalności, funkcjonalności, zrozumiałości i solidności. Użytkownik powinien móc odebrać informację, obsłużyć interfejs, zrozumieć działanie i korzystać z treści przy użyciu różnych narzędzi. Projektant powinien analizować rzeczywistą treść i interakcję, a nie wyłącznie nieruchomy obraz ekranu. Źródło: W3C, Understanding WCAG 2.2, sprawdzono w październiku 2026 r.

Przekład zasady na implementację powinien mieć cztery jawne elementy: kryterium, decyzję projektową, zachowanie komponentu i test akceptacyjny. Dla przycisku "Dodaj do koszyka" może to wyglądać tak: użytkownik musi rozpoznać działanie, projekt zawiera jednoznaczną etykietę, przycisk jest dostępny z klawiatury, a po aktywacji pojawia się komunikat o dodaniu produktu. Programista wdraża zachowanie, a osoba oceniająca sprawdza cały przebieg na stronie.

Tabela pokazuje, jak zespół przechodzi od kryterium WCAG do dowodu akceptacji na przykładzie przycisku koszyka.

Tabela pokazuje, że samo odnotowanie kryterium nie wystarcza: każdy wymóg potrzebuje zachowania i testu, który da się powtórzyć.

Projektant może sprawdzić kontrast kolorów, etykiety, strukturę nagłówków, widoczny fokus i treść komunikatów. Projekt makiety nie potwierdza semantyki HTML, relacji między etykietą a polem, odczytu statusów przez czytnik ekranu ani działania po błędzie serwera. Formalna ocena wdrożonego serwisu obejmuje zdefiniowany zakres produktu, reprezentatywne widoki i udokumentowane wyniki.

Przegląd przed developmentem ułatwia zmianę hierarchii, treści i stanów komponentu, zanim powstanie wiele zależnych widoków. Jeśli potrzebujesz wyznaczyć zakres kontroli serwisu i uporządkować ryzyka, audyt cyfrowy serwisu pomaga przygotować plan oceny obszarów UX, UI i dostępności.

Zasada postrzegalności wymaga, aby użytkownik mógł odebrać istotną informację za pomocą dostępnego dla siebie kanału. Projektant uwzględnia tekst alternatywny dla treściowych obrazów, kontrast, powiększanie i napisy do materiałów wideo. Tekst alternatywny to tekstowy opis funkcji lub informacji przekazywanej przez obraz; obraz wyłącznie dekoracyjny powinien być pomijany przez technologię asystującą.

Kontrast należy sprawdzać dla każdej pary tekstu i tła oraz dla stanów komponentu, a nie tylko dla kolorów w przewodniku marki. W projekcie warto oddzielić kolor podstawowy, kolor tekstu, tło, obramowanie, fokus, stan błędu i stan wyłączenia. W3C wyjaśnia kryteria kontrastu tekstu i elementów nietekstowych w dokumentacji WCAG 2.2; wymagania zależą od rodzaju treści i kryterium. Źródło: W3C, Understanding WCAG 2.2, sprawdzono w październiku 2026 r.

Powiększenie tekstu i zmiana szerokości widoku mogą ujawnić, czy układ nadal pozwala wykonać zadanie. Tekst nie powinien nachodzić na przyciski, znikać z karty produktu ani wymuszać przewijania w dwóch kierunkach tam, gdzie treść można ułożyć ponownie. Napisy w filmie powinny przekazywać wypowiedzi i ważne dźwięki, a informacja wizualna istotna dla zrozumienia filmu może wymagać dodatkowego opisu.

Tabela odpowiada na pytanie, jakie ryzyko powodują częste decyzje projektowe i jak sprawdzić je przed wdrożeniem. Wynik kontroli zapisz przy konkretnym komponencie i stanie, ponieważ ten sam kolor może mieć różny kontrast na innym tle.

Tabela pomaga powiązać każdy element wizualny z ryzykiem i testem, zamiast traktować kontrast jako jedyną kontrolę postrzegalności.

Makieta powinna pokazywać, jak treść i kolor współpracują ze sobą w stanie zwykłym, fokusie, błędzie i potwierdzeniu. Dla komunikatu o błędnym kodzie pocztowym sam czerwony obrys pola nie wyjaśnia przyczyny; potrzebny jest tekst wskazujący oczekiwany format. Dla zdjęcia produktu opis alternatywny powinien zależeć od jego roli: zdjęcie główne może opisywać cechę, a powtórzone zdjęcie dekoracyjne nie musi dublować treści.

Z perspektywy KC Mobile przegląd kontrastu jest najbardziej użyteczny wtedy, gdy odbywa się na rzeczywistych stanach komponentu i docelowym rozmiarze tekstu. Zalecamy przekazywać developerowi tokeny kolorów wraz z przeznaczeniem i parami tła, aby nowy wariant przycisku nie trafił do interfejsu bez kontroli.

Każde zadanie dostępne za pomocą interfejsu powinno dać się wykonać klawiaturą, a fokus musi pozostać widoczny i nie może utknąć w komponencie. Fokus to wskaźnik pokazujący element, który aktualnie odbiera działanie klawiatury. Podstawowy test wykonujemy klawiszami Tab i Shift+Tab, Enter, Spacja oraz strzałkami, jeśli wzorzec komponentu przewiduje ich użycie.

Kolejność fokusu powinna odpowiadać logicznej kolejności treści i działań, a nie przypadkowej kolejności warstw w makiecie. Pominięcie powtarzalnego bloku, na przykład nawigacji, umożliwia przejście do głównej treści bez wielokrotnego przechodzenia przez te same linki. Po otwarciu menu fokus powinien trafiać do przewidywalnego elementu, a po jego zamknięciu wracać do kontrolki, która je otworzyła.

Scenariusz sklepu powinien obejmować nagłówek, wyszukiwarkę, listę produktów, wybór wariantu, koszyk, dostawę, płatność i potwierdzenie. Sprawdzamy, czy fokus nie znika pod przyklejonym paskiem, czy nie przeskakuje do początku strony po aktualizacji koszyka i czy pole pojawiające się warunkowo jest osiągalne. WCAG 2.2 obejmuje kryteria obsługi klawiaturą, braku pułapki klawiaturowej, kolejności i widoczności fokusu. Źródło: W3C, Understanding WCAG 2.2, sprawdzono w październiku 2026 r.

Scenariusz przejścia przez sklep bez myszy:

1. Otwórz stronę i przejdź Tabem do nawigacji, obserwując każdy widoczny fokus.
2. Otwórz menu, przejdź po pozycjach, zamknij je i potwierdź powrót fokusu.
3. Przejdź do produktu, wybierz wariant i sprawdź, czy zmiana jest czytelna.
4. Dodaj produkt do koszyka, przejdź do checkoutu i uzupełnij wymagane pola.
5. Zmień metodę dostawy, popraw błąd i sprawdź, czy wpisane dane pozostały.
6. Przejdź do podsumowania i potwierdź zamówienie w uzgodnionym środowisku testowym.

Tester zapisuje przeglądarkę, urządzenie, klawisze, ostatni poprawnie osiągnięty element i wynik zadania. Zapis "menu nie działa" nie wystarcza: opis powinien wskazywać, czy fokus utknął, czy element nie reagował na Enter, czy też po zamknięciu menu wrócił w nieprzewidywalne miejsce.

Projekt powinien określać działanie klawiszy dla każdego nietypowego komponentu. W zwykłym przycisku Enter lub Spacja może aktywować działanie, a w menu rozwijanym strzałki mogą przechodzić między pozycjami zgodnie z zastosowanym wzorcem. Nie dodawaj skrótów klawiszowych, które przechwytują pojedyncze litery bez możliwości ich wyłączenia lub zmiany, gdy mogą kolidować z wpisywaniem tekstu.

Dostępny formularz ma widoczną etykietę, instrukcję dla pól wymagających określonego formatu i błąd powiązany z polem, którego dotyczy. Placeholder, czyli podpowiedź widoczna wewnątrz pustego pola, nie powinien być jedyną etykietą, ponieważ znika podczas wpisywania. Wymagane pola i reguły walidacji należy wyjaśnić przed wysłaniem formularza.

Komunikat błędu powinien wskazywać problem i możliwy sposób poprawy. "Wpisz kod pocztowy w formacie 00-000" daje instrukcję, a "Błędne dane" nie identyfikuje pola ani poprawnej wartości. Przy długim formularzu podsumowanie błędów może prowadzić do pól, a po nieudanej walidacji wpisane wcześniej dane powinny pozostać w formularzu.

Każde pole wymaga spójnego zestawu stanów: początkowego, aktywnego, wypełnionego, błędnego i wyłączonego, jeśli występuje. Projektant opisuje kolor, ikonę, treść, widoczną etykietę oraz sposób powiązania błędu z kontrolką. Programista sprawdza semantyczne powiązanie etykiety i opisu błędu, a także to, czy czytnik ekranu informuje o błędzie po jego wystąpieniu.

Treść walidacji należy uzgodnić z zespołem biznesowym, bo poprawny format może zależeć od zasad usługi. Pole na numer telefonu może dopuszczać różne formaty, a formularz fakturowy może wymagać danych, które nie są potrzebne przy zakupie prywatnym. Interfejs powinien wyjaśniać warunek przed wysłaniem, zamiast ujawniać go dopiero po odrzuceniu formularza.

Test formularza obejmuje co najmniej poprawne wysłanie, wysłanie z pustym wymaganym polem, niepoprawny format, błąd po stronie serwera i poprawienie danych po błędzie. W każdym przypadku sprawdzamy, czy komunikat jest blisko pola, czy da się do niego dotrzeć klawiaturą i czy nie znika przed odczytaniem. Jeśli formularz ma kilka kroków, po błędzie zachowujemy kontekst bieżącego kroku i nie zmuszamy użytkownika do ponownego wprowadzania niezwiązanych danych.

Dostępny checkout komunikuje wybrany produkt, wariant, dostawę, płatność i wynik zamówienia bez polegania wyłącznie na zmianie wyglądu. Każdy etap powinien zachować kontekst, pozwolić poprawić dane i wyjaśniać, co jest wymagane do przejścia dalej. Błąd checkoutu może przejść automatyczny skan, a mimo to blokować zakup, jeśli użytkownik nie rozpoznaje zmiany stanu lub nie potrafi wrócić do pola z błędem.

Przy wyborze wariantu należy udostępnić nazwę opcji i aktualne informacje o cenie oraz dostępności. Po zmianie wariantu użytkownik musi wiedzieć, czy zmieniło się zdjęcie, cena lub stan magazynowy; fokus powinien zostać w przewidywalnym miejscu. Jeśli zmiana ujawnia nowe pola, interfejs musi poinformować o nich bez nagłego przenoszenia użytkownika w inną część strony.

Wybór dostawy powinien przekazywać nazwę metody, koszt i termin zgodnie z danymi sklepu. Przy opcji punktu odbioru sprawdzamy, czy jego wybór można wykonać z klawiatury i czy po zamknięciu selektora użytkownik wraca do sensownego miejsca. Zmiana dostawy może aktualizować koszt i sumę zamówienia, więc interfejs powinien zakomunikować nową wartość tekstowo.

Płatność wymaga czytelnych nazw metod i konkretnych błędów. Po powrocie z bramki sklep powinien rozróżniać stan potwierdzony, oczekujący i nieudany, jeśli takie stany występują w procesie. Komunikat "coś poszło nie tak" nie wyjaśnia, czy użytkownik ma ponowić płatność, wybrać inną metodę czy skontaktować się ze sklepem.

Po wysłaniu zamówienia potwierdzenie powinno zawierać informację, że zamówienie zostało przyjęte, oraz wskazać dalsze kroki. Komunikat powinien być dostępny bez przewijania do góry i możliwy do odczytania przez technologię asystującą. Licznik koszyka ani zmiana koloru przycisku nie mogą być jedynym potwierdzeniem dodania produktu.

Perspektywa KC Mobile: test całego checkoutu ujawnia problemy, których nie widać w pojedynczej makiecie. Szczególnej uwagi wymagają pola warunkowe i automatyczna aktualizacja podsumowania, bo potrafią zmienić kolejność treści albo nie przekazać nowej wartości czytnikowi ekranu. Zalecamy przejść całą ścieżkę klawiaturą i osobno sprawdzić odczyt najważniejszych komunikatów.

Przed publikacją sprawdzamy scenariusz pozytywny i co najmniej jeden scenariusz przerwany: nieudaną płatność, brak punktu odbioru lub brak wymaganej zgody. Dla każdego zapisujemy, gdzie trafia fokus, jak brzmi komunikat, które dane pozostają w formularzu i czy użytkownik może kontynuować bez powtórzenia wcześniejszych kroków.

Komponent UI jest przygotowany z myślą o dostępności, gdy jego specyfikacja zawiera nazwę, rolę, stany, obsługę klawiaturą i sposób ogłoszenia zmiany. Komponent to powtarzalny element interfejsu, na przykład przycisk, dialog albo lista rozwijana. Zespół powinien opisać zarówno jego zachowanie w bibliotece, jak i użycie w konkretnej ścieżce.

Tabela pokazuje, co trzeba ustalić dla czterech typowych komponentów. Stan komponentu oznacza sytuację, która wymaga widocznego i programowo rozpoznawalnego zachowania.

Tabela ułatwia opisanie komponentu przed implementacją, ale akceptacja wymaga testu działającej wersji i kontekstu strony.

Przycisk powinien używać etykiety opisującej skutek, na przykład "Zapisz adres", a nie samego "OK", jeśli kilka podobnych przycisków występuje na stronie. Wyłączenie przycisku nie powinno być jedynym wyjaśnieniem, dlaczego użytkownik nie może kontynuować; wymaganie warto opisać przy polu albo przed przyciskiem.

Dialog po otwarciu powinien otrzymać nazwę i przekazać fokus do sensownego miejsca wewnątrz. Użytkownik musi móc go zamknąć przy użyciu dostępnej metody, a po zamknięciu fokus powinien wrócić do elementu, który go otworzył. Okno potwierdzenia usunięcia danych powinno też wyjaśniać skutek działania, zamiast opierać się na samym kolorze przycisku.

Zakładki wymagają informacji, która karta jest wybrana, i powiązania jej z właściwym panelem. Jeśli zastosowany wzorzec wykorzystuje strzałki do zmiany karty, Tab powinien zachowywać logiczną nawigację strony. Lista rozwijana musi przekazywać wybraną wartość również po zamknięciu, a pusta lista powinna wyjaśniać brak dostępnych opcji.

Gotowa biblioteka komponentów nie zapewnia sama z siebie dostępności. Błąd wspólnego komponentu może powtórzyć się na wielu widokach, dlatego testujemy bazowy wzorzec, a po implementacji sprawdzamy jego użycie w koszyku, formularzu i na stronie produktu. Kryterium akceptacji zapisujemy jako obserwowalne zachowanie, na przykład: "Po zamknięciu dialogu fokus wraca na przycisk, który go otworzył".

Dostępność przed publikacją sprawdzamy przez przegląd makiet, test automatyczny, test ręczny i ocenę z technologiami asystującymi. W3C opisuje WCAG-EM jako metodykę definiowania zakresu, poznania produktu, doboru reprezentatywnej próbki, oceny i raportowania wyników. WCAG-EM 2 opublikowano w lipcu 2026 r. i obejmuje również aplikacje oraz inne produkty cyfrowe; wybór metody należy dopasować do zakresu oceny. Źródło: W3C, WCAG-EM Overview, sprawdzono w październiku 2026 r.

Przed przekazaniem makiety do developmentu projektant powinien przejść poniższą procedurę:

1. Wybierz najważniejsze zadania użytkownika, na przykład wyszukiwanie, zakup i kontakt.
2. Zaznacz komponenty oraz wszystkie stany, także błędy i potwierdzenia.
3. Sprawdź kontrast tekstu, komponentów i fokusu w stanie zwykłym oraz aktywnym.
4. Zweryfikuj widoczne etykiety, instrukcje, nagłówki i treść komunikatów.
5. Sprawdź układ po powiększeniu i w wąskim widoku, uwzględniając długie etykiety.
6. Opisz kolejność fokusu i oczekiwany wynik działania klawiaturą.
7. Zapisz nierozstrzygnięte pytania dla programisty i osobę odpowiedzialną za ich akceptację.

Ta procedura pozwala wychwycić ryzyko na etapie projektu, ale nie potwierdza poprawności kodu ani odczytu strony przez czytnik ekranu. Skaner automatyczny, taki jak axe DevTools lub WAVE, może wskazać część problemów z kontrastem, etykietami i strukturą. W3C wyjaśnia, że narzędzia mogą wykrywać problemy i wspierać przegląd, ale nie rozstrzygają wszystkich aspektów dostępności; potrzebna jest ocena człowieka. Źródło: W3C, Selecting Web Accessibility Evaluation Tools, sprawdzono w październiku 2026 r.

Test ręczny obejmuje obsługę klawiaturą, powiększenie, widok wąski, formularze, komunikaty błędów i treść odczytywaną przez czytnik ekranu. Tester zapisuje scenariusz, wynik, urządzenie, przeglądarkę i kryterium, którego dotyczy obserwacja. Test z osobą korzystającą z technologii asystującej może ujawnić problemy użyteczności, których nie rozstrzyga sama kontrola zgodności; W3C opisuje udział użytkowników jako uzupełnienie oceny zgodności. Źródło: W3C, Involving Users in Evaluating Web Accessibility, sprawdzono w październiku 2026 r.

Zakres oceny sklepu powinien obejmować typy stron i stany, które prowadzą do zakupu: stronę główną, listę produktów, kartę produktu, koszyk, checkout oraz komunikaty systemowe. Jeśli te widoki korzystają ze wspólnych komponentów, test próbki powinien objąć różne warianty komponentu, a nie tylko pierwszy widok. Wynik jednej podstrony nie uzasadnia deklaracji o całym sklepie.

Raport powinien podawać zakres, wersję serwisu, zastosowaną metodę, sprawdzone widoki, narzędzia, wynik i ograniczenia testu. W3C udostępnia strukturę raportowania oceny dostępności, a WCAG-EM Report Tool służy do porządkowania wyników pracy osoby oceniającej i nie wykonuje automatycznego skanowania. Źródła: W3C, Template for Accessibility Evaluation Reports oraz WCAG-EM Report Tool, sprawdzono w październiku 2026 r. Jeśli potrzebujesz niezależnej oceny zakresu i kolejności prac, audyt dostępności serwisu może zebrać bariery z kilku ścieżek w jeden plan.

Poprawki dostępności priorytetyzujemy według wpływu na wykonanie zadania, zasięgu problemu i kosztu zmiany. Problem, który uniemożliwia wybór dostawy albo wysłanie formularza, wymaga szybszej reakcji niż niespójność dekoracyjna. Każda poprawka powinna mieć właściciela, kryterium akceptacji, miejsce występowania i test regresji.

Zespół może porządkować problemy w cztery grupy:

• Blokada zadania: użytkownik nie może zalogować się, wysłać formularza albo zakończyć zakupu.
• Utrudnienie: użytkownik może kontynuować, ale musi wykonać dodatkowe lub nieoczywiste działanie.
• Zasięg: błąd występuje we wspólnym komponencie albo na pojedynczym widoku.
• Koszt naprawy: zmiana wymaga poprawy treści, biblioteki UI, kodu aplikacji lub integracji zewnętrznej.

Naprawę warto grupować według wspólnego źródła, na przykład stylu fokusu, komunikatu błędu albo wzorca formularza. Poprawienie wspólnego komponentu może usunąć problem na wielu podstronach, ale zmiana może też wpłynąć na inne miejsca użycia. Po wdrożeniu testujemy pierwotny błąd oraz sąsiednie scenariusze.

Efekt mierzymy przez powtórzenie tego samego testu w tych samych warunkach. Zespół porównuje, czy użytkownik może wykonać zadanie, czy komunikat jest dostępny i czy inne stany komponentu nadal działają. Dane analityczne, takie jak porzucenie formularza na konkretnym etapie, mogą wskazać miejsce wymagające diagnozy, ale same nie dowodzą, że przyczyną jest bariera dostępności.

Lista problemów powinna zawierać identyfikator, widok, komponent, opis wpływu, sposób odtworzenia, kryterium akceptacji, właściciela i status. Po każdej zmianie komponentu wykonujemy test regresji w ścieżkach, które z niego korzystają. Dzięki temu zespół może odróżnić naprawę potwierdzoną testem od poprawki, która została jedynie wdrożona.

Plan oceny kilku ścieżek i kolejności prac można ułożyć w ramach audytu cyfrowego KC Mobile, jeśli zespół potrzebuje wspólnego zakresu dla UX, UI i dostępności.

• Jak przygotować stronę internetową pod dostępność cyfrową WCAG
• Audyt WCAG WordPress: praktyczna kontrola dostępności strony krok po kroku
• Jak przygotować sklep Shoper do wymogów WCAG i Europejskiego Aktu o Dostępności
• Information architecture: 7 błędów, które ograniczają dostępność