Mit VoiceOver auf iPhone und iPad testen

Am Smartphone ist VoiceOver der mit Abstand meistgenutzte Screenreader – wer nur mobil testen kann, testet trotzdem etwas sehr Relevantes. Eingeschaltet wird er mit einem Dreifachklick auf die Seitentaste, bedient mit Wischgesten: einmal tippen sagt an, doppeltippen aktiviert, zwei Finger drehen schaltet den Rotor um. Der mobile Durchlauf deckt vier Kriterien ab, die am Desktop gar nicht auftreten: Zielgröße, Zeigergesten, Ziehbewegungen und Ausrichtung.

Diese Seite behandelt ausschließlich iPhone und iPad. Die Mac-Seite derselben Prüfung – Tastenbefehle, VO-Taste, Safari am Desktop – steht unter Mit VoiceOver am Mac testen. Die Rotor-Logik ist auf beiden Geräten dieselbe, die Bedienung nicht.

Das Wichtigste in Kürze

• VoiceOver ist auf jedem iPhone und iPad vorinstalliert.
• Erst den Kurzbefehl setzen: Einstellungen → Bedienungshilfen → Bedienungshilfen-Kurzbefehl → VoiceOver. Danach schaltet ein Dreifachklick an und aus.
• Grundgesten: einmal tippen = ansagen, doppeltippen = aktivieren, streichen = nächstes Element, mit drei Fingern streichen = scrollen.
• Der Rotor ist ein gedachter Drehknopf: zwei Finger drehen wählt die Kategorie, nach oben oder unten streichen springt darin.
• Getestet wird mit Safari. Alle iOS-Browser nutzen WebKit – ein zweiter Browser bringt keinen zusätzlichen Befund.
• Drei Finger dreifach tippen schaltet den Bildschirmvorhang: der ehrlichste Test.
• Mobil geprüft werden vor allem Zielgröße (2.5.8), Zeigergesten (2.5.1), Ziehbewegungen (2.5.7) und Ausrichtung (1.3.4).

Einrichten – und wieder herauskommen

Der Kurzbefehl ist der wichtigste Schritt, und er kommt vor dem Einschalten: Einstellungen → Bedienungshilfen → Bedienungshilfen-Kurzbefehl → VoiceOver. Danach schaltet ein Dreifachklick auf die Seitentaste VoiceOver an und aus. Wer diesen Schritt überspringt, sitzt beim ersten Versuch fest, weil auch die Einstellungen-App auf Doppeltipp-Bedienung umgestellt ist.

Zwei Einstellungen lohnen sich davor:

• Rotor-Kategorien ausdünnen: Einstellungen → Bedienungshilfen → VoiceOver → Rotor. Für Website-Tests brauchst du Überschriften, Links, Formularelemente und Landmarken; jede zusätzliche Kategorie macht die Drehgeste länger.
• Sprechtempo hochziehen: unter VoiceOver → Sprechtempo. Die Vorgabe ist für einen Test zu langsam.

Notausgang für zwischendurch: mit zwei Fingern tippen hält die Sprachausgabe an und setzt sie fort.

Die Gesten, die zählen

Zwei davon sind für einen Test besonders ergiebig. Erkunden durch Berühren zeigt, wie groß Trefferflächen tatsächlich sind – alles, was man nur knapp findet, ist ein Kandidat für 2.5.8. Und der Bildschirmvorhang schaltet das Display schwarz, während das Gerät normal weiterläuft: Er nimmt einem die Möglichkeit, unbewusst doch hinzuschauen, und ist damit der ehrlichste Durchlauf, den man ohne Übung hinbekommt.

Der Rotor

Zwei Finger auf den Bildschirm legen und drehen, als wäre dort ein Knopf: Das schaltet zwischen den Kategorien um. Danach springt ein Streichen nach oben oder unten innerhalb der gewählten Kategorie – etwa von Überschrift zu Überschrift. Es ist dieselbe Idee wie die Elementliste am Desktop, nur ohne Liste; entsprechend wichtig ist, die Kategorien vorher auf die vier relevanten zu reduzieren.

So testest du eine Seite auf dem iPhone

Ein Durchlauf in 25 Minuten, Safari geöffnet, Bildschirmvorhang an:

