European Accessibility Act w aplikacji mobilnej: co musi spełniać aplikacja iOS i Android

Redakcja: Mateusz Białczak · Recenzja merytoryczna: Norbert Sitko · Aktualizacja: 28 czerwca 2026

28 czerwca 2025 roku zaczął obowiązywać europejski akt o dostępności (EAA, European Accessibility Act). Rok później rynek jest już za fazą „kiedy wejdzie w życie", a w fazie nadzoru: organy mogą kontrolować produkty i usługi oraz reagować na skargi. Mimo to większość poradników po polsku wciąż omawia dostępność pod kątem witryny WWW i sklepu internetowego. Tymczasem dla banku, przewoźnika czy sieci handlowej najważniejszym kanałem kontaktu z klientem jest dziś aplikacja mobilna — a ta rządzi się innymi prawami niż strona.

Ten przewodnik jest praktyczny i celowo skupiony na aplikacji mobilnej. Pokazujemy, czego wymaga prawo, co te wymagania znaczą w realnych ścieżkach: logowania, zakupu, płatności, a także jak to wszystko sprawdzić. Z góry uczciwa uwaga: pełna zgodność jest trudna i niewiele aplikacji spełnia każdy wymóg co do joty. Dlatego ton tego tekstu jest doradczy, nie alarmistyczny — chodzi o sensowne priorytety, nie o paraliż.

Standardy w pigułce: WCAG, poziomy AA i AAA

WCAG (Web Content Accessibility Guidelines — wytyczne dotyczące dostępności treści cyfrowych) to opracowany przez konsorcjum W3C zestaw kryteriów, które sprawiają, że z aplikacji lub serwisu korzysta więcej osób — także niewidomych, słabowidzących, niesłyszących, z ograniczeniami ruchowymi czy poznawczymi. Wytyczne organizuje cztery zasady, w polskiej terminologii nazywane: postrzegalność (treść da się odebrać zmysłami), funkcjonalność (da się ją obsłużyć), zrozumiałość (da się ją pojąć) i solidność (dobrze współpracuje z technologiami wspomagającymi). Te cztery filary są wspólne dla strony i dla aplikacji.

Każde kryterium WCAG ma przypisany poziom zgodności:

• Poziom A — absolutne minimum. Bez niego część użytkowników w ogóle nie skorzysta z aplikacji (np. nieopisany przycisk ikonowy, którego czytnik ekranu nie potrafi nazwać).
• Poziom AA — standard rynkowy i wymagany prawnie. To do niego odsyłają regulacje europejskie i polskie. Obejmuje m.in. kontrast tekstu, skalowanie czcionki czy widoczność fokusa.
• Poziom AAA — najwyższy, często niemożliwy do spełnienia w całym produkcie. Sam W3C nie zaleca wymagać AAA dla całych serwisów. To zbiór ambitnych usprawnień, nie cel obowiązkowy.

W praktyce „zgodność z WCAG" w kontekście prawa oznacza poziom AA. Tego pułapu trzymamy się w całym artykule.

WCAG 2.1 czy WCAG 2.2 — którą wersję bierzemy pod uwagę?

To pytanie pojawia się przy każdym projekcie i łatwo się w nim pogubić, bo w obiegu są dwie wersje wytycznych. Rozstrzygnijmy je raz, jasno: w tym artykule podstawą jest WCAG 2.1 na poziomie AA, bo to ta wersja jest dziś prawnie wiążąca w Europie.

