Checkliste für die Barrierefreiheit mobiler Apps: Ohne Risiko veröffentlichen

Wenn Nutzer zusätzliche Anstrengungen unternehmen müssen, um Ihre App zu nutzen, werden sie dies nicht tun. Das ist einfache Mathematik. Wenn Schaltflächen von Screenreadern nicht gelesen werden können oder Formulare bei größeren Schriftgrößen nicht mehr funktionieren, melden die Nutzer keine Fehler. Sie deinstallieren die App. Deshalb sind Tests zur Barrierefreiheit mobiler Apps nicht mehr nur ein „nettes QA-Verfahren“, sondern eine Voraussetzung für die Veröffentlichung.

Die Barrierefreiheit beeinflusst die Zuverlässigkeit des Produkts und entscheidet zunehmend darüber, ob Unternehmenskunden Ihre App überhaupt in die engere Wahl ziehen. Mit dem seit Juni 2025 geltenden Europäischen Barrierefreiheitsgesetz und WCAG 2.2 als Standard-Benchmark für mobile Apps steht das Testen der Barrierefreiheit nun neben Leistung und Sicherheit an erster Stelle bei der Release-Vorbereitung. Diese Checkliste zeigt, was vor der Markteinführung tatsächlich getestet werden muss, damit Barrierefreiheitslücken nicht zu Last-Minute-Korrekturen, Compliance-Problemen oder stillschweigend verlorenen Geschäften führen.

Standards, die wirklich wichtig sind

Sie wissen bereits, dass es WCAG gibt. Die eigentliche Frage ist, wie sich dies auf das Testen auswirkt.

Standards ≠ Reales Testen
WCAG definiert erwartete Ergebnisse. Es berücksichtigt jedoch nicht, wie sich die Barrierefreiheit in dynamischen mobilen Schnittstellen, auf verschiedenen Geräten oder unter realen Bedingungen mit assistiver Technologie verhält. Hier treten die meisten Fehler auf.

Mobile Geräte erhöhen die Komplexität
Im Gegensatz zu Desktop-Umgebungen laufen mobile Apps auf fragmentierten Geräten, Betriebssystemebenen und Barrierefreiheits-APIs. Selbst wenn Sie „den Standard erfüllen”, kann das Verhalten in der Praxis beeinträchtigt sein.

Häufige Schwachstellen sind:

• Die Geste steht im Konflikt mit Bildschirmleseprogrammen
• Inkonsistente Implementierung der Barrierefreiheits-API unter iOS und Android
• Übergänge zwischen nativen und WebView-Anwendungen, die den Fokus und Ankündigungen unterbrechen
• Layout-Regressionen bei Schriftartskalierung, Dunkelmodus oder Überschreibungen der Barrierefreiheit des Betriebssystems

Compliance allein reicht nicht aus
Teams entdecken dies oft erst bei Beschaffungsaudits, wenn Fragen der Barrierefreiheit plötzlich von technischen Details zu Vertragsrisiken werden.

Ansatz für das Testen der Barrierefreiheit auf Mobilgeräten

Effektive Tests der mobilen Barrierefreiheit funktionieren in drei Ebenen. Wenn eine davon übersprungen wird, schleichen sich blinde Flecken in die Produktion ein, die oft unbemerkt bleiben, bis die Konversionsrate sinkt, Beschwerden über die Barrierefreiheit auftauchen oder Fragen zur Compliance aufkommen. Diese blinden Flecken zeigen sich in Form von Kundenabwanderung, Support-Tickets oder ins Stocken geratenen Unternehmensgesprächen. Die WCAG2-Mobile-Richtlinien 2025 des W3C betonen die Notwendigkeit, automatisierte Prüfungen, manuelle Validierungen und Tests mit echten Benutzern zu kombinieren, um eine zuverlässige Abdeckung der Barrierefreiheit zu erreichen.

Ebene 1: Automatisierte Scans

