Najważniejsze wnioski
- Audyt WCAG należy zamawiać dla konkretnie zdefiniowanego produktu, wersji, zakresu funkcji i momentu badania, a nie dla samej domeny.
- Brief powinien wskazywać standard, poziom zgodności, reprezentatywną próbę widoków oraz krytyczne scenariusze, takie jak logowanie, formularz, koszyk i płatność.
- Skan automatyczny jest pomocny, ale nie zastępuje testów manualnych, klawiaturą, technologiami asystującymi ani oceny zachowania komponentów dynamicznych.
- Odbiór audytu powinien obejmować użyteczny raport, priorytety napraw, wskazanie kryteriów WCAG, dowody błędów i zasady retestu.
- Widget dostępności może być szybkim pierwszym krokiem wspierającym użytkowników, ale nie zastępuje audytu ani trwałej naprawy barier w kodzie, projekcie i treści.
Dla zarządzającego
Audyt WCAG jest narzędziem do zarządzania ryzykiem produktowym i jakością obsługi, jeśli obejmuje procesy o znaczeniu biznesowym oraz kończy się możliwym do wdrożenia planem napraw i retestem.
Dla sprzedaży
W rozmowie z klientem warto ustalić, jakie zadania użytkownik ma wykonać bez bariery: znaleźć ofertę, założyć konto, wysłać formularz, kupić produkt lub uzyskać pomoc. Te zadania powinny wejść do zakresu audytu.
Audyt WCAG warto zamówić jako badanie konkretnego produktu i konkretnych zadań użytkownika, a nie jako ogólne „sprawdzenie strony”. Dobry brief określa, co będzie badane, według jakiego standardu, na jakich urządzeniach i w jakim formacie mają zostać przekazane wyniki. Dzięki temu raport może stać się planem pracy dla UX, redakcji, programistów i osób odpowiedzialnych za e-commerce.
Ten artykuł ma charakter informacyjny, a nie porady prawnej. Stan źródeł technicznych: 12 grudnia 2024 r. dla WCAG 2.2. [DO WERYFIKACJI: jeżeli audyt ma służyć konkretnemu obowiązkowi prawnemu lub postępowaniu zakupowemu, potwierdź aktualne wymagania z prawnikiem oraz właściwą instytucją.]
Najważniejsze wnioski
- Podaj nie tylko domenę, ale też środowiska, role użytkowników, integracje i procesy dostępne po zalogowaniu.
- Wskaż wersję WCAG oraz poziom zgodności; dla wielu nowych projektów praktycznym punktem odniesienia jest WCAG 2.2 na poziomie AA.
- Wymagaj testów manualnych oraz testów klawiaturą i technologiami asystującymi, nie tylko raportu z automatu.
- Ustal format raportu, zasady priorytetyzacji błędów, termin retestu i kryteria zamknięcia zgłoszeń.
- Odróżniaj audyt WCAG od funkcji wspierających dostępność dostępnych w widżecie.
Dlaczego hasło „proszę o audyt WCAG strony” nie wystarcza?
Domena może obejmować kilka serwisów, subdomen, szablonów, wersji językowych, panel klienta, moduł płatności, osadzone mapy, dokumenty PDF oraz elementy dostarczane przez zewnętrznych dostawców. Sam adres nie mówi również, czy wykonawca ma sprawdzić tylko stronę główną, czy pełną ścieżkę zakupu wraz z błędami walidacji.
W3C podkreśla, że automatyczne narzędzia są użyteczne, lecz nie są w stanie samodzielnie ustalić zgodności ze standardem. Nie ocenią rzetelnie między innymi sensowności tekstów linków, logiki kolejności fokusu, zrozumiałości komunikatu błędu ani faktycznej obsługi złożonego modala przez czytnik ekranu.
Audyt jest wartościowy wtedy, gdy osoba odpowiedzialna za poprawkę wie: gdzie leży bariera, kogo blokuje, dlaczego występuje i jak sprawdzić, że została usunięta.
To szczególnie ważne w sklepie. O tym, jakie obszary najczęściej wymagają sprawdzenia, przeczytasz w materiale Dostępność sklepu internetowego – checklista pierwszych kroków. Przy planowaniu zakresu warto też znać cztery zasady WCAG na przykładzie sklepu internetowego.
Co wpisać do briefu audytu WCAG?
1. Określ cel, decyzję i odbiorców raportu
Najpierw nazwij powód badania. Celem może być odbiór redesignu, przygotowanie backlogu napraw, ocena nowej ścieżki zakupu, weryfikacja serwisu przed publikacją albo sprawdzenie efektów wcześniejszych prac. Cel determinuje próbę, szczegółowość raportu i potrzebę retestu.
W briefie wskaż, kto wykorzysta wyniki: zespół frontend, UX, redakcja, właściciel produktu, agencja lub dział compliance. Raport dla zarządu może mieć krótkie podsumowanie ryzyk, ale zespół wdrożeniowy potrzebuje instrukcji odtwarzalnych w konkretnym komponencie.
2. Opisz zakres produktu, a nie tylko listę URL-i
Wymień domeny, subdomeny, środowisko testowe i produkcyjne, aplikacje webowe, wersje mobilne oraz system CMS lub framework, jeśli ta informacja może pomóc w zaplanowaniu badania. Zaznacz, które części nie są dostępne publicznie, i przekaż bezpieczny sposób uzyskania kont testowych.
WCAGbot Accessibility Path: od briefu do retestu
Zakres powinien obejmować także elementy pochodzące od dostawców zewnętrznych: bramkę płatniczą, CAPTCHA, czat, mapę, system rezerwacji, player wideo czy narzędzie zgód. Nie oznacza to, że każdą cudzą usługę da się naprawić po stronie właściciela serwisu. Audyt powinien jednak jasno rozróżniać: błąd własnego rozwiązania, ograniczenie integracji i element poza uzgodnionym zakresem.
3. Zdefiniuj scenariusze użytkownika
Reprezentatywna próba nie polega na losowym wyborze wielu podstron. Powinna obejmować różne typy szablonów, komponentów i stanów interfejsu. W e-commerce krytyczne są zazwyczaj wyszukiwanie, filtracja, karta produktu, warianty, koszyk, formularz adresowy, wybór dostawy, płatność, potwierdzenie zakupu oraz konto klienta.
| Element briefu | Co doprecyzować | Przykład kryterium odbioru |
|---|---|---|
| Zakres | Domeny, role, środowiska, integracje | Raport wskazuje badane i wyłączone obszary |
| Standard | Wersja WCAG, poziom, EN 301 549 | Każdy problem ma odniesienie do kryterium |
| Próba | Szablony, komponenty, stany błędów | Próba obejmuje krytyczne ścieżki użytkownika |
| Metodyka | Automaty, test manualny, klawiatura, czytnik | Raport opisuje metody i konfiguracje testowe |
| Raport | Dowody, wpływ, priorytet, rekomendacja | Każdy błąd jest możliwy do odtworzenia |
| Retest | Zakres, termin, liczba rund | Status poprawki potwierdzony po wdrożeniu |
Jeżeli formularze są ważną częścią usługi, poproś o osobne sprawdzenie etykiet, instrukcji, komunikatów błędów, podsumowania błędów i zachowania po wysłaniu formularza. Temat rozwija artykuł o nagłówkach i linkach na stronie zrozumiałej bez wzroku, ponieważ struktura i nazwy elementów są podstawą orientacji użytkownika.
Jaki standard wskazać: WCAG, EN 301 549 czy PAD?
Te pojęcia nie są tożsame. WCAG to wytyczne W3C dotyczące dostępności treści internetowych. EN 301 549 to europejska norma obejmująca wymagania dostępności dla produktów i usług ICT, szersze niż same treści WWW. Polski Akt o Dostępności (PAD) to ustawa wdrażająca wymagania Europejskiego Aktu o Dostępności do polskiego porządku prawnego.
Brief techniczny może przyjąć WCAG 2.2 AA jako wymaganie projektowe, a jednocześnie wymagać mapowania istotnych ustaleń do EN 301 549 lub wymagań mających zastosowanie do danego produktu. Nie należy automatycznie sprowadzać obowiązków PAD wyłącznie do WCAG 2.1 AA. Kontekst wyjaśniają teksty: WCAG 2.1, WCAG 2.2 i EN 301 549 – czym się różnią oraz EN 301 549 dla e-commerce: wymagania poza samym WCAG.
Jakiej metodyki wymagać od wykonawcy?
Dobry opis metodyki powinien zawierać co najmniej testy automatyczne, ocenę manualną, test klawiaturą bez myszy, sprawdzenie fokusu, testy formularzy oraz testy z wybranymi technologiami asystującymi. W zależności od produktu warto uzgodnić również powiększenie, reflow, responsywność, orientację mobilną, multimedia i dokumenty.
Nie chodzi o stworzenie bardzo długiej listy przeglądarek bez uzasadnienia. Chodzi o podanie konfiguracji, które wykonawca rzeczywiście wykorzysta, oraz opisanie ograniczeń testu. Przykładowo można uzgodnić badanie klawiaturą, NVDA z Chrome, VoiceOver z Safari oraz mobilny proces zakupu. Zakres powinien wynikać z urządzeń i rynku produktu.
W osobnym punkcie wymagaj testu kolejności fokusu, widoczności fokusu i obsługi wszystkich interaktywnych komponentów bez myszy. Praktyczną procedurę dla zespołu opisuje artykuł Nawigacja klawiaturą: test strony bez myszy w 15 minut. Jeśli serwis używa niestandardowych komponentów, istotna będzie również ocena semantyki oraz ARIA; zobacz ARIA bez pułapek: kiedy pomaga, a kiedy psuje dostępność.
Skan automatyczny a pełny audyt WCAG
WCAGbot Accessibility Path: jak przejść od badania do poprawy?
Nazwany schemat WCAGbot Accessibility Path pomaga uporządkować pracę po audycie: najpierw cel i zakres, potem reprezentatywna próba oraz badanie, następnie priorytetyzacja, naprawa źródłowa i retest. Widget może działać równolegle jako pierwszy krok wspierający użytkownika, lecz nie może być kryterium zamknięcia błędu wykrytego w audycie.
- Ustal cel: określ, czy oceniasz produkt, redesign czy konkretny proces.
- Wybierz próbę: uwzględnij typy stron oraz warianty i stany interfejsu.
- Przeprowadź badanie: połącz automaty, ocenę manualną i technologie asystujące.
- Ustal priorytety: najpierw bariery blokujące realizację krytycznego zadania.
- Napraw źródłowo: popraw kod, komponent, treść lub proces.
- Wykonaj retest: potwierdź wynik na wdrożonej wersji.
Jakie kryteria odbioru raportu wpisać do zamówienia?
Nie odbieraj raportu wyłącznie na podstawie liczby znalezionych błędów. Niska liczba nie musi oznaczać wysokiej dostępności, a wysoka liczba może wynikać z powtarzalności tego samego problemu. Odbiór powinien opierać się na jakości informacji potrzebnej do naprawy.
- Raport opisuje badany zakres, wersję produktu, datę, próbę i ograniczenia.
- Każdy problem ma unikalny identyfikator, lokalizację, kroki odtworzenia i dowód.
- Każde ustalenie wskazuje odpowiednie kryterium sukcesu WCAG oraz poziom A albo AA, jeśli ma zastosowanie.
- Opis wyjaśnia wpływ na użytkownika, a nie tylko techniczną nieprawidłowość.
- Priorytet jest zdefiniowany według jasnej skali, na przykład blokujący, wysoki, średni i niski.
- Rekomendacja naprawy uwzględnia semantykę, zachowanie klawiatury i komunikację z czytnikiem ekranu.
- Wykonawca przekazuje listę wyników pozytywnych i obszarów niebadanych, jeśli są istotne dla interpretacji wyniku.
- Umowa określa liczbę rund retestu, sposób zgłaszania poprawek i formę potwierdzenia zamknięcia błędu.
Mini-scenariusz: audyt sklepu z płatnością zewnętrzną
Scenariusz ilustracyjny, nie opisuje wdrożenia klienta. Sklep zamawia audyt przed zmianą szablonu. W pierwszej wersji briefu podaje wyłącznie stronę główną i kategorię produktów. Wykonawca prosi o uzupełnienie zakresu o wyszukiwarkę, filtr cenowy, wybór wariantu, koszyk, formularz dostawy, logowanie, odzyskiwanie hasła, błędy walidacji oraz przekierowanie do zewnętrznej płatności.
Po doprecyzowaniu audyt obejmuje test klawiaturą całej ścieżki zakupowej. W raporcie zespół dostaje rozróżnienie: poprawki w kodzie sklepu, kwestie konfiguracji formularza oraz ograniczenia strony płatności, której kodu sklep nie kontroluje. Kryterium odbioru nie brzmi „brak błędów na domenie”, tylko „zweryfikowano uzgodnione kroki procesu, opisano bariery, przypisano właściciela poprawki i wykonano retest elementów zmienionych”.
Gdzie widget dostępności ma miejsce w tym procesie?
WCAGbot pozwala dodać funkcje wspierające dostępność bez kodowania, po wklejeniu jednej linii kodu. Użytkownik może między innymi zwiększyć tekst, zmienić kontrast, użyć czytania treści, większego kursora czy przewodnika do czytania. Są to praktyczne funkcje pomocnicze, szczególnie gdy zespół przygotowuje plan trwałych zmian.
Tabela kryteriów odbioru raportu z audytu
Nie usuwają jednak automatycznie problemu w strukturze nagłówków, błędnej nazwie przycisku, kolejności fokusu, nieprawidłowej walidacji formularza ani niedostępnej integracji płatniczej. Dlatego widget wspiera dostępność i komfort części użytkowników, ale nie zastępuje audytu WCAG, testów z użytkownikami ani napraw źródłowych.
Doświadczeniowe CTA: otwórz panel WCAGbot na własnej stronie testowej, zwiększ tekst, włącz kontrast i sprawdź, czy układ formularza, koszyka oraz menu nadal pozostaje czytelny. Pomocny będzie też materiał Kontrast, większy tekst i czytanie treści w WCAGbot.
Podsumowanie dla zarządzającego i sprzedaży
Dla zarządzającego dobrze przygotowany audyt jest podstawą decyzji: które bariery blokują kluczowe procesy, kto odpowiada za naprawę i kiedy wynik zostanie sprawdzony ponownie. Dla sprzedaży i obsługi klienta jest źródłem wiedzy o trudnościach, które mogą uniemożliwiać użytkownikowi kontakt lub zakup.
Najbezpieczniejsza formuła zamówienia to: konkretny zakres, jasno wskazany standard, reprezentatywne zadania, metodyka łącząca automaty i testy manualne, raport wdrożeniowy oraz retest. Dopiero taki zestaw pozwala świadomie planować dostępność cyfrową.
Dodaj funkcje dostępności swojej strony i przetestuj WCAGbot jako szybki pierwszy krok, równolegle planując audyt i trwałe naprawy tam, gdzie audyt wskaże rzeczywistą barierę.
FAQ: jak zamówić audyt WCAG?
Czy audyt WCAG można zrobić wyłącznie automatem?
Nie. Narzędzia automatyczne pomagają wykrywać część problemów, ale nie oceniają wszystkich kryteriów ani całego doświadczenia użytkownika. Audyt powinien obejmować także testy manualne.
Czy wystarczy zbadać stronę główną sklepu?
Nie, jeśli celem jest ocena dostępności sklepu. Strona główna nie reprezentuje formularzy, koszyka, płatności, konta klienta, filtrów ani komunikatów błędów.
Jaką wersję WCAG wpisać do briefu?
W briefie należy podać konkretną wersję i poziom, na przykład WCAG 2.2 AA. Jeśli audyt służy określonemu obowiązkowi lub rynkowi, zakres trzeba dodatkowo potwierdzić dla tej sytuacji.
Czy WCAG 2.2 AA oznacza automatycznie zgodność z PAD?
Nie należy przyjmować takiego uproszczenia. PAD, EN 301 549 i WCAG są odrębnymi dokumentami oraz wymagają analizy zakresu produktu i obowiązków mających zastosowanie do danej firmy.
Czy do audytu trzeba dać dostęp do kont testowych?
Tak, gdy ważne funkcje są dostępne po zalogowaniu. Warto przygotować konta testowe z różnymi rolami i ustalić bezpieczny sposób ich przekazania.
Czy płatność zewnętrzna powinna wejść do zakresu?
Tak, przynajmniej jako element ścieżki użytkownika. Raport powinien odróżniać problemy możliwe do naprawy przez właściciela sklepu od ograniczeń dostawcy płatności.
Jak ustalić priorytet błędów?
Priorytet powinien zależeć od wpływu na użytkownika i znaczenia procesu. Bariery uniemożliwiające zakup, wysłanie formularza lub logowanie zwykle wymagają szybszej reakcji niż problemy w mniej istotnym obszarze.
Czy raport powinien zawierać gotowy kod naprawczy?
Nie zawsze. Powinien jednak zawierać wystarczająco precyzyjną rekomendację dla zespołu, w tym opis oczekiwanego zachowania, semantyki i sposobu testu po poprawce.
Co to jest retest audytu WCAG?
Retest to ponowna weryfikacja konkretnych problemów po wdrożeniu zmian. Nie jest automatycznie pełnym audytem całego serwisu, chyba że strony uzgodnią szerszy zakres.
Czy widget dostępności zastępuje audyt WCAG?
Nie. Widget może wspierać użytkowników funkcjami takimi jak kontrast, większy tekst czy czytanie treści, ale nie zastępuje oceny eksperckiej i naprawy problemów w źródle strony.