Dlaczego? EAA nie wymienia WCAG wprost — odsyła do tzw. norm zharmonizowanych. Tą normą jest EN 301 549 (europejska norma „Wymagania dostępności produktów i usług ICT"). Jej obowiązująca wersja, EN 301 549 V3.2.1 (2021), włącza w całości właśnie WCAG 2.1 i — co kluczowe dla nas — obejmuje nie tylko strony, ale też „oprogramowanie niewebowe, takie jak natywne aplikacje mobilne".

WCAG 2.2 to nowsza wersja wytycznych, opublikowana przez W3C jako standard 5 października 2023 roku. Różnice względem 2.1 są przyrostowe, nie rewolucyjne:

WCAG 2.2 względem 2.1	Szczegóły
Dodaje 9 nowych kryteriów	m.in. 2.4.11 Fokus niezasłonięty (AA), 2.5.7 Przeciąganie (AA), 2.5.8 Rozmiar celu — minimum (AA), 3.2.6 Spójna pomoc (A), 3.3.7 Powtórne wprowadzanie (A), 3.3.8 Dostępne uwierzytelnianie (AA)
Usuwa jedno kryterium	4.1.1 (Parsowanie) zostało uznane za nieaktualne i wycofane
Jest wstecznie zgodna	aplikacja zgodna z 2.2 pozostaje zgodna z 2.1

Kierunek jest jasny: kolejna wersja normy EN 301 549 (v4.1.x), przygotowywana na zlecenie Komisji Europejskiej (mandat M/587), ma włączyć WCAG 2.2, a jej publikację zapowiadano na 2026 rok. Dlatego rozsądna strategia to projektować i audytować względem WCAG 2.1 AA jako obowiązku, a kryteria z 2.2 (zwłaszcza dostępne uwierzytelnianie i rozmiar celów dotykowych — wprost mobilne) traktować jako wartościowe wzmocnienie i przygotowanie na przyszłość. W treści nie będziemy ich mieszać: opisywane dalej wymagania to WCAG 2.1 AA, a do nowości z 2.2 wracamy tam, gdzie naprawdę pomagają.

Kogo w Polsce obowiązuje dostosowanie — i co z sektorem publicznym

Europejski akt o dostępności (EAA) to dyrektywa UE (2019/882), która od 28 czerwca 2025 roku wymaga, by wybrane produkty i usługi kierowane do konsumentów spełniały wymagania dostępności. W Polsce wdraża ją ustawa z dnia 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze (Dz.U. 2024 poz. 731), również obowiązująca od 28 czerwca 2025 roku.

Obowiązek dotyczy podmiotów gospodarczych: producentów, importerów, dystrybutorów i usługodawców oferujących objęte produkty lub usługi konsumentom na rynku unijnym. Lista usług jest dla aplikacji mobilnych bardzo konkretna i obejmuje m.in.:

• handel elektroniczny (e-commerce),
• bankowość detaliczną i usługi płatnicze dla konsumentów,
• transport pasażerski (informacja, bilety, odprawa),
• usługi telekomunikacyjne,
• dostęp do audiowizualnych usług medialnych oraz rozpowszechnianie e-booków.

Dwa istotne zawężenia. Po pierwsze, mikroprzedsiębiorcy świadczący usługi są w dużej mierze zwolnieni z obowiązków (mikroprzedsiębiorstwo to firma zatrudniająca mniej niż 10 osób i z rocznym obrotem nieprzekraczającym 2 mln euro). Po drugie, ustawa odnosi się do produktów i usług dla konsumentów — narzędzia czysto wewnętrzne, firmowe (B2B) zwykle są poza jej zakresem. Mimo to większość aplikacji bankowych, sklepowych, transportowych czy telekomunikacyjnych mieści się dokładnie w środku tego obowiązku.

A czy aplikacja mobilna w ogóle „liczy się" jak strona? Tak. Norma EN 301 549 wprost traktuje aplikacje mobilne (jako „oprogramowanie niewebowe") na równi z treściami internetowymi — i bez znaczenia jest, czy aplikacja powstała natywnie (Swift, Kotlin), we Flutterze, czy w React Native. Sklep z aplikacjami nie jest tu żadną „szarą strefą".

