W teście axe-core dziesięciu podstron CometWeb znalazłem jedno naruszenie dotyczące kontrastu tekstu w cenniku. Zmierzone wartości kontrastu wynosiły 4,49:1 i 3,81:1 przy wymaganym minimum 4,5:1. W pierwszym przypadku zabrakło jednej setnej, a oba fragmenty miały kontrast poniżej wymaganego progu.
Wynik skanowania nie pozwala ocenić zgodności całej strony z WCAG 2.1 AA, ponieważ część wymagań trzeba sprawdzić ręcznie. Omawiam zasady standardu, różnice między jego wersjami i to, jakie problemy da się wykryć automatycznie, a do jakich potrzebne są testy z użyciem klawiatury i technologii asystujących.
WCAG 2.1: cztery zasady i 13 wytycznych
WCAG 2.1 to wytyczne W3C dotyczące dostępności treści internetowych, opublikowane jako rekomendacja w czerwcu 2018 r. Rozszerzają WCAG 2.0 o 17 kryteriów sukcesu, głównie z myślą o urządzeniach mobilnych, osobach słabowidzących i osobach z niepełnosprawnościami poznawczymi. Listę nowych kryteriów podaje przegląd zmian w WCAG 2.1 na stronie W3C. Czym jest sam standard i skąd się wziął, opisuje hasło WCAG w słowniku.
Kryteria są pogrupowane w cztery zasady i 13 wytycznych. WCAG 2.0 miało 12 wytycznych, a 2.1 dodało wytyczną 2.5, o wprowadzaniu danych inaczej niż klawiaturą.
Cztery zasady WCAG to postrzegalność, funkcjonalność, zrozumiałość i solidność, a polska ustawa z 2019 r. wymienia je w art. 5 ust. 2.
| Zasada w tłumaczeniu W3C | W ustawie z 2019 r. | O co chodzi | Kryteria A+AA | Przykład kontroli |
|---|---|---|---|---|
| 1. Postrzegalność | Postrzegalność | Informację i interfejs da się odebrać przynajmniej jednym zmysłem, którym dysponuje użytkownik | 20 | Czy obraz niosący informację ma tekst alternatywny, a tekst wystarczający kontrast |
| 2. Funkcjonalność | Funkcjonalność | Interfejs da się obsłużyć, także bez myszy | 17 | Czy całą ścieżkę zamówienia przejdziesz klawiaturą, bez pułapki focusu |
| 3. Zrozumiałość | Zrozumiałość | Treść i działanie interfejsu są przewidywalne i czytelne | 10 | Czy formularz opisuje błąd i mówi, jak go poprawić |
| 4. Solidność | Kompatybilność | Treść działa z przeglądarkami i technologiami asystującymi | 3 | Czy przycisk ma nazwę i rolę odczytywaną przez czytnik ekranu |
Kolumnę „Kryteria A+AA” policzyłem sam w tekście rekomendacji WCAG 2.1.
Solidność ma trzy kryteria, ale jedno z nich, 4.1.2 Nazwa, rola, wartość, dotyczy każdego przycisku, pola i niestandardowego komponentu na stronie.
Solidność i Kompatybilność to ta sama zasada WCAG
Czwarta zasada ma w Polsce dwie nazwy, choć w oryginale to jedna zasada, Robust. Autoryzowane tłumaczenie W3C z 2021 r. mówi „Solidność”, a załącznik do ustawy z 2019 r. „Kompatybilność”.
Pułapka polega na tym, że w tłumaczeniu W3C „Kompatybilność” to z kolei nazwa wytycznej 4.1. Porównując ustawę ze standardem, dopasowuj więc kryteria po numerach.
Poziomy A, AA i AAA: zgodność z WCAG 2.1 AA to 50 kryteriów
Poziomy się sumują, więc zgodność z WCAG 2.1 na poziomie AA oznacza spełnienie wszystkich 50 kryteriów z poziomów A i AA w ocenianym zakresie. W samej rekomendacji naliczyłem 30 kryteriów poziomu A, 20 poziomu AA i 28 poziomu AAA, razem 78.
Zgodność dotyczy całych stron i kompletnych procesów, więc jeśli jeden krok zamówienia łamie kryterium, cały proces jest niezgodny. Drugą drogą jest zgodna wersja alternatywna z tymi samymi informacjami i funkcjami. Obie reguły opisują wymagania zgodności w rekomendacji WCAG 2.1.
Poziom AAA jest najwyższy, a W3C sam odradza go jako wymóg dla całych serwisów: „It is not recommended that Level AAA conformance be required as a general policy for entire sites”. Uzasadnia to tym, że części treści nie da się dopasować do każdego kryterium AAA, i dlatego przepisy oraz większość zamówień mówią o poziomie AA.
| Wersja (publikacja) | Kryteria A | Kryteria AA | Razem do spełnienia na AA | Wydanie, z którego liczyłem |
|---|---|---|---|---|
| WCAG 2.0 (11 grudnia 2008 r.) | 25 | 13 | 38 | 11 grudnia 2008 r. |
| WCAG 2.1 (5 czerwca 2018 r.) | 30 | 20 | 50 | 6 maja 2025 r. |
| WCAG 2.2 (5 października 2023 r.) | 31 | 24 | 55 | 12 grudnia 2024 r. |
Skrypt liczył oznaczenia poziomów w wydaniach z ostatniej kolumny. Według przeglądu WCAG 2 na stronie W3C kolejne wydania wersji mają te same kryteria sukcesu, więc liczby odpowiadają wersjom z 2018 i 2023 r. Poziomy kryteriów są takie same we wszystkich trzech wersjach.
Co WCAG 2.1 dodało do WCAG 2.0: 17 nowych kryteriów
WCAG 2.1 dodało 17 kryteriów sukcesu: 5 na poziomie A, 7 na AA i 5 na AAA. Nazwy w tabeli podaję za autoryzowanym tłumaczeniem W3C, a ostatnia kolumna mówi, czy axe-core 4.13 ma dla kryterium regułę uruchamianą domyślnie.
| Kryterium | Poziom | Co sprawdzić w praktyce | Reguła axe-core |
|---|---|---|---|
| 1.3.4 Orientacja | AA | Strona działa w pionie i w poziomie, chyba że konkretna orientacja jest niezbędna | tylko eksperymentalna |
| 1.3.5 Określenie pożądanej wartości | AA | Pola danych osobowych mają poprawny autocomplete, np. email, tel | tak (autocomplete-valid) |
| 1.4.10 Dopasowanie do ekranu | AA | Treść przy szerokości 320 pikseli CSS nie wymaga przewijania w dwóch kierunkach | brak |
| 1.4.11 Kontrast elementów nietekstowych | AA | Ikony, obramowania pól i stany kontrolek mają kontrast co najmniej 3:1 | brak |
| 1.4.12 Odstępy w tekście | AA | Po zwiększeniu odstępów tekstu treść się nie ucina i nie nachodzi na siebie | częściowo (avoid-inline-spacing) |
| 1.4.13 Treść spod kursora lub fokusu | AA | Podpowiedzi i menu po najechaniu da się zamknąć, najechać na nie i nie znikają same | brak |
| 2.1.4 Jednoznakowe skróty klawiaturowe | A | Skróty z jednej litery da się wyłączyć albo przemapować | brak |
| 2.5.1 Gesty dotykowe | A | Gest wielopunktowy lub po ścieżce ma odpowiednik jednym dotknięciem | brak |
| 2.5.2 Rezygnacja ze wskazania | A | Akcja wykonuje się przy puszczeniu, a nie przy naciśnięciu, lub da się ją przerwać | brak |
| 2.5.3 Etykieta w nazwie | A | Nazwa dostępna kontrolki zawiera tekst, który użytkownik widzi na przycisku | tylko eksperymentalna |
| 2.5.4 Aktywowanie ruchem | A | Funkcję wywoływaną potrząśnięciem urządzenia da się uruchomić inaczej i wyłączyć | brak |
| 4.1.3 Komunikaty o stanie | AA | Komunikat „Dodano do koszyka” dociera do czytnika ekranu bez przenoszenia focusu | brak |
| 1.3.6 Określenie przeznaczenia | AAA | Przeznaczenie komponentów i ikon da się określić programowo | poza zakresem pomiaru |
| 2.2.6 Ostrzeżenie o limicie czasu | AAA | Użytkownik wie, po jakim czasie bezczynności straci dane | poza zakresem pomiaru |
| 2.3.3 Animacja po interakcji | AAA | Animację wywołaną interakcją da się wyłączyć | poza zakresem pomiaru |
| 2.5.5 Rozmiar celu dotykowego | AAA | Cel dotykowy ma co najmniej 44 × 44 piksele CSS, z wyjątkami | poza zakresem pomiaru |
| 2.5.6 Równoległy mechanizm wprowadzania danych | AAA | Strona nie blokuje przełączania między dotykiem, myszą i klawiaturą | poza zakresem pomiaru |
Każde kryterium ma wyjątki opisane w dokumentach Understanding WCAG, więc sprawdź je przed zgłoszeniem błędu. Według objaśnienia W3C do kryterium 1.4.10 mapy, diagramy czy tabele danych mogą przewijać się w dwóch kierunkach, bo wymagają układu dwuwymiarowego.
Z dwunastu nowych kryteriów A i AA domyślną regułę axe-core mają tylko dwa: 1.3.5 i 1.4.12.
Skąd ta luka? Dopasowanie do ekranu, treść po najechaniu, gesty czy komunikaty o stanie zależą od zachowania strony w czasie i od tego, co widzi użytkownik, a pojedynczy skan drzewa DOM tego nie odtworzy.
Jak to zmierzyłem
24 września 2026 r. uruchomiłem axe-core 4.13.0 w Chromium dołączonym do Playwright 1.62.1, na 10 stronach cometweb.io. W próbie były obie strony główne, cennik, strona modułu, dwa narzędzia, formularz kontaktowy, dwa artykuły plus hasło słownika.
Włączyłem tylko 62 domyślne reguły oznaczone tagami WCAG 2.0 i 2.1 dla poziomów A i AA. Każde z 50 kryteriów dostało jeden wynik, zależnie od tego, czy ma przypisaną regułę i co ta reguła zwróciła. Tagi i wyniki „do weryfikacji” opisuje dokumentacja API axe-core.
Skan widział strony bez otwartych menu, wysłanych formularzy i okien dialogowych, a skrypt i pełny opis są w metodologii.
Domyślne reguły axe-core dotykają 19 z 50 kryteriów WCAG 2.1 AA
We wrześniu 2026 r. domyślną regułę axe-core 4.13 miało 19 z 50 kryteriów A i AA w WCAG 2.1, zwykle obejmującą tylko część kryterium. 28 kryteriów nie ma żadnej reguły, a trzy mają tylko regułę eksperymentalną, która domyślnie się nie uruchamia. Narzędzia podpisują wyniki numerami kryteriów WCAG, co łatwo odczytać jako „kryterium sprawdzone”.
Według poziomu domyślną regułę ma 14 z 30 kryteriów poziomu A i tylko 5 z 20 kryteriów poziomu AA.
Reguła axe-core bada tylko fragment kryterium
Reguła image-alt wykryje obraz bez tekstu alternatywnego, ale nie oceni, czy tekst „obrazek1.jpg” coś mówi. Reguła meta-viewport, przypisana do 1.4.4, sprawdza tylko, czy znacznik viewport blokuje powiększanie. Według WCAG treść ma działać po powiększeniu do 200%, a to sprawdzasz już sam.
Jedenaście kryteriów z wynikiem „reguły nic nie znalazły” przeszło tylko część automatyczną i tylko w zbadanym stanie strony. Najwięcej pracy zostaje przy 28 kryteriach bez żadnej reguły. Należą do nich brak pułapki klawiatury (2.1.2), kolejność focusu (2.4.3), widoczny focus (2.4.7), identyfikacja błędów (3.3.1) i komunikaty o stanie (4.1.3). Te wymagania sprawdzasz ręcznie albo scenariuszem testowym, który klika i sprawdza efekt.
Dlatego czysty raport axe czytam jako „na pierwszy rzut oka w porządku”, a potem i tak biorę klawiaturę.
Skan cometweb.io: jedno naruszenie kontrastu i 1460 elementów do weryfikacji
Opisane we wstępie naruszenie dotyczyło sześciu elementów tekstu pomocniczego o rozmiarze 12 px w cenniku. Surowe wyniki wskazywały na błąd kontrastu we wspólnym szablonie. Tego samego dnia rozjaśniłem kolor tekstu i ponownie sprawdziłem polską oraz angielską wersję cennika. W obu skanach reguły kontrastu przeszły poprawnie.
Na każdej stronie reguła kontrastu oddała człowiekowi od 88 do 209 elementów. Z 1460 takich przypadków 1220 to tekst na gradiencie, dla którego biblioteka nie wyznaczy jednego koloru tła.
Na stronie z ciemnymi, cieniowanymi sekcjami, takiej jak moja, większość decyzji o kontraście podejmuje więc człowiek. Na wszystkich stronach wróciły jeszcze dwa przypadki do przejrzenia: aria-controls wskazujący panel menu, który trafia do DOM dopiero po otwarciu, i link do polityki prywatności w formularzu newslettera, na gradiencie.
Automat dobrze łapie powtarzalne błędy w kodzie i regresje między wdrożeniami. Resztę ocenia człowiek, co W3C w poradniku o wyborze narzędzi do oceny dostępności mówi wprost: narzędzia nie ocenią wszystkich aspektów dostępności i potrzebny jest ludzki osąd.
Kryterium 4.1.1 Parsing: w WCAG 2.1 zawsze spełnione, w 2.2 usunięte
Kryterium 4.1.1 Parsing (po polsku: Poprawność kodu) nadal figuruje w aktualnym wydaniu WCAG 2.1 na poziomie A, z uwagą, że dla treści w HTML lub XML należy je uznać za zawsze spełnione. WCAG 2.2 usunęło je jako przestarzałe.
Jeśli raport z audytu nadal wylicza duplikaty id jako błędy 4.1.1, zapytaj, do którego wydania standardu się odnosi. Zduplikowany identyfikator, na który wskazuje etykieta lub atrybut ARIA, może za to łamać 1.3.1 albo 4.1.2, i właśnie do 4.1.2 axe-core przypisuje regułę duplicate-id-aria.
WCAG 2.1 czy WCAG 2.2: sześć nowych kryteriów A i AA
WCAG 2.2 dodało dziewięć kryteriów, z czego sześć na poziomach A i AA, i usunęło 4.1.1 Parsing jako przestarzałe (przegląd zmian w WCAG 2.2).
| Kryterium WCAG 2.2 | Poziom |
|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA |
| 2.4.12 Focus Not Obscured (Enhanced) | AAA |
| 2.4.13 Focus Appearance | AAA |
| 2.5.7 Dragging Movements | AA |
| 2.5.8 Target Size (Minimum) | AA |
| 3.2.6 Consistent Help | A |
| 3.3.7 Redundant Entry | A |
| 3.3.8 Accessible Authentication (Minimum) | AA |
| 3.3.9 Accessible Authentication (Enhanced) | AAA |
Przy nowym projekcie celowałbym od razu w WCAG 2.2 AA. Powody biorę z przeglądu WCAG 2 i komunikatu W3C o normie ISO:
- treść zgodna z WCAG 2.2 jest zgodna także z 2.1 i 2.0, bo W3C projektuje kolejne wersje jako zgodne wstecz;
- w drugą stronę to działa gorzej, bo strona zgodna z 2.1 AA może oblać sześć nowych kryteriów A i AA;
- od października 2025 r. WCAG 2.2 jest normą ISO/IEC 40500:2025, identyczną z wersją W3C z października 2023 r.
W liczbach różnica jest mała, z 50 do 55 kryteriów do spełnienia, ale dotyczy sytuacji, które znasz z wielu serwisów. Przyklejony nagłówek całkiem zasłania element z focusem albo cele dotykowe są za małe. Formularz każe drugi raz wpisać te same dane, a logowanie bez alternatywy wymaga zapamiętania albo przepisania kodu.
Jak przetestować każde z sześciu nowych kryteriów, pokazuję w artykule Audyt dostępności cyfrowej: zakres, testy WCAG i EAA.
Która wersja WCAG obowiązuje w Polsce
W Polsce WCAG 2.1 na poziomie AA obowiązuje podmioty publiczne, na mocy ustawy z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych. Obowiązek objął najpierw strony internetowe, a potem aplikacje mobilne, zgodnie z harmonogramem z art. 27 tej ustawy.
Czy i jaki obowiązek dotyczy twojej organizacji, potwierdź z prawnikiem.
Podmioty publiczne: załącznik do ustawy o dostępności cyfrowej
Podmiotom publicznym ustawa o dostępności cyfrowej każe w art. 5 ust. 1 spełnić wymagania z załącznika.
Załącznik nosi tytuł „Wytyczne dla dostępności treści internetowych 2.1…” i wymienia kryteria poziomów A i AA, między innymi 1.4.3 Kontrast (minimalny), 2.5.3 Etykieta w nazwie i 4.1.3 Komunikaty o stanie. Ustawa wymaga też deklaracji dostępności, co przypomina serwis gov.pl w opisie „WCAG 2.1 w skrócie”.
Porównałem skryptem załącznik z listą kryteriów WCAG 2.1 i wyszło, że wymienia 49 z 50 kryteriów A i AA (30 A i 19 AA), z tymi samymi poziomami. Brakuje tylko 1.2.4 Napisy rozszerzone (na żywo).
To pominięcie pasuje do przepisu ustawy, który wyłącza z jej stosowania multimedia nadawane na żywo (art. 3 ust. 2 pkt 1), choć samego uzasadnienia ustawa nie podaje. Wynik porównania zapisałem w pliku annex-pl-2019.json.
Alternatywną drogę daje ustawa w art. 5 ust. 3, zgodnie z którym wymagania z załącznika uznaje się za spełnione, gdy podmiot publiczny zapewnia dostępność z uwzględnieniem punktów 9, 10 i 11 normy EN 301 549 V2.1.2, europejskiej normy, której część o stronach opiera się na WCAG.
Firmy: Polski Akt o Dostępności i EN 301 549
Polski Akt o Dostępności to ustawa o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług, która wdraża European Accessibility Act. Obowiązuje zasadniczo od 28 czerwca 2025 r. i dotyczy wskazanych produktów i usług, m.in. handlu elektronicznego i bankowości detalicznej.
Wymagania wynikają z samej ustawy, więc załącznik ustawy z 2019 r. nie ma tu bezpośredniego zastosowania. Zakres PAD z wyłączeniami oraz nowe wydanie EN 301 549 z WCAG 2.2 opisuję w tym samym artykule o audycie dostępności cyfrowej.
Jak sprawdzić, czy strona spełnia WCAG 2.1: 9 kroków
Pełna ocena zgodności z WCAG 2.1 to audyt, ale ja zaczynam od szybkiego przeglądu, który pokazuje największe problemy.
- Ustal zakres i wypisz szablony stron i kluczowe procesy: logowanie, formularz kontaktowy, koszyk, płatność.
- Uruchom test automatyczny, który wyłapie część błędów, takich jak brakujące etykiety, niski kontrast tekstu czy dziury w strukturze nagłówków. Za darmo zrobisz to w Chrome: DevTools > Lighthouse > zaznacz kategorię Accessibility > Analyze page load. Lighthouse uruchamia reguły axe-core, co widać w jego kodzie źródłowym.
- Przejrzyj wyniki „do weryfikacji”, czyli miejsca, w których narzędzie przyznaje, że nie wie, więc traktuj każdy jak zadanie do zamknięcia. Kontrast tekstu na gradiencie czy zdjęciu sprawdź ręcznie w najciemniejszym i najjaśniejszym punkcie tła.
- Przejdź ścieżki klawiaturą, używając klawiszy Tab, Shift+Tab, Enter, spacja i Escape. Focus ma być widoczny, iść w sensownej kolejności i nigdzie nie utykać.
- Sprawdź powiększenie i układ, bo według WCAG tekst ma działać po powiększeniu do 200%, a widok ma się mieścić w szerokości 320 pikseli CSS (kryteria 1.4.4 i 1.4.10).
- Zmierz kontrast w rzeczywistych stanach: tekst 4,5:1 (duży 3:1), elementy nietekstowe 3:1, także dla focusu i komunikatów o błędach. Wyjątkiem są nieaktywne (wyłączone) elementy, logotypy i czysta dekoracja. Pomoże w tym sprawdzanie kontrastu.
- Wyślij formularze z błędami, bo błąd ma być opisany tekstem, powiązany z polem i możliwy do poprawienia bez utraty danych.
- Sprawdź nazwy kontrolek, bo przyciski z samą ikoną potrzebują nazwy dostępnej, a widoczny tekst na przycisku ma być jej częścią (2.5.3).
- Zapisz wersję i poziom, bo wynik bez opisu „WCAG 2.1 AA, te strony, te procesy, ta data” nie nadaje się do porównania ani do deklaracji dostępności.
Do samodzielnego przeglądu przyda się checklista dostępności, a planowanie pełnego audytu z próbkowaniem według WCAG-EM i raportowaniem opisuję w artykule o audycie dostępności cyfrowej, podlinkowanym wyżej.
Moduł Dostępność w CometWeb Insight: automatyczna część audytu
Moduł Dostępność w CometWeb Insight robi automatyczną część kontroli na wielu stronach w jednym przebiegu:
- sprawdza wybrane kryteria i pokazuje, których elementów dotyczy problem;
- porządkuje poprawki według wpływu na użytkownika;
- rozpisuje zasady WCAG na mapę kryteriów ze statusem: sprawdzone automatycznie, problem wykryty, wymaga ręcznej weryfikacji, nie dotyczy albo brak danych;
- po poprawce robi ponowny test tego samego zakresu.
Siatkę 50 kryteriów wyżej zbudowałem na tej samej zasadzie co mapę w module. Certyfikatu zgodności z WCAG moduł nie wystawia, a testy ręczne i ocenę prawną robisz sam.
Załóż konto w Insight i uruchom pierwszy audyt dostępności.
Trzy wnioski o WCAG 2.1 AA
- Poziom AA to 50 kryteriów, a liczą się wszystkie z poziomów A i AA, w całych procesach i bez tolerancji na progach.
- Automat dotyka 19 z nich, bo domyślne reguły axe-core 4.13 zwykle badają tylko część kryterium, a przy pozostałych 31 siada człowiek z klawiaturą.
- Nowy projekt celuj w WCAG 2.2 AA, bo treść zgodna z 2.2 spełnia też 2.1 i 2.0, kosztem pięciu kryteriów więcej. Obowiązek prawny ustalasz osobno.
Jutro rano uruchom axe na swoim cenniku, a potem przejdź zamówienie samą klawiaturą, bo u mnie w jednym miejscu zabrakło jednej setnej.
Najczęstsze pytania
Czy WCAG 2.1 jest nadal aktualne?
WCAG 2.1 pozostaje rekomendacją W3C i to na nią powołuje się polska ustawa o dostępności cyfrowej podmiotów publicznych. Najnowszą wersją jest jednak WCAG 2.2 z października 2023 r. Treść zgodna z 2.2 jest zgodna także z 2.1, dlatego nowe projekty najlepiej od razu planować pod WCAG 2.2 AA.
Czy prywatna firma musi spełniać WCAG 2.1?
Prywatnej firmy ustawa z 2019 r. nie obejmuje, bo dotyczy podmiotów publicznych. Firmy świadczące wskazane usługi konsumentom, na przykład e-handel, podlegają ustawie z 26 kwietnia 2024 r. wdrażającej European Accessibility Act, z wymaganiami powiązanymi z normą EN 301 549. Czy obowiązek dotyczy konkretnej firmy, zależy od rodzaju usługi i wyłączeń, na przykład dla mikroprzedsiębiorców.
Czy inne narzędzia sprawdzą więcej kryteriów WCAG 2.1 niż axe-core?
Inne narzędzia mogą mieć reguły dla innej liczby kryteriów, ale sensu treści i zachowania strony po interakcji automatycznie nie oceni żadne z nich. Zmierzyłem tylko axe-core 4.13, więc wynik 19 z 50 dotyczy tego narzędzia.
Czy wynik automatycznego testu potwierdza zgodność z WCAG 2.1?
Automatyczny test zgodności nie potwierdza. Sprawdza wybrane reguły w zbadanym stanie strony, a sensowność tekstu alternatywnego, obsługę klawiaturą złożonych komponentów czy zrozumiałość komunikatów błędów ocenia człowiek. Czysty raport to punkt startu do testów ręcznych.
Źródła
- W3C, Web Content Accessibility Guidelines (WCAG) 2.1: rekomendacja, wymagania zgodności, poziomy, uwaga do 4.1.1; kryteria policzone skryptem 24.09.2026.
- W3C WAI, What's New in WCAG 2.1: lista 17 nowych kryteriów.
- Ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych: art. 3, art. 5 i załącznik.
- W3C WAI, WCAG 2 Overview: daty wersji i aktualizacji, zgodność wsteczna, ISO/IEC 40500:2025.
- W3C, Wytyczne dla dostępności treści internetowych (WCAG) 2.1, autoryzowane tłumaczenie: polskie nazwy zasad i kryteriów; tłumaczenie z 13 kwietnia 2021 r.
- W3C WAI, What's New in WCAG 2.2: nowe kryteria i usunięcie 4.1.1.
- W3C WAI, Selecting Web Accessibility Evaluation Tools
- axe-core, API documentation: wyniki „incomplete” (do weryfikacji), tagi i reguły eksperymentalne.
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2
- W3C, Web Content Accessibility Guidelines (WCAG) 2.0
- Ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług: Polski Akt o Dostępności, wdrożenie European Accessibility Act.
- GoogleChrome/lighthouse, gatherer Accessibility: Lighthouse wstrzykuje do strony axe-core (w
package.jsonzależność axe-core ^4.13.0); stan kodu z 25.09.2026.
Dane i skrypty z pomiaru: metodologia, liczba kryteriów (JSON), lista kryteriów (CSV), porównanie z załącznikiem ustawy, wyniki skanu, mapa kryteriów, skrypt zliczający. Skan pokazuje stan moich stron z 24 września 2026 r. i nie jest oceną ich zgodności z WCAG.