Eine barrierefreie responsive Website ist nicht dasselbe wie eine barrierefreie App – auch wenn beide „auf dem Telefon funktionieren“. In diesem Artikel werden die entscheidenden Unterschiede zwischen der Barrierefreiheit einer Website und der Barrierefreiheit einer nativen iOS- oder Android-App erläutert.
Kurz gesagt – was dieser Artikel behandelt
Andere Technologie, ähnliche Regeln
Eine responsive Website wird aus HTML erstellt, das bereits über eine integrierte Barrierefreiheitsebene (semantische Tags, ARIA) verfügt, die Browser und Bildschirmleseprogramme zu interpretieren wissen. Im Gegensatz dazu wird eine native App aus den eigenen UI-Komponenten des Betriebssystems erstellt (UIKit/SwiftUI auf iOS, Jetpack Compose/Views auf Android) – und jede Komponente benötigt ihr eigenes Barrierefreiheits-Tagging, getrennt von ihrem visuellen Design. Die zugrunde liegenden Prinzipien ähneln WCAG (Kontrast, Touch-Target-Größe, ein klar zugänglicher Name), aber die Werkzeuge zu ihrer Umsetzung sind völlig anders.
VoiceOver und TalkBack: Nicht derselbe Screenreader
VoiceOver (iOS) und TalkBack (Android) sind zwei verschiedene Bildschirmleseprogramme mit unterschiedlichen Navigationsgesten und unterschiedlicher Unterstützung für benutzerdefinierte Komponenten. Eine Komponente, die auf iOS perfekt getaggt ist, funktioniert unter Android möglicherweise nicht richtig, wenn Entwickler nicht beide Plattformen separat getestet haben. Man kann nicht davon ausgehen, dass „wir es auf iOS getestet haben, also muss es auch auf Android funktionieren.“
💡 Wichtiger Punkt
Auf beiden Plattformen benötigt jede interaktive Komponente (Schaltfläche, Eingabefeld, Bild) Folgendes: eine klare Barrierefreiheitsbezeichnung, eine definierte Barrierefreiheitsrolle/-eigenschaft und manchmal auch einen Barrierefreiheitshinweis, der erklärt, was passiert, wenn darauf getippt wird.
Was ist das Besondere an nativen Apps?
Native Apps stehen auch vor Herausforderungen, die es auf Websites nicht gibt: benutzerdefinierte Touch-Gesten (Wischen, Auf- und Zuziehen), die eine zugängliche Alternative erfordern; Navigation zwischen Bildschirmen, die auch über einen Bildschirmleser sinnvoll sein muss; und Push-Benachrichtigungen, die auch dann zugänglich sein müssen, wenn sie außerhalb der App selbst erscheinen. Darüber hinaus müssen Touch-Target-Größen mindestens 44 x 44 Pixel gemäß den Richtlinien von Apple und 48 x 48 dp gemäß den Richtlinien von Google erfüllen – eine Anforderung, die auf Websites nicht immer in der gleichen Form vorhanden ist.
So testen Sie eine barrierefreie App
- Schalten Sie VoiceOver oder TalkBack ein und versuchen Sie, die Kernaufgaben der App (Registrierung, Kauf, Suche) nur damit zu erledigen.
- Überprüfen Sie Kontrast und Textgröße bei aktivierten Systemeinstellungen für die Barrierefreiheit (größerer Text, hoher Kontrast).
- Bestätigen Sie die Unterstützung für die dynamische Textgröße (Dynamic Type auf iOS), ohne dass das Layout kaputt geht.
- Testen Sie separat auf beiden Plattformen – es reicht nicht aus, nur eine zu testen.
Verfügen Sie auch über Dokumente, die Ihrer Bewerbung beiliegen?
Unser Tool scannt die mit Ihrer App oder Website verknüpften PDF-Dateien – Nutzungsbedingungen, Leitfäden, Formulare – und zeigt Ihnen genau, welche Ihrer Aufmerksamkeit bedürfen.
Scannen Sie Ihre Website kostenlos ←Nach dem Scan können Sie die gefundenen Dokumente auch direkt und kostenlos über zugänglich machenAccessiDoc.