Automatisierte Tools helfen dabei, strukturelle Barrierefreiheitslücken in mobilen Apps schnell zu erkennen, insbesondere wenn sie frühzeitig in Entwicklungs-Pipelines oder Regressionstests integriert werden.

Typische Probleme, die durch Automatisierung aufgedeckt werden:

• Fehlende Barrierefreiheitsbezeichnungen oder semantische Rollen
• Unzureichender Farbkontrast
• Tap-Ziele unterhalb der empfohlenen Größe
• Grundlegende Kompatibilitätsfehler bei Bildschirmleseprogrammen

Viele Teams stärken diese Phase, indem sie Automatisierung mit KI-basierten Softwaretests kombinieren, um während der Releases kontinuierlich Barrierefreiheitsrisiken und Funktionsfehler zu kennzeichnen.

Die Automatisierung beschleunigt die Früherkennung bei Tests der Barrierefreiheit mobiler Anwendungen, kann jedoch die Interaktion realer Benutzer nicht nachbilden, die eine manuelle Validierung erfordert.

Ebene 2: Manuelles Testen von assistiver Technologie

Hier wird das Testen der Barrierefreiheit mobiler Apps von der Theorie in die Praxis umgesetzt.

Führen Sie wichtige Abläufe mit assistiven Technologien durch:

• VoiceOver (iOS) oder TalkBack (Android) Navigation
• Schriftgrößenanpassung und dynamische Textanpassungen
• Dunkler Modus und Kontrasteinstellungen
• Externe Tastatur oder Sprachsteuerung

Die manuelle Validierung wird oft Teil umfassenderer Testdienstleistungen für mobile Anwendungen, da sich Probleme der Barrierefreiheit mit der Benutzerfreundlichkeit, der Leistung und der Gerätekompatibilität überschneiden.

In dieser Phase werden in der Regel folgende Probleme aufgedeckt:

• Unlogische Fokusreihenfolge
• Konflikte zwischen Gesten und Barrierefreiheitseinstellungen
• Stille dynamische Aktualisierungen
• Benutzerdefinierte UI-Komponenten, denen Barrierefreiheitsstatus fehlen

Während der Barrierefreiheitsprüfung der Eurovision-Apps durch QAwerk haben unsere manuellen Tests mit VoiceOver und TalkBack mehrere Fehler mit hoher Priorität aufgedeckt, darunter Fehler bei der Schriftartskalierung, Unterbrechungen beim Scrollen, Unstimmigkeiten bei der Audioausgabe und nicht beschriftete Inhalte.

Ebene 3: Validierung durch echte Nutzer

Echte Nutzer, die auf assistive Technologien angewiesen sind, decken Lücken auf, die die interne Qualitätssicherung selten vorhersieht.

Sie konzentrieren sich insbesondere auf:

• Onboarding-Abläufe
• Checkout- oder Zahlungsvorgänge
• Authentifizierungs- oder formularlastige Bildschirme

Selbst kurze Validierungssitzungen zeigen oft Folgendes auf:

• Navigationsprobleme
• Kognitive Belastungsbarrieren
• Probleme bei der Interpretation durch Screenreader
• Gerätespezifische Verhaltensunterschiede

Unternehmen, die sich auf Compliance-Audits oder Produkteinführungen vorbereiten, ergänzen ihre interne Qualitätssicherung in der Regel durch strukturierte Barrierefreiheitstests, um die Ergebnisse mit den WCAG-Anforderungen und den sich weiterentwickelnden Barrierefreiheitsvorschriften in Einklang zu bringen.

Checkliste für die Barrierefreiheit mobiler Apps

Dieser Abschnitt dient eher als praktische Checkliste für die Barrierefreiheit mobiler Apps als als theoretischer Überblick. Probleme werden in der Regel nach Auswirkungen auf die Benutzer und Risikopotenzial priorisiert – derselbe Ansatz wird auch bei echten Barrierefreiheitsprüfungen verwendet.

Release-kritische Barrierefreiheitsfehler

Diese Probleme wirken sich direkt auf die Benutzerfreundlichkeit aus und führen bei einem Barrierefreiheitsaudit für mobile Apps häufig zu Compliance-Risiken.

