Najważniejsze wnioski
- Dofinansowanie nie tworzy jednej, automatycznej reguły nakazującej dostosowanie całej strony firmy do WCAG. Trzeba sprawdzić status beneficjenta, dokumentację naboru, umowę oraz faktyczny zakres projektu.
- Jeżeli strona, formularz, portal, dokumenty lub materiały cyfrowe służą rekrutacji, komunikacji albo obsłudze projektu, wymagania dostępności mogą dotyczyć właśnie tych elementów.
- Podmiot publiczny podlega odrębnym obowiązkom wynikającym z ustawy o dostępności cyfrowej. Usługi handlu elektronicznego mogą natomiast podlegać Polskiemu Aktowi o Dostępności, niezależnie od finansowania projektu.
- W projektach z Funduszy Europejskich dostępność należy uwzględnić przed zakupem lub budową rozwiązania: w opisie zakresu, kryteriach odbioru, testach i umowie z wykonawcą.
- Widget dostępności może być szybkim pierwszym krokiem wspierającym użytkowników, ale nie zastępuje audytu WCAG ani napraw formularzy, kodu, dokumentów i treści.
Dla zarządzającego
Przed podpisaniem umowy lub uruchomieniem projektu ustal, które kanały cyfrowe są jego częścią i kto odpowiada za dostępność. Największym ryzykiem nie jest sam brak widgetu, lecz zbudowanie niedostępnego rozwiązania bez wymagań, testów i budżetu na poprawki.
Dla sprzedaży
Jeżeli strona projektu prowadzi do formularza, zakupu, rezerwacji lub kontaktu, sprzedaż powinna przekazać zespołowi wdrożeniowemu wymagania dostępności już na etapie briefu. Dzięki temu nie trzeba później przebudowywać kluczowej ścieżki użytkownika pod presją terminu odbioru.
Nie każda firma, która otrzymała dofinansowanie, musi automatycznie przebudować całą stronę internetową do WCAG. Dostępność może jednak być obowiązkiem ustawowym, warunkiem naboru albo standardem dotyczącym konkretnych elementów projektu: strony rekrutacyjnej, formularza, platformy, dokumentów PDF, e-usługi czy sklepu internetowego.
Najbezpieczniejsze pytanie nie brzmi więc: „czy mamy dotację?”, lecz: „które kanały cyfrowe są objęte projektem, jakie wymagania wpisano do dokumentacji i jakie przepisy dotyczą naszej usługi?”
Stan prawny i źródła w artykule: 28 czerwca 2025 r. Tekst ma charakter informacyjny i nie stanowi indywidualnej porady prawnej. Przy konkretnym naborze należy sprawdzić aktualny regulamin, umowę o dofinansowanie, kryteria wyboru oraz załączniki.
Najważniejsze wnioski
- Samo finansowanie projektu nie przesądza o obowiązku dostosowania całej istniejącej witryny.
- Wymaganie może dotyczyć strony, dokumentów i narzędzi używanych do rekrutacji, informacji, obsługi uczestników albo realizacji usługi.
- Podmiot publiczny, prywatny beneficjent projektu i e-commerce objęty PAD mogą działać na podstawie różnych reżimów.
- Dostępność trzeba opisać przed zakupem lub budową rozwiązania, a nie dopiero podczas kontroli albo odbioru.
- WCAGbot wspiera dostępność po szybkim wdrożeniu, ale bariery w kodzie, formularzach, dokumentach i treści wymagają osobnej diagnozy oraz naprawy źródłowej.
Czy dofinansowanie samo w sobie nakłada obowiązek WCAG?
Nie ma jednej uniwersalnej odpowiedzi. Dofinansowanie może uruchamiać wymagania dostępności, ale ich zakres zależy od źródła obowiązku. W praktyce trzeba rozdzielić co najmniej trzy sytuacje.
| Źródło wymagania | Kogo lub czego może dotyczyć | Co sprawdzić w pierwszej kolejności | Praktyczny skutek |
|---|---|---|---|
| Ustawa o dostępności cyfrowej | Podmioty publiczne wskazane w ustawie oraz ich strony i aplikacje | Status podmiotu oraz zakres ustawowy | Obowiązki dotyczą co do zasady stron należących do podmiotu, nie tylko projektu |
| Regulamin naboru i umowa o dofinansowanie | Beneficjenta i rezultaty konkretnego projektu | Regulamin, kryteria, wniosek, umowę, załączniki | Wymagania mogą obejmować wyłącznie finansowane lub wykorzystywane elementy |
| Polski Akt o Dostępności | Określone produkty i usługi, w tym usługi handlu elektronicznego | Charakter usługi, odbiorcę, status przedsiębiorcy | Obowiązek może istnieć niezależnie od otrzymania dotacji |
| Wymagania zamówienia | Wykonawcę strony, systemu, aplikacji lub dokumentów | Opis przedmiotu zamówienia, kryteria odbioru, procedurę testów | Brak zapisu często utrudnia egzekwowanie poprawek od wykonawcy |
Dlatego nie warto ograniczać analizy do hasła „WCAG 2.1 AA” w briefie. Najpierw trzeba ustalić, czy wymaganie wynika z prawa, dokumentacji projektowej czy umowy z wykonawcą. Dopiero później można określić właściwy zakres testów i poprawek.
Dotacja nie zmienia niedostępnej strony w dostępny projekt. Zmienia za to wagę pytania, czy dostępność została zaplanowana i odebrana tak samo jak pozostałe wymagania.
Kiedy strona związana z projektem powinna być dostępna?
W projektach współfinansowanych z Funduszy Europejskich dostępność jest związana z zasadą równości szans i niedyskryminacji. W praktyce szczególnej uwagi wymagają kanały, przez które odbiorca ma uzyskać informację, zgłosić udział lub skorzystać z efektu projektu.
Strona jest finansowanym rezultatem projektu
Jeżeli budżet obejmuje stworzenie albo modernizację serwisu, platformy, e-usługi, sklepu, portalu informacyjnego lub systemu obsługi użytkownika, dostępność powinna zostać wpisana do wymagań realizacyjnych. Nie należy zakładać, że wystarczy ogólne zdanie o „stronie zgodnej z WCAG”. W dokumentacji trzeba doprecyzować zakres, standard, metodę testu, kryteria odbioru oraz sposób zgłaszania i poprawiania błędów.
Strona służy rekrutacji lub komunikacji projektu
Dostępność może być wymagana także wtedy, gdy serwis nie jest głównym kosztem projektu, ale pełni jego ważną funkcję. Dotyczy to między innymi publikacji naboru, formularzy zgłoszeniowych, regulaminów, harmonogramów, informacji o wsparciu, materiałów szkoleniowych, kontaktu z uczestnikami i newsletterów.
W tej sytuacji nie wystarczy sprawdzić strony głównej. Należy przejść całą ścieżkę użytkownika: od informacji, przez formularz, do potwierdzenia i kontaktu. Pomocna będzie mapa dostępności ścieżki użytkownika; jej logikę można zastosować także do projektu niebędącego sklepem.
Jak ustalić, czy projekt z dofinansowaniem wymaga dostępności?
Beneficjent jest podmiotem publicznym
Ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych ma własny zakres podmiotowy. Jeżeli beneficjent jest podmiotem objętym tą ustawą, obowiązki dotyczą jego stron internetowych i aplikacji w granicach określonych przepisami, a nie tylko serwisu stworzonego z dotacji. Rządowe materiały wyjaśniają, że wymagania ustawowe są powiązane z WCAG 2.1 na poziomie AA, z uwzględnieniem zakresu określonego w ustawie.
Nie należy jednak przenosić tego mechanicznie na każdą prywatną firmę korzystającą z funduszy. Prywatny beneficjent może mieć obowiązek wynikający z projektu, ale nie musi przez sam fakt otrzymania środków stać się podmiotem publicznym.
Projekt prowadzi do sprzedaży lub zawarcia umowy online
Od 28 czerwca 2025 r. Polski Akt o Dostępności obejmuje między innymi usługi handlu elektronicznego. Chodzi o usługi oferowane konsumentowi na odległość, drogą elektroniczną i na indywidualne żądanie, w celu zawarcia umowy. Może to obejmować sklep, zakup usługi, rezerwację czy płatność online.
PAD i dofinansowanie to dwa odrębne zagadnienia. Dotacja nie przesądza o stosowaniu PAD, a wyłączenie dotyczące usług mikroprzedsiębiorcy nie zwalnia automatycznie z warunków naboru albo umowy. Szerzej omawia to artykuł Mikroprzedsiębiorca a PAD: kiedy działa wyłączenie dla usług?. Dla sklepów warto także przeczytać: czy Polski Akt o Dostępności dotyczy sklepu online.
WCAG, EN 301 549 i PAD: dlaczego to nie są synonimy?
Te pojęcia często pojawiają się obok siebie w dokumentacji projektowej, ale opisują różne rzeczy.
- WCAG to wytyczne dotyczące dostępności treści internetowych. Pomagają oceniać między innymi kontrast, strukturę nagłówków, formularze, obsługę klawiaturą, komunikaty błędów i alternatywy dla treści nietekstowych.
- EN 301 549 to norma dotycząca wymagań dostępności dla produktów i usług ICT. Jej zakres jest szerszy niż same strony: może obejmować także dokumenty elektroniczne, oprogramowanie i inne technologie informacyjno-komunikacyjne.
- Polski Akt o Dostępności to ustawa wdrażająca Europejski Akt o Dostępności. Ustala wymagania dla określonych produktów i usług, a nie jest prostym poleceniem „wdrożyć WCAG 2.1 AA na każdej stronie”.
Przed rozpoczęciem prac warto sprawdzić różnice między WCAG 2.1, WCAG 2.2 i EN 301 549. Przy e-commerce szczególnie ważne jest również omówienie EN 301 549 dla e-commerce, ponieważ koszyk i płatność są tylko częścią środowiska cyfrowego używanego przez klienta.
Jak sprawdzić wymagania przed rozpoczęciem projektu?
Praktyczny proces można uporządkować jako WCAGbot Accessibility Path. To nie jest procedura prawna ani zastępstwo audytu. Jest to sposób pracy, który pomaga zespołowi nie pominąć dostępności między wnioskiem, zamówieniem i uruchomieniem serwisu.
- Zbierz dokumenty. Otwórz regulamin naboru, kryteria wyboru, umowę o dofinansowanie, wniosek, wytyczne, opis projektu i plan zakupów.
- Wypisz kanały cyfrowe projektu. Uwzględnij stronę, landing page, formularze, platformę, sklep, strefę użytkownika, PDF-y, materiały wideo, e-mail i system płatności.
- Połącz kanał z zadaniem użytkownika. Zamiast testować przypadkowe podstrony, zapisz: „uczestnik ma znaleźć nabór, pobrać dokument, wypełnić formularz i otrzymać potwierdzenie”.
- Określ wymagania odbiorowe. Wskaż standard lub kryteria, zakres testów ręcznych, obowiązek usunięcia błędów oraz odpowiedzialność wykonawcy.
- Przetestuj ścieżki przed odbiorem. Wykonaj test klawiaturą, sprawdź widoczność fokusu, etykiety pól, komunikaty błędów, strukturę nagłówków, kontrast i działanie przy powiększeniu tekstu.
- Zaplanuj utrzymanie. Nowy PDF, formularz promocyjny lub zmiana w koszyku może wprowadzić kolejną barierę. Dostępność wymaga procesu aktualizacji, a nie jednorazowego odbioru.
Dobry punkt startowy stanowi checklista pierwszych kroków dla dostępności sklepu internetowego. Nawet gdy projekt nie dotyczy sklepu, lista pomaga zauważyć elementy krytyczne: formularze, treści, linki, obrazy i mechanizmy kontaktu.
Trzy źródła wymagań dostępności
Co wpisać do umowy z wykonawcą strony?
Wymaganie dostępności musi być możliwe do zweryfikowania. Ogólne sformułowanie „strona będzie dostępna” jest za mało precyzyjne, aby bezspornie odebrać rezultat lub wymagać poprawki.
W opisie przedmiotu zamówienia, zapytaniu ofertowym lub umowie warto określić:
- które widoki, formularze, dokumenty i procesy są objęte zakresem;
- do jakich wymagań odwołuje się projekt, na przykład WCAG, EN 301 549 albo standard wskazany przez instytucję finansującą;
- że testy obejmują obsługę klawiaturą oraz ocenę kluczowych ścieżek użytkownika, a nie wyłącznie automatyczny skan;
- kto wykonuje test, kto zgłasza błędy i kto potwierdza ich usunięcie;
- jak wykonawca dostarcza dostępne dokumenty, instrukcje, materiały redakcyjne i komponenty do dalszej edycji;
- jak wygląda okres poprawkowy oraz odbiór po usunięciu niezgodności.
Rządowy materiał dotyczący zamówień publicznych wskazuje, że dostępność warto opisać w opisie przedmiotu zamówienia, umowie, kryteriach odbioru oraz procedurze testów. Zawiera też przykład czternastodniowego terminu usunięcia zgłoszonych niezgodności. Nie jest to jednak uniwersalny termin ustawowy dla każdego beneficjenta i każdego projektu — termin trzeba ustalić w dokumentacji właściwej dla danego zamówienia.
Jakie bariery najczęściej blokują udział w projekcie?
Strona może wyglądać nowocześnie, a mimo to zatrzymać użytkownika przy podstawowym zadaniu. Krytyczne są zwłaszcza formularze i elementy interaktywne: pole bez widocznej etykiety, komunikat błędu oznaczony wyłącznie kolorem, niedziałający klawisz Escape w oknie modalnym czy przycisk opisany tylko ikoną.
W badaniu automatycznym WebAIM Million 2025 co najmniej jeden wykrywalny błąd związany z WCAG 2 wystąpił na 94,8% z miliona przeanalizowanych stron głównych. Badanie nie oznacza, że tyle stron jest całkowicie niedostępnych: automatyczne narzędzia wykrywają tylko część problemów. Jest jednak dobrym przypomnieniem, że test automatyczny nie powinien być jedynym etapem odbioru.
Do szybkiego testu kluczowego procesu przyda się instrukcja nawigacji klawiaturą bez myszy. Warto również sprawdzić, czy nagłówki i linki są zrozumiałe bez wzroku. To działania, które pomagają wykryć bariery, których nie naprawi sama zmiana kolorów w panelu dostępności.
Mini-scenariusz ilustracyjny: strona rekrutacyjna do projektu
Poniższy scenariusz jest ilustracyjny i nie opisuje rzeczywistego klienta ani wdrożenia.
Firma realizuje projekt szkoleniowy finansowany z programu regionalnego. Na swojej istniejącej stronie publikuje opis wsparcia, regulamin PDF, formularz zgłoszeniowy i dane kontaktowe. Sam serwis firmy nie był finansowany z projektu, ale strona rekrutacyjna służy bezpośrednio naborowi uczestników.
Zespół powinien sprawdzić przede wszystkim, czy kandydat może samodzielnie: znaleźć informację o rekrutacji, przeczytać warunki, pobrać dostępny dokument, wypełnić pola formularza, zrozumieć błędy i wysłać zgłoszenie klawiaturą. Następnie należy zestawić wynik z wymaganiami naboru oraz umowy.
Jeśli strona ma pilnie zacząć wspierać użytkowników, można dodać WCAGbot jedną linią kodu i udostępnić funkcje takie jak kontrast, powiększenie tekstu, większe odstępy, czytanie treści czy przewodnik do czytania. Otwórz panel WCAGbot na własnej stronie, przetestuj kontrast i zwiększ tekst, a następnie przejdź formularz wyłącznie klawiaturą. Taki test pozwala odróżnić pomocną funkcję interfejsu od błędu, który trzeba naprawić w źródle.
Przykładowo widget może ułatwić użytkownikowi zmianę kontrastu lub powiększenie tekstu. Nie naprawi jednak trwale formularza bez poprawnej etykiety, błędnie przygotowanego PDF-a ani procesu płatności, który blokuje fokus klawiatury. Granicę między tymi działaniami szerzej wyjaśnia artykuł Widget dostępności a zgodność z WCAG: uczciwe porównanie.
Czy widget dostępności wystarczy w projekcie z dotacją?
Nie. Widget dostępności może być rozsądnym pierwszym krokiem, ponieważ wspiera użytkowników bez przebudowy serwisu. WCAGbot oferuje między innymi tryby kontrastu, nasycenia i skali szarości, zmianę wielkości tekstu, interlinii i odstępów, czytanie treści, większy kursor, wyróżnianie linków oraz sześć gotowych profili użytkownika.
WCAGbot Accessibility Path dla projektu finansowanego
To funkcje wspierające dostępność, które można uruchomić szybko po dodaniu jednej linii kodu. Nie są jednak dowodem zgodności całej strony z WCAG, EN 301 549, warunkami projektu ani PAD. Nie zastępują audytu i naprawy źródłowej, szczególnie gdy bariera leży w strukturze HTML, opisach pól, logice formularza, obsłudze klawiatury, dokumencie PDF, multimediach lub integracji z płatnością.
W projekcie z dofinansowaniem rozsądny model działania wygląda tak: najpierw zdefiniuj wymagania i krytyczne ścieżki, następnie wykonaj testy, usuń bariery w źródle, a funkcje wspierające dostępność potraktuj jako dodatkowe wsparcie dla użytkownika. Więcej o tej kolejności przeczytasz w materiale Widget dostępności czy audyt WCAG przy małym budżecie?.
Podsumowanie dla zarządzającego i sprzedaży
Dofinansowanie nie jest skrótem myślowym oznaczającym „cała firma musi spełniać WCAG”. Jest natomiast wyraźnym sygnałem, że przed uruchomieniem strony, formularza czy platformy należy sprawdzić dokumentację projektu i obowiązki właściwe dla danego podmiotu oraz usługi.
Dla zarządzającego kluczowe jest przypisanie odpowiedzialności i budżetu: ktoś musi przeanalizować wymagania, ktoś przetestować rezultat, a wykonawca powinien mieć obowiązek usunąć wykryte bariery. Dla sprzedaży i obsługi klienta ważne jest, aby ścieżka od informacji do formularza, zamówienia lub płatności była dostępna dla różnych użytkowników.
Dodaj funkcje poprawiające dostępność swojej strony i przetestuj WCAGbot. Potraktuj je jako szybkie wsparcie użytkownika oraz element szerszego planu: audytu, napraw w kodzie i treści, testów oraz utrzymania dostępności.
FAQ: dofinansowanie a WCAG
Czy każda firma z dofinansowaniem musi mieć stronę zgodną z WCAG?
Nie. Obowiązek zależy od statusu firmy, zasad naboru, umowy o dofinansowanie, zakresu projektu oraz funkcji strony. Trzeba sprawdzić dokumenty konkretnego projektu, a nie opierać się wyłącznie na fakcie otrzymania środków.
Czy dotacja oznacza obowiązek dostosowania całej istniejącej strony?
Nie zawsze. Wymagania mogą dotyczyć tylko części związanej z projektem, na przykład strony rekrutacyjnej, formularza, platformy lub dokumentów. Inaczej może być, gdy beneficjent jest podmiotem publicznym objętym ustawą o dostępności cyfrowej.
Czy strona rekrutacyjna do projektu musi być dostępna?
Jeżeli służy informowaniu o projekcie, naborowi uczestników lub składaniu zgłoszeń, należy szczególnie dokładnie sprawdzić wymagania dostępności w dokumentacji programu. Dostępność powinna obejmować także formularz, komunikaty błędów i dokumenty do pobrania.
Czy dostępność dotyczy plików PDF publikowanych w projekcie?
Może dotyczyć. Regulaminy, formularze, instrukcje, harmonogramy i materiały edukacyjne udostępniane uczestnikom są częścią doświadczenia cyfrowego. Ich zakres należy ocenić razem ze stroną oraz wymaganiami projektu.
Czy Polski Akt o Dostępności dotyczy sklepu finansowanego z dotacji?
Może dotyczyć, jeżeli sklep świadczy usługę handlu elektronicznego objętą ustawą. Obowiązek wynika wtedy z charakteru usługi, a nie z samego dofinansowania. Należy też sprawdzić, czy ma zastosowanie wyłączenie dla usług mikroprzedsiębiorcy.
Czy mikroprzedsiębiorca z dotacją jest zwolniony ze wszystkich wymagań dostępności?
Nie. Wyłączenie przewidziane w PAD dla usług mikroprzedsiębiorców nie oznacza automatycznego zwolnienia z warunków naboru, umowy o dofinansowanie, wymagań zamówienia lub innych obowiązków. Każdą podstawę należy ocenić oddzielnie.
Czy wystarczy automatyczny test WCAG przed odbiorem projektu?
Nie. Automatyczne narzędzia pomagają wykryć część problemów, ale nie zastępują testów ręcznych. Należy co najmniej sprawdzić klawiaturę, fokus, formularze, komunikaty błędów, strukturę treści i kluczowe procesy użytkownika.
Czy WCAG 2.1 AA i EN 301 549 oznaczają to samo?
Nie. WCAG opisuje wytyczne dla treści internetowych, a EN 301 549 ma szerszy zakres dotyczący technologii informacyjno-komunikacyjnych. W dokumentacji projektu trzeba czytać dokładne sformułowanie wymagania, a nie traktować tych pojęć jako zamienników.
Czy widget WCAG zapewnia zgodność z wymaganiami projektu?
Nie. Widget może wspierać użytkowników funkcjami takimi jak kontrast, powiększenie tekstu czy czytanie treści. Nie zastępuje jednak audytu, testów ani poprawy barier w kodzie, formularzach, dokumentach i procesach transakcyjnych.
Co zrobić przed podpisaniem umowy z wykonawcą strony?
Trzeba wpisać wymagania dostępności do zakresu prac i kryteriów odbioru. Warto określić objęte elementy, metodę testowania, odpowiedzialność za poprawki, dokumentację oraz sposób potwierdzenia usunięcia błędów.
Źródła i materiały
- Fundusze Europejskie – Wytyczne dotyczące realizacji zasad równościowych
- Elektroniczny Dziennik Ustaw – ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych
- gov.pl – FAQ dotyczące dostępności cyfrowej
- gov.pl – Polski Akt o Dostępności a usługi handlu elektronicznego
- WebAIM Million 2025
- gov.pl – dostępność cyfrowa w umowach i zamówieniach publicznych
- www.gov.pl
- www.gov.pl
- www.canaxess.com
- accessibility.build
- aiscopedigital.com
- webaim.org
