Dostępność cyfrowa i WCAG 2.2 a konwersja

Dostępność cyfrowa oznacza, że strona, sklep lub aplikacja pozostają zrozumiałe i możliwe do obsłużenia przez osoby o różnych potrzebach, także korzystające z klawiatury, czytnika ekranu lub powiększenia. WCAG 2.2 to standard W3C zawierający sprawdzalne kryteria na poziomach A, AA i AAA. Wiele z nich dotyczy elementów ważnych również dla użyteczności: etykiet pól, widocznego fokusu, zrozumiałych komunikatów błędów i odpowiednio dużych obszarów klikalnych. Usunięcie takich barier pomaga osobom z niepełnosprawnościami, a często ułatwia korzystanie z serwisu także pozostałym użytkownikom.

Ten wpis nie jest przewodnikiem referencyjnym po WCAG ani instrukcją wdrożeniową dla zespołu deweloperskiego. Pełne definicje kryteriów są w dokumentach W3C i nie ma sensu ich tu przepisywać. Chodzi o coś innego: gdzie dostępność i optymalizacja konwersji rozwiązują dokładnie ten sam problem, jak to sprawdzić bez budżetu na audyt zewnętrzny i jak wpiąć poprawki w jedną kolejkę zadań. Czym jest sama dyscyplina CRO, opisuje osobny wpis: czym jest optymalizacja konwersji.

W skrócie

• Obszar wspólny dostępności i użyteczności jest duży. Kontrast, kolejność fokusu, obsługa klawiaturą, etykiety pól, zrozumiałe komunikaty błędów i wielkość celów dotykowych to jednocześnie kryteria WCAG i klasyczne przyczyny porzuceń.
• WCAG 2.2 dodało dziewięć nowych kryteriów sukcesu i usunęło jedno (4.1.1 Parsing). Kilka z nowych dotyczy dokładnie tych miejsc, w których pieniądze wyciekają najszybciej: formularzy, logowania i interakcji przeciąganiem.
• Poziom AA jest praktycznym punktem odniesienia w rozmowach o zgodności — poziom A to minimum, AAA nie jest realistyczny jako wymóg dla całego serwisu.
• Najwięcej widać w koszyku i w formularzach, bo tam ścieżka jest długa, kroków jest wiele, a każda przerwa w obsłudze klawiaturą albo niejasny błąd kończy się wyjściem.
• Testy ręczne i automatyczne uzupełniają się. Klawiatura, powiększenie i kontrola formularzy pokazują problemy w użyciu, a skaner szybko wykrywa powtarzalne błędy techniczne. Test z czytnikiem ekranu powinien prowadzić ktoś, kto umie poprawnie korzystać z tej technologii.
• Automat rozstrzyga tylko warunki maszynowo weryfikowalne. Dokumentacja W3C wprost pokazuje granicę: test automatyczny stwierdzi brak atrybutu alt, ale ocena, czy tekst alternatywny jest właściwy, wymaga obejrzenia obrazu w kontekście.
• Poprawki warto połączyć z planem rozwoju produktu i konwersji, zachowując przy tym wymagania dostępności jako osobne kryterium akceptacji. Bariera prawna lub blokująca zadanie nie powinna czekać na test biznesowy.
• Najtaniej naprawia się w systemie projektowym. Poprawka w komponencie pola, przycisku i modala rozwiązuje ten sam defekt na wszystkich stronach naraz.
• Polski Akt o Dostępności obowiązuje od 28 czerwca 2025 roku i obejmuje między innymi wskazane w ustawie usługi handlu elektronicznego. Ustawa przewiduje wyłączenia, w tym dla usług oferowanych lub świadczonych przez mikroprzedsiębiorców. Zakres obowiązków konkretnej firmy wymaga oceny prawnej.

Gdzie dostępność i użyteczność to ten sam problem

Rozdzielanie tych dwóch obszarów jest wygodne organizacyjnie i bezsensowne merytorycznie. Użytkownik korzystający z czytnika ekranu i użytkownik w pośpiechu na telefonie w tramwaju wywracają się na tych samych elementach — pierwszy zawsze, drugi czasem. Kryterium dostępności bywa więc po prostu ostrzejszym testem tej samej rzeczy, którą i tak bada się w CRO.

Ta tabela jest jednocześnie listą hipotez do pracy nad konwersją. Żadna z pozycji nie wymaga zakładania, że użytkownik ma niepełnosprawność, żeby uzasadnić poprawkę.

Co z tego widać w koszyku i w formularzach

