Przejdź do treści
Pandus

WCAG dla aplikacji mobilnych: co obowiązuje i jak testować na Androidzie i iOS

Zaktualizowano 14 października 2026 · 7 min czytania

Wiele sklepów i usług ma aplikację obok strony internetowej i szybko pojawia się pytanie: czy WCAG dotyczy aplikacji mobilnych? Krótko: WCAG napisano dla treści internetowych, ale jego kryteria stosuje się także do aplikacji. W3C publikuje wskazówki, jak to robić, a europejska norma EN 301 549 ma rozdział o oprogramowaniu, który wymienia aplikacje mobilne. Ta strona wyjaśnia, które dokumenty mają znaczenie i jak testować aplikację narzędziami Google i Apple.

Z góry: Pandus sprawdza strony internetowe, w tym mobilną wersję strony, a nie natywne aplikacje na iOS ani Androida. W części dotyczącej aplikacji ta strona wskazuje narzędzia platform. To ogólna informacja, a nie porada prawna.

Czy istnieje WCAG dla urządzeń mobilnych?

Nie ma osobnego standardu. W3C mówi wprost, że nie ma osobnych wytycznych dla dostępności mobilnej. Zamiast tego:

  • WCAG 2.2 obejmuje strony i aplikacje internetowe, także treści używane na urządzeniach mobilnych. Mobilna strona internetowa lub aplikacja webowa w przeglądarce telefonu to po prostu treść internetowa.
  • WCAG2ICT – Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies – wyjaśnia, jak WCAG 2.0, 2.1 i 2.2 stosują się do dokumentów i oprogramowania spoza sieci. To nota grupy roboczej W3C z grudnia 2025 r. o charakterze informacyjnym: sama zaznacza, że nie ustanawia wymagań i nie jest standardem.
  • WCAG2Mobile – Guidance on Applying WCAG 2.2 to Mobile Applications – to szkic noty grupy roboczej z maja 2025 r., nadal praca w toku. Obejmuje aplikacje natywne, mobilne strony internetowe i aplikacje hybrydowe oraz rozwija starszą notę Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile. Również jest informacyjna, a nie normatywna.

Sam WCAG więc dla aplikacji się nie zmienia. Noty wyjaśniają, kryterium po kryterium, jak pojęcia napisane dla sieci – takie jak „strona internetowa” czy „zestaw stron internetowych” – można odczytać dla oprogramowania i gdzie kryterium wymaga innego odczytania lub nie ma zastosowania.

EN 301 549: rozdział 11 dla oprogramowania

W Unii Europejskiej technicznym odniesieniem dla dostępności ICT jest EN 301 549. Jej struktura rozdziela rodzaje treści:

  • Rozdział 9 – Web. Strony internetowe. Uwaga w normie mówi, że aplikacje internetowe, w tym mobilne aplikacje internetowe, są objęte jej szeroką definicją strony internetowej.
  • Rozdział 10 – Dokumenty niewebowe.
  • Rozdział 11 – Oprogramowanie. Jego klauzula ogólna wymienia oprogramowanie platformowe, oprogramowanie z interfejsem użytkownika, narzędzia autorskie, technologię wspomagającą i aplikacje mobilne.

Klauzule 11.1–11.4 dla oprogramowania podążają za zasadami WCAG – postrzegalność, funkcjonalność, zrozumiałość, solidność – a kolejne klauzule dodają własne wymagania, takie jak 11.5 Interoperacyjność z technologią wspomagającą i 11.7 Preferencje użytkownika. WCAG2ICT wspomina też, że EN 301 549 stwierdza, iż 2.4.2 Tytuł strony i 3.1.2 Język części nie mają zastosowania do oprogramowania niewebowego. Rozdział 5, Wymagania ogólne, stosuje się także do aplikacji.

To, czy jakieś prawo wymaga dostępności Państwa aplikacji, zależy od tego, kim Państwo są i co sprzedają. Nasz przewodnik po EAA wyjaśnia europejski akt o dostępności, który używa EN 301 549 jako odniesienia technicznego.

Kryteria WCAG 2.2 najważniejsze w aplikacjach

Wszystkie kryteria A i AA są istotne, ale te wracają w przeglądach aplikacji raz po raz:

Jak testować dostępność na Androidzie

Poradnik testowania Google łączy kontrole automatyczne i ręczne:

  1. Accessibility Scanner. Darmowa aplikacja z Google Play. Włącza się ją w Ustawienia → Ułatwienia dostępu → Accessibility Scanner, otwiera aplikację i dotyka Snapshot dla jednego ekranu lub Record dla przepływu. Podpowiada usprawnienia dotyczące etykiet treści, rozmiaru celów dotykowych, elementów klikalnych oraz kontrastu tekstu i obrazów. Wymaga Androida 9.0 lub nowszego, a Google zaznacza, że nie zastępuje testów ręcznych.
  2. TalkBack. Wbudowany czytnik ekranu Androida. Przesuwanie w prawo i w lewo przez każdy element: czy każdy jest ogłaszany z jasną nazwą i celem, czy można dotrzeć do wszystkich, czy tymczasowe komunikaty są czytane na głos?
  3. Automatyczne testy UI. Od Compose 1.8.0 Accessibility Test Framework może działać w testach UI Compose: należy dodać zależność ui-test-junit4-accessibility i wywołać enableAccessibilityChecks() na regule testu. Kontrole obejmują brakujące etykiety, kontrast kolorów, małe cele dotykowe i kolejność przechodzenia.

