Najważniejsze wnioski
- Cztery zasady porządkują wszystkie kryteria WCAG i ułatwiają diagnozę problemu.
- Każdą zasadę da się sprawdzić na konkretnym elemencie sklepu bez znajomości numerów kryteriów.
- Większość barier w e-commerce mieści się w zasadach funkcjonalności i zrozumiałości.
- Nazwanie zasady, której dotyczy problem, przyspiesza ustalenie, kto ma go naprawić.
Dla zarządzającego
Cztery zasady to najprostszy język, w którym zespół techniczny, treściowy i obsługa klienta mogą rozmawiać o tym samym problemie.
Dla sprzedaży
Zamiast numerów kryteriów pokaż klientowi jeden przykład z każdej zasady na jego własnej stronie. Rozmowa robi się konkretna w minutę.
Kryteriów sukcesu w WCAG jest kilkadziesiąt i mało kto pamięta ich numery. Cztery zasady, na których cały dokument się opiera, pamięta się jednak bez trudu — a w codziennej pracy okazują się przydatniejsze niż numeracja.
Ich największa zaleta jest praktyczna: pozwalają w kilka sekund ustalić, czego problem dotyczy i kto powinien go naprawić. Poniżej każda z nich na konkretnym elemencie sklepu.
Postrzegalność: czy użytkownik w ogóle to odbierze
Informacja musi być przedstawiona w sposób możliwy do odebrania — również wtedy, gdy użytkownik nie widzi obrazu, nie rozróżnia kolorów albo nie słyszy dźwięku.
W sklepie ta zasada mieszka przede wszystkim w karcie produktu. Zdjęcie bez opisu alternatywnego to brak informacji dla osoby korzystającej z czytnika ekranu. Próbka koloru oznaczona wyłącznie kolorem to brak informacji dla osoby, która tego koloru nie rozróżnia. Cena umieszczona na grafice promocyjnej znika dla obu tych grup.
Typowa naprawa: opisy alternatywne mówiące, co jest na zdjęciu, nazwy wariantów obok próbek kolorów, ceny i warunki promocji jako tekst.
Funkcjonalność: czy użytkownik może tego użyć
Elementy interfejsu muszą dać się obsłużyć — nie tylko myszą i nie tylko w narzuconym czasie.
To zasada, w którą uderza większość barier w e-commerce. Wybór wariantu działający wyłącznie po najechaniu kursorem. Okno modalne z rozmiarówką, które zatrzymuje fokus i nie zamyka się klawiszem Esc. Licznik czasu na dokończenie płatności, którego nie da się wydłużyć. Karuzela promocji przewijająca się automatycznie bez możliwości zatrzymania.
Test jest banalny: przejdź całą ścieżkę zakupową używając wyłącznie klawiatury. Szczegółową listę miejsc do sprawdzenia zestawiamy w checkliście dostępności sklepu internetowego.
Zrozumiałość: czy użytkownik wie, co się dzieje
Treść i działanie interfejsu muszą być zrozumiałe i przewidywalne.
W sklepie ta zasada rozstrzyga się w formularzu zamówienia. Komunikat „błąd formularza” nie mówi, które pole poprawić. Czerwona ramka bez tekstu nie mówi nic osobie, która tej czerwieni nie rozróżnia. Pole „numer” bez etykiety pozostawia użytkownika w domyśle, czy chodzi o numer domu, telefonu czy zamówienia.
Do tej samej zasady należy przewidywalność: menu, które zmienia kolejność na różnych podstronach, i formularz, który wysyła się sam po wybraniu opcji z listy, zaskakują każdego użytkownika, a części z nich uniemożliwiają dokończenie zakupu.
Solidność: czy technologie asystujące to odczytają
Treść musi być na tyle solidnie zbudowana, żeby mogły ją poprawnie zinterpretować różne programy użytkownika, w tym technologie asystujące.
W praktyce chodzi tu najczęściej o nazwy dostępne kontrolek i o poprawne używanie atrybutów ARIA. Przycisk zbudowany z elementu div bez nazwy jest dla czytnika ekranu bezimienny. Atrybut ARIA użyty niepoprawnie potrafi zaszkodzić bardziej niż jego brak, bo zgłasza stan niezgodny z rzeczywistością.
| Zasada | Pytanie diagnostyczne | Typowy problem w sklepie | Kto naprawia |
|---|---|---|---|
| Postrzegalność | Czy da się to odebrać? | Zdjęcie produktu bez opisu | Zespół treści |
| Funkcjonalność | Czy da się tego użyć? | Okno rozmiarówki bez obsługi klawiatury | Zespół techniczny |
| Zrozumiałość | Czy da się to zrozumieć? | Komunikat błędu bez wskazania pola | Treść i technika wspólnie |
| Solidność | Czy technologie to odczytają? | Przycisk bez nazwy dostępnej | Zespół techniczny |
Nie musisz pamiętać, że to kryterium 3.3.1. Wystarczy, że powiesz: „użytkownik nie rozumie, co poszło nie tak”. Reszta to już tylko szukanie numeru.
Scenariusz: cztery pytania na jednym ekranie
Rozważmy scenariusz przeglądu karty produktu. Zespół zadaje cztery pytania po kolei. Czy da się to odebrać? — zdjęcia mają opisy, ale dostępność wariantu oznaczona jest wyłącznie szarym tłem próbki. Czy da się tego użyć? — wybór rozmiaru działa myszą, klawiaturą już nie. Czy da się to zrozumieć? — po dodaniu do koszyka nie pojawia się żaden komunikat, zmienia się tylko licznik w rogu. Czy technologie to odczytają? — przycisk powiększenia zdjęcia nie ma nazwy.
Cztery pytania, cztery znaleziska, każde od razu przypisane do właściwego zespołu. Ten sam przegląd zrobiony bez struktury kończy się listą uwag, o której nikt nie wie, kto ma ją zrealizować.
Jak używać tego na co dzień
Zasady sprawdzają się jako wspólny język między zespołami i jako pierwszy filtr przy zgłoszeniach od użytkowników. Kiedy przychodzi wiadomość „nie mogę dokończyć zamówienia”, cztery pytania zwykle wystarczą, żeby ustalić, gdzie leży problem.
Którą zasadę narusza ten problem
Warto też wiedzieć, czego zasady nie rozstrzygną: tego, czy proces ma sensowną liczbę kroków i czy język opisu jest zrozumiały dla przeciętnego klienta. Kontekst wersji i norm opisujemy w tekście o WCAG 2.1, WCAG 2.2 i EN 301 549, a granice tego, co złagodzi warstwa prezentacji, w tekście o widgecie a zgodności z WCAG. Funkcje panelu, które dotyczą głównie postrzegalności, opisujemy w przeglądzie kontrastu, tekstu i czytania treści, a kontekst obowiązków w przewodniku po PAD.
Jak wprowadzić te pytania do pracy zespołu
Cztery zasady najlepiej działają wtedy, gdy przestają być wiedzą teoretyczną, a stają się rutyną. Dwa miejsca sprawdzają się najlepiej.
Przy projektowaniu nowego elementu. Zanim komponent trafi do implementacji, ktoś zadaje cztery pytania: czy informację da się odebrać bez patrzenia na kolor, czy element da się obsłużyć klawiaturą, czy jego zachowanie jest przewidywalne i czy ma nazwę, którą odczyta czytnik ekranu. Odpowiedzi na etapie projektu kosztują minuty. Te same odpowiedzi po wdrożeniu kosztują sprint.
Przy obsłudze zgłoszenia. Kiedy przychodzi wiadomość „nie mogę dokończyć zamówienia”, cztery pytania zamieniają ogólną skargę w konkretne zadanie dla właściwego zespołu, zanim ktokolwiek zacznie zgadywać.
Czego zasady nie rozstrzygną
Warto od razu wiedzieć, gdzie ta metoda się kończy. Cztery zasady i oparte na nich kryteria są testowalne, więc świadomie pomijają rzeczy trudne do jednoznacznej oceny.
Nie odpowiedzą na pytanie, czy proces zakupowy ma sensowną liczbę kroków. Nie ocenią, czy opis produktu jest napisany językiem zrozumiałym dla przeciętnego klienta. Nie rozstrzygną, czy formularz zbiera dane, które naprawdę są potrzebne. Sklep może spełniać wszystkie kryteria na poziomie AA i nadal być uciążliwy w obsłudze.
Dlatego test z udziałem realnych użytkowników, w tym osób korzystających z technologii asystujących, pozostaje uzupełnieniem, którego nie zastąpi żadna lista kontrolna. Zasady pilnują podłogi. Sufit wyznacza obserwacja tego, jak ludzie faktycznie kupują. Kontekst obowiązków opisujemy w przewodniku po PAD, a ustalenie ich zakresu w tekście o tym, czy PAD dotyczy sklepu online.
Jeżeli miałbyś zapamiętać z tego tekstu tylko jedno, niech to będą cztery pytania w kolejności: czy da się to odebrać, czy da się tego użyć, czy da się to zrozumieć, czy technologie to odczytają. Zadane na dowolnym ekranie sklepu wystarczają, żeby w minutę ustalić, czy problem istnieje i kto ma go naprawić.
Warto na koniec zauważyć, że te same cztery pytania działają poza sklepem. Sprawdzają się przy ocenie panelu administracyjnego, wewnętrznego narzędzia dla zespołu, prezentacji dla klienta czy wiadomości e-mail wysyłanej po zamówieniu. Wszędzie tam, gdzie ktoś ma coś odebrać, obsłużyć i zrozumieć, ta sama struktura porządkuje myślenie — i tym właśnie różni się od listy kryteriów, którą trzeba mieć pod ręką.
Najczęstsze pytania
Czy trzeba znać numery kryteriów?
Do codziennej pracy nie. Numery przydają się w dokumentacji zgodności, ale do diagnozy wystarczą cztery zasady.
Która zasada sprawia w sklepach najwięcej problemów?
Najczęściej funkcjonalność i zrozumiałość, ponieważ dotyczą koszyka, formularza i komunikatów błędów, czyli miejsc, w których kończy się zakup.
Czy postrzegalność to tylko kwestia opisów zdjęć?
Nie. Obejmuje także kontrast, wykorzystanie koloru jako jedynego nośnika informacji oraz alternatywy dla materiałów dźwiękowych i wideo.
Co oznacza solidność w praktyce?
Że kontrolki mają nazwy dostępne, a stan interfejsu jest zgłaszany technologiom asystujących zgodnie ze stanem faktycznym.
Czy ARIA zawsze poprawia dostępność?
Nie. Niepoprawnie użyta potrafi zaszkodzić bardziej niż jej brak, bo przekazuje nieprawdziwe informacje o roli lub stanie elementu.
Jak szybko sprawdzić funkcjonalność?
Przechodząc ścieżkę zakupową wyłącznie klawiaturą, od wyszukania produktu po potwierdzenie zamówienia.
Czy te zasady dotyczą też aplikacji mobilnej?
Tak, stosuje się je odpowiednio, choć aplikacja ma dodatkowe wymagania wynikające z platformy.
Czy widget dostępności pokrywa którąś z zasad?
Głównie postrzegalność, w zakresie prezentacji. Funkcjonalność, zrozumiałość i solidność wymagają pracy w kodzie i treści.