Osobny, starszy reżim dotyczy sektora publicznego. Ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848) — wdrażająca unijną dyrektywę o dostępności stron i aplikacji sektora publicznego — wymaga od podmiotów publicznych zgodności z WCAG 2.1 AA. Dla aplikacji mobilnych podmiotów publicznych obowiązuje od 23 czerwca 2021 roku i nakłada dodatkowo obowiązek publikacji deklaracji dostępności. To ważne rozróżnienie, do którego zaraz wracamy: deklaracja dostępności i obowiązki z EAA to dwa różne porządki prawne.

Deklaracja dostępności w aplikacji — czy nadal jej potrzebuję?

To jedno z najczęstszych nieporozumień, więc warto je wyprostować. Deklaracja dostępności (sformalizowane oświadczenie o stanie dostępności wraz z danymi kontaktowymi i procedurą zgłaszania uwag) to instytucja ustawy z 2019 roku — dla sektora publicznego. Jeśli wydajesz aplikację jako podmiot publiczny (urząd, szpital, uczelnia, samorząd), deklaracja dostępności nadal jest obowiązkowa i nic w tym zakresie nie zniknęło.

Jeśli natomiast jesteś prywatnym podmiotem gospodarczym objętym EAA (bank, sklep, przewoźnik), nie składasz „deklaracji dostępności" w tym samym, urzędowym sensie. EAA wymaga jednak czegoś pokrewnego: udostępnienia informacji o dostępności produktu lub usługi — opisu, jak spełnia ona wymagania — w ramach ogólnych warunków/umowy i w formie, która sama jest dostępna. W praktyce oznacza to czytelną, dostępną sekcję informacyjną o cechach dostępności, a nie identyczny formularz jak w sektorze publicznym.

Wniosek: temat „oświadczenia o dostępności" jest aktualny w obu światach, ale pod różnymi nazwami i z różnym zakresem. Warto wiedzieć, w którym z nich się działa, zanim skopiuje się wzór deklaracji od urzędu.

Co EAA realnie znaczy w aplikacji mobilnej — najważniejsze wymagania

Tu zaczyna się sedno. Te same kryteria WCAG 2.1 AA, które na stronie spełnia się znacznikami HTML i atrybutami ARIA, w aplikacji mobilnej realizuje się mechanizmami systemowymi iOS i Androida. Te mechanizmy są wspólne dla wszystkich technologii: aplikacja natywna (Swift, Kotlin), Flutter i React Native korzystają z tych samych usług dostępności systemu, więc podlegają dokładnie tym samym kryteriom — liczy się efekt na ekranie, nie wybór technologii. Poniżej najważniejsze obszary, ścieżka po ścieżce.

Czytniki ekranu: VoiceOver i TalkBack

Czytnik ekranu (screen reader) to wbudowane w system narzędzie, które odczytuje zawartość ekranu na głos i pozwala obsługiwać aplikację bez patrzenia — VoiceOver na iOS, TalkBack na Androidzie. To pierwszy i najważniejszy test dostępności aplikacji.

Z punktu widzenia WCAG liczą się tu trzy rzeczy. Nazwa, rola i wartość każdego elementu interaktywnego (kryterium 4.1.2): czytnik musi powiedzieć, że to przycisk, przełącznik czy pole, jak się nazywa i w jakim jest stanie (zaznaczony, nieaktywny). Etykiety tekstowe dla obrazów i ikon niosących znaczenie (1.1.1) — ikona kosza powinna mówić „Usuń", a nie być „nieoznaczonym przyciskiem". Logiczna kolejność odczytu i fokusa (1.3.2, 2.4.3) — czytnik powinien przechodzić przez ekran w kolejności zgodnej z układem i sensem, a nie skakać losowo.

Skalowanie czcionki i Dynamic Type

Wielu użytkowników powiększa systemowy rozmiar tekstu. Kryterium 1.4.4 (zmiana rozmiaru tekstu) wymaga, by przy powiększonej czcionce treść pozostawała czytelna i kompletna — nie była ucinana, nie znikała pod krawędzią ekranu, a przyciski nie „połykały" swoich napisów. Na iOS służy do tego Dynamic Type (dynamiczny rozmiar tekstu), na Androidzie skalowalne jednostki tekstu (sp) i ustawienie rozmiaru czcionki.