Testy w emulatorze Androida. Emulatory nie mają zainstalowanego TalkBack. Codelab Google radzi wybrać obraz emulatora ze sklepem Play i zainstalować z niego Android Accessibility Suite. Google zaznacza też, że Accessibility Test Framework w Android Studio nie wykryje problemów występujących tylko wtedy, gdy aplikacja działa na urządzeniu, więc przed wydaniem należy przetestować aplikację na prawdziwym telefonie.

Jak testować dostępność na iOS

  1. Accessibility Inspector. Otwiera się go w Xcode przez Xcode → Open Developer Tool → Accessibility Inspector. Apple opisuje go jako narzędzie do wyświetlania, odpytywania i testowania informacji o dostępności elementów aplikacji oraz audytu pod kątem problemów takich jak obcięty tekst, elementy bez etykiet, rozmiar tekstu i kontrast kolorów.
  2. VoiceOver na urządzeniu. Poradnik testowania Apple mówi, aby zainstalować aplikację na fizycznym urządzeniu, ponieważ VoiceOver nie jest dostępny w Simulatorze. Włącza się go w Ustawienia → Dostępność → VoiceOver, a kurtyny ekranu (screen curtain) można użyć do testowania bez patrzenia na ekran.
  3. Automatyczne audyty w testach UI. Poradnik Apple wskazuje też dodawanie audytów dostępności do testów UI.

Zatem co do „testowania dostępności w symulatorze iOS”: można przeglądać i audytować za pomocą Accessibility Inspector, ale prawdziwy test z czytnikiem ekranu wymaga iPhone’a lub iPada.

Co obejmuje Pandus, a czego nie

Pandus sprawdza strony internetowe: co tydzień każdą podstronę serwisu, silnikiem axe-core w prawdziwej przeglądarce, względem WCAG 2.2 A i AA. Obejmuje to problemy szkodzące mobilnym odwiedzającym Państwa serwis, takie jak viewport blokujący powiększanie czy zbyt małe cele dotykowe. Nie testuje natywnych aplikacji na iOS ani Androida i nie testuje ekranów aplikacji hybrydowej wewnątrz jej powłoki.

Jeśli klienci kupują zarówno na stronie, jak i w aplikacji, stronę warto sprawdzić naszym darmowym WCAG checkerem lub darmową kontrolą, a aplikację testować narzędziami platform opisanymi wyżej. Kroki ręczne dla stron opisano w jak testować WCAG. Nasze kontrole to automatyczna kontrola, a nie pełny audyt, i nie są poradą prawną.

Najczęstsze pytania

Czy WCAG dotyczy aplikacji mobilnych?

WCAG napisano dla treści internetowych, ale jego kryteria można stosować do aplikacji natywnych. W3C wyjaśnia jak w dwóch notach informacyjnych, WCAG2ICT i szkicu WCAG2Mobile, a EN 301 549 zawiera w rozdziale 11 wymagania dla oprogramowania, w tym aplikacji mobilnych.

Czy istnieje osobny standard W3C dla dostępności mobilnej?

Nie. W3C mówi, że nie ma osobnych wytycznych dla dostępności mobilnej. WCAG obejmuje treści internetowe na urządzeniach mobilnych, a noty wyjaśniają, jak stosować go do aplikacji natywnych i hybrydowych.

Jak testować dostępność na Androidzie?

Accessibility Scanner z Google Play daje automatyczne sugestie, TalkBack służy do testu z czytnikiem ekranu, a od Compose 1.8.0 Accessibility Test Framework działa w testach UI Compose. Scanner nie zastępuje testów ręcznych.

Czy mogę testować VoiceOver w symulatorze iOS?

Nie. Apple mówi, że VoiceOver nie jest dostępny w Simulatorze, więc do testu z czytnikiem ekranu aplikację należy zainstalować na fizycznym urządzeniu. Accessibility Inspector w Xcode pomaga przeglądać i audytować elementy.

Czy Pandus testuje aplikacje mobilne?

Nie. Pandus sprawdza strony internetowe, w tym mobilną wersję strony, ale nie natywne aplikacje na iOS ani Androida. Dla aplikacji należy użyć narzędzi platform opisanych na tej stronie.

Źródła

  • W3C WAI, Mobile Accessibility at W3C: https://www.w3.org/WAI/standards-guidelines/mobile/
  • W3C, WCAG2ICT (Group Note, December 2025): https://www.w3.org/TR/wcag2ict-22/
  • W3C, Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile, Group Draft Note, May 2025): https://www.w3.org/TR/wcag2mobile-22/
  • ETSI, EN 301 549 V3.2.1, clauses 9 and 11: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf
  • Android Developers, Test your app's accessibility: https://developer.android.com/guide/topics/ui/accessibility/testing
  • Android Developers, Compose accessibility testing: https://developer.android.com/develop/ui/compose/accessibility/testing
  • Android Developers, Accessibility in Jetpack Compose codelab (TalkBack on an emulator): https://developer.android.com/codelabs/jetpack-compose-accessibility
  • Google, Get started with Accessibility Scanner: https://support.google.com/accessibility/android/answer/6376570
  • Apple Developer, Accessibility Inspector: https://developer.apple.com/documentation/accessibility/accessibility-inspector
  • Apple Developer, Performing accessibility testing for your app: https://developer.apple.com/documentation/accessibility/performing-accessibility-testing-for-your-app