Ścieżka zakupowa i formularz kontaktowy są miejscami, w których defekty dostępności najszybciej zamieniają się w utraconą sprzedaż, bo intencja jest już wysoka, a użytkownik ma za sobą inwestycję czasu. Kilka wzorców wraca w audytach niezależnie od branży i technologii.

Fokus, który gubi się przy modalach. Otwarcie okna z wyborem punktu odbioru, formularzem rabatu albo zgodami zostawia fokus na tle. Użytkownik klawiatury tabuluje po niewidocznej treści pod spodem, a po zamknięciu okna wraca na początek strony i przewija cały koszyk od nowa. To defekt z kategorii 2.4.3 i 2.1.1, a mierzalnym objawem jest porzucenie dokładnie na tym kroku.

Placeholder w roli etykiety. Rozwiązanie wygląda czysto w projekcie i psuje się przy pierwszej poprawce danych: po wpisaniu treści nie widać już, czego dotyczy pole. Przy dłuższym formularzu rozliczeniowym oznacza to zgadywanie, w którym polu jest numer domu, a w którym lokalu. Kryterium 3.3.2 wymaga etykiety obecnej cały czas — i to jest też najprostsza poprawka konwersyjna w całej tej liście.

Błąd bez adresu i bez wskazówki. Formularz zwraca komunikat na górze strony, bez przeniesienia fokusu i bez wskazania pola. Użytkownik czytnika nie dowiaduje się, że coś się stało; użytkownik widzący szuka czerwonej ramki, której nie ma, bo jedynym oznaczeniem jest kolor tekstu. Kryteria 3.3.1 i 3.3.3 opisują ten przypadek dokładnie: błąd musi być wskazany tekstem i uzupełniony podpowiedzią naprawy, jeśli naprawa jest znana.

Powtórne wpisywanie tych samych danych. Adres dostawy, potem ten sam adres jako dane do faktury, potem raz jeszcze numer telefonu do kuriera. Kryterium 3.3.7 traktuje to jako defekt, nie niedogodność — i jest to jeden z niewielu przypadków, w których wymóg dostępności wprost skraca formularz.

Logowanie i kody jednorazowe. Blokada wklejania w polu kodu, wymóg przepisania go z pamięci, test wymagający rozpoznania obrazków. Kryterium 3.3.8 wymaga dostępności alternatywnej metody. W praktyce to najbardziej kosztowny defekt w serwisach z kontem użytkownika, bo dotyczy klientów wracających, czyli tych najtańszych w pozyskaniu.

Interakcje oparte wyłącznie na przeciąganiu. Suwaki cen, przeciąganie do porównania, sortowanie listy życzeń. Kryterium 2.5.7 wymaga alternatywy dla przeciągania — a alternatywa w postaci dwóch pól z zakresem ceny bywa po prostu szybsza dla wszystkich.

Zbyt małe cele dotykowe. Kryterium 2.5.8 podaje konkretną wartość: co najmniej 24 × 24 piksele CSS dla celu wskaźnika (z wyjątkami opisanymi w dokumencie). Najczęściej łamią ją krzyżyki usuwania z koszyka, steppery ilości i ikony w tabelach porównawczych. Objawem w danych o zachowaniu są powtórzone kliknięcia obok elementu — jak je czytać, opisuje wpis o nagraniach sesji i mapach ciepła.

Słowniczek

• WCAG — Web Content Accessibility Guidelines, rekomendacja W3C definiująca sprawdzalne kryteria dostępności treści internetowych; aktualna wersja to 2.2.
• Kryterium sukcesu — pojedynczy, testowalny warunek w WCAG, przypisany do poziomu A, AA albo AAA.
• Poziom AA — poziom zgodności obejmujący kryteria A i AA; w praktyce rynkowej i regulacyjnej najczęstszy punkt odniesienia.
• Czytnik ekranu — program odczytujący interfejs głosem lub na monitor brajlowski; na Windows najpopularniejszy jest NVDA, w systemach Apple VoiceOver, na Androidzie TalkBack.
• Kolejność fokusu — kolejność, w jakiej elementy interaktywne otrzymują zaznaczenie przy nawigacji tabulatorem; powinna odpowiadać logicznej kolejności treści.
• Nazwa dostępna — tekst, którym element jest identyfikowany przez technologie asystujące; dla pola formularza wynika najczęściej z powiązanej etykiety.
• Cel dotykowy — obszar, który da się kliknąć lub dotknąć, żeby wywołać akcję; kryterium 2.5.8 podaje dla niego minimalny rozmiar.
• EN 301 549 — europejska norma dostępności produktów i usług ICT, przenosząca wymagania WCAG na grunt europejskich regulacji i zamówień; kolejne wersje aktualizują odniesienie do wersji WCAG.