Powiązane jest kryterium 1.4.10 (dopasowanie układu, ang. reflow): na wąskim ekranie z dużą czcionką treść powinna mieścić się w jednej kolumnie, bez zmuszania użytkownika do przewijania w dwóch kierunkach naraz. To częsta pułapka formularzy i ekranów płatności, gdzie sztywne układy „rozjeżdżają się" przy większym tekście.

Kontrast i kolor

Kryterium 1.4.3 (kontrast minimalny) wymaga odpowiedniego stosunku jasności między tekstem a tłem — co najmniej 4,5:1 dla zwykłego tekstu i 3:1 dla dużego. Kryterium 1.4.11 (kontrast elementów nietekstowych) rozszerza ten wymóg na ikony, obramowania pól i wskaźnik fokusa. Z kolei 1.4.1 (użycie koloru) mówi, że znaczenie — błąd, sukces, status — nie może być przekazywane wyłącznie kolorem; potrzebny jest też tekst, ikona lub inny sygnał.

Tryb ciemny bywa tu zdradliwy. Projekt, który świetnie wygląda w trybie jasnym, w ciemnym potrafi zgubić kontrast przy przyciskach pomocniczych, etykietach drugorzędnych czy stanach nieaktywnych. Każdy motyw trzeba przetestować osobno.

Dostępność w realnych aplikacjach: czytnik ekranu wyróżniający i odczytujący element (z lewej), ten sam ekran logowania przy powiększonej czcionce systemowej (w środku) oraz kontrast interfejsu w trybie ciemnym (z prawej).

Fokus, gesty i obsługa bez precyzyjnego dotyku

Nie każdy obsługuje telefon precyzyjnym dotykiem. Część osób korzysta z zewnętrznej klawiatury, przełączników (switch control) lub sterowania głosem. Stąd kilka kryteriów funkcjonalności. Widoczny fokus (2.4.7): aktywny element musi być wyraźnie zaznaczony, gdy poruszamy się klawiaturą lub przełącznikiem. Gesty wskaźnika (2.5.1): funkcje oparte na złożonych gestach (np. przeciągnięcie dwoma palcami) powinny mieć prostszą alternatywę. Anulowanie wskaźnika (2.5.2): akcja nie powinna wykonywać się nieodwracalnie w momencie samego dotknięcia. Etykieta w nazwie (2.5.3): widoczny napis na przycisku powinien zgadzać się z jego nazwą dostępności — to warunek działania sterowania głosem.

Przy nawigacji klawiaturą lub przełącznikiem użytkownik musi widzieć, gdzie aktualnie jest. Niewidoczny fokus to ślepa uliczka.

Orientacja ekranu: pozioma to nie kaprys

Kryterium 1.3.4 (orientacja) wymaga, by aplikacja działała zarówno w pionie, jak i w poziomie, chyba że konkretna orientacja jest niezbędna (np. skaner kodów). To jedno z najczęściej pomijanych wymagań — wiele aplikacji jest „zaszytych" na sztywno w pionie. Dla osoby, która ma telefon zamontowany na stałe na wózku w poziomie, zablokowana orientacja oznacza, że aplikacji po prostu nie da się wygodnie używać.

Co ciekawe, w tym samym kierunku idzie sama platforma. Google zapowiedziało, że na dużych ekranach (gdy krótszy bok wyświetlacza ma co najmniej 600 dp) system ignoruje wymuszanie przez aplikację jednej orientacji i blokady proporcji okna. Zachowanie to wprowadził Android 16, a Android 17 czyni je obowiązkowym — aplikacje aktualizowane w sklepie Google Play będą musiały być budowane pod docelowy poziom API 37 (tzw. target API), co stanie się wymogiem dystrybucji od sierpnia 2027 roku. Innymi słowy: to, czego od dawna chce WCAG, staje się też wymogiem technicznym ekosystemu. Warto przygotować elastyczne układy wcześniej, zamiast gasić pożar pod presją terminu.

