Najważniejsze wnioski
- Informacja o dostępności usługi opisuje faktyczny poziom dostępności, sposoby korzystania z usługi, ograniczenia oraz dostępne formy wsparcia.
- Nie należy mylić informacji o dostępności usługi z deklaracją dostępności publikowaną przez podmioty publiczne na podstawie odrębnych przepisów.
- Treść informacji musi być spójna z rzeczywistym działaniem sklepu, formularzy, płatności, obsługi klienta i dokumentów udostępnianych użytkownikowi.
- Widget dostępności może ułatwiać odbiór części treści i interfejsu, ale nie zastępuje audytu, testów ani napraw źródłowych w kodzie i treści.
- Najbezpieczniejszy proces to: ustalenie zakresu usługi, testy krytycznych ścieżek, opis potwierdzonych funkcji i ograniczeń, publikacja oraz regularna aktualizacja.
Dla zarządzającego
Informacja o dostępności usługi pomaga uporządkować odpowiedzialność za dostępność w firmie. Nie powinna być marketingową deklaracją bez pokrycia, lecz krótkim, aktualnym opisem tego, co użytkownik może zrobić samodzielnie, gdzie potrzebuje wsparcia i jakie bariery firma nadal usuwa.
Dla sprzedaży
Dobrze przygotowana informacja zmniejsza niepewność klientów przed zakupem lub kontaktem. Zespół sprzedaży i obsługi klienta powinien znać jej treść, umieć wskazać dostępne kanały wsparcia oraz nie obiecywać funkcji, których sklep albo usługa faktycznie nie zapewnia.
Informacja o dostępności usługi to praktyczny opis, który pozwala użytkownikowi ocenić, czy może samodzielnie skorzystać z oferty, strony, aplikacji, formularza, płatności albo obsługi klienta. Powinna odpowiadać na konkretne pytania: co jest dostępne, jak z tego skorzystać, jakie ograniczenia są znane i gdzie uzyskać pomoc.
W e-commerce taka informacja nie powinna kończyć się na zdaniu „nasza strona jest dostępna”. Sklep internetowy jest usługą złożoną z wielu etapów: wyszukania produktu, wyboru wariantu, koszyka, logowania, dostawy, płatności, kontaktu i obsługi posprzedażowej. Każdy z tych etapów może mieć inne bariery.
Najważniejsze wnioski
- Opisuj dostępność usługi, a nie intencje firmy.
- Wskazuj zarówno dostępne funkcje, jak i znane ograniczenia.
- Nie deklaruj pełnej zgodności z WCAG ani PAD bez odpowiedniej weryfikacji.
- Traktuj informację jako dokument aktualizowany po zmianie motywu, checkoutu, formularza lub integracji.
- Zapewnij łatwy kontakt dla osoby, która nie może ukończyć procesu samodzielnie.
Czym jest informacja o dostępności usługi?
To informacja przeznaczona dla odbiorcy usługi. Ma pomóc mu zrozumieć sposób korzystania z oferty oraz dowiedzieć się, czy usługa uwzględnia potrzeby osób korzystających z klawiatury, czytnika ekranu, powiększenia, alternatywnych sposobów percepcji treści lub wsparcia pracownika.
W kontekście ustawy o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług, określanej potocznie jako Polski Akt o Dostępności (PAD), obowiązki zależą od rodzaju usługi i statusu przedsiębiorcy. Ustawa obejmuje wskazane w niej produkty i usługi, a nie każdą działalność bez wyjątku. Dlatego przed publikacją warto najpierw ustalić, czy dana firma i dana usługa znajdują się w zakresie regulacji.
Stan prawny: 24 lutego 2026 r. Materiał ma charakter informacyjny, nie stanowi porady prawnej ani indywidualnej oceny obowiązków przedsiębiorcy.
Rzetelna informacja o dostępności nie mówi, że problemów nie ma. Mówi użytkownikowi, co może zrobić bez przeszkód, czego może się spodziewać i gdzie otrzyma pomoc.
Czy informacja o dostępności usługi to deklaracja dostępności?
Nie zawsze. Te pojęcia są często używane zamiennie, ale mogą oznaczać różne dokumenty i różne obowiązki.
| Element | Informacja o dostępności usługi | Deklaracja dostępności |
|---|---|---|
| Główny cel | Opisuje dostępność konkretnej usługi dla użytkownika. | Informuje o stanie dostępności strony lub aplikacji podmiotu objętego odrębnymi przepisami. |
| Typowy odbiorca | Klient sklepu, użytkownik platformy, osoba korzystająca z usługi cyfrowej. | Użytkownik serwisu albo aplikacji podmiotu publicznego. |
| Zakres | Może obejmować stronę, proces zakupowy, dokumenty, kontakt i wsparcie. | Dotyczy zakresu wskazanego w przepisach o dostępności cyfrowej stron i aplikacji mobilnych podmiotów publicznych. |
| Treść praktyczna | Funkcje, ograniczenia, alternatywy, kontakt, aktualizacja. | Status dostępności, niedostępne treści, przygotowanie deklaracji i procedura zgłoszeniowa. |
| Ryzyko błędnego użycia | Ogólnik bez pokrycia w rzeczywistym działaniu usługi. | Skopiowanie wzoru bez sprawdzenia strony lub aplikacji. |
Jeżeli prowadzisz sklep lub usługę komercyjną, nie kopiuj automatycznie deklaracji dostępności podmiotu publicznego. Najpierw określ podstawę prawną i zakres obowiązków. W przypadku wątpliwości dotyczących PAD przydatnym punktem wyjścia jest artykuł Mikroprzedsiębiorca a PAD: kiedy dotyczy e-commerce?.
Kiedy e-commerce powinien przygotować taką informację?
Warto przygotować ją niezależnie od tego, czy firma po analizie uzna, że podlega konkretnemu obowiązkowi ustawowemu. Jest użyteczna operacyjnie: porządkuje wiedzę zespołu, pomaga obsłudze klienta i pozwala użytkownikowi szybciej uzyskać realną pomoc.
Jeżeli firma świadczy usługę objętą PAD, treść, forma, miejsce publikacji i sposób aktualizacji wymagają dokładnego odniesienia do ustawy oraz jej załączników. W szczególności trzeba odróżnić:
- ustawę PAD – akt prawny określający zakres i obowiązki dotyczące wybranych produktów oraz usług;
- EN 301 549 – normę techniczną dotyczącą wymagań dostępności ICT;
- WCAG – wytyczne W3C dotyczące dostępności treści internetowych.
WCAGbot Accessibility Path dla informacji o dostępności usługi
Nie należy sprowadzać całego obowiązku informacyjnego ani całej dostępności usługi wyłącznie do hasła „WCAG 2.1 AA”. WCAG jest ważnym punktem odniesienia dla stron i aplikacji, ale usługa może obejmować również regulaminy, kanały komunikacji, informacje o produkcie, dokumenty, proces płatności czy obsługę klienta.
Co powinna zawierać informacja o dostępności usługi?
Najlepsza treść jest konkretna, zrozumiała i możliwa do sprawdzenia. Poniższa struktura sprawdzi się jako roboczy szablon dla sklepu lub platformy.
1. Nazwa oraz zakres usługi
Wskaż, czego dokument dotyczy. Zamiast pisać „strona firmy”, napisz na przykład: „Sklep internetowy umożliwiający przeglądanie produktów, dodawanie ich do koszyka, złożenie zamówienia, wybór dostawy, płatność online i kontakt z obsługą klienta”.
2. Sposób korzystania z usługi
Wyjaśnij, jakie kanały są dostępne: strona www, aplikacja, telefon, e-mail, czat, punkt stacjonarny lub pomoc konsultanta. Podaj, czy do zakupu wymagane jest konto, akceptacja plików cookie, potwierdzenie SMS albo użycie zewnętrznego operatora płatności.
3. Dostępne funkcje wspierające użytkownika
Wymieniaj tylko funkcje, które faktycznie działają i których zakres znasz. Przykładowo:
- obsługa wybranych obszarów klawiaturą;
- widoczny fokus w elementach interaktywnych;
- możliwość powiększenia tekstu bez utraty podstawowej funkcjonalności;
- teksty alternatywne przy części obrazów informacyjnych;
- komunikaty błędów przy formularzach;
- funkcje wspierające dostępność uruchamiane przez widget.
Jeśli korzystasz z WCAGbot, opisuj go precyzyjnie. Narzędzie może udostępniać między innymi tryby kontrastu, skalę szarości, zmianę czytelności tekstu, powiększenie tekstu, odstępów i interlinii, czytanie treści, większy kursor, funkcje skupienia, przewodnik do czytania oraz zatrzymywanie animacji. Może także automatycznie uzupełniać wybrane wykrywalne atrybuty ARIA, alt i title. Nie oznacza to jednak, że każda bariera w sklepie została usunięta.
Więcej o tej granicy wyjaśnia tekst Widget dostępności WCAGbot: możliwości i ograniczenia oraz poradnik Automatyczne atrybuty: gdzie pomagają, gdzie ryzykują.
4. Znane ograniczenia
Ta część buduje wiarygodność. Nie musi być długa, ale nie może ukrywać problemów, które firma już zna. Przykłady sformułowań:
- „Część starszych plików PDF może nie mieć pełnej struktury nagłówków.”
- „Wybrane materiały wideo mogą nie zawierać napisów.”
- „Niektóre elementy modułu płatności są dostarczane przez zewnętrznego operatora i wymagają odrębnej weryfikacji.”
- „Po wdrożeniu nowej wersji motywu prowadzimy ponowne testy formularza zamówienia.”
Nie wpisuj ograniczeń „na zapas” ani nie przenoś odpowiedzialności bez wyjaśnienia. Jeśli kluczowy etap zakupu zależy od zewnętrznego rozwiązania, użytkownik nadal potrzebuje wiedzieć, jak uzyskać pomoc, gdy nie może przejść dalej.
5. Alternatywna pomoc i kontakt
Podaj realny kanał wsparcia oraz opisz, w czym zespół może pomóc. Zamiast ogólnego „skontaktuj się z nami”, użyj komunikatu: „Jeżeli nie możesz złożyć zamówienia przy użyciu strony, skontaktuj się z obsługą klienta telefonicznie lub e-mailowo. Pomożemy w uzyskaniu informacji o produkcie i przyjęciu zamówienia w dostępnej formie, o ile jest to możliwe w danym przypadku”.
Sprawdź, czy kontakt sam nie tworzy bariery. Formularz kontaktowy, adres e-mail zapisany jako grafika albo telefoniczna infolinia bez alternatywy tekstowej nie będą dobrym rozwiązaniem dla wszystkich użytkowników.
6. Data aktualizacji oraz właściciel treści
Dodaj datę ostatniej aktualizacji i wskaż zespół odpowiedzialny za aktualność, na przykład dział e-commerce, compliance, UX lub obsługę klienta. Dzięki temu dokument nie staje się zapomnianą podstroną po zmianie checkoutu, aplikacji lub motywu.
Informacja o dostępności a deklaracja dostępności
WCAGbot Accessibility Path: jak przygotować informację krok po kroku?
Nazwa WCAGbot Accessibility Path porządkuje proces przygotowania informacji tak, aby nie opierała się na przypuszczeniach ani automatycznych deklaracjach.
- Wyznacz granice usługi. Wypisz wszystkie elementy usługi: katalog, karta produktu, koszyk, formularze, płatność, dokumenty, kontakt i kanały wsparcia.
- Wybierz krytyczne ścieżki. Dla e-commerce będą to zwykle wyszukanie produktu, warianty, dodanie do koszyka, dane kupującego, dostawa, płatność i potwierdzenie zamówienia.
- Zweryfikuj fakty. Wykonaj test klawiaturą, sprawdź komunikaty błędów, kolejność fokusu, kontrast, powiększenie oraz zachowanie interfejsu z czytnikiem ekranu. Praktyczny plan znajdziesz w artykule Testy klawiaturą i czytnikiem ekranu: praktyczny plan.
- Oddziel funkcje od zgodności. Opisz funkcje wspierające dostępność, ale nie przedstawiaj ich jako dowodu pełnej zgodności usługi z prawem, WCAG lub EN 301 549.
- Opisz ograniczenia oraz pomoc. Wprowadź procedurę przekazywania zgłoszeń do osoby, która może podjąć działanie.
- Ustal cykl aktualizacji. Aktualizuj dokument po zmianach w motywie, koszyku, płatnościach, formularzach, treściach wideo i dokumentach do pobrania.
Jak testować treść przed publikacją?
Informacja o dostępności powinna być dostępna tak samo jak usługa, którą opisuje. Przed publikacją przejdź krótką checklistę:
- Czy link do informacji jest łatwy do znalezienia z poziomu stopki, pomocy albo regulaminu?
- Czy nagłówki tworzą logiczną strukturę?
- Czy tekst da się przeczytać po powiększeniu i przy zmienionych odstępach?
- Czy kontrast tekstu, linków i elementów interaktywnych jest wystarczający?
- Czy wszystkie linki mają jasne nazwy, a nie tylko „kliknij tutaj”?
- Czy strona działa z klawiaturą i ma widoczny fokus?
- Czy dane kontaktowe są zapisane jako tekst, a nie wyłącznie w grafice?
- Czy deklarowane funkcje można rzeczywiście znaleźć i uruchomić?
Pomocna będzie także checklista kontrastu, altów, nagłówków, linków i komunikatów błędów. W przypadku procesu zakupowego sprawdź dodatkowo dostępność formularzy, koszyka i płatności w e-commerce.
Mini-scenariusz: sklep z niepełną informacją o checkoutcie
Scenariusz ilustracyjny, nie opisuje realnego wdrożenia klienta.
Sklep internetowy publikuje na stronie zdanie: „Nasza platforma jest dostosowana do potrzeb wszystkich użytkowników”. Użytkownik korzystający wyłącznie z klawiatury wybiera produkt, ale po przejściu do dostawy fokus nie trafia do listy metod. Nie może samodzielnie zakończyć zakupu. W informacji o dostępności nie ma ani opisu ograniczenia, ani telefonu, ani e-maila do wsparcia.
Lepsze rozwiązanie obejmuje trzy działania. Po pierwsze, zespół zgłasza błąd do wykonawcy i planuje naprawę źródłową komponentu dostawy. Po drugie, dodaje dostępny kanał wsparcia dla osób, które nie mogą ukończyć zamówienia. Po trzecie, aktualizuje informację o dostępności, wskazując zakres testów i znane ograniczenie do czasu usunięcia problemu.
Widget może w tym czasie wesprzeć część użytkowników, na przykład poprzez zwiększenie tekstu, zmianę kontrastu lub ułatwienia w czytaniu. Nie naprawi jednak błędnej obsługi fokusu w kodzie zewnętrznego modułu. To przykład bariery wymagającej audytu i naprawy źródłowej.
Jakie ryzyka pojawiają się najczęściej?
Ryzyko 1: kopiowanie cudzej treści
Wzór z innej strony nie odzwierciedla Twoich integracji, metod płatności, wersji motywu ani procesów obsługi klienta. Skopiowana informacja może być nieprawdziwa już w dniu publikacji.
Ryzyko 2: mylenie widgetu z audytem
Widget dostępności jest rozsądnym pierwszym krokiem, gdy chcesz szybko dodać użytkownikom funkcje takie jak kontrast, czytanie treści, powiększenie czy prowadzenie fokusu. Nie jest jednak zamiennikiem audytu WCAG, testów z użytkownikami i trwałych napraw. Różnice opisuje artykuł Widget dostępności a audyt WCAG: różnice i wybór.
Układ informacji o dostępności usługi e-commerce
Ryzyko 3: pomijanie zmian po wdrożeniu
Dostępność może pogorszyć się po instalacji nowej aplikacji Shopify, aktualizacji motywu WordPress, zmianie systemu płatności albo dodaniu kreatora landing page. Dlatego informacja o dostępności musi mieć właściciela i datę przeglądu. Więcej o tym ryzyku przeczytasz w poradniku Regresja dostępności po zmianie motywu lub aplikacji.
Podsumowanie dla zarządzającego i sprzedaży
Informacja o dostępności usługi jest narzędziem komunikacji i zarządzania ryzykiem, ale tylko wtedy, gdy opiera się na sprawdzonych faktach. Zarządzający powinni zapewnić właściciela procesu, budżet na naprawy źródłowe oraz procedurę aktualizacji. Sprzedaż i obsługa klienta powinny znać dostępne kanały pomocy, aby nie pozostawić użytkownika samego na etapie zakupu.
Jeżeli chcesz zacząć od szybkiego wsparcia użytkowników, otwórz panel WCAGbot na własnej stronie, przetestuj tryby kontrastu, zwiększ tekst, sprawdź czytanie treści i zobacz, które funkcje odpowiadają potrzebom Twoich odbiorców. Następnie zaplanuj audyt oraz poprawki w miejscach, w których widget nie może usunąć bariery.
Dodaj funkcje dostępności swojej strony i przetestuj WCAGbot: https://wcagbot.pl/#kontakt
FAQ: informacja o dostępności usługi
Czy każda firma musi publikować informację o dostępności usługi?
Nie należy zakładać, że identyczny obowiązek dotyczy każdej firmy. Zakres PAD zależy między innymi od rodzaju produktu lub usługi oraz warunków wskazanych w ustawie. Niezależnie od obowiązku prawnego warto publikować praktyczną informację, jeśli firma prowadzi usługę cyfrową i chce ułatwić użytkownikom kontakt oraz zakupy.
Czy informacja o dostępności usługi musi być na osobnej podstronie?
Nie zawsze, ale musi być łatwa do znalezienia, czytelna i dostępna. Może być osobną podstroną albo wyraźną sekcją w centrum pomocy czy regulaminie. W praktyce osobna podstrona ułatwia aktualizację i linkowanie z obsługi klienta.
Czy widget dostępności wystarczy, aby napisać, że usługa jest zgodna z WCAG?
Nie. Widget wspiera użytkownika poprzez dodatkowe funkcje interfejsu, lecz nie potwierdza pełnej zgodności całej usługi z WCAG, EN 301 549 ani PAD. Błędy w kodzie, formularzach, strukturze dokumentów, opisach produktów i integracjach wymagają odrębnej oceny oraz napraw.
Jak opisać znane bariery bez zniechęcania klientów?
Opisz je krótko, konkretnie i razem z informacją o pomocy lub planowanym działaniu. Użytkownik potrzebuje wiedzieć, czego dotyczy problem, na jakim etapie występuje oraz jak może ukończyć sprawę alternatywną drogą.
Czy trzeba wskazywać zgodność z WCAG 2.1 AA lub WCAG 2.2?
Wskazuj poziom zgodności tylko wtedy, gdy masz podstawę w audycie, testach i aktualnej ocenie zakresu. Samo użycie wytycznych WCAG jako punktu odniesienia jest inne niż publiczne oświadczenie o zgodności całej usługi.
Jak często aktualizować informację o dostępności usługi?
Po każdej istotnej zmianie wpływającej na korzystanie z usługi oraz w ustalonym cyklu przeglądu. Istotne zmiany to między innymi nowy motyw, checkout, formularz, operator płatności, aplikacja zewnętrzna, dokumenty do pobrania lub kanał obsługi klienta.
Czy opis dostępności płatności powinien obejmować zewnętrznego operatora?
Tak, jeżeli płatność jest etapem korzystania z Twojej usługi. Należy jasno opisać rolę zewnętrznego rozwiązania, sprawdzić krytyczną ścieżkę użytkownika i zapewnić pomoc, gdy użytkownik nie może dokończyć procesu.
Czy mikroprzedsiębiorca jest zwolniony z obowiązków PAD?
Ustawa przewiduje szczególne zasady dotyczące mikroprzedsiębiorców świadczących usługi, ale ich zastosowanie wymaga sprawdzenia ustawowej definicji i zakresu prowadzonej działalności. Nie zakładaj zwolnienia bez analizy aktualnego tekstu ustawy.
Czy informacja o dostępności powinna zawierać dane kontaktowe?
Tak, to dobra praktyka i kluczowy element użyteczności dokumentu. Podaj co najmniej dostępny kanał kontaktu oraz opisz, w jakich sprawach użytkownik może otrzymać pomoc.
Od czego zacząć, jeśli sklep nie był jeszcze testowany?
Zacznij od mapy krytycznych ścieżek zakupowych, testu klawiaturą oraz sprawdzenia formularzy, komunikatów błędów, kontrastu i płatności. Równolegle możesz wdrożyć funkcje wspierające dostępność, a następnie zlecić audyt i zaplanować poprawki źródłowe.
