Wer Barrierefreiheit nur am Desktop-Browser testet, hat ein Problem. Mobile Geräte bringen eigene Herausforderungen mit: andere Eingabemethoden, andere Screenreader, andere Orientierungen, andere Schriftgrößen. Und eine Realität, die oft unterschätzt wird: Viele Menschen mit Behinderungen nutzen ihr Smartphone als primäres Endgerät – weil es einfacher zu halten ist, weil es immer dabei ist, weil native Bedienungshilfen tief integriert sind.
Dieser Artikel behandelt die wichtigsten Anforderungen und Prüfmethoden für mobile Webseiten und Apps.
Touch-Targets sind interaktive Bereiche auf dem Bildschirm – Buttons, Links, Formularfelder. WCAG 2.5.5 (AAA) empfiehlt mindestens 44×44 CSS-Pixel. WCAG 2.2 hat mit 2.5.8 (AA) eine verbindlichere Anforderung von mindestens 24×24 Pixel eingeführt.
In der Praxis gilt: Je kleiner ein Touch-Target, desto mehr Fehleingaben passieren – besonders bei Nutzenden mit Tremor, motorischen Einschränkungen oder einfach großen Händen. Ein "Löschen"-Icon mit 16×16 Pixel ist für viele Menschen schlicht nicht bedienbar.
Wichtig: Das Touch-Target muss nicht das sichtbare Element sein. Ein kleines Icon kann ein unsichtbares, größeres Klickziel haben – per Padding oder Pseudoelement.
Ein klassischer Fehler: Das Viewport-Meta-Tag enthält user-scalable=no oder maximum-scale=1. Das verhindert, dass Nutzende die Seite vergrößern können – und ist seit WCAG 1.4.4 ein expliziter Verstoß.
Viele Nutzende mit Sehbehinderungen, die keinen Screenreader nutzen, vergrößern einfach den Browser. Das Sperren des Zooms nimmt ihnen diese Möglichkeit. Die Lösung ist einfach: das Attribut schlicht weglassen. Browser ignorieren es teilweise ohnehin.
Tief in iOS integriert. Aktivierung: Dreifach-Klick auf den Seitenknopf. Funktioniert mit Safari – andere Browser auf iOS haben eingeschränkten Screenreader-Support.
Standard-Screenreader auf Android. In den Einstellungen unter Bedienungshilfen → TalkBack zu finden. Zusammen mit Chrome getestet.
Mobile Screenreader funktionieren anders als Desktop-Screenreader. Statt Tab-Navigation gibt es Wischgesten: Mit einem Finger nach rechts oder links wischen navigiert Element für Element. Mit zwei Fingern tippen wird die aktuelle Aktion ausgeführt (entspricht Enter).
Für Web-Tests reicht es, VoiceOver oder TalkBack zu aktivieren und durch eine eigene Seite zu navigieren. Die wichtigsten Fragen: Werden alle interaktiven Elemente angesagt? Klingen die Beschriftungen sinnvoll? Ist die Reihenfolge logisch?
WCAG 1.3.4 (AA) fordert, dass Inhalte nicht auf eine Bildschirmausrichtung beschränkt sind. Wer sein Tablet oder Smartphone in einem Ständer befestigt hat, kann die Ausrichtung nicht ändern. Eine App, die nur im Querformat funktioniert, ist für diese Menschen eine Barriere.
Ausnahmen sind möglich: Wenn die Orientierung für die Funktion essenziell ist (z.B. ein Piano-Spiel), darf sie festgelegt sein. Aber eine normale Website oder App hat keinen solchen Grund.
Icons, Links und Buttons unter 24×24px. Besonders häufig bei Icons ohne beschriftende Texte.
user-scalable=no im Viewport-Meta-Tag. Einfach entfernen.
Tooltips oder Menüs, die nur bei Mouse-Hover erscheinen, funktionieren auf Touch-Geräten nicht.
Wenn ein Modal geöffnet wird, muss der Fokus hineinwandern – und beim Schließen zurück zum auslösenden Element.