Treści w WebView — najłatwiejsze do przeoczenia

WebView to komponent osadzający treść internetową (HTML) wewnątrz aplikacji mobilnej — często regulaminy, ekrany płatności, formularze zgód czy fragmenty sklepu. Bardzo łatwo o nim zapomnieć, bo „to przecież nie nasz ekran". Tymczasem ta treść również musi być dostępna: czytnik ekranu ma ją poprawnie odczytać, język treści ma być właściwie oznaczony (kryteria z grupy 3.1), a fokus nie może w niej „utknąć" bez możliwości wyjścia. Audyt, który pomija WebView, jest niepełny — a to właśnie w osadzonym formularzu płatności najczęściej kryją się problemy.

Komunikaty o stanie i błędy

Aplikacje stale komunikują: „dodano do koszyka", „błąd połączenia", „płatność zrealizowana". Kryterium 4.1.3 (komunikaty o stanie) wymaga, by takie informacje były ogłaszane technologiom wspomagającym bez wymuszania przeniesienia fokusa. Osobno kryteria z grupy 3.3 (błędy) wymagają, by komunikat o błędzie był opisany tekstowo, zrozumiały i powiązany z właściwym polem — a w akcjach krytycznych, jak płatność, by istniało podsumowanie i możliwość korekty przed finalizacją. Dla osoby korzystającej z czytnika „cichy" toast informacyjny jest jak komunikat, którego nigdy nie było.

Jak audytować dostępność aplikacji mobilnej

Audyt dostępności aplikacji to w większości praca manualna z prawdziwymi technologiami wspomagającymi, a nie pojedyncze kliknięcie skanera. Sprawdzona kolejność wygląda tak:

1. Określ zakres i próbkę. Wybierz kluczowe ścieżki (logowanie, zakup, płatność, ustawienia) i reprezentatywny zestaw ekranów oraz powtarzalnych komponentów. Tu pomaga otwarta metodyka Appt-EM (Appt Evaluation Methodology) fundacji Appt — pięcioetapowa metoda oceny dostępności aplikacji mobilnych: zdefiniowanie zakresu, eksploracja aplikacji, dobór próbki, audyt i raport.
2. Testuj prawdziwymi narzędziami. Przejdź ścieżki z włączonym VoiceOver i TalkBack, przy powiększonej czcionce, w trybie ciemnym, z zewnętrzną klawiaturą i przy ograniczeniu animacji. Czytnik ekranu wychwytuje to, czego nie zobaczy żaden skaner.
3. Wesprzyj się testami automatycznymi — narzędziami systemowymi (Accessibility Inspector na iOS, Accessibility Scanner / testy frameworkowe na Androidzie). Wykryją część problemów: brak etykiet, za mały kontrast, zbyt małe cele dotykowe. To jednak tylko wstęp.
4. Spisz wynik względem kryteriów WCAG 2.1 AA, z poziomem ważności i sugestią naprawy.

Dobrym punktem oparcia są źródła neutralne i oficjalne. Sposób mapowania kryteriów WCAG na oprogramowanie niewebowe opisuje dokument WCAG2ICT konsorcjum W3C; dodatkowa, informacyjna interpretacja pod kątem aplikacji to WCAG2Mobile (notatka robocza W3C z 2025 roku, oparta na WCAG 2.2 — pomocna, choć nienormatywna). Praktyczne wskazówki techniczne dają oficjalna dokumentacja dostępności Apple i Androida oraz otwarte wytyczne Orange dla iOS i Androida. Po polsku konkretne instrukcje publikuje serwis rządowy o dostępności cyfrowej — m.in. jak znaleźć podstawowe błędy i jak testować automatycznie aplikacje mobilne.

