Lista kontrolna dostępności strony dla małych firm i sklepów

Wyobraź sobie klientkę, która korzysta z czytnika ekranu. Znajduje buty, których szukała, wybiera rozmiar i naciska coś, co uważa za przycisk koszyka. Czytnik mówi: „przycisk”. Nic więcej. Takich przycisków na stronie są trzy i żaden nie ma nazwy, więc klientka wychodzi, a Ty nigdy się nie dowiesz dlaczego.

Tak wygląda większość problemów z dostępnością na stronach małych firm: właściciel ich nie widzi, a dla klienta to ślepa uliczka. Ta lista kontrolna jest dla osób, które prowadzą sklep na Shopify, WooCommerce, Shoperze czy Wixie albo stronę na Squarespace i nie mają programisty na etacie.

Czy strona mojej małej firmy musi być dostępna?

Jeśli sprzedajesz konsumentom w UE, prawdopodobnie tak. Europejski akt w sprawie dostępności (otwiera się w nowej karcie) obejmuje usługi handlu elektronicznego od 28 czerwca 2025 r. Główne zwolnienie dotyczy mikroprzedsiębiorstw świadczących usługi, czyli firm zatrudniających mniej niż 10 osób, których roczny obrót lub suma bilansowa nie przekracza 2 mln euro. W Polsce to samo zwolnienie przewiduje ustawa z 26 kwietnia 2024 r. (otwiera się w nowej karcie) (art. 4 pkt 1).

Handel elektroniczny oznacza tu sprzedaż na odległość, przez stronę lub aplikację, „na indywidualne żądanie konsumenta w celu zawarcia umowy konsumenckiej” (art. 3 pkt 30). Sklep internetowy czy system rezerwacji spełnia tę definicję. Zwolnienie dotyczy tylko usług: sprzedaż produktów objętych aktem, takich jak czytniki e-booków, nadal podlega przepisom o produktach (art. 4 ust. 5). Siedziba poza UE też nie pomaga, bo brytyjski sklep sprzedający klientom we Francji podlega aktowi w zakresie tej sprzedaży (art. 3 pkt 4). Przepisy krajowe i kary omawiamy w przewodniku po Europejskim akcie w sprawie dostępności.

Brytyjski Equality Act 2010 (otwiera się w nowej karcie) wymaga racjonalnych usprawnień dla osób z niepełnosprawnościami, ale nie określa normy technicznej dla stron. W USA wytyczne Departamentu Sprawiedliwości z marca 2022 r. (otwiera się w nowej karcie) mówią, że firmy otwarte dla klientów muszą zapewnić dostępność tego, co oferują online, a normy takie jak WCAG „dostarczają pomocnych wskazówek”. Bez względu na przepisy klient, który nie może dokończyć zamówienia, po prostu nie kupi.

Jakie problemy z dostępnością stron są najczęstsze?

Dominuje sześć błędów. W WebAIM Million 2026 (otwiera się w nowej karcie), automatycznym skanie miliona najpopularniejszych stron głównych z lutego 2026 r., na 95,9% stron wykryto błędy WCAG, średnio 56,1 błędu na stronę. Najczęstszym problemem był tekst o niskim kontraście, obecny na 83,9% stron głównych.

Za tymi testami stoi WCAG, czyli Wytyczne dla dostępności treści internetowych; większość przepisów odsyła do ich poziomu AA, a najnowszą wersję omawiamy w przewodniku po WCAG 2.2. Kilku punktów z poniższej listy żaden skaner nie oceni.

Czy każdy przeczyta Twoje teksty i zrozumie obrazy?

Zacznij od tego, bo te poprawki są tanie i zwykle zrobisz je samodzielnie w edytorze strony. Tekst potrzebuje wystarczającego kontrastu, obrazy niosące informację potrzebują tekstu alternatywnego, a nic nie powinno opierać się wyłącznie na kolorze. Według Colour Blind Awareness (otwiera się w nowej karcie) zaburzenia widzenia barw ma mniej więcej co dwunasty mężczyzna i co dwusetna kobieta.

• Kontrast. Zwykły tekst potrzebuje współczynnika kontrastu co najmniej 4,5:1 (otwiera się w nowej karcie) względem tła, duży tekst co najmniej 3:1. Sprawdź swoje kolory, także tekst na zdjęciach w banerach, w bezpłatnym narzędziu. Nasz poradnik o kontraście kolorów pokazuje poprawki, które nie naruszają identyfikacji wizualnej marki.
• Teksty alternatywne produktów. Opisz to, co kupujący musi wiedzieć: „Granatowy wełniany sweter z prążkowanym golfem, widok z przodu” jest lepsze niż „zdjęcie produktu 1”. Zacznij od dziesięciu najlepiej sprzedających się produktów.
• Obrazy dekoracyjne. Ozdobny zawijas w tle powinien mieć pusty tekst alternatywny, żeby czytnik ekranu go pominął. Niektóre platformy wstawiają w puste pole alt nazwę pliku, więc sprawdź, jak działa Twoja.
• Sam kolor. Informacja „Brak w magazynie” pokazana tylko jako wyszarzona próbka albo pole obowiązkowe oznaczone wyłącznie na czerwono nie dotrą do każdego. Obejrzyj stronę w trybie skali szarości w telefonie i dodaj słowo lub ikonę wszędzie tam, gdzie znika znaczenie.
• Powiększenie. Przy powiększeniu 200% w przeglądarce tekst powinien się powiększać bez nachodzenia na inne elementy i bez ucinania, a menu nadal działać.
• Język strony. Każde bezpłatne narzędzie wykryje brak deklaracji języka. To ustawienie motywu albo zmiana jednej linijki w szablonie.

