Manuelle Barrierefreiheitstests für Mobile-Apps
Barrierefreiheitstests für Mobile-Apps
Native iOS- und Android-Apps, React Native und Flutter — auf echten Geräten mit Screenreader, nicht im Emulator. Der Standard ist EN 301 549, Abschnitt 11 „Software".
Wir antworten zu Geschäftszeiten
Das Gesetz nennt Apps ausdrücklich
Kein Nice-to-have. Vier Dokumente führen Mobile-Apps eigenständig auf.
European Accessibility Act
Die Richtlinie (EU) 2019/882 gilt seit dem 28. Juni 2025. Sie erfasst Apps von Banken, E-Commerce, Verkehr, E-Books und Telekommunikation.
BFSG · Deutschland
Die deutsche Umsetzung des EAA, gleiches Datum. Auf dem deutschen Markt ist das der Text, auf den sich Einkäufer bei Ihrer App berufen.
Ukraine: Beschluss 895
Ziffer 7 verpflichtet Anbieter universeller elektronischer Kommunikationsdienste, Websites UND Mobile-Apps barrierefrei zu machen. Gültig ab 15.07.2028.
EN 301 549 V3.2.1
Der technische Standard, auf den sowohl EU- als auch ukrainische Anforderungen verweisen. Für Apps gilt Abschnitt 11, nicht Abschnitt 9.
Abschnitt 11 ist nicht dieselbe Checkliste wie fürs Web
Eine Webseite bewertet EN 301 549 nach Abschnitt 9, der auf WCAG verweist. Eine native App fällt unter Abschnitt 11 „Software" mit eigenen Anforderungen an Namen und Rollen, Fokus, Gesten und Systemeinstellungen. Ein Website-Audit deckt die App nicht ab, selbst wenn beide dieselben Daten zeigen.
Für Apps gibt es kaum Automatisierung
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.
Deshalb wird alles Wesentliche von Hand durchgegangen
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.
Beide Plattformen, echte Geräte
Ein Emulator bildet weder den Screenreader noch die System-Einstellungen für Barrierefreiheit ab
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 und nativer Code
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.
Was wir genau prüfen
Acht Bereiche, jeder auf beiden Plattformen
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.
Was Sie bekommen
- 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
Kosten
Kalkulation nach Briefing
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.
Briefing sendenBrauchen Sie auch die Website? Manuelle Website-Tests
Häufige Fragen
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.
Erzählen Sie uns von Ihrer App
Wir melden uns zu Geschäftszeiten mit Kalkulation, Zeitplan und der Liste dessen, was wir prüfen.
Briefing sendenBriefing → Angebot mit Zeitplan und Preis