1. Von oben nach unten durchstreichen (nach rechts, wiederholt). Kommt jedes Element an die Reihe, und stimmt die Reihenfolge mit der gelesenen überein? Das prüft 1.3.2 Bedeutungstragende Reihenfolge.
2. Rotor auf Überschriften stellen und die Struktur durchspringen. Ergibt sie ein Inhaltsverzeichnis? Zuständig ist 1.3.1 Info und Beziehungen.
3. Rotor auf Formularelemente und jedes Feld ansteuern. Jedes muss einen Namen bekommen – fehlt er, fehlt das verknüpfte Label; Absicherung 4.1.2.
4. Trefferflächen abtasten, indem du mit einem Finger über den Bildschirm fährst. Enge Icon-Reihen und kleine Schließen-Kreuze fallen dabei sofort auf – 2.5.8 verlangt 24 × 24 CSS-Pixel oder genug Abstand.
5. Nach Gesten ohne Alternative suchen. Wischbare Karussells, ziehbare Karten, Schieberegler: Jede solche Bedienung braucht einen Weg mit einfachem Tippen – 2.5.1 und 2.5.7.
6. Gerät quer drehen (Rotationssperre aus). Bleibt die Seite bedienbar? 1.3.4 Ausrichtung verbietet die Festlegung auf eine Richtung.
7. Dynamische Schriftgröße hochstellen (Einstellungen → Anzeige & Helligkeit → Textgröße, für mehr Stufen unter Bedienungshilfen → Anzeige & Textgröße → Größerer Text). Bricht der Text um oder wird er abgeschnitten? Das ist die mobile Entsprechung von Reflow und Textabständen.
8. Ein Formular absenden und einen Fehler provozieren. Wird die Meldung angesagt? 3.3.1 Fehlererkennung und 4.1.3 Statusmeldungen.
9. Jeden Befund im Code nachsehen. Erst dann ist er einer.

Die Eigenheiten, die keine Befunde sind

Nicht alles, was ungewohnt klingt, ist ein Fehler deiner Seite:

• VoiceOver sagt bei Links „Link“ und bei Schaltflächen „Taste“ – das ist die Rollenansage und genau das, was passieren soll.
• Beim Laden wird die Seite mit „Web-Inhalt“ angekündigt; das ist Programmverhalten.
• VoiceOver liest Kommas und Bindestriche je nach Ausführlichkeitseinstellung unterschiedlich vor.
• Auf iOS gibt es keine zweite Browser-Engine: Chrome und Firefox nutzen ebenfalls WebKit. Ein Befund unter Safari ist deshalb ein Befund für alle iOS-Browser – und ein zweiter Browser-Test bringt nichts.

Ein echter Unterschied, den man dagegen ernst nehmen sollte: VoiceOver ist bei Beschriftungen nachsichtiger als TalkBack. Es leitet Namen häufiger aus benachbartem Text oder Dateinamen ab. Wenn ein Icon-Button unter TalkBack nur „Schaltfläche“ heißt, unter VoiceOver aber einen Namen bekommt, fehlt trotzdem die Beschriftung im Markup.

Safari, In-App-Browser und WebViews

Ein mobiler Befund kann drei verschiedene Ursachen haben, und die Unterscheidung spart viel Suchzeit:

Safari ist der Normalfall und die Umgebung, in der du testest. In-App-Browser – also der Browser, der sich innerhalb von Instagram, LinkedIn oder einer Mail-App öffnet – nutzen dieselbe WebKit-Engine, bringen aber eine eigene, oft schlecht bedienbare Rahmenoberfläche mit: eine Kopfzeile mit winzigen Symbolen, manchmal ohne verlässliche Zurück-Möglichkeit für VoiceOver. Wenn ein großer Teil deines Traffics aus sozialen Netzwerken kommt, lohnt ein Blick genau dorthin – die Barriere sitzt dann nicht in deiner Seite, aber sie trifft deine Nutzenden.

WebViews in nativen Apps verhalten sich noch einmal anders: Dort entscheidet die App, welche Bedienelemente außen herum existieren und ob VoiceOver zwischen App-Oberfläche und Webinhalt sauber wechselt. Wer eine eigene App mit eingebetteten Webseiten betreibt, muss beide Ebenen prüfen.

