Najważniejsze wnioski
- Rozdział 9 normy odsyła do WCAG 2.1 na poziomie A i AA, ale nie wyczerpuje jej zakresu.
- Dokumenty poza stroną, takie jak faktury i regulaminy w PDF, mają własne wymagania.
- Aplikacja mobilna sklepu podlega wymaganiom dla oprogramowania.
- Dokumentacja i wsparcie użytkownika, w tym obsługa klienta, również mieszczą się w zakresie normy.
Dla zarządzającego
Zakres prac jest szerszy niż sama strona. Zaplanuj przegląd aplikacji mobilnej, dokumentów PDF i kanałów obsługi klienta, a nie tylko serwisu.
Dla sprzedaży
Jeżeli klient mówi „mamy WCAG 2.1 AA”, zapytaj o faktury PDF, aplikację i infolinię. To zwykle otwiera rozmowę o realnym zakresie.
W rozmowach o wymaganiach technicznych EN 301 549 pojawia się prawie zawsze w jednym kontekście: „rozdział 9 odsyła do WCAG 2.1 AA”. To prawda i to najważniejszy pojedynczy fakt o tej normie. Jest też jednak połowa obrazu.
Norma dotyczy produktów i usług ICT, a nie wyłącznie treści webowych. Dla sklepu internetowego oznacza to co najmniej trzy dodatkowe obszary, które zwykle nie trafiają do briefu dla agencji.
Co dokładnie mówi rozdział 9
W wersji V3.2.1 z marca 2021 r. rozdział 9 obejmuje treści webowe i odwołuje się do WCAG 2.1 na poziomach A i AA. Zgodność z WCAG 2.1 AA odpowiada spełnieniu wymagań klauzul od 9.1 do 9.4 oraz warunków zgodności z klauzuli 9.6. Relacje między tymi dokumentami rozkładamy na czynniki pierwsze w tekście o WCAG 2.1, WCAG 2.2 i EN 301 549.
To wyjaśnia, dlaczego skrót „WCAG 2.1 AA” jest tak popularny. Wyjaśnia też, dlaczego bywa mylący: spełnienie rozdziału 9 nie oznacza spełnienia całej normy, jeżeli usługa obejmuje więcej niż stronę internetową.
Warstwa druga: aplikacja mobilna
Aplikacja mobilna sklepu to oprogramowanie, a norma zawiera odrębne wymagania dla oprogramowania. Kryteria WCAG stosuje się do niej odpowiednio, ale dochodzą kwestie typowe dla platformy: współpraca z systemowym czytnikiem ekranu, respektowanie systemowych ustawień rozmiaru czcionki i ograniczenia ruchu, obsługa gestów oraz zachowanie przy zmianie orientacji ekranu.
W praktyce aplikacja bywa najsłabszym ogniwem, ponieważ powstaje w innym zespole niż strona, często u innego dostawcy, i rzadko trafia do tego samego audytu.
Warstwa trzecia: dokumenty poza stroną
Faktura PDF, potwierdzenie zamówienia, regulamin do pobrania, instrukcja produktu, karta gwarancyjna — to wszystko są dokumenty poza stroną i norma traktuje je odrębnie od treści webowych.
Typowy problem: faktura generowana jako obraz osadzony w PDF. Dla osoby korzystającej z czytnika ekranu jest to pusta kartka. Podobnie regulamin wyeksportowany z edytora bez struktury nagłówków — formalnie dostępny do pobrania, praktycznie nie do przejrzenia.
| Element sklepu | Obszar normy | Najczęstszy problem |
|---|---|---|
| Strona sklepu | Treści webowe | Formularze i komunikaty błędów |
| Aplikacja mobilna | Oprogramowanie | Brak współpracy z czytnikiem systemowym |
| Faktura i potwierdzenie PDF | Dokumenty poza stroną | Skan lub obraz zamiast tekstu |
| Pomoc i FAQ | Dokumentacja | Treść wyłącznie w plikach do pobrania |
| Infolinia i czat | Wsparcie użytkownika | Brak alternatywnego kanału kontaktu |
Warstwa czwarta: dokumentacja i wsparcie
Norma obejmuje również dokumentację produktu oraz usługi wsparcia użytkownika. Dla sklepu oznacza to pomoc, FAQ, instrukcje zwrotu — a także kanały obsługi klienta.
Praktyczna konsekwencja jest prosta i często zaskakuje: jeżeli jedynym sposobem kontaktu jest czat, który nie działa z klawiaturą, to problem nie kończy się na czacie. Kończy się na tym, że użytkownik nie ma jak zgłosić żadnego innego problemu. Dlatego alternatywny kanał kontaktu jest tak istotny.
Sklep, który ma dostępną stronę i niedostępną fakturę, przeprowadził klienta przez cały proces zakupu po to, żeby zatrzymać go na ostatnim kroku.
Scenariusz: audyt, który zatrzymał się na stronie
Rozważmy scenariusz sklepu, który zamawia audyt i dostaje dobry wynik dla serwisu. Ścieżka zakupowa działa z klawiaturą, formularze mają etykiety, kontrast jest poprawiony. Zespół uznaje temat za zamknięty.
Trzy miesiące później przychodzi zgłoszenie od klienta korzystającego z czytnika ekranu: nie jest w stanie odczytać faktury, bo generator wystawia ją jako obraz. Przy okazji okazuje się, że aplikacja mobilna nie ma opisów przycisków w koszyku, a jedyny szybki kanał kontaktu to czat bez obsługi klawiatury.
Audyt nie był zły. Był po prostu zamówiony na jedną warstwę z czterech — bo brief mówił „sprawdźcie stronę”.
Jak rozszerzyć zakres bez rozdmuchania budżetu
Nie trzeba robić wszystkiego naraz. Sensowna kolejność to: najpierw ścieżka zakupowa na stronie według checklisty dostępności sklepu, potem dokumenty, które klient dostaje po zakupie, potem aplikacja mobilna, jeśli istnieje, a na końcu kanały wsparcia.
Dokumenty warto wziąć wcześnie, bo poprawka jest zwykle tania: wystarczy, żeby generator wystawiał tekst zamiast obrazu i żeby regulamin miał strukturę nagłówków. Kontekst prawny dla całości opisujemy w przewodniku po PAD dla e-commerce, a ustalenie zakresu obowiązków w tekście o tym, czy PAD dotyczy sklepu online. Funkcje wspierające, które można udostępnić od razu, opisujemy przy instalacji WCAGbot.
Cztery warstwy sklepu w zasięgu normy
Jak zapisać zakres w briefie dla wykonawcy
Większość audytów kończy się na stronie nie dlatego, że wykonawca zrobił coś źle, lecz dlatego, że tak brzmiało zlecenie. Brief „sprawdźcie dostępność naszej strony” dostanie odpowiedź dokładnie o stronie.
Wystarczy wymienić warstwy wprost: serwis wraz ze ścieżką zakupową, aplikacja mobilna, dokumenty generowane po zakupie, materiały pomocy oraz kanały kontaktu z obsługą. Przy każdej warstwie warto dopisać, czy ma być objęta tym zleceniem, czy świadomie odkładana na później — i w drugim przypadku zanotować termin.
Taki brief kosztuje pięć minut, a rozwiązuje najczęstszy problem projektów dostępnościowych: przekonanie, że temat został zamknięty, podczas gdy sprawdzono jedną czwartą zakresu.
Najtańsze poprawki poza stroną
Dobra wiadomość jest taka, że warstwy poza serwisem bywają tańsze do naprawienia niż sam serwis, ponieważ problem tkwi zwykle w jednym miejscu.
Faktura generowana jako obraz to zwykle kwestia konfiguracji generatora — po zmianie ustawień wszystkie kolejne dokumenty zawierają warstwę tekstową. Regulamin bez struktury nagłówków poprawia się raz, w źródłowym dokumencie. Brakujący alternatywny kanał kontaktu to dopisanie adresu e-mail i telefonu obok czatu.
Trzy takie poprawki potrafią zająć jedno popołudnie, a usuwają bariery, które dotykają klienta dokładnie w momencie, gdy właśnie u Ciebie kupił. To zwykle najlepszy stosunek efektu do kosztu w całym projekcie.
Warto na koniec zaznaczyć jedną rzecz: kolejność warstw nie jest przypadkowa. Strona dotyczy wszystkich odwiedzających, dokumenty po zakupie dotyczą wszystkich kupujących, aplikacja dotyczy części z nich, a kanały wsparcia dotyczą tych, którzy już napotkali problem. Porządkowanie prac według liczby dotkniętych osób daje zwykle lepszy efekt niż porządkowanie ich według kolejności rozdziałów w normie.
Na koniec uwaga o dostawcach zewnętrznych. Faktury generuje zwykle system księgowy, aplikację mobilną buduje inny zespół, czat pochodzi od dostawcy zewnętrznego. Oznacza to, że część poprawek nie leży po Twojej stronie — ale zgłoszenie ich dostawcy już tak. Warto wpisać wymagania dostępności do rozmów przy odnowieniu umowy; to moment, w którym dostawca faktycznie słucha, a koszt zmiany jest po jego stronie.
Jest jeszcze jeden powód, dla którego warto wyjść poza stronę: warstwy pozawebowe dotykają klientów w momentach o największej wadze. Faktura, potwierdzenie zamówienia i kontakt z obsługą pojawiają się wtedy, gdy transakcja już się odbyła i gdy klient ma najmniej cierpliwości do przeszkód. Bariera na tym etapie kosztuje nie tylko jedno zamówienie, ale też zaufanie do kolejnego zakupu — a to jest strata trudniejsza do odrobienia niż porzucony koszyk.
Najczęstsze pytania
Czy zgodność z WCAG 2.1 AA wystarcza do spełnienia normy?
Odpowiada wymaganiom rozdziału 9 dla treści webowych. Jeżeli usługa obejmuje aplikację, dokumenty poza stroną albo wsparcie użytkownika, te obszary ocenia się dodatkowo.
Czy faktura PDF podlega wymaganiom?
Dokumenty poza stroną mają w normie własne wymagania. Faktura będąca obrazem bez warstwy tekstowej jest typowym problemem.
Czy aplikacja mobilna wymaga osobnego audytu?
Zwykle tak. Powstaje w innym środowisku, ma inne mechanizmy dostępności i rzadko jest objęta audytem strony.
Co z czatem obsługi klienta?
Jeżeli czat jest jedynym kanałem kontaktu i nie da się go obsłużyć klawiaturą, użytkownik traci możliwość zgłoszenia czegokolwiek. Alternatywny kanał jest konieczny.
Która wersja normy obowiązuje?
Wersja V3.2.1 z marca 2021 r. jest tą, która odsyła do WCAG 2.1 AA. Przy dokumentacji zgodności sprawdź, jaka wersja jest przywołana w odniesieniu do Twojego obowiązku.
Czy widget dostępności pomaga w tych warstwach?
Działa w przeglądarce, więc nie obejmuje aplikacji mobilnej, dokumentów PDF ani infolinii. Granice opisujemy w tekście o widgecie a zgodności z WCAG.
Od czego zacząć przy ograniczonym budżecie?
Od ścieżki zakupowej na stronie, potem od dokumentów po zakupie. Te dwa obszary dotyczą największej liczby klientów.
Czy norma dotyczy też treści marketingowych?
Materiały publikowane w serwisie są treścią webową i mieszczą się w rozdziale 9. Materiały do pobrania traktuje się jak dokumenty poza stroną.