A narzędzia oparte na AI? Rynek rośnie i potrafią one przyspieszyć część pracy — zasugerować brakujące etykiety, oznaczyć ryzyka kontrastu, pomóc opisać obrazy. Traktujemy je jako wsparcie, nie zamiennik: ocena tego, czy kolejność odczytu jest sensowna, czy komunikat błędu jest zrozumiały i czy ścieżka płatności da się przejść bez wzroku, wymaga człowieka i prawdziwego czytnika ekranu. Żadne automatyczne narzędzie nie „zagwarantuje zgodności" — i żaden uczciwy dostawca tego nie obieca.

Obszar (zasada)	Co sprawdzamy	Czym testujemy
Postrzegalność	etykiety ikon, kontrast, skalowanie czcionki, tryb ciemny	czytnik ekranu, ustawienia systemowe, pomiar kontrastu
Funkcjonalność	fokus, gesty, orientacja, cele dotykowe	klawiatura/przełącznik, zmiana orientacji, skaner
Zrozumiałość	błędy opisane tekstem, spójna nawigacja, język treści	testy walidacji, przegląd manualny
Solidność	nazwa/rola/stan elementów, komunikaty o stanie, WebView	czytnik ekranu, testy zdarzeń

Najczęstsze błędy — i dlaczego pełna zgodność jest trudna

Zanim wskażemy potknięcia, jedno założenie: znalezienie błędów nie jest oskarżeniem. Pełna zgodność z WCAG 2.1 AA jest wymagająca i w praktyce niewiele aplikacji spełnia każde kryterium bez wyjątku — nawet dojrzałe, znane produkty potykają się choćby o orientację ekranu. Celem audytu nie jest „zaliczenie egzaminu", lecz usunięcie barier, które realnie odcinają część użytkowników.

Najczęściej powtarzają się:

• Nieoznaczone przyciski ikonowe — kosz, filtr, „wstecz" czytane przez czytnik jako „przycisk" bez nazwy.
• Ucinany tekst przy powiększonej czcionce — napisy na przyciskach przycięte w pionie, etykiety w dolnym menu skrócone wielokropkiem bez możliwości odczytania całości.
• Kontrast poniżej progu, zwłaszcza w trybie ciemnym i w stanach nieaktywnych.
• Status przekazywany samym kolorem — czerwone pole bez komunikatu tekstowego.
• Niewidoczny fokus przy obsłudze klawiaturą lub przełącznikiem.
• Pułapki fokusa w oknach modalnych i w WebView.
• Zablokowana orientacja tam, gdzie pozioma nie jest niezbędna.
• „Ciche" komunikaty o stanie, których czytnik ekranu nie ogłasza.

Klasyczny zestaw usterek z jednego ekranu: przy większej czcionce przyciski przycinają własne napisy, a element dolnej nawigacji „gubi" nazwę pod wielokropkiem. Oba przypadki to naruszenie kryterium 1.4.4.

Dobra wiadomość jest taka, że większość tych usterek to nie przebudowa architektury, lecz dyscyplina na poziomie komponentów: konsekwentne etykiety, elastyczne układy, jeden przegląd kontrastu na motyw. Im wcześniej w cyklu wytwarzania, tym taniej.

Jak podchodzi do tego Norbsoft

Dostępność jest u nas elementem szerszego audytu jakości — usługi Mobilnej Transparentności, w której wspólnie z klientem ustalamy zakres i sprawdzamy aplikację m.in. pod kątem funkcjonalności, użyteczności, bezpieczeństwa i właśnie dostępności. To podejście „najpierw rozumiemy, potem ustalamy priorytety", a nie automatyczny raport bez kontekstu produktu.

