Dlaczego headless zmienia zasady gry dla dostępności
Tradycyjny sklep na Shoperze, WooCommerce czy PrestaShop renderuje HTML na serwerze platformy. Właściciel sklepu kontroluje treść — ale nie strukturę kodu. Nie może dodać skip linka, zmienić hierarchii nagłówków ani naprawić fokusa w nawigacji. Może co najwyżej wkleić overlay — a ten nie rozwiązuje problemów strukturalnych.
Headless frontend oddziela warstwę prezentacji od platformy. Sklep pobiera dane przez API, a cały HTML, CSS i JavaScript pisze zespół frontendowy. To oznacza pełną kontrolę nad semantyką, klawiaturą, ARIA i każdym elementem DOM.
Co konkretnie implementujemy — i jakie kryteria WCAG to adresuje
Skip link — „Przejdź do treści"
Ukryty link na samej górze strony, widoczny po naciśnięciu Tab. Pozwala użytkownikowi klawiatury ominąć header, nawigację i wyszukiwarkę — i przeskoczyć bezpośrednio do treści. Bez tego każda podstrona zaczyna się od kilkunastu Tab-ów przez menu.
Semantyczny HTML i landmarki
Każda strona ma poprawną strukturę: <header>, <main>, <footer>, <nav>. Nagłówki tworzą logiczną hierarchię (h1 → h2 → h3). Screen reader JAWS, NVDA czy VoiceOver widzi stronę jako uporządkowany dokument, nie jako płaski ciąg elementów.
Pełna nawigacja klawiaturą
Każdy interaktywny element — przycisk, link, pole formularza, filtr, modal — jest dostępny Tab-em i obsługuje klawisze Enter, Escape, strzałki. Modale mają focus trap (Tab nie ucieka poza modal) i przywracają fokus po zamknięciu. Focus ring (czerwona ramka 3px) jest zawsze widoczny na aktywnym elemencie.
ARIA na dynamicznych komponentach
Wyszukiwarka ma role="search", sugestie mają role="listbox" z aria-expanded i aria-controls. Modale mają role="dialog" z aria-modal. Panel dostępności używa role="switch" z aria-checked na każdym przełączniku. Checkboxy mają role="checkbox" z aria-label.
aria-live — ogłaszanie zmian dynamicznych
Gdy użytkownik dodaje produkt do koszyka — screen reader ogłasza nową liczbę produktów. Gdy wyszukiwarka zwraca sugestie — ogłasza ile ich jest. Bez aria-live dynamiczne zmiany na stronie są niewidoczne dla osób korzystających z czytników ekranu.
Atrybut lang na <html>
Strona deklaruje język treści (np. lang="pl"), dzięki czemu screen reader wie jakiej wymowy użyć. Bez tego czytnik może czytać polski tekst z angielską fonetyką — co czyni treść niezrozumiałą.
prefers-reduced-motion z systemu operacyjnego
Oprócz przełącznika w widgecie, storefront respektuje systemowe ustawienia użytkownika. Jeśli ktoś włączył „zmniejsz ruch" w macOS, Windows czy iOS — strona automatycznie wyłącza animacje CSS bez potrzeby ręcznej konfiguracji.
Widget preferencji wizualnych — 11 funkcji dostosowania
Oprócz fundamentów w kodzie, storefront zawiera panel preferencji wizualnych z 11 kontrolkami: regulacja rozmiaru tekstu, odstępów między literami, wysokości linii, tryb wysokiego kontrastu, zatrzymanie animacji, ukrycie obrazów, powiększony kursor, linia czytania, podświetlenie linków, podświetlenie nagłówków i wyciszenie dźwięków.
Widget to narzędzie wygody — nie certyfikat zgodności. Adresuje 7 z 78 kryteriów WCAG 2.1. Pozostałe 71 kryteriów wymagają zmian w kodzie źródłowym — i to właśnie daje headless frontend. Szczegółowa analiza prawna i naukowa widgetu: Widget dostępności — co robi, czego nie robi i dlaczego.
Dlaczego accessibility overlaye nie działają
Narzędzia typu overlay obiecują zgodność z WCAG po wklejeniu jednej linijki JavaScript. W praktyce:
Federalna Komisja Handlu ukarała dostawcę overlay kwotą 1 000 000 USD za fałszywe twierdzenia o zgodności z WCAG. Wewnętrzne testy dostawcy wykrywały błędy na niemal wszystkich testowanych stronach.
DG COMM w Europa Web Guide stwierdza, że żadne narzędzie automatyczne nie pokrywa wszystkich kryteriów WCAG 2.1. Overlaye mogą obniżyć dostępność strony dla części użytkowników.
Narzędzia automatyczne wykrywają ok. 13% kryteriów WCAG 2.2 AA. Pozostałe 70% wymaga oceny człowieka. Overlay nie naprawi semantyki HTML, nawigacji klawiaturą ani opisów alt.
69% specjalistów ds. dostępności oceniło overlaye jako nieskuteczne lub zupełnie nieskuteczne. Wśród respondentów z niepełnosprawnościami — 72%.
5 testów, które możesz zrobić sam w 10 minut
Nie potrzebujesz audytora ani specjalistycznego oprogramowania, żeby sprawdzić podstawową dostępność swojego sklepu. Poniższe testy wykryją najczęstsze problemy — te same, które odpowiadają za ponad 80% błędów zgłaszanych przez użytkowników z niepełnosprawnościami.
Test klawiatury — odłóż myszkę
Otwórz stronę główną sklepu i nawiguj wyłącznie klawiaturą: Tab (przód), Shift+Tab (tył), Enter (klik), Escape (zamknij). Przejdź przez: menu → wyszukiwarkę → produkt → dodaj do koszyka → koszyk.
Test skip linka
Otwórz stronę i naciśnij Tab raz. Czy pojawił się link „Przejdź do treści" (lub podobny)? Kliknij Enter — czy fokus przeskoczył do głównej treści strony, pomijając header i menu?
Test nagłówków — drzewko struktury
Zainstaluj rozszerzenie HeadingsMap (Chrome/Firefox) i otwórz dowolną stronę kategorii lub produktu. Sprawdź drzewko nagłówków.
Test kontrastu — 4.5:1
Kliknij prawym przyciskiem na tekst → Zbadaj element. Sprawdź kolor tekstu i kolor tła. Wpisz oba kolory w dowolny kontrast checker (np. wbudowany w Chrome DevTools — ikonka kontrastu przy kolorze w panelu Styles).
Test screen readera — 2 minuty z VoiceOver
Na macOS: Cmd+F5 włącza VoiceOver. Nawiguj po stronie produktu. Na Windows: pobierz NVDA (darmowy) i zrób to samo.
Czy logo powinno być linkiem do strony głównej?
Tak — i to jest wymóg WCAG, nie kwestia gustu. Logo sklepu w nagłówku powinno być linkiem prowadzącym do strony głównej. To uniwersalna konwencja webowa, którą użytkownicy — zarówno widzący, jak i korzystający z czytników ekranu — traktują jako nawigację „home".
- WCAG SC 3.2.3 (AA) — „Consistent Navigation": nawigacja powtarzalna na każdej podstronie w tej samej kolejności
- WCAG SC 3.2.4 (AA) — „Consistent Identification": ten sam element pełni tę samą funkcję na każdej stronie
- Screen reader ogłasza: „Strona główna, link" — użytkownik natychmiast wie jak wrócić
- Konwencja znana od lat 90. — badania NNGroup potwierdzają, że 96% użytkowników oczekuje klikalnego logo
- Łamie oczekiwania użytkownika — klik na logo nie robi nic lub prowadzi w nieoczekiwane miejsce
- Screen reader nie ogłosi tego jako nawigację — użytkownik nie wie jak wrócić na stronę główną
- Zwiększa cognitive load — użytkownik musi szukać innego sposobu powrotu
- Linkowanie do wyszukiwarki dezorientuje — wyszukiwarka jest już widoczna w nagłówku
Headless = kontrola = dostępność
WCAG 2.1 AA wymaga zmian w 78 kryteriach sukcesu — od semantyki HTML, przez nawigację klawiaturą, po dynamiczne ogłaszanie zmian. Żaden overlay ani widget tego nie zrobi. Headless frontend daje jedyną rzecz, która jest potrzebna: pełną kontrolę nad kodem źródłowym.
Źródła
- WCAG 2.1 — W3C Recommendation, 5 czerwca 2018
w3.org/TR/WCAG21/ - EN 301 549 V3.2.1 — ETSI, CEN, CENELEC (marzec 2021)
etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf - FTC, sprawa nr 2223156 — overlay accessibility (styczeń–kwiecień 2025)
ftc.gov/legal-library/browse/cases-proceedings/2223156-accessibe-inc - DG COMM, Komisja Europejska — Accessibility Overlays, Europa Web Guide
fondazionelia.org/en/research-and-development/accessibility-overlays-are-not-the-solution-says-the-european-commission/ - Accessible.org: Accessibility Scans Reliably Flag 13% of WCAG Criteria
accessible.org/automated-scans-wcag/ - WebAIM Practitioners Survey #3 (styczeń 2021, n=758)
webaim.org/projects/practitionersurvey3/ - NNGroup: Accessibility Widgets Are Not Enough for Screen-Reader Users
nngroup.com/videos/accessibility-widget/ - EDF + IAAP: Joint Statement on Accessibility Overlays (maj 2023)
edf-feph.org/publications/joint-statement-on-accessibility-overlays/ - NNGroup: Homepage Links Remain a Necessity (logo linking study)
nngroup.com/articles/homepage-links/