TL;DR:
Od 28 czerwca 2025 wchodzą w życie nowe obowiązki wynikające z Europejskiego Aktu o Dostępności (EAA).
Dotyczy to wszystkich serwisów i aplikacji oferowanych komercyjnie – także sklepów internetowych, bankowości, usług B2B, rezerwacji, e-booków itd.
Strony muszą być dostępne cyfrowo zgodnie z WCAG 2.1 (poziom AA), w przeciwnym razie grożą kary, audyt i potencjalne roszczenia klientów.
Jeśli jesteś twórcą, freelanserem, firmą software house – też musisz to wiedzieć.
1. Na jakiej podstawie prawnej?
Zmiany wynikają z:
- Dyrektywy 2016/2102 (UE) – obowiązuje od 2018 roku, ale tylko dla instytucji publicznych.
- Europejskiego Aktu o Dostępności (EAA) – czyli Dyrektywa 2019/882 (UE) – wchodzi w życie 28 czerwca 2025 i rozszerza obowiązki dostępności na sektor prywatny.
Czyli teraz: jeśli robisz aplikację dla urzędu – już to powinieneś wdrażać.
Jeśli tworzysz soft dla firm – masz czas do 28 czerwca 2025, żeby zdążyć z dostosowaniem istniejących systemów oraz przygotować nowe zgodnie z wymaganiami.
2. Od kiedy i kogo obowiązują nowe przepisy?
🔹 Od 28 czerwca 2025 dostępność cyfrowa staje się prawnie obowiązkowa dla:
- sklepów internetowych,
- platform rezerwacyjnych,
- aplikacji bankowych i finansowych,
- e-booków i e-learningu,
- oprogramowania z interfejsem użytkownika (również desktopowych),
- wszelkich innych usług cyfrowych kierowanych do konsumentów na terenie UE.
A co z projektami tworzonymi przed tą datą?
🟢 Jeśli aplikacja/strona powstała wcześniej, ale nadal będzie używana po 28 czerwca 2025 – też musi być dostosowana.
🛠️ Masz więc czas do tej daty, aby przeprowadzić audyt, poprawić niedostępne elementy i spełnić wymagania WCAG 2.1 (AA).
Nie ma znaczenia, kiedy projekt był zbudowany – liczy się to, czy będzie dostępny publicznie po tej dacie.
3. Co musi być na stronie / w aplikacji? Konkretne wymagania
✅ Teksty alternatywne (alt) przy grafikach
- Każdy element graficzny – logo, ikona, wykres, zdjęcie – musi mieć opis alternatywny.
- Dzięki temu użytkownicy korzystający z czytników ekranu wiedzą, co przedstawia obraz.
✅ Odpowiedni kontrast kolorów
- Tekst musi być czytelny na tle. Wymagany jest kontrast minimum 4.5:1 dla tekstów zwykłych i 3:1 dla dużych.
- Przykład: jasnożółty tekst na białym tle odpada.
✅ Obsługa tylko za pomocą klawiatury
- Cała strona powinna być dostępna bez użycia myszy – wszystkie funkcje muszą działać przez Tab, Enter, ESC, Space.
- Nawigacja, formularze, menu rozwijane – wszystko.
✅ Logiczna struktura HTML (nagłówki i aria)
- Muszą być poprawnie zagnieżdżone <h1>, <h2>, <h3> itd. oraz atrybuty ARIA tam, gdzie trzeba.
- To pozwala osobom korzystającym z technologii asystujących zrozumieć strukturę strony.
✅ Formularze z etykietami i informacją o błędach
- Każde pole formularza musi mieć label, a przy błędzie – użytkownik musi dostać jasny komunikat.
- Komunikaty typu „Niepoprawne dane” bez wskazania pola = błąd dostępności.
✅ Responsywność i skalowalność treści
- Strona musi poprawnie działać przy zoomie 200%, a layout nie może się „rozjeżdżać”.
- Dotyczy to również urządzeń mobilnych i osób z ograniczonym widzeniem.
4. Kto to będzie egzekwował i co grozi?
👮 Organ nadzorujący:
W Polsce odpowiedzialne są:
- Ministerstwo Cyfryzacji – jako instytucja koordynująca
- Urząd Komunikacji Elektronicznej (UKE) – jako organ nadzorczy
🕵️ Jak wygląda kontrola?
- Użytkownicy mogą zgłaszać problemy z dostępnością (na przykład brak altów, nieczytelny kontrast).
- UKE będzie analizował zgłoszenia i przeprowadzał audyty na stronie.
- Firmy będą miały 30 dni na reakcję i naprawienie błędów – jeśli nie, może zostać nałożona kara finansowa.
💣 Konsekwencje:
- Kary pieniężne – wysokość zależna od rodzaju naruszenia
- Publiczne upomnienie – w przypadku usług masowych, to również wizerunkowy strzał w stopę
- Zatrzymanie finansowania publicznego – w przypadku np. firm realizujących projekty z dotacji
5. Odpowiedzialność programisty – różne scenariusze
🧑💻 Scenariusz 1: Jesteś freelancerem i realizujesz cały projekt
Jeśli podpisujesz umowę, w której zobowiązujesz się do „wdrożenia strony/usługi zgodnej z prawem” – masz obowiązek spełnić wymogi EAA.
Klient może żądać poprawek albo wstrzymać płatność.
💡 Rekomendacja: dodaj zapis o „dostępności zgodnej z WCAG 2.1 AA” lub… że nie obejmuje – i wtedy klient sam podejmuje decyzję.
👨💼 Scenariusz 2: Pracujesz B2B dla agencji / software house’u
Formalnie odpowiada agencja, ale…
Jeśli wiedziałeś o przepisach, a zrobiłeś coś ewidentnie niezgodnego – klient końcowy może dochodzić roszczeń wobec agencji, a agencja wobec Ciebie (regres).
💡 Wskazówka: nie milcz. Zgłoś temat do PM-a, lidera – zrób notatkę w systemie ticketowym / Jira. Masz wtedy dowód, że informowałeś.
🏗️ Scenariusz 3: Tworzysz produkt / SaaS jako founder lub CTO
Tu jesteś już pełnoprawnym właścicielem produktu – a więc Twoja firma ponosi pełną odpowiedzialność.
Jeśli użytkownicy zgłoszą niedostępność, możesz być zmuszony do:
- wprowadzenia kosztownych poprawek po czasie
- wypłaty odszkodowań
- zawieszenia działalności, jeśli produkt jest kluczowy (np. bankowość, dostępność publiczna)
💡 Protip: zainwestuj wcześniej w audyt dostępności – są też darmowe narzędzia do szybkiej diagnozy.
🧾 Podsumowanie – co powinieneś zrobić jako web developer?
📚 Zapoznaj się z wymaganiami dostępności (WCAG 2.1, poziom AA).
To nie tylko dobra praktyka – możesz zostać o to zapytany na rozmowie rekrutacyjnej albo w ramach code review.
👥 Uświadom swój zespół i PM-a – temat dostępności często nie dociera do zespołów developerskich, bo biznes „nie wie, że musi”.
Warto poruszyć to na spotkaniu sprintowym, refinemencie albo review.
💼 Porozmawiaj z klientem lub product ownerem – jeśli nikt nie zgłasza wymogu dostępności, być może nawet nie wiedzą, że to obowiązek prawny.
Wystarczy wspomnieć, że od czerwca 2025 roku grożą kary i trzeba się dostosować.
🛡️ Zabezpiecz się formalnie – jeśli pracujesz jako freelancer albo B2B, warto mieć zapis w umowie, że klient został poinformowany o obowiązku dostępności.
W niektórych przypadkach brak takiego zapisu może sprawić, że to Ty poniesiesz odpowiedzialność cywilną – nawet jeśli to klient zaniedbał temat.
