Wstęp
Przez kilka tygodni testowałam dostępność WCAG trzech polskich sklepów internetowych: giganta, średniego gracza i apteki niszowej. Obok mnie pracował Claude. Oto co znaleźliśmy osobno, co znaleźliśmy razem i gdzie żadne z nas nie wystarczyło.
-
- Jak testowałam dostępność sklepów — metodologia
- Co wykrywa AI, a co pomija? Wyniki w liczbami
- 3 błędy dostępności, których żaden automat nie wykryje
- Czego AI nie sprawdzi w sklepie internetowym — 5 granic technicznych
- Czy narzędzia automatyczne wyłapią błędy kontrastu?
- Dlaczego AI nie może przetestować checkoutu?
- Najważniejsze wnioski z badania
Jak testowałam dostępność sklepów internetowych — metodologia
Badanie zostało zaprojektowane tak, żeby porównać wyniki testu manualnego z analizą AI na tych samych stronach, przy tych samych kryteriach WCAG. Na samym początku ustaliłam jedną prostą zasadę: najpierw zawsze ja, potem Claude, żadne z nas nie widzi wyniku drugiego przed zakończeniem własnej analizy.
Co testowałam? Trzy sklepy, cztery widoki, pięć scenariuszy
3 sklepy internetowe:
- Allegro — lider polskiego e-commerce, zbudowany w oparciu o framework JavaScript z własnym design systemem Metrum. Skala: setki linków na jednej stronie.
- Formeds — sklep z suplementami na Shopify. Widoczna troska o podstawy dostępności: skip link, aria-label na przyciskach, poprawna struktura ARIA.
- Apteline — apteka internetowa z niestandardową ścieżką zakupową i modalem wyboru apteki jako warunkiem złożenia zamówienia.
4 widoki:
- Strona główna
- Karta produktu
- Koszyk
- Checkout
Pięć scenariuszy testowych:
- S1 — Nawigacja strukturalna VoiceOver (skip linki, nagłówki, landmarki)
- S2 — Obrazy, przyciski i komunikaty VoiceOver
- S3 — Dostępność klawiaturowa
- S4 — Kontrast kolorów
- S5 — Dynamiczne komponenty JS (modale, dropdowny, karuzele, tabsy)
Badanie objęło 35 kryteriów WCAG 2.1 na poziomach A i AA. Żadne kryterium AAA nie weszło do badania, ponieważ WCAG AA to aktualny standard wymagany przepisami.
Wyniki w arkuszu pokazują dla każdego kryterium, czy błąd znalazł człowiek, Claude, oboje, czy żadne z nich. Kolumna Δ oznacza rozbieżność , przypadki w których wyniki się różniły.
Co wykrywa AI, a co pomija? Wyniki z liczbami
Recall mówi, ile błędów znalezionych przeze mnie Claude też wykrył. Precision mówi, jaka część zgłoszeń Claude’a to rzeczywiste błędy.
| Scenariusz | Recall AI (śr.) | Precision AI (śr.) | Błędy przeoczone | Fałszywe alarmy |
|---|---|---|---|---|
| S1 Nawigacja VoiceOver | 75% | 57% | ~2,3 / sklep | ~6,3 / sklep |
| S2 Obrazy i przyciski | 82% | 48% | ~2,7 / sklep | ~10,7 / sklep |
| S3 Klawiatura | 25% | 59% | ~11 / sklep | ~3,3 / sklep |
| S4 Kontrast | 39% | 90% | ~4,5 / sklep | ~1 / sklep |
| S5 Dynamiczne komponenty | 51% | 63% | ~6,3 / sklep | ~4,7 / sklep |
AI najlepiej radzi sobie z semantyką statyczną (S1–S2: recall 75–82%) i jest prawie bezużyteczne przy testach klawiaturowych (S3: recall 25%). Kontrast to osobna historia – tu recall wynosi 39%, ale precision już 90%: gdy AI zgłasza błąd kontrastu, prawie zawsze ma rację.
Nawigacja strukturalna: gdzie AI ma przewagę skali
| Kryterium WCAG | Człowiek (suma) | Claude (suma) | Obserwacja |
|---|---|---|---|
| 2.4.1 Możliwość pominięcia bloków | 2 | 2 | Zgodność |
| 1.3.1 Informacje i relacje | 9 | 8 | Bliskie zgodności |
| 2.4.4 Cel łącza (w kontekście) | 7 | 9 | Claude znalazł więcej- przewaga skali |
| 4.1.3 Linki otwierające nową kartę | 1 | 5 | Claude wykrył 8 nieoznaczonych linków przy 223 linkach na stronie |
Dostępność klawiaturowa: recall 25% — dlaczego AI tu zawodzi?
| Kryterium WCAG | Człowiek (suma) | Claude (suma) |
|---|---|---|
| 2.1.1 Klawiatura | 9 | 4 |
| 2.1.2 Bez pułapki na klawiaturę | 4 | 1 |
| 2.4.3 Kolejność fokusu | 9 | 1 |
| 2.4.7 Widoczny fokus | 11 | 1 |
| 4.1.2 Nazwa, rola, wartość | 0 | 6 |
Recall 25% oznacza: trzy na cztery błędy klawiaturowe są dla AI niewidoczne. Przy testach klawiaturowych człowiek jest niezbędny, nie jako weryfikator AI, ale jako jedyne źródło wiarygodnych wyników.
3 błędy dostępności w sklepach internetowych, których żaden automat nie wykryje
Błąd 1: Prawidłowe kryterium WCAG, zła diagnoza — jak AI się myli
Claude zgłosił błąd 4.1.2 na Apteline: element fokusowalny bez odpowiedniej roli ARIA. Manualny test ujawnił jednak, że diagnoza była błędna: element „Zobacz więcej” w ogóle nie był dostępny klawiaturą i Tab do niego nie docierał. Claude widział za dużo, tester zobaczył właściwe miejsce.
AI analizuje surowy DOM bez kontekstu wizualnego. Nie wie, czy element jest w nagłówku, stopce, ukrytym menu czy modalu w innym stanie. Każdy błąd zgłoszony przez AI wymaga weryfikacji kontekstu przez człowieka.
Błąd 2: Kod wygląda poprawnie, implementacja nie — koszyk Formeds
Koszyk Formeds działa jako drawer. Kod był poprawny: role="dialog", aria-modal="true", przycisk zamknięcia z aria-label. Claude ocenił strukturę ARIA jako prawidłową.
Manualny test ujawnił, że implementacja JavaScript nie dotrzymała obietnicy kodu. Po otwarciu koszyka fokus pozostawał pod modalem, a Tab przemieszczał się po elementach strony w tle. Przycisk zamknięcia (X) był niedostępny klawiaturą. Jedyną metodą zamknięcia był Escape.
ARIA deklaruje zachowanie, JavaScript je realizuje lub nie. Claude widzi deklarację, człowiek testuje realizację.
Błąd 3: ARIA wstrzykiwana przez framework JS w runtime — menu „Moje Allegro”
Menu „Moje Allegro” zawiera komponent zakładek z pełną semantyką ARIA. Claude ocenił go jako błąd, bo widział brak wymaganych atrybutów. Weryfikacja z VoiceOver wykazała, że komponent działa poprawnie.
Przyczyna: Allegro jest zbudowane w oparciu o framework JavaScript. Atrybuty ARIA nie istnieją w statycznym HTML i są wstrzykiwane przez JavaScript w runtime. AI analizujące statyczny HTML tego nie widzi i zgłasza fałszywy alarm.
Analiza statyczna HTML może służyć wyłącznie jako punkt wyjścia do audytu stron opartych na frameworkach JS. Dla komponentów dynamicznych jedyną wiarygodną metodą jest test manualny na żywym DOM.
Czego AI nie sprawdzi w audycie dostępności sklepu — 5 granic technicznych
| Kategoria błędu | Dlaczego AI nie może tego sprawdzić | Co to znaczy dla audytu |
|---|---|---|
| Ucięty wskaźnik fokusu | Problem leży w interakcji CSS z przeglądarką, nie w kodzie | Człowiek testuje klawiaturą, robi screenshot, AI analizuje przyczynę |
| Zarządzanie fokusem po zamknięciu modalu | Stan dynamiczny wymaga faktycznego otwarcia i zamknięcia modalu | Zawsze wymaga testu manualnego |
| ARIA wstrzykiwana przez React, Vue i inne frameworki | Atrybuty nie istnieją w statycznym HTML , powstają gdy JS uruchomi się w przeglądarce | Fałszywe alarmy dla wszystkich dynamicznych komponentów |
| Tekst na obrazie lub gradiencie | Brak wartości CSS, są piksele | Pipeta lub screenshot |
| Checkout z aktywną sesją | Bez aktywnej sesji AI widzi formularz logowania zamiast procesu zakupowego | Wymaga aktywnej sesji dostarczonej przez człowieka |
Czy narzędzia automatyczne wyłapią błędy kontrastu w sklepie?
Analiza kontrastu przyniosła zaskakujące wyniki w obu kierunkach.
Gdzie AI wygrało z WAVE i ANDI: Formeds ma restrykcyjną politykę bezpieczeństwa, która blokowała zewnętrzne narzędzia. Claude, działający przez rozszerzenie Chrome, poradził sobie, przeszedł przez 80 węzłów tekstowych w jednym wywołaniu i obliczył ratio matematycznie dla każdego.
Błąd systemowy Allegro: Claude znalazł cztery błędne błędne w całym design systemie Metrum. WAVE i ANDI przegapiły błąd breadcrumba (#ff5a00 na #ECEFF1, ratio 2.71:1 przy wymaganym 4.5:1), bo nie rozwiązują poprawnie łańcucha transparentnych teł.
Automatyczne narzędzia jako szybki przesiew → AI do głębszej analizy trudnych przypadków → człowiek do gradientów, obrazów i stanów dynamicznych. Żaden z tych trzech elementów osobno nie wyłapie wszystkiego.
Dlaczego AI nie może przetestować checkoutu sklepu internetowego?
Checkout to jednocześnie miejsce, gdzie bariery dostępności bolą najbardziej, użytkownik nie może zapłacić i miejsce, gdzie AI bez pomocy człowieka jest bezradne.
Apteline: sesja wygasła, Claude widział pusty formularz logowania zamiast podsumowania zamówienia. Formeds: restrykcyjna polityka bezpieczeństwa blokowała część narzędzi, testy checkoutu były możliwe dopiero po dostarczeniu aktywnej sesji przez człowieka.
Odkryłam też, że Apteline narusza kryterium WCAG 3.3.4 Zapobieganie błędom (AA): kliknięcie „Zamawiam” finalizuje zamówienie natychmiast, bez kroku weryfikacji. Ten błąd jest błędem projektowym, nie kodowym i tylko test manualny mógł go ujawnić.
Najważniejsze wnioski z badania
AI jest skutecznym narzędziem do przesiewu statycznej semantyki w skali, ale test manualny pozostaje niezbędny wszędzie tam, gdzie dostępność objawia się w ruchu, interakcji i kontekście, czyli dokładnie tam, gdzie bariery bolą użytkowników najbardziej.
- Claude nie odróżnia błędu od świadomej decyzji projektowej. Tylko człowiek słuchający VoiceOver w kontekście rzeczywistego zadania oceni, czy dane rozwiązanie działa czy szkodzi.
- Claude analizuje DOM, nie stronę. Widzi płaski kod, a tester widzi żywą stronę. Dlatego wyniki AI są punktem wyjścia, niekońcową oceną.
- Skala sklepu nie równa się lepsza dostępność. Formeds miał skip link na każdej podstronie i poprawną strukturę ARIA, której Allegro nie ma. Apteline to osobna kategoria, systemowy błąd projektowy całej ścieżki zakupowej.
- Człowiek jest niezastąpiony nie tylko jako tester końcowy, ale też jako korektor AI w trakcie. Każda sesja, w której podawałam Claude kontekst wizualny, kończyła się wynikami, których żadne z nas nie znalazłoby samodzielnie.
- Narzędzie AI uczy się na podstawie rzeczywistych testów. Po przebadaniu trzech sklepów narzędzie jest znacząco lepsze niż na początku.
Jak łączyć AI z testami manualnymi w praktyce?
| Scenariusz testowy | AI jako pierwszy pass | Człowiek koniecznie |
|---|---|---|
| Nawigacja strukturalna (S1) | Silne — duże strony, wiele linków | Weryfikacja kontekstu, testy z VoiceOver |
| Obrazy i przyciski (S2) | Silne — alt, etykiety | Obrazy dekoracyjne, stany dynamiczne |
| Klawiatura (S3) | Słabe — wiele false positives | Każdy test manualny, szczególnie focus management |
| Kontrast (S4) | Warunkowe — działa przy CSS, nie przy gradientach | Gradienty, obrazy, stany hover/focus |
| Dynamiczne komponenty (S5) | Słabe — fałszywe alarmy przy frameworkach JS | Każdy modal, dropdown, carousel |
| Checkout | Warunkowo — wymaga aktywnej sesji | Człowiek dostarcza zalogowaną sesję |
Twój sklep też ma bariery dostępności?
Większość z nich jest niewidoczna w kodzie i ujawniają się dopiero pod klawiaturą i czytnikiem ekranu. Audyt dostępności dla sklepów internetowych łączy test manualny z automatycznymi.
Powiązane artykuły
Raport z audytu dostępności cyfrowej – jak wygląda i co zawiera?
Audyt dostępności WCAG stron szkolnych w praktyce- studium przypadku
Jakimi narzędziami automatycznie sprawdzisz dostępność swojej strony?
