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.
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ń.
Jak sam napisałeś na początku, norma dokładnie tak traktuje te 6 kryteriów - nie badamy. 6, a nie 7, bo listę wziąłem z załącznika do ustawy, a tam samowolnie dodali to siódme:) W moim tekście nie skupiam się na tym, jak pomimo wszystko wdrożyć takie zalecenia, tylko dlaczego te kryteria nie podlegały ocenie. Technologia się rozwija i być może niektóre z kryteriów wrócą. Na przykład odnośnie kryterium 3.1.2 to Android dopiero od pewnego czasu obsługuje elementy w innych językach. Uważam też, że Twoje argumenty nie zawsze trafiają w sedno. Na przykład 2.4.1 to kryterium jasno mówi, jak ma reagować interfejs. Ma służyć do pomijania treści powtarzających się na różnych podstronach. Kontenery są propozycją dla stron internetowych na realizację tego kryterium. Ale tego nie należy wprost przenosić do aplikacji mobilnych, bo tam cel jest inny. Kryterium 2.4.5 odnosi się wprost do stron internetowych, ale gdyby nawet przełożyć to na ekrany, to ja nie znam aplikacji, gdzie to kryterium jest spełnione. Piszesz o aplikacjach mobilnych banków, ale wskaż mi taką, która spełnia to kryterium. Czy faktycznie do każdego ekranu tej aplikacji możesz dotrzeć na 2 różne sposoby? Moja aplikacja mBank tak na pewno nie ma, chociaż są pewne skróty do wykorzystania. Dobrze znowu się z Tobą pospierać. Może odpal na nowo jakiś blog, choćby i tu na Substacku. Wciąż za mało jest dobrych treści po polsku. Chociaż i tak jest lepiej, niż kilka lat temu.
tekst jak zwykle dobry, dziekuję
a za "i skończenia wojen odpalanych przez starych dziadów z małymi fiutkami." specjalny szacun
Bardzo Ci dziękuję.
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ę.
Jak sam napisałeś na początku, norma dokładnie tak traktuje te 6 kryteriów - nie badamy. 6, a nie 7, bo listę wziąłem z załącznika do ustawy, a tam samowolnie dodali to siódme:) W moim tekście nie skupiam się na tym, jak pomimo wszystko wdrożyć takie zalecenia, tylko dlaczego te kryteria nie podlegały ocenie. Technologia się rozwija i być może niektóre z kryteriów wrócą. Na przykład odnośnie kryterium 3.1.2 to Android dopiero od pewnego czasu obsługuje elementy w innych językach. Uważam też, że Twoje argumenty nie zawsze trafiają w sedno. Na przykład 2.4.1 to kryterium jasno mówi, jak ma reagować interfejs. Ma służyć do pomijania treści powtarzających się na różnych podstronach. Kontenery są propozycją dla stron internetowych na realizację tego kryterium. Ale tego nie należy wprost przenosić do aplikacji mobilnych, bo tam cel jest inny. Kryterium 2.4.5 odnosi się wprost do stron internetowych, ale gdyby nawet przełożyć to na ekrany, to ja nie znam aplikacji, gdzie to kryterium jest spełnione. Piszesz o aplikacjach mobilnych banków, ale wskaż mi taką, która spełnia to kryterium. Czy faktycznie do każdego ekranu tej aplikacji możesz dotrzeć na 2 różne sposoby? Moja aplikacja mBank tak na pewno nie ma, chociaż są pewne skróty do wykorzystania. Dobrze znowu się z Tobą pospierać. Może odpal na nowo jakiś blog, choćby i tu na Substacku. Wciąż za mało jest dobrych treści po polsku. Chociaż i tak jest lepiej, niż kilka lat temu.