Befunde protokollieren

Auf dem Gerät mitzuschreiben funktioniert nicht – deshalb nehme ich auf. Die Bildschirmaufnahme von iOS zeichnet die VoiceOver-Ausgabe mit auf, wenn der Ton über den Lautsprecher läuft und die Aufnahme mit aktiviertem Mikrofon gestartet wird. Ein brauchbarer Befund enthält Gerät, iOS-Version, „Safari“, den Zeitstempel in der Aufnahme und die wörtliche Ansage – dazu einen Screenshot der Stelle. Damit kann jemand die Ursache im Markup suchen, ohne das Gerät je in der Hand gehabt zu haben.

Häufiger Fehler in der Praxis

Ohne Bildschirmvorhang testen. Wer sieht, tippt unbewusst dorthin, wo das Element liegt – und übersieht genau die Fälle, in denen die Wischreihenfolge nicht stimmt.

Nur auf dem neuesten Gerät prüfen. Die interessanten Layoutfehler entstehen auf kleinen Bildschirmen und bei großer dynamischer Schrift.

Den Simulator nehmen. Der iOS-Simulator in Xcode bringt VoiceOver nicht in der Form mit, die für einen Gestentest taugt. Ein echtes Gerät ist hier nicht optional.

Die mobile Prüfung als Nachtrag behandeln. Vier der geprüften Kriterien lassen sich am Desktop überhaupt nicht auslösen. Wer nur dort prüft, hat sie nie angesehen.

Häufige Fragen

Reicht der Test auf dem iPhone, oder brauche ich auch Android?

Beide zusammen decken den mobilen Markt ab. Die Gesten unterscheiden sich, und TalkBack ist bei fehlenden Beschriftungen strenger. Wenn nur eines möglich ist, nimm das Gerät, das deine Zielgruppe eher nutzt – und lies das andere Kapitel mit: Mit TalkBack testen.

Muss ich in mehreren Browsern testen?

Auf iOS nicht. Apple schreibt WebKit für alle Browser vor, deshalb verhalten sich Chrome und Firefox dort wie Safari. Am Desktop ist das anders – dort lohnt der zweite Browser, siehe Mit NVDA testen.

Warum überspringt VoiceOver ein Element ganz?

Weil es nicht im Accessibility Tree steht oder nicht fokussierbar ist – typischerweise ein <div> mit onclick statt eines echten Bedienelements. Die Erklärung dazu steht unter Screenreader-Grundlagen, die Lösung unter Buttons vs. Links.

Zählt der mobile Test für das BFSG?

Ja. Das BFSG unterscheidet nicht zwischen Desktop- und Mobilansicht; geprüft wird das Angebot, wie es Nutzende erreichen. Für native Apps kommen über die EN 301 549 weitere Anforderungen hinzu.

Wie schreibe ich einen Befund auf, den nur das Handy zeigt?

Mit Gerät, iOS-Version, Browser, dem gewählten Rotor-Eintrag und der wörtlichen Ansage – plus einem Screenshot. Ein Befund ohne die wörtliche Ansage ist für die Person, die ihn beheben soll, schwer nachzuvollziehen; wie ich Befunde formuliere, steht unter Mit VoiceOver am Mac testen.

Verwandte Themen

• Mit VoiceOver am Mac testen – dieselbe Prüfung am Desktop, mit Tastenbefehlen statt Gesten
• Mit TalkBack testen – die Android-Hälfte des mobilen Marktes
• Mit NVDA testen – der kostenlose Windows-Test
• Reflow, Zoom & Textabstände – die Layout-Kriterien, die mobil zuerst auffallen
• Wie Screenreader-Nutzer surfen – das Navigationsverhalten hinter den Gesten

Quellen

• VoiceOver auf dem iPhone verwenden – Benutzerhandbuch (Apple)
• WebAIM Screen Reader User Survey #10 – mobile Nutzung und Verteilung
• Mobile Accessibility – Einordnung der WCAG für mobile Anwendungen (W3C WAI)
• WCAG 2.2 – die Kriterien, denen Befunde zugeordnet werden (W3C)