Kompetencje w tym obszarze są częścią naszego warsztatu technologicznego: projektujemy interfejsy zgodne ze standardami WCAG, optymalizujemy aplikacje pod czytniki ekranu VoiceOver i TalkBack oraz obsługujemy lokalizację, w tym układy pisane od prawej do lewej (RTL, right-to-left). Audyt prowadzimy według ustrukturyzowanej listy kontrolnej, która wiąże kolejne kryteria WCAG z konkretną techniką testowania na urządzeniu — od czytnika ekranu, przez zmianę orientacji i czcionki, po testy walidacji błędów.

Mamy też doświadczenie w budowie dokładnie tych ścieżek, w których dostępność jest krytyczna: bankowych, zakupowych i lojalnościowych. Współtworzyliśmy Portfel SGB — aplikację płatności zbliżeniowych dla banków spółdzielczych, gdzie logowanie i autoryzacja muszą być niezawodne dla każdego. Rozwijaliśmy aplikacje e-commerce Modivo i Empik Foto z wymagającymi ścieżkami zakupowymi oraz program lojalnościowy Costa Coffee Club. To realne, złożone procesy — a dostępność rozstrzyga się właśnie w nich, nie na ekranie powitalnym. Od 2003 roku zrealizowaliśmy ponad 200 projektów, używanych przez odbiorców w 45 krajach, na iOS, Androidzie i w technologii Kotlin Multiplatform.

Podsumowanie i co dalej

Rok po wejściu EAA dostępność przestała być tematem „na później". Dla aplikacji bankowych, sklepowych, transportowych czy telekomunikacyjnych zgodność z WCAG 2.1 AA jest dziś wymogiem, a nie wyróżnikiem. Jednocześnie nie jest to próg nie do przejścia: zdecydowana większość barier wynika z drobnych, naprawialnych decyzji projektowych, a uporządkowany audyt pozwala je wyłapać i ułożyć w sensownej kolejności.

Zespół Norbsoft wspierał już jeden z dużych polskich banków w pracach nad dostosowaniem komponentów design systemu jego aplikacji mobilnej do wymagań standardu WCAG — czyli na poziomie, na którym poprawki najszybciej rozchodzą się na całą aplikację. Jeśli zastanawiasz się, na ile Twoja aplikacja spełnia dziś wymagania EAA i od czego zacząć, dobrym pierwszym krokiem jest audyt dostępności w ramach Mobilnej Transparentności — z konkretną listą priorytetów zamiast ogólnego niepokoju. Zastrzeżenie uczciwe do końca: audyt techniczny zmniejsza ryzyko i poprawia jakość, ale nie jest jednoznaczny z formalnym potwierdzeniem pełnej zgodności prawnej — tę ocenia się zawsze w kontekście konkretnego produktu i przepisów.

Najczęściej zadawane pytania (FAQ)

Czy European Accessibility Act dotyczy mojej aplikacji mobilnej?

Najczęściej tak, jeśli oferujesz konsumentom usługę z listy objętej EAA — handel elektroniczny, bankowość detaliczną, transport pasażerski, telekomunikację lub e-booki — i nie jesteś mikroprzedsiębiorcą. Aplikacja mobilna jest tu traktowana na równi ze stroną internetową. Czysto wewnętrzne narzędzia firmowe zwykle pozostają poza zakresem ustawy.

WCAG 2.1 czy WCAG 2.2 — którą wersję stosować?

Prawnie wiążąca jest dziś WCAG 2.1 na poziomie AA, bo do niej odsyła obowiązująca norma EN 301 549 (wersja 3.2.1). WCAG 2.2 to nowsza, wstecznie zgodna wersja dodająca dziewięć kryteriów. Kolejna edycja normy ma włączyć 2.2, dlatego warto audytować względem 2.1, a wybrane kryteria 2.2 wdrażać z wyprzedzeniem.

Czy potrzebuję deklaracji dostępności w aplikacji?

Formalna deklaracja dostępności to obowiązek sektora publicznego (ustawa z 2019 roku) i tam nadal obowiązuje, także dla aplikacji mobilnych. Podmioty prywatne objęte EAA nie składają takiej deklaracji, ale mają obowiązek udostępnić informację o dostępności produktu lub usługi — w warunkach umowy i w formie samej w sobie dostępnej.

