Dostępnik o 7 odrzuconych kryteriach sukcesu
Mam poczucie, że piszę dzisiaj banały, o którzych wszyscy wiedzą. Ale może tak chociaż dla przypomnienia... 7 kryteriów WCAG, których nie stosujemy przy badaniu aplikacji mobilnych.
Kiedy badamy dostępność aplikacji mobilnej, nie sprawdzamy wszystkich kryteriów WCAG 2.1 na poziomie AA. Ustawa o dostępności cyfrowej — a dokładniej norma EN 301 549, do której odsyła — wyłącza siedem kryteriów sukcesu z oceny aplikacji mobilnych. Nie dlatego, że dostępność w tych obszarach jest nieważna, ale dlatego, że te kryteria po prostu nie pasują do realiów aplikacji.
Warto wiedzieć, które to kryteria i dlaczego akurat one.
Trochę kontekstu, zanim przejdziemy do listy
Ustawa o dostępności cyfrowej wymaga, żeby aplikacje mobilne podmiotów publicznych spełniały wymagania z punktów 9, 10 i 11 normy EN 301 549 V2.1.2. To tam, w tabelarycznym wykazie kryteriów, część pozycji ma przypis: “nie dotyczy aplikacji mobilnych”.
Powód jest jeden: WCAG powstawały z myślą o stronach internetowych. Kiedy tworzono te kryteria, aplikacje mobilne albo nie istniały, albo były zupełnie innym bytem niż dziś. Część kryteriów zakłada model wielostronicowej witryny, struktur HTML, atrybutów języka w znacznikach i mechanizmów nawigacyjnych typowych dla przeglądarek. W natywnych aplikacjach mobilnych tego po prostu nie ma.
Przejdźmy zatem przez te siedem kryteriów.
2.4.1 Możliwość pominięcia bloków — bo system operacyjny już to robi
Kryterium 2.4.1 wymaga, żeby użytkownik mógł pominąć bloki treści powtarzające się na wielu stronach — np. nawigację główną, baner czy nagłówek serwisu. Na stronach internetowych oznacza to zazwyczaj “link do treści głównej” na początku strony.
W aplikacji mobilnej tego mechanizmu nie potrzeba z innego powodu. VoiceOver na iOS i TalkBack na Androidzie mają własne gesty do poruszania się między elementami interfejsu — można przeskakiwać między kontrolkami, nagłówkami czy określonymi typami elementów. System operacyjny przejmuje tu funkcję, którą na stronie internetowej musi zapewnić developer.
Innymi słowy: problem, który 2.4.1 rozwiązuje w sieci, w aplikacjach mobilnych rozwiązuje platforma.
Poza tym aplikacje mobilne mają interfejs dotykowy w obrębie całego ekranu. Możesz więc dotknąć dowolnego fragmentu ekranu, żeby przemieścić fokus.
2.4.2 Tytuł strony — bo w aplikacji nie ma “strony”
To kryterium mówi, że strony internetowe powinny mieć tytuły opisujące ich temat lub cel. Tytuł strony w HTML to element <title> w sekcji <head> — czytnik ekranu ogłasza go przy każdym załadowaniu nowej strony. Jest to także element wyświetlany przez wyszukiwarkę w rodzaju Google, nazwa zakładki w przeglądarce i pełni kilka innych funkcji. Dotyczy to jednak stron internetowych.
W natywnej aplikacji mobilnej nie ma stron w sensie webowym. Są ekrany, widoki, fragmenty interfejsu — ale nie mają odpowiednika <title>. Model nawigacji w aplikacji jest fundamentalnie inny: przechodzisz między ekranami, a nie ładujesz kolejne dokumenty.
To nie znaczy, że ekrany aplikacji nie powinny mieć dostępnych nazw — powinny. Ale WCAG 2.4.2 w swojej dosłownej formie po prostu nie przystaje do tego modelu.
2.4.5 Wiele dróg — bo aplikacja to nie serwis informacyjny
Kryterium 2.4.5 wymaga, żeby do konkretnej strony w serwisie prowadziło więcej niż jedno wejście — np. mapa serwisu, wyszukiwarka czy powiązane linki. Chodzi o to, żeby użytkownik nie musiał przechodzić przez całą hierarchię, jeśli zna inną drogę.
To ma sens dla serwisów z dziesiątkami czy setkami stron. Aplikacja mobilna to zazwyczaj narzędzie do wykonywania konkretnych zadań, z ograniczoną i celowo zaprojektowaną strukturą nawigacji. Nie oczekujemy, że aplikacja bankowa będzie miała mapę aplikacji ani że komunikator będzie oferował alternatywne ścieżki do ustawień.
W aplikacjach natywnych obowiązują wzorce nawigacyjne narzucone przez platformę (zakładki, stos ekranów, menu boczne) — i to wystarczy.
3.1.2 Język części — bo znaczniki językowe to domena HTML
Kryterium 3.1.2 mówi, że jeśli w treści pojawia się fragment w innym języku, powinien być oznaczony atrybutem języka — tak, żeby syntezator mowy mógł przełączyć wymowę na ten język.
Na stronie internetowej robi się to atrybutem lang w HTML. Natywna aplikacja mobilna nie korzysta z HTML ani z żadnego porównywalnego systemu znaczników dokumentu. Nie ma tu ani technicznej możliwości, ani utrwalonego mechanizmu do oznaczania języka fragmentów interfejsu.
Oczywiście dobra praktyka nakazuje, żeby aplikacja obsługiwała wielojęzyczność i żeby syntezatory mowy dostawały właściwe informacje — ale WCAG 3.1.2 w swojej dosłownej postaci zakłada infrastrukturę HTML, której w natywnej aplikacji nie ma.
3.2.3 Spójna nawigacja — bo platformy mają własne wzorce
To kryterium wymaga, żeby elementy nawigacji powtarzające się na wielu stronach pojawiały się w tej samej kolejności. Chodzi o przewidywalność: jeśli menu jest zawsze w tym samym miejscu, użytkownik wie, gdzie go szukać.
W aplikacji mobilnej za spójność nawigacji odpowiada przede wszystkim platforma. iOS ma swoje zasady Human Interface Guidelines, Android — Material Design. Aplikacje, które tych wytycznych przestrzegają, z definicji oferują spójną nawigację — bo użytkownik zna już wzorzec z innych aplikacji na tej samej platformie.
Ponadto kryterium 3.2.3 zakłada powtarzalność elementów nawigacyjnych na wielu stronach. W aplikacjach o innej architekturze to pojęcie po prostu nie jest przystosowane do opisu interfejsu.
Warto przypomnieć sobie, że to kryterium sukcesu jest przede wszystkim dla tych, co korzystają z interfejsu na pamięć, bez każdorazowego czytania elementów menu lub etykiet zakładek. W aplikacjach standardem jest pewien układ tych elementów.
3.2.4 Spójna identyfikacja — z tego samego powodu co 3.2.3
Kryterium 3.2.4 mówi, że elementy pełniące tę samą funkcję na różnych stronach powinny być identyfikowane w ten sam sposób — mieć tę samą etykietę, tę samą dostępną nazwę.
Podobnie jak 3.2.3, to kryterium zakłada wielostronicową witrynę, gdzie te same komponenty (np. ikona wyszukiwarki, przycisk “dodaj do koszyka”) pojawiają się w wielu miejscach. W aplikacji mobilnej mamy do czynienia z bardziej zwartym interfejsem, a platforma i tak narzuca wzorce identyfikacji kontrolek.
Co nie znaczy, że spójna identyfikacja w aplikacjach nie jest ważna — jest. Ale kryterium 3.2.4 w swojej literalnej formie nie przystaje do architektury natywnych aplikacji.
4.1.3 Komunikaty o stanie — bo WCAG pisano dla HTML-a
To kryterium dodano w WCAG 2.1. Wymaga, żeby komunikaty o stanie — informacje o sukcesie operacji, błędach, postępie ładowania, zmianach w koszyku — były dostępne dla technologii asystujących bez konieczności przenoszenia na nie fokusu.
Sformułowanie kryterium zawiera kluczowy zwrot: “w treści implementowanej przy użyciu języków znaczników”. I tu jest problem — natywna aplikacja mobilna nie jest zbudowana przy użyciu języków znaczników. UIKit, SwiftUI, Android Views, Jetpack Compose — żadne z tych środowisk nie jest językiem znaczników.
Z tego samego powodu, dla którego WCAG 3.1.2 nie pasuje do aplikacji, 4.1.3 technicznie też nie “trafia” w natywne aplikacje. Norma EN 301 549 ma co prawda swój odpowiednik w punkcie 11.4.1.3 — wymaganie dla oprogramowania pozawebowego obsługującego technologie asystujące — ale WCAG 4.1.3 dosłownie odczytywane, nie obejmuje natywnych aplikacji.
Co z tego wynika praktycznie?
Wyłączenie kryterium z obowiązku nie znaczy, że można o nim zapomnieć. W kilku z tych siedmiu przypadków idea stojąca za kryterium jest jak najbardziej aktualna — tylko mechanizm realizacji jest inny.
Ekrany aplikacji powinny mieć dostępne nazwy (duch 2.4.2). Syntezatory mowy powinny wiedzieć, w jakim języku czytają (duch 3.1.2). Komunikaty o stanie powinny trafiać do użytkowników czytników ekranu (duch 4.1.3).
Wyłączenia mówią nam, że nie możemy oceniać aplikacji dosłownie tak samo jak stron internetowych — nie że dostępność w tych obszarach nas nie dotyczy. To ważna różnica, szczególnie dla audytorów, którzy przechodzą z audytowania stron www na audytowanie aplikacji.
Pojawia się tu pytanie, a co z aplikacjami z kontrolek WebView? Ano wtedy to już nie ma tych wyłączeń, bo trafiamy na treści wykonane za pomocą języka znaczników. Kontrolki tego typu są obsługiwane przez technologie asystujące tak, jak strony internetowe z całym dobrodziejstwem inwentarza.A lista kryteriów, które obowiązują w aplikacjach? To temat na osobny numer.
Wieści o dostępności
Mam już kilka zaklepanych prezentacji i 1 stolik tematyczny. Wydaje się, że panel dyskusyjny też powoli ogarniamy. Tu możesz przejrzeć opisy wystąpień. Jeszcze nie wszystkie są wprowadzone na stronę, więc stay tuned!
Jeżeli chcesz przybyć na AutomaticA11y 2026, to skorzystaj z formularza zgłoszeniowego. Prawie połowa miejsc jest już zaklepana, co jest dla mnie bardzo miłe. Świadczy o zaufaniu, bo przecież wciąż nie ma programu.
Jak zwykle przymilam się o kawę dla osób, które przybędą na miejsce. Mam nadzieję, że uda się nam nazbierać tyle, żeby nie szukać sponsorów.
Ministerstwo Cyfryzacji opublikowało raport z badania nad wykorzystaniem sztucznej inteligencji w dostępności cyfrowej. Jeszcze nie czytałem, ale wezmę się za to.
26 i 27 marca będę w Poznaniu na konferencji dla osób koordynujących dostępność na uczelniach. Opowiem tam o tym, jak zarządzać cyfrową dostępnością na uczelni. A jak ktoś chce się spotkać i pogadać - zapraszam. Kto mnie zna, to wie że ze mnie słaby zawodnik, ale może tym razem się uda.
Jeżeli lubisz semantykę jak ja i Wojtek Kutyła, to zachęcam Cię do kupienia jego kursu online na ten temat. Semantyka i alternatywy tekstowe to fundamenty dostępności stron internetowych i nie tylko stron. Ważne jest nie tylko to, co widzisz, ale jeszcze bardziej to, co widzą technologie asystujące.
I to by było na tyle. W zeszłym tygodniu miałem urodziny. Miałem nawet napisać wersy na ten temat i może nawet wyrapować. Ale za dużo się dzieje na świecie, w mojej rodzinie i w mojej głowie. Dlatego Tobie życzę spokoju, uciechy z wiosny i skończenia wojen odpalanych przez starych dziadów z małymi fiutkami. Trzymaj się.
Hej Jacek,
przeczytałem z uwagą Twój najnowszy wpis „Dostępnik o 7 odrzuconych kryteriach sukcesu” (16.03.2026). Zgadzam się w 100% z punktem wyjścia: EN 301 549 w klauzuli 11 jawnie wyłącza te siedem kryteriów sukcesu WCAG 2.1 AA dla natywnych aplikacji mobilnych („does not apply” dla non-web software). To fakt prawny i nie ma co go podważać.
Jednak nie zgadzam się z Twoją argumentacją przedstawioną w tekście. W każdym z siedmiu punktów jest ona moim zdaniem nadmiernie uproszczona, a momentami wręcz frywolna. Wydaje mi się, że w tym konkretnym obszarze – mapowaniu kryteriów WCAG na natywne aplikacje mobilne oraz wykorzystywaniu dokumentacji Apple HIG i Android Accessibility Guidelines – brakuje głębszego, bardziej precyzyjnego spojrzenia. Zamiast pokazywać rzeczywiste mapowanie tych kryteriów na natywne API (zgodnie z WCAG2ICT i WCAG2Mobile), tekst w wielu miejscach sprowadza sprawę do „nie ma HTML / platforma to załatwi / nie ma stron”. To wygodne, ale pomija to, co same platformy jawnie od nas wymagają.
Pozwolę sobie odnieść się punkt po punkcie z konkretnymi odwołaniami do aktualnej dokumentacji Apple i Google:
1. 2.4.1 Możliwość pominięcia bloków
Pisze: „VoiceOver i TalkBack mają własne gesty… system operacyjny przejmuje tu funkcję”.
To klasyczne „platforma załatwi”. Apple w HIG Accessibility jasno wymaga jawnego grupowania semantycznego (UIAccessibilityContainerType.semanticGroup). Bez tego VoiceOver i tak bombarduje użytkownika setkami nieuporządkowanych elementów, nawet przy gestach systemowych. To nie platforma magicznym sposobem rozwiązuje problem – to deweloper musi świadomie budować strukturę accessibility tree.
2. 2.4.2 Tytuł strony
Pisze: „w natywnej aplikacji nie ma stron… nie mają odpowiednika <title>”.
Apple HIG Accessibility wprost mówi: „Give each screen a unique title and provide headings that identify sections in your information hierarchy”. Android od wersji 9 daje android:accessibilityPaneTitle. Brak poprawnego tytułu ekranu = czytnik mówi „niezatytułowany widok”. Mapowanie jest jednoznaczne i obie platformy traktują to jako podstawowy wymóg.
3. 2.4.5 Wiele dróg
Pisze: „aplikacja to narzędzie zadaniowe… nie oczekujemy mapy aplikacji”.
To najsłabszy punkt tekstu. WCAG2Mobile (i WCAG2ICT) mapuje to kryterium na alternatywne ścieżki wewnątrz aplikacji (wyszukiwarka, szybkie akcje, deep links, voice shortcuts). Nawet w najbardziej „narzędziowych” aplikacjach widzimy to w praktyce: natywna aplikacja Ustawienia na iOS ma uporządkowaną liniową nawigację po sekcjach, ale jednocześnie wbudowaną wyszukiwarkę opcji. Dokładnie tak samo w aplikacji Facebook w ustawieniach znajdziesz zarówno zwijane/rozwijane sekcje, jak i dedykowaną wyszukiwarkę konkretnych opcji. W bankowości, e-sklepie czy komunikatorze użytkownicy z niepełnosprawnościami realnie potrzebują „wielu dróg”. Redukowanie tego do „apka ma być prosta” pomija rzeczywiste potrzeby.
4. 3.1.2 Język części
Pisze: „natywna aplikacja nie korzysta z HTML… nie ma technicznej możliwości”.
Apple ma accessibilityLanguage / accessibilitySpeechLanguage (dokumentacja Foundation). Android – setAccessibilityLocale i android:locale. Syntezator musi wiedzieć, kiedy przełączyć wymowę (np. angielski fragment w polskiej apce). Twierdzenie „nie ma możliwości” jest po prostu nieprawdziwe.
5. 3.2.3 Spójna nawigacja
Pisze: „za spójność odpowiada przede wszystkim platforma (HIG / Material Design)”.
Platforma daje szablon, ale deweloper decyduje o kolejności w bottom bar, tab barze, drawerze i stosie ekranów. Jeśli „Konto” raz jest na pozycji 2, a raz na 5 – spójność jest złamana. Android Principles of Navigation i Apple HIG podkreślają, że to deweloper odpowiada za przewidywalność w całej aplikacji.
6. 3.2.4 Spójna identyfikacja
Analogicznie. To deweloper decyduje, czy ikona „kosza” zawsze ma tę samą dostępną nazwę w całej apce. Platforma nie robi tego automatycznie we wszystkich przypadkach.
7. 4.1.3 Komunikaty o stanie
Tu największy problem. Pisze w uproszczeniu, że „nie dotyczy”, bo nie ma języków znaczników.
Jetpack Compose ma dedykowane LiveRegion i announceForAccessibility (oficjalna dokumentacja Accessibility in Jetpack Compose). Apple ma UIAccessibilityAnnouncementNotification. To jest dokładny odpowiednik ARIA live regions. Nawet EN 301 549 ma osobną klauzulę 11.4.1.3 wymagającą dokładnie tego efektu. Sugerowanie, że „nie dotyczy” może prowadzić deweloperów do pomijania announcementów – a to jedna z najczęstszych przyczyn frustracji użytkowników czytników.
Podsumowując: wyłączenie z normy jest słuszne, ale Twoje argumenty w tekście były po prostu błędne. Mapowanie tych kryteriów na aplikacje mobilne istnieje (WCAG2ICT + WCAG2Mobile) i da się je precyzyjnie zrealizować natywnymi mechanizmami. Zamiast uproszczeń typu „platforma to załatwi” warto było pokazać rzeczywiste rozwiązania. Taka argumentacja jest szkodliwa przede wszystkim dla deweloperów aplikacji mobilnych i audytorów dostępności – bo łatwo z niej wyciągnąć wniosek, że „nie trzeba nic robić”. W efekcie tracą na tym użytkownicy z niepełnosprawnościami, którzy korzystają z tych aplikacji na co dzień.
Dzięki za tekst i liczę na merytoryczną dyskusję.
tekst jak zwykle dobry, dziekuję
a za "i skończenia wojen odpalanych przez starych dziadów z małymi fiutkami." specjalny szacun