Czy da się korzystać z Twojej strony za pomocą klawiatury?

Wiele osób przegląda strony bez myszy: użytkownicy czytników ekranu, osoby z drżeniem rąk lub ograniczoną ruchomością dłoni i każdy, komu właśnie padł touchpad. Odłóż mysz i naciśnij Tab. Każdy link, przycisk i pole formularza powinny być osiągalne w sensownej kolejności; zawsze powinno być widać, gdzie jesteś, a utknąć nie powinno się nigdzie.

• Widoczny fokus. Obrys powinien pokazywać, który element jest aktywny, a przyklejony nagłówek czy dymek czatu nie może go zasłaniać (kryterium 2.4.11 z WCAG 2.2, Focus Not Obscured). Wiele motywów usuwa obrys ze względów estetycznych; programista może go przywrócić.
• Żadnych pułapek. Otwórz z klawiatury menu, wybór rozmiaru, wyskakujące okna i galerię zdjęć, wybierz coś i spróbuj wyjść. Klawisz Escape powinien zamykać wyskakujące okna.
• Nazwy dla ikon. Każdy link i przycisk w postaci ikony potrzebuje nazwy, którą odczyta czytnik ekranu, np. „Koszyk, 2 produkty”. Zamiast „Kliknij tutaj” napisz, dokąd prowadzi link.
• Link pomijający i nagłówki. Najlepiej, by pierwsze naciśnięcie Tab pokazywało link „Przejdź do treści”. W ankiecie WebAIM wśród użytkowników czytników ekranu z 2024 r. (otwiera się w nowej karcie) 71,6% respondentów odpowiedziało, że długą stronę przeglądają najpierw po nagłówkach, więc używaj prawdziwych poziomów nagłówków, a nie pogrubionego tekstu.
• Cele dotykowe. WCAG 2.2 wymaga celów o wymiarach co najmniej 24 na 24 piksele CSS albo wystarczającego odstępu wokół nich (kryterium sukcesu 2.5.8 (otwiera się w nowej karcie)).

Czy każdy przejdzie przez Twoje formularze, koszyk i zamówienie?

W procesie zamówienia problemy z dostępnością kosztują Cię pieniądze bezpośrednio, więc przetestuj go od początku do końca, także to, co się dzieje, gdy coś pójdzie nie tak. Każde pole potrzebuje widocznej etykiety, komunikaty o błędach muszą słowami wyjaśniać problem, a logowanie nie powinno zależeć od testów pamięci ani łamigłówek. Strony operatora płatności też się liczą.

• Etykiety, a nie placeholdery. Tekst zastępczy znika, gdy tylko ktoś zacznie pisać, i często jest zbyt blady, by go przeczytać. Każde pole potrzebuje etykiety, która pozostaje widoczna.
• Komunikaty o błędach. Wyślij pusty formularz. Każdy błąd powinien być opisany słowami („Podaj kod pocztowy, np. 00-950”), znajdować się przy swoim polu i być odczytywany przez czytnik ekranu, a nie tylko zmieniać kolor ramki na czerwony.
• Nie pytaj dwa razy. Zaproponuj opcję „Adres rozliczeniowy taki sam jak adres dostawy”, zamiast kazać przepisywać adres. WCAG 2.2 uczyniło to wymaganiem poziomu A (3.3.7, zbędne wprowadzanie danych).
• Logowanie. Pozwól wklejać hasła i kody jednorazowe oraz korzystać z menedżerów haseł. Blokowanie wklejania narusza kryterium dostępnego uwierzytelniania (otwiera się w nowej karcie) z WCAG 2.2, chyba że oferujesz inny sposób logowania.
• CAPTCHA. W ankiecie WebAIM z 2024 r. użytkownicy czytników ekranu uznali CAPTCHA za najbardziej problematyczny element internetu. Jeśli potrzebujesz ochrony przed botami, unikaj łamigłówek wizualnych i zawsze zapewniaj alternatywę niewizualną.
• Limity czasu. Jeśli rezerwacja koszyka lub terminu wygasa, uprzedź o tym i pozwól ją przedłużyć.