Czy aplikacja naprawdę musi działać w orientacji poziomej?

Co do zasady tak — kryterium 1.3.4 wymaga obsługi obu orientacji, chyba że konkretna jest niezbędna (np. skaner kodów). Dodatkowo platforma Android na dużych ekranach przestaje respektować wymuszanie jednej orientacji, a od 2027 roku stanie się to wymogiem dystrybucji w Google Play. Elastyczny układ warto przygotować wcześniej.

Czy treści w WebView też muszą być dostępne?

Tak. Treść osadzona w komponencie WebView — regulaminy, formularze, ekrany płatności — podlega tym samym wymaganiom co reszta aplikacji. Czytnik ekranu musi ją poprawnie odczytać, język treści ma być oznaczony, a fokus nie może w niej utknąć. To częste i łatwe do przeoczenia źródło problemów.

Czy automatyczny lub oparty na AI audyt wystarczy?

Nie wystarczy samodzielnie. Narzędzia automatyczne i wspierane przez AI wykrywają część usterek — brak etykiet, za niski kontrast, zbyt małe cele dotykowe — i przyspieszają pracę. Ocena kolejności odczytu, zrozumiałości komunikatów czy przejścia ścieżki płatności bez wzroku wymaga jednak testów manualnych z prawdziwym czytnikiem ekranu.

Co grozi za brak zgodności?

Od 28 czerwca 2025 roku rynek jest w fazie nadzoru. Organy mogą kontrolować produkty i usługi, rozpatrywać skargi i nakazywać działania naprawcze, a w skrajnych przypadkach ograniczać udostępnianie niezgodnego produktu na rynku. Niezależnie od sankcji niedostępna aplikacja realnie traci użytkowników, którzy nie są w stanie dokończyć w niej zakupu czy płatności.

Źródła

• Komisja Europejska — European Accessibility Act (dyrektywa (UE) 2019/882, obowiązuje od 28 czerwca 2025) — commission.europa.eu
• Ustawa z dnia 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze (Dz.U. 2024 poz. 731) — eli.gov.pl
• Biznes.gov.pl — Kto ma obowiązek zapewniać dostępność produktów i usług (2025) — biznes.gov.pl
• Ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848) — eli.gov.pl
• W3C WAI — WCAG 2.1 włączone do EN 301 549 (norma obejmuje aplikacje mobilne, 2018) — w3.org
• Komisja Europejska (Shaping Europe's digital future) — EN 301 549 i jego wersje — digital-strategy.ec.europa.eu
• W3C — What's New in WCAG 2.2 (standard z 5 października 2023; 9 nowych kryteriów, wycofanie 4.1.1) — w3.org
• W3C — WCAG2ICT (stosowanie WCAG do oprogramowania niewebowego) — w3.org
• W3C — Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile), notatka robocza z 6 maja 2025 — w3.org
• Apple — Accessibility (dokumentacja dla deweloperów: VoiceOver, Dynamic Type) — developer.apple.com
• Android Developers — Accessibility (TalkBack, wytyczne UI) — developer.android.com
• Android Developers Blog — Prepare your app for resizability and orientation changes (Android 16/17, duże ekrany, API 37 od sierpnia 2027; luty 2026) — android-developers.googleblog.com
• Appt Foundation — Appt Evaluation Methodology (metodyka oceny dostępności aplikacji mobilnych) — appt.org
• Orange — Accessibility guidelines for mobile (iOS i Android) — a11y-guidelines.orange.com
• Serwis Rzeczypospolitej Polskiej — Jak znaleźć podstawowe błędy dostępności cyfrowej aplikacji mobilnej — gov.pl
• Serwis Rzeczypospolitej Polskiej — Jak automatycznie testować dostępność cyfrową aplikacji mobilnych — gov.pl