Jak sprawdzić dostępność: testy ręczne i automatyczne

Szybki przegląd warto prowadzić dwiema ścieżkami. Testy ręczne pokazują, czy ważne zadanie da się ukończyć, a narzędzia automatyczne szybko znajdują część powtarzalnych błędów w wielu szablonach. Kolejność można dopasować do zespołu, ale żadna z tych metod nie zastępuje drugiej ani pełnej oceny zgodności prowadzonej przez kompetentnego audytora.

Krok pierwszy: przejście ścieżki wyłącznie klawiaturą. Od strony produktu, przez dodanie do koszyka, wybór dostawy i płatności, aż po potwierdzenie zamówienia — tabulatorem, strzałkami, spacją i enterem, bez dotykania myszy. Notowane są trzy rzeczy: gdzie nie widać fokusu, gdzie fokus przeskakuje wbrew układowi strony i gdzie ścieżka się kończy, bo elementu nie da się aktywować. Ten jeden przebieg zwykle znajduje więcej problemów niż cały automatyczny raport.

Krok drugi: test z czytnikiem ekranu. Taki test powinien prowadzić doświadczony badacz lub użytkownik technologii asystującej. Osoba, która dopiero poznaje NVDA, VoiceOver lub TalkBack, może pomylić barierę serwisu z nieznajomością obsługi narzędzia. Należy sprawdzić między innymi nazwy pól i przycisków, komunikowanie zmiany stanu, obsługę błędów oraz dostępność treści otwieranej w modalach.

Krok trzeci: powiększenie i zmiana rozmiaru tekstu. Widok przy dwukrotnym powiększeniu pokazuje, czy przyklejone paski nie zjadają ekranu, czy podsumowanie koszyka nie ucieka poza widok i czy przycisk zamówienia pozostaje osiągalny. To także najszybszy test na treści dostępne wyłącznie po najechaniu myszą.

Krok czwarty: kontrast i stany elementów. Sprawdzane są wartości dla tekstu, dla obramowań pól i dla stanów: aktywny, nieaktywny, z błędem, w fokusie. Najczęstszym defektem nie jest tekst główny, a właśnie stan nieaktywny i komunikat błędu.

Krok piąty: skan automatyczny i analiza wyników. Skaner uruchomiony na kluczowych szablonach — stronie produktu, kategorii, koszyku, procesie zakupu, formularzu kontaktowym i logowaniu — daje listę potencjalnych błędów technicznych. Narzędzia takie jak axe DevTools, WAVE i Lighthouse pomagają w przeglądzie, ale wynik wymaga weryfikacji przez człowieka.

Dlaczego automat wyłapuje tylko część

Narzędzia automatyczne rozstrzygają wyłącznie warunki, które da się sprawdzić maszynowo: obecność atrybutu, wyliczalny stosunek kontrastu, poprawność struktury nagłówków, powiązanie etykiety z polem, poprawność użycia atrybutów ARIA. Nie rozstrzygają niczego, co wymaga sądu o znaczeniu albo o zachowaniu interfejsu w czasie. Dokumentacja W3C pokazuje tę granicę na najprostszym przykładzie: test automatyczny stwierdzi, że atrybut alt jest nieobecny, ale ocena, czy tekst alternatywny jest właściwy, wymaga obejrzenia obrazu i osądzenia go w kontekście.

Wniosek jest prosty: ani wysoki wynik punktowy, ani pojedynczy komunikat błędu nie rozstrzygają zgodności. W3C zaznacza, że narzędzia mogą zwracać wyniki fałszywe lub mylące i nie potrafią samodzielnie ocenić dostępności. Dobrze sprawdzają się jako wsparcie audytu, kontrola powtarzalnych reguł i zabezpieczenie przed regresją. Ostateczna ocena wymaga wiedzy eksperckiej, testów ręcznych i właściwego zakresu stron.

Jak wpiąć to w backlog razem z pracą nad konwersją

Osobny projekt „dostępność" prowadzi zwykle do jednorazowego raportu i zerowego wdrożenia, bo konkuruje o zasoby z pracą, która ma przypisany przychód. Skuteczniejsze jest wejście tymi samymi drzwiami, co reszta optymalizacji: jeden backlog, jedno kryterium szeregowania, jedna definicja ukończenia.

Szeregowanie po wpływie i koszcie. Pozycja w kolejce zależy od tego, na ilu krokach ścieżki zakupowej defekt występuje, ile użytkowników go dotyka, czy blokuje ukończenie zadania i ile kosztuje poprawka. Blokada w checkoucie wygrywa z brakiem tekstu alternatywnego na blogu, choć oba są defektami dostępności.

Trzy kategorie zamiast jednej listy. Blokery ścieżki (nie da się ukończyć zadania), defekty formularzy i koszyka (da się, ale drożej i z porzuceniami) oraz reszta. Pierwsza kategoria wchodzi jako naprawa błędu, nie jako usprawnienie — i nie czeka na kwartalne planowanie.

Poprawka w systemie projektowym, nie na stronie. Pole formularza, przycisk, modal, komunikat błędu i pasek zgód to komponenty. Naprawa w komponencie usuwa ten sam defekt na wszystkich szablonach naraz, a naprawa na jednej stronie wraca przy następnym wdrożeniu.

Definicja ukończenia dla komponentu. Warto ją zapisać raz: obsługa klawiaturą, widoczny fokus, nazwa dostępna, stan błędu opisany tekstem, minimalny rozmiar celu dotykowego, kontrast dla wszystkich stanów. To krótka lista i przenosi ciężar z audytów na moment wytwarzania.

Relacja do testów A/B. Poprawki dostępności typu „bloker" wdraża się bez testu, bo test na ścieżce, której część użytkowników nie może ukończyć, mierzy zepsuty stan. Testowanie ma sens dla wariantów rozwiązania — na przykład dwóch sposobów pokazania błędów w długim formularzu — a nie dla decyzji, czy błąd naprawiać.

Ten sposób pracy jest tym samym, co układanie backlogu w audycie UX: dowody z zachowania użytkowników, przegląd heurystyczny, ścieżka zakupowa oraz szybkość i dostępność dają jedną kolejkę zadań uszeregowaną po wpływie i koszcie wdrożenia, a nie osobne raporty dla osobnych specjalizacji.

Polski Akt o Dostępności: najważniejszy kontekst prawny

Europejski Akt o Dostępności to dyrektywa (UE) 2019/882 wdrożona w Polsce ustawą z 26 kwietnia 2024 roku, nazywaną Polskim Aktem o Dostępności. Przepisy stosuje się od 28 czerwca 2025 roku. Obejmują określone produkty i usługi, w tym usługi handlu elektronicznego, bankowość detaliczną, e-booki, wybrane usługi transportu pasażerskiego oraz łączność elektroniczną. Oficjalny serwis gov.pl wskazuje, że ustawy nie stosuje się do usług oferowanych lub świadczonych przez mikroprzedsiębiorców; występują również inne wyłączenia i przepisy przejściowe.

WCAG 2.2 jest wartościowym celem technicznym, ale samo spełnienie wybranej listy kryteriów nie stanowi automatycznie opinii o zgodności z Polskim Aktem o Dostępności. Zakres obowiązków zależy od rodzaju usługi, wielkości podmiotu, rynku i wyjątków przewidzianych w ustawie. Agencja może przeprowadzić ocenę techniczną, wskazać bariery, przygotować plan napraw i udokumentować wdrożenia. Ocena prawna oraz formalna deklaracja zgodności powinny należeć do odpowiednio uprawnionych specjalistów po stronie firmy.

Z praktycznego punktu widzenia porządek pracy nie zależy od tej oceny. Defekty z tabeli wyżej są warte naprawy z powodu konwersji niezależnie od tego, jaki jest wynik analizy prawnej — a jeśli wynik będzie taki, że przepisy obejmują daną działalność, serwis jest wtedy bliżej wymagań, zamiast zaczynać od zera pod terminem.

Jak podchodzimy do tego w Space Ads

Zaczynamy od ustalenia najważniejszych zadań użytkownika i reprezentatywnych szablonów. Każdą ścieżkę sprawdzamy klawiaturą, przy powiększeniu oraz — z udziałem osoby znającej technologię — czytnikiem ekranu. Skan automatyczny wykorzystujemy równolegle do znalezienia błędów powtarzających się w komponentach. Wyniki łączymy w jeden plan prac, lecz bariery dostępności traktujemy jako wymagania do usunięcia, a nie hipotezy, które muszą wygrać test A/B. Poprawki kierujemy do systemu projektowego i wspólnych komponentów, aby działały na wszystkich szablonach i nie wracały przy kolejnym wdrożeniu. Zakres techniczny dokumentujemy, ale nie zastępujemy nim oceny prawnej.

Plan działania

1. Przejść ścieżkę zakupową i formularz kontaktowy wyłącznie klawiaturą. Zanotować miejsca bez widocznego fokusu, przeskoki wbrew układowi strony i elementy, których nie da się aktywować.
2. Zaplanować test z czytnikiem ekranu. Zaangażować osobę, która sprawnie korzysta z wybranej technologii asystującej; sprawdzić nazwy pól, przyciski, zmianę stanu i obsługę błędów.
3. Obejrzeć ścieżkę przy dwukrotnym powiększeniu. Zweryfikować przyklejone paski, banery zgód i osiągalność przycisku zamówienia.
4. Zmierzyć kontrast dla wszystkich stanów elementów. Aktywny, nieaktywny, z błędem, w fokusie — nie tylko dla tekstu głównego.
5. Naprawić etykiety pól przed czymkolwiek innym. Etykieta widoczna cały czas, powiązana z polem, plus opis wymaganego formatu tam, gdzie format jest nieoczywisty.
6. Uporządkować obsługę błędów w formularzach. Komunikat tekstowy przy polu, przeniesienie fokusu do pierwszego błędu, podpowiedź naprawy, oznaczenie inne niż sam kolor.
7. Usunąć powtórne wpisywanie danych. Przeniesienie adresu dostawy do danych rozliczeniowych, brak blokady wklejania w polach kodów.
8. Dodać alternatywę dla interakcji przeciąganiem. Pola zakresu obok suwaka ceny, przyciski obok przeciągania.
9. Powiększyć cele dotykowe w koszyku. Usuwanie produktu, stepper ilości, ikony w tabelach — do co najmniej minimalnego rozmiaru z kryterium 2.5.8.
10. Uruchomić skaner na wszystkich szablonach. Traktować wynik jako listę regresji, nie jako ocenę dostępności.
11. Wpiąć defekty do jednego backlogu z pracą konwersyjną. Szeregować po wpływie na ukończenie ścieżki i koszcie wdrożenia; blokery jako naprawa błędu.
12. Zapisać definicję ukończenia dla komponentów. Klawiatura, fokus, nazwa dostępna, stan błędu, rozmiar celu, kontrast stanów — sprawdzane przy wytwarzaniu, nie w audycie.

Częsty błąd → co zrobić zamiast tego

Najczęstsze pytania

Czym jest dostępność cyfrowa w praktyce?

Dostępność cyfrowa to zdolność serwisu do obsłużenia użytkownika niezależnie od sposobu korzystania: klawiaturą zamiast myszy, czytnikiem ekranu, powiększeniem, jedną ręką na telefonie. W praktyce oznacza to zestaw konkretnych warunków — czytelny kontrast, logiczną kolejność fokusu, pełną obsługę klawiaturą, etykiety pól, zrozumiałe komunikaty błędów i wystarczająco duże cele dotykowe.

Czym różni się WCAG 2.2 od WCAG 2.1?

WCAG 2.2 dodało dziewięć nowych kryteriów sukcesu i usunęło jedno (4.1.1 Parsing). Nowe kryteria dotyczą między innymi zasłaniania elementu w fokusie, alternatywy dla interakcji przeciąganiem, minimalnego rozmiaru celu dotykowego, spójnego umiejscowienia pomocy, powtórnego wpisywania danych oraz dostępnego uwierzytelniania. Kryteria z wersji 2.1 pozostają w mocy.

Czy poprawa dostępności zwiększa konwersję?

Część poprawek działa dokładnie tak samo jak klasyczne usprawnienia konwersyjne, bo dotyczy tych samych defektów: brakujących etykiet, niejasnych błędów, zbyt małych elementów klikalnych i przerwanej obsługi klawiaturą. Skala efektu zależy od serwisu i musi zostać zmierzona na własnych danych — poprawki tego typu nie mają uniwersalnego, przenośnego wyniku.

Który poziom zgodności WCAG przyjąć jako cel?

Praktycznym punktem odniesienia jest poziom AA, obejmujący kryteria poziomów A i AA. Poziom A jest minimum, które nie wystarcza do sensownej obsługi typowej ścieżki zakupowej, a poziom AAA zawiera wymagania trudne do spełnienia dla całego serwisu i zwykle traktowane wybiórczo.

Czy narzędzia automatyczne wystarczą do sprawdzenia dostępności?

Nie. Narzędzia automatyczne pomagają wykrywać braki atrybutów, część problemów z kontrastem, strukturą i składnią ARIA. Nie ocenią jednak wszystkich kryteriów, a niektóre wyniki mogą być fałszywe lub wymagać interpretacji. Pełna ocena łączy narzędzia z testami ręcznymi i wiedzą o sposobie korzystania z technologii asystujących.

Od czego zacząć, jeśli budżet jest mały?

Od przejścia ścieżki zakupowej i głównego formularza wyłącznie klawiaturą, a następnie od naprawy etykiet pól i komunikatów błędów. Ten zakres nie wymaga narzędzi ani zewnętrznego audytu, a dotyka miejsc o najwyższej wartości transakcyjnej. Poprawki warto wprowadzać w komponentach systemu projektowego, żeby objęły wszystkie szablony naraz.

Czy europejski akt o dostępności dotyczy każdej firmy?

Nie w sposób automatyczny. Europejski akt o dostępności to dyrektywa UE wdrażana przepisami krajowymi, a jej wymagania obejmują określone kategorie produktów i usług cyfrowych, z wyjątkami przewidzianymi w tych przepisach. Ocena, czy i w jakim zakresie dotyczą konkretnej działalności, należy do prawników danej firmy — agencja może dostarczyć stan techniczny serwisu i backlog poprawek, nie opinię prawną.

Czy dostępność wpływa na SEO?

Częściowo się pokrywają, ale to nie to samo. Poprawna struktura nagłówków, sensowne teksty alternatywne, opisowe nazwy odnośników i czytelna treść pomagają zarówno technologiom asystującym, jak i robotom wyszukiwarek. Większość kryteriów WCAG dotyczy jednak interakcji — fokusu, klawiatury, obsługi błędów — i nie ma odpowiednika w sygnałach wyszukiwarek.

Najważniejsze

• Znaczna część kryteriów WCAG 2.2 opisuje jednocześnie zwykłe defekty użyteczności, więc dostępność i praca nad konwersją naprawiają w tych miejscach ten sam problem.
• Najwięcej widać w koszyku i formularzach: gubiony fokus przy modalach, placeholder w roli etykiety, błąd bez wskazówki, powtórne wpisywanie danych, blokada wklejania kodu, interakcje tylko przeciąganiem i zbyt małe cele dotykowe.
• WCAG 2.2 dodało dziewięć kryteriów i usunęło 4.1.1 Parsing; poziom AA jest praktycznym punktem odniesienia.
• Ocena powinna łączyć przejście klawiaturą, powiększenie, test z czytnikiem ekranu prowadzony przez kompetentną osobę oraz narzędzia automatyczne.
• Skaner nie potwierdza zgodności i może zwracać wyniki wymagające ręcznej weryfikacji; najlepiej służy do wykrywania powtarzalnych problemów i regresji.
• Poprawki należą do jednego backlogu z pracą konwersyjną, szeregowanego po wpływie na ukończenie ścieżki i koszcie wdrożenia, a wdrażane są w komponentach systemu projektowego.
• Polski Akt o Dostępności stosuje się od 28 czerwca 2025 roku do wskazanych produktów i usług, w tym e-handlu, z ustawowymi wyłączeniami; zakres obowiązków konkretnej firmy wymaga oceny prawnej.

Źródła i dalsza lektura

• W3C — Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI — How to Meet WCAG 2.2 (Quick Reference)
• W3C WAI — Easy Checks – A First Review of Web Accessibility
• W3C WAI — Selecting Web Accessibility Evaluation Tools
• EUR-Lex — Dyrektywa (UE) 2019/882 (europejski akt o dostępności)
• ISAP — Ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze
• Gov.pl — Polski Akt o Dostępności — usługi handlu elektronicznego

Numery i poziomy kryteriów odpowiadają dokumentowi WCAG 2.2 na stan lipiec 2026, a stan przepisów krajowych i wersje norm zharmonizowanych zmieniają się niezależnie od treści poradników — przed decyzją opartą na konkretnym wymogu warto sprawdzić aktualne teksty źródłowe.

Czytaj dalej

• Czym jest optymalizacja konwersji i jak zwiększyć sprzedaż za pomocą CRO
• Błędy na landing page, które zabijają konwersję
• Jak wykonać audyt sklepu internetowego
• Microsoft Clarity vs Hotjar — jak czytać nagrania i mapy ciepła
• Czym jest i jak zwiększyć współczynnik konwersji
• Audyt UX