Jeśli część procesu zamówienia należy do platformy lub operatora płatności, i tak ją przetestuj, zgłoś problemy i wpisz je na listę znanych ograniczeń.

A banery cookies, wyskakujące okna i czaty?

Dla klientów skrypty zewnętrzne są częścią Twojej strony. Baner cookies, którego nie da się zamknąć klawiaturą, blokuje każdą podstronę, a okno zapisu do newslettera, które przejmuje fokus w trakcie zamówienia, może zniweczyć sprzedaż. Przetestuj każdy dodany skrypt i pytaj dostawców o dostępność, zanim zainstalujesz kolejny.

• Baner cookies. Czy przyciski akceptacji i odrzucenia są osiągalne klawiszem Tab, czytelne przy powiększeniu 200% i czy potem da się wrócić do miejsca, w którym się było?
• Wyskakujące okna. Fokus powinien przejść do okna, pozostać w nim do zamknięcia, a potem wrócić na miejsce. Escape powinien je zamykać.
• Czaty. Przycisk potrzebuje nazwy, okno powinno otwierać się i zamykać z klawiatury, a na telefonie nie może zasłaniać przycisku „Zapłać teraz”.
• Karuzele. Wszystko, co porusza się automatycznie dłużej niż pięć sekund, musi mieć możliwość wstrzymania, zatrzymania lub ukrycia (WCAG 2.2 (otwiera się w nowej karcie), kryterium sukcesu 2.2.2).
• Elementy osadzone. Widżety opinii, mapy i narzędzia rezerwacji też są na Twojej stronie. Błędy zgłaszaj dostawcy.

Czy Twoje filmy, PDF-y i menu działają dla każdego?

Filmy potrzebują napisów, nagrania audio transkrypcji, a ważne informacje nie powinny istnieć wyłącznie w PDF-ie lub na obrazie. Restauracja z menu w postaci zeskanowanego PDF-a albo sklep z tabelą rozmiarów jako zdjęciem wykluczają użytkowników czytników ekranu i każdego, kto musi powiększać treść na telefonie.

• Napisy i transkrypcje. Popraw automatyczne napisy przed publikacją. Podcasty potrzebują wersji tekstowej.
• Tekst na obrazkach. Menu, cenniki, tabele rozmiarów i godziny otwarcia umieść na zwykłej stronie. Jeśli PDF jest konieczny, wyeksportuj go z edytora tekstu z nagłówkami i znacznikami, zamiast skanować wydruk.
• Starsze pliki. EAA nie wymaga poprawiania plików biurowych ani nagranych wcześniej materiałów audio i wideo opublikowanych przed 28 czerwca 2025 r. ani archiwów, których już nie aktualizujesz (art. 2 ust. 4). Nowe pliki są objęte przepisami.

Co można naprawić samodzielnie, a kiedy potrzebny jest programista lub audyt?

Większość problemów z treścią naprawisz samodzielnie w CMS-ie: teksty alternatywne, nagłówki, treść linków, kolory, napisy i wiele etykiet pól. Problemy na poziomie motywu, takie jak brak stylów fokusu, pułapki klawiaturowe czy niestandardowe listy rozwijane, wymagają programisty. Audyt ma największy sens po naprawieniu podstaw albo przed wdrożeniem nowego projektu strony.

Gdzie w tym miejsce na widżet taki jak nasz? Panel po stronie odwiedzającego, taki jak SiteAccessible, pozwala zwiększyć kontrast, powiększyć tekst albo włączyć linijkę do czytania. To pomaga części odwiedzających, ale nie odhacza żadnego punktu z tej listy: przycisk bez nazwy nadal jest bez nazwy, a pułapka klawiaturowa nadal jest pułapką. Najpierw napraw stronę, a widżet traktuj jako dodatek.

Jak udokumentować wykonaną pracę?

Prowadź prosty rejestr: co i kiedy przetestowano, co naprawiono, a co wciąż nie działa, a potem opublikuj rzetelne podsumowanie w deklaracji dostępności. Jeśli obejmuje Cię EAA, musisz też opublikować informacje o tym, jak Twoja usługa spełnia wymagania dostępności, zwykle w regulaminie lub równoważnym dokumencie.

Ten drugi obowiązek wynika z załącznika V dyrektywy, a formę określa prawo krajowe. Nasz poradnik o pisaniu deklaracji dostępności zawiera szablon do dostosowania. Potem trzymaj się rytmu:

1. Przejdź listę kontrolną na trzech kluczowych stronach i zrób zrzut ekranu każdego błędu.
2. W tym tygodniu samodzielnie popraw punkty dotyczące treści.
3. Przekaż programiście punkty dotyczące motywu i procesu zamówienia, zaczynając od najpoważniejszych.
4. Sprawdź każdą poprawkę ponownie, klawiaturą i narzędziem automatycznym.
5. Opublikuj lub zaktualizuj deklarację, z datą.
6. Powtarzaj to przy każdej nowej aplikacji, zmianie motywu czy nowej stronie docelowej.