Manualne testy dostępności aplikacji mobilnych
Testy dostępności aplikacji mobilnych
Natywne iOS i Android, React Native oraz Flutter — na prawdziwych urządzeniach z czytnikami ekranu, a nie w emulatorze. Standard to EN 301 549, rozdział 11 „Oprogramowanie".
Odpowiadamy w godzinach pracy
Prawo wymienia aplikacje wprost
To nie jest opcja. Cztery dokumenty wymieniają aplikacje mobilne osobno.
European Accessibility Act
Dyrektywa (UE) 2019/882 obowiązuje od 28 czerwca 2025 roku. Obejmuje aplikacje banków, e-commerce, transportu, e-booków i telekomunikacji.
BFSG · Niemcy
Niemiecka implementacja EAA, ta sama data. Na rynku niemieckim to dokument, na który powołują się kupujący, pytając o aplikację.
Ukraina: uchwała 895
Punkt 7 zobowiązuje dostawców powszechnych usług komunikacji elektronicznej do zapewnienia dostępności zarówno stron, jak i aplikacji mobilnych. Obowiązuje od 15.07.2028.
EN 301 549 V3.2.1
Standard techniczny, do którego odsyłają wymogi unijne i ukraińskie. Dla aplikacji obowiązuje rozdział 11, a nie rozdział 9.
Rozdział 11 to nie ta sama lista kontrolna co dla stron
Stronę internetową EN 301 549 ocenia według rozdziału 9, który odsyła do WCAG. Aplikacja natywna podlega rozdziałowi 11 „Oprogramowanie" z własnymi wymaganiami wobec nazw i ról, fokusu, gestów i ustawień systemowych. Audyt strony nie obejmuje aplikacji, nawet jeśli obie pokazują te same dane.
Dla aplikacji prawie nie ma automatyzacji
On the web automation is mature: our Audit walks a site daily against 90+ rules. Native apps have no tooling at that level. Android Accessibility Scanner and Xcode Accessibility Inspector catch the basics: missing labels, small touch targets, weak contrast. Focus order, gesture logic, state announcements and behaviour at system-level font scaling are invisible to them.
Dlatego wszystko istotne przechodzi się ręcznie
A tester walks every user journey on a real device with the screen reader on — sign-up, payment, changing settings. That is how you find screens you cannot leave, buttons with no name, modals that never take focus, and forms whose errors are never announced.
Obie platformy, prawdziwe urządzenia
Emulator nie odtwarza ani czytnika ekranu, ani systemowych ustawień dostępności
iOS
Key journeys with VoiceOver on a physical iPhone: focus order, rotor gestures, element names and roles, Dynamic Type and Voice Control, behaviour under Switch Control.
Android
The same with TalkBack across device generations and OS versions: announcements, traversal order, Switch Access, behaviour after a font-size or display-scale change.
React Native, Flutter i kod natywny
Cross-platform apps are tested as native ones — from the user side there is no difference. The report states where the cause sits: your code, a framework component, or the build configuration.
Co dokładnie sprawdzamy
Osiem obszarów, każdy na obu platformach
Screen reader and focus order
Every screen is walked by ear: do all elements have names and roles, does traversal order make sense, does focus get lost in modals, and is there a way out of them.
Touch targets and gestures
At least 44×44 pt on iOS and 48×48 dp on Android, enough spacing between adjacent controls, and an alternative to complex gestures — swipe, long press, drag.
Text scaling
Dynamic Type on iOS and system font size on Android at their largest: no clipping, no overlap, no buttons pushed off-screen.
Contrast and themes
Light and dark themes, high contrast mode, colour inversion, and the readability of text over images and video.
Orientation and motion
Portrait and landscape with no loss of content, system Reduce Motion respected, and no automatic animation that cannot be stopped.
Forms and errors
Field labels, hints, keyboard type, error announcements, and the ability to correct input without losing what is already filled in.
Media and timeouts
Video captions, playback control, audio autostart, and every place the app puts a clock on an action — SMS codes, sessions, carts.
System settings
Whether the app respects what the person already set on their phone: bold text, reduced transparency, disabled animation, larger pointer, an external keyboard.
Co otrzymujecie
- A report of every issue mapped to EN 301 549 clause 11 and to WCAG criteria, ranked by severity with an estimate of the fix effort
- Screen recordings with the screen reader on — you see and hear exactly what breaks, so a developer does not have to reproduce the bug blind
- A prioritised action plan: fix before release, next sprint, or requires a change to the navigation architecture
- A re-check of the critical issues once you have fixed them
Koszt
Wyceniamy na podstawie briefu
The price depends on the number of screens, the platforms, and whether you want sessions with real users. Send us the app or describe it and we will come back with a quote and a timeline.
Wyślij briefPotrzebna też strona? Manualne testy stron
Częste pytania
Can an app be tested automatically, like a website?
Partly. Android Accessibility Scanner and Xcode Accessibility Inspector find missing labels, small touch targets and weak contrast. But native apps have nothing at the level of web scanners: focus order, gesture logic, state announcements and behaviour at large font sizes have to be walked by hand on a device.
Does this work for React Native and Flutter?
Yes. From the user side there is no difference — the screen reader works with whatever the platform exposes. The report separately states where the cause sits: your code, a framework component, or the build configuration, because the fix differs in each case.
Which standard applies to apps?
EN 301 549, clause 11 "Software". This matters: web pages are assessed under clause 9, which references WCAG, while apps fall under clause 11 with its own requirements for names, roles, focus and system settings. A website audit does not cover the app, even when both hold the same data.
Which devices do you test on?
Physical ones. An emulator reproduces neither the screen reader, nor the system accessibility settings, nor real gestures. We use several device generations and OS versions, because TalkBack and VoiceOver behave differently between them.
Do we also need a website audit?
If you have both a site and an app — yes, these are two separate assessments under different clauses of the standard. The site is covered by the automated Audit plus manual testing; the app by manual testing only. Ordering both together costs less than separately, because part of the preparation is shared.
Opowiedzcie o swojej aplikacji
Wrócimy w godzinach pracy z wyceną, terminami i listą tego, co sprawdzimy.
Wyślij briefBrief → oferta z terminami i ceną