Bildschirmleseprogramm und Fokusintegrität
Die Kompatibilität mit Screenreadern und das logische Fokusverhalten entscheiden darüber, ob Benutzer, die auf assistive Technologien angewiesen sind, überhaupt in der App navigieren können. Selbst optisch ausgefeilte Benutzeroberflächen bestehen den Barrierefreiheitstest nicht, wenn semantische Rollen, die Fokusbehandlung oder die Darstellung des Barrierefreiheitsbaums fehlerhaft sind.

Was zu überprüfen ist:

• Jedes interaktive Element zeigt eine Beschriftung, eine Rolle und einen Status an.
• Die Wischnavigation folgt einer logischen Lesereihenfolge
• Modale Fenster fangen den Fokus korrekt ein.
• Beim Schließen von Dialogen wird der Fokus wieder auf den Auslöser zurückgesetzt.
• Versteckte Elemente erhalten niemals den Fokus.

In unserer Praxis haben während der Barrierefreiheitstests der neu gestalteten Plattform von Elsewhen fehlende Alt-Texte und Probleme mit semantischen Markups dazu geführt, dass Screenreader die Kerninhalte nicht korrekt interpretieren konnten. Probleme wie diese sind selten komplex, aber ohne strukturierte Tests der Barrierefreiheit für Mobilgeräte, die in den Release-Prozess integriert sind, leicht zu übersehen.

Touch, Gesten und Zielzugänglichkeit
Die Barrierefreiheit auf Mobilgeräten scheitert oft auf der Interaktionsebene. Kleine Tippziele, dichte Layouts oder ausschließlich gestenbasierte Steuerelemente schaffen Barrieren, selbst wenn das visuelle Design übersichtlich erscheint.

Zu überprüfen:

• Mindestgröße der Ziele: 44×44 pt (iOS) / 48×48 dp (Android)
• Ausreichender Abstand (~8 dp) zwischen interaktiven Elementen
• Single-Touch-Alternativen für Mehrpunktgesten
• Kritische Aktionen, die nicht ausschließlich auf Gesten basieren

Dies ist eine der häufigsten Feststellungen bei Tests zur Barrierefreiheit mobiler Anwendungen.

Visuelle Barrierefreiheit und Skalierung
Kontrast, Schriftgrößenanpassung und Flexibilität bei der Ausrichtung wirken sich direkt auf die Lesbarkeit aus, insbesondere in realen mobilen Anwendungsfällen wie Außenbeleuchtung oder Systemzugänglichkeits-Einstellungen.

Zu überprüfen:

• 4,5:1 Kontrast für Standardtext, 3:1 für große Text-/UI-Elemente
• Der Dunkelmodus führt nicht zu Kontrastverschlechterungen
• Die Schriftgrößenanpassung (~200 %) beeinträchtigt das Layout nicht
• Die Ausrichtung im Hoch- und Querformat bleibt nutzbar
• Keine abgeschnittenen oder versteckten CTAs

Kontrastverringerungen im Dunkelmodus treten besonders häufig nach einer Neugestaltung der Benutzeroberfläche auf.

Formulare, Fehler und dynamisches Feedback
Formulare, Validierungsmeldungen und dynamische UI-Zustände entscheiden häufig darüber, ob Benutzer wichtige Aktionen wie die Anmeldung oder den Checkout abschließen können. Probleme mit der Barrierefreiheit treten hier in der Regel eher in Form von stillen Validierungsproblemen oder fehlenden programmatischen Ankündigungen als in Form von visuellen Fehlern auf.

Was zu überprüfen ist:

• Nur sichtbare Beschriftungen anstelle von Platzhaltern
• Validierungsfeedback wird programmgesteuert für assistive Technologien bereitgestellt
• Fehler identifizieren sowohl das Feld als auch das Problem
• Warnungen bei Ablauf der Sitzung ermöglichen eine Verlängerung
• Leere oder Ladezustände werden deutlich angezeigt

Stille Formularfehler sind ein häufiger Grund dafür, dass die Barrierefreiheit mobiler Apps aufgegeben wird.

Risiken mit hoher Auswirkung auf die Benutzerfreundlichkeit

Sobald die wichtigsten Hindernisse beseitigt sind, treten bei umfassenden Tests des Benutzerflusses häufig Risiken für die Barrierefreiheit auf Ebene der Benutzerfreundlichkeit zutage. Diese führen zwar selten zu rechtlichen Konsequenzen, beeinträchtigen jedoch das Engagement und die Kundenbindung erheblich.

Zu überprüfen:

• Keine Textverkürzung bei maximaler Schriftgröße
• Konsistente Navigationsstruktur über alle Bildschirme hinweg
• Stabile Layouts ohne unerwartete Verschiebungen
• Klare Rückmeldung bei leeren oder Ladezuständen

Diese Punkte treten häufig bei der Barrierefreiheitstestung von mobilen Apps auf, sobald vollständige Benutzerabläufe getestet wurden.

Erweiterte und verstärkte Überprüfungen

Diese Prüfungen spiegeln eher die Reife der Barrierefreiheit als die grundlegende Konformität wider. Sie werden in der Regel Teil der Release-Hardening- oder Unternehmensstandards für Barrierefreiheit für mobile Apps.

Zu überprüfende Punkte:

• Kompatibilität mit Sprachsteuerung/Sprachzugriff
• Barrierefreiheitseinstellungen wie „Fettdruck“, „Bewegungen reduzieren“ oder „Kontrast erhöhen“
• Konsistenz des Fokus bei Hybrid/WebView
• Unterstützung der Navigation mit externen Tastaturen
• Optionale assistive Technologien wie Braillezeilen

Strenge Barrierefreiheitsstandards für mobile Apps umfassen in der Regel diese Überprüfungen vor größeren Releases.

Wo Teams in der Regel scheitern

Die meisten Probleme mit der Barrierefreiheit beginnen mit Abkürzungen bei der Umsetzung. Barrierefreiheit wird eher als Checkbox denn als Indikator für Produktqualität betrachtet, und so sammeln sich still und leise Probleme an.

Automatisierung ohne Kontext

Automatisierte Scans helfen dabei, offensichtliche Probleme wie fehlende Beschriftungen, Kontrastverstöße und zu kleine Tippziele schnell zu erkennen. Das ist zwar nützlich, aber nicht wirklich ausreichend. Was bei der Automatisierung übersehen wird, sind Verhaltensprobleme: unvorhersehbare Fokuswechsel, Gestenkonflikte und stille UI-Aktualisierungen. Diese führen in der Regel zu Ausfällen.

Aus diesem Grund sollte ein strukturiertes Testen der Barrierefreiheit auf Mobilgeräten Automatisierung mit manueller Validierung kombinieren. KI kann die Erkennung beschleunigen, aber der Kontext der Benutzerfreundlichkeit erfordert weiterhin eine menschliche Validierung, da selbst die besten KI-Testtools sich eher auf die Erkennung von Mustern als auf das tatsächliche Interaktionsverhalten konzentrieren.

Automatisierung sorgt für Abdeckung. Menschliche Validierung verhindert teure Überraschungen, die die Automatisierung nicht erkennen kann.

Testen auf einem Gerät

Das Barriereverhaltens variiert zwischen den Geräten stärker, als viele Teams erwarten. VoiceOver ändert sich zwischen den iOS-Versionen. TalkBack verhält sich auf Samsung-Geräten anders als auf Pixel-Geräten. Allein die Bildschirmgröße kann den Fokusfluss verändern.

Das Testen auf einem Gerät vermittelt die Illusion der Bereitschaft – ähnlich wie die Überprüfung der Kompatibilität auf einem einzigen Browser. Wenn Ihr Team bereits eine strukturierte Checkliste für das Testen mobiler Apps befolgt, sollte die Barrierefreiheit in dieselbe Geräteabdeckungsmatrix integriert werden, anstatt separat getestet zu werden.

Barrierefreiheit zu spät hinzugefügt

Wenn Barrierefreiheit erst in der QA-Phase berücksichtigt wird, wird die Nachbesserung teuer. Layoutverschiebungen. Refactoring von Komponenten. Neugestaltung von Gesten unter Termindruck. Die Einbettung von Richtlinien zur Barrierefreiheit für Mobilgeräte während des Designs und der Entwicklung verhindert solche Nachbesserungen in der späten Phase. Aus diesem Grund behandeln erfahrene Teams Barrierefreiheit als Designinput und nicht als QA-Prüfpunkt. So bleiben die Release-Zeitpläne vorhersehbar.

Für Teams, die auf dem EU-Markt tätig sind, ist dies auch eine regulatorische Realität gemäß dem Europäischen Barrierefreiheitsgesetz, das sich direkt auf digitale Produkte, einschließlich mobiler Apps, auswirkt.

Übersehene Regressionsprüfungen

Barrierefreiheit versagt selten lautstark. Sie verschlechtert sich still und leise. Eine Designaktualisierung entfernt Beschriftungen. Eine Framework-Aktualisierung verschiebt die Fokusreihenfolge. Eine Aktualisierung der Farbtoken zerstört den Kontrast. Ohne wiederkehrende Validierung treten zuvor behobene Probleme erneut auf.

Teams, die bereits strukturierte Überprüfungen wie ein Web-Barrierefreiheits-Audit durchführen, wenden dieselbe Regressionsdisziplin oft auch auf mobile Geräte an, insbesondere wenn sie die Übereinstimmung mit den WCAG-Anforderungen für mobile Geräte sicherstellen wollen.

Lücken in der Verantwortung

Barrierefreiheit liegt oft zwischen Design, Entwicklung und Qualitätssicherung. Geteilte Verantwortung klingt nach Zusammenarbeit, bis niemand mehr für die Umsetzung verantwortlich ist.

Eine klare Zuständigkeit verbessert die Konsistenz, insbesondere für Unternehmen, die eine stärkere ADA-Konformität ihrer mobilen Apps anstreben. Barrierefreiheit wird nachhaltig, wenn sie zugewiesen, gemessen und überprüft wird.

Verhindern von Rückschritten bei der Barrierefreiheit

Die Barrierefreiheit in mobilen Apps scheitert, weil sie nicht in die Bereitstellungsmechanismen eingebettet ist. Nachhaltige Tests der Barrierefreiheit mobiler Apps erfordern eine strukturelle Integration.

• In SDLC-Workflows einbetten. Akzeptanzkriterien für Barrierefreiheit gehören in Tickets. „Screenreader schließt den Checkout ohne Probleme ab” ist eine messbare Definition für „fertig”. Behandeln Sie es wie Leistungsschwellen oder Sicherheitsakzeptanz.
• Legen Sie Release-Gates fest. Es erfolgt keine Bereitstellung, bis kritische Blockaden in der Checkliste für die Barrierefreiheit mobiler Apps behoben sind. Barrierefreiheit steht neben Absturzrate, Unit-Tests und Leistungs-KPIs.
• Automatisieren Sie, was automatisierbar ist. CI-Pipelines können mithilfe strukturierter Tools zum Testen der Barrierefreiheit mobiler Geräte kontinuierlich Beschriftungen, Kontraste und Zielgrößen validieren. Die Automatisierung ersetzt zwar nicht die manuelle Validierung, verhindert jedoch häufige Regressionen, bevor diese die Staging-Phase erreichen.
• Planen Sie eine strukturierte manuelle Validierung. Vierteljährliche Überprüfungen mit Hilfe von assistiver Technologie tragen dazu bei, die Übereinstimmung mit den WCAG für mobile Apps und sich weiterentwickelnden regulatorischen Anforderungen, wie z. B. der ADA-Konformität für mobile Apps, aufrechtzuerhalten. Teams, die dies überspringen, entdecken Regressionen oft erst nach Kundenbeschwerden.
• Führen Sie eine nachvollziehbare Dokumentation. Eine aktuelle Erklärung zur Barrierefreiheit, ein aktualisiertes VPAT/ACR und dokumentierte Zeitpläne für Abhilfemaßnahmen reduzieren Reibungsverluste bei der Beschaffung. Wenn Unternehmenskunden Nachweise für die Barrierefreiheit in mobilen Apps verlangen, schafft die Dokumentation Vertrauen, anstatt reaktive Audits auszulösen.

UI-Updates verbessern oft die Optik, beeinträchtigen jedoch unbeabsichtigt die Barrierefreiheit. Ohne kontinuierliche Überprüfungen schleichen sich Regressionen in die Produktion ein. Behandeln Sie Barrierefreiheit als Release-Kriterium, dann ist sie kein Risiko mehr, sondern wird zu einem Wettbewerbsvorteil.

FAQ

Wie kann ich meine mobile App auf Barrierefreiheit testen?

Beginnen Sie mit automatisierten Scan-Tools wie Accessibility Scanner (Android) und Xcode Accessibility Inspector (iOS), um strukturelle Probleme zu identifizieren. Validieren Sie dann manuell kritische Abläufe mit aktiviertem VoiceOver und TalkBack. Überprüfen Sie Kontrastverhältnisse, die Größe von Tippzielen und das Layoutverhalten bei maximaler Schriftgrößenanpassung.

Für zuverlässige Tests der Barrierefreiheit auf Mobilgeräten kombinieren Sie:

• automatisierte Prüfungen für wiederholbare Validierungen
• manuelle Tests mit assistiver Technologie
• Validierungssitzungen mit echten Benutzern

Dieser mehrschichtige Ansatz spiegelt wider, wie professionelle Dienstleister für die Prüfung der Barrierefreiheit mobiler Apps die Produktionsreife bewerten.

Gilt WCAG auch für mobile Apps?

Ja. Die WCAG dient weltweit als primäre Referenz für die Einhaltung der WCAG-Vorgaben für mobile Anwendungen. Sie bildet die Grundlage für die Europäische Barrierefreiheitsrichtlinie gemäß EN 301 549, fließt in die ADA-Rechtsprechung in den USA ein und prägt die Barrierefreiheitsanforderungen in Beschaffungsstandards wie Section 508.

Seit 2025 haben die W3C-Leitlinien zur Anwendung der WCAG auf native Apps die Erwartungen an die WCAG für mobile Apps klargestellt und bestätigt, dass die Barrierefreiheitsanforderungen über Websites hinausgehen.

Wie oft sollten Tests zur Barrierefreiheit mobiler Anwendungen durchgeführt werden?

Automatisierte Prüfungen werden in der Regel bei jedem Build durchgeführt. Eine manuelle Validierung sollte vor Releases erfolgen, die Änderungen an der Benutzeroberfläche oder der Interaktion beinhalten. Eine umfassende Überprüfung der Checkliste für mobile Barrierefreiheitstests wird in der Regel vierteljährlich oder nach größeren Neugestaltungen durchgeführt.

Eine konsistente Validierung trägt dazu bei, die ADA-Konformität mobiler Apps aufrechtzuerhalten und verhindert, dass sich Regressionen unbemerkt ansammeln.

Welche Geräte sollten für Tests der Barrierefreiheit mobiler Anwendungen verwendet werden?

Eine Basisausstattung umfasst:

• ein aktuelles iPhone mit dem neuesten iOS
• ein Android-Flaggschiffgerät (Samsung oder Pixel)
• ein weiteres Android-Gerät eines anderen Herstellers

Unterschiede bei der TalkBack-Implementierung, der Gestensteuerung und den System-Barrierefreiheits-APIs wirken sich auf die Barrierefreiheit von Apps auf verschiedenen Geräten aus. Wenn Analysen eine signifikante Nutzung älterer Betriebssysteme zeigen, sollten Sie mindestens ein älteres Gerät in Ihren Testpool aufnehmen.