Mit VoiceOver am Mac testen

VoiceOver ist auf jedem Mac vorinstalliert und mit Cmd+F5 in Sekunden gestartet. Der Rotor (VO+U) macht die Struktur deiner Seite in wenigen Minuten hörbar: Wenn die Überschriftenliste kein sinnvolles Inhaltsverzeichnis ergibt, hast du den ersten Befund schon gefunden. Diese Seite behandelt den Desktop-Test; die Gestenbedienung auf iPhone und iPad steht unter Mit VoiceOver auf iPhone und iPad testen.

Das Wichtigste in Kürze

• Ein/Aus: Cmd+F5. Auf iPhone und iPad gilt eine eigene Bedienung – siehe VoiceOver auf iPhone und iPad.
• Die VoiceOver-Taste heißt VO und ist standardmäßig Ctrl+Option. Fast jeder Befehl beginnt damit.
• Getestet wird in Safari. VoiceOver und Safari sind aufeinander abgestimmt.
• Der Rotor ist das eigentliche Prüfwerkzeug: Er zeigt Überschriften, Links, Formularelemente und Landmarken als Liste – also das Gerüst deines Markups.
• Anders als NVDA und JAWS kennt VoiceOver keine Einzeltasten-Navigation. Statt H für Überschriften stellt man die Navigationseinheit im Rotor ein.
• Der Bildschirmvorhang (VO+Shift+F11) schwärzt das Display – der einzige Weg, sich beim Testen nicht selbst zu betrügen.
• Nicht jede Abweichung ist ein Fehler. Ein Befund liegt vor, wenn Name, Rolle, Zustand oder Struktur inhaltlich falsch sind.
• Ein Screenreader-Test ersetzt keinen vollständigen Test: Kontraste, Reflow bei 400 % Zoom und Tastaturfallen findet er nicht.

VoiceOver am Mac einrichten

Vier Handgriffe, die den Unterschied zwischen „quälend“ und „arbeitsfähig“ ausmachen:

1. Starten mit Cmd+F5. Beim ersten Start bietet VoiceOver ein Einführungstraining an – die zehn Minuten lohnen sich, weil danach die Modifier-Logik sitzt.
2. Sprechtempo hochdrehen. Im VoiceOver-Dienstprogramm (VO+F8) unter „Sprachausgabe“. Die Werkseinstellung ist extrem langsam; geübte Nutzer hören mit ungefähr dem doppelten Tempo. Wer im Demo-Tempo testet, überschätzt die Geduld für lange Vorreden erheblich.
3. Untertitel-Panel einschalten. Ebenfalls im Dienstprogramm, unter „Visuelles“. Es zeigt jede Ansage zusätzlich als Text am Bildschirmrand – unbezahlbar fürs Protokoll, weil man Ansagen so kopieren statt abtippen kann.
4. Safari-Einstellung prüfen. Damit Tab durch alle Links läuft, muss in Safari unter „Erweitert“ die Option „Tab-Taste hebt jedes Objekt auf einer Webseite hervor“ aktiv sein. Fehlt sie, überspringt Tab die Links – und man meldet einen Befund, der keiner ist.

Die Befehle, die man wirklich braucht

Die letzte Zeile ist die wichtigste. Solange man den Bildschirm sieht, ergänzt das Auge unbewusst alles, was die Ansage nicht liefert – und man hält eine Seite für bedienbar, die es nicht ist. Das hab ich am Anfang selbst monatelang falsch gemacht: mitgelesen, genickt, weitergeklickt. Mit schwarzem Bildschirm bleiben genau die Stellen übrig, an denen es hakt.

Und auf dem iPhone?

Am Smartphone ist VoiceOver der mit Abstand meistgenutzte Screenreader überhaupt, und der mobile Durchlauf deckt vier Kriterien ab, die am Desktop gar nicht auftreten: Zielgrößen (2.5.8), Gesten-Fallen (2.5.1), Ziehbewegungen (2.5.7) und Ausrichtungssperren (1.3.4).

Die Bedienung ist dort eine andere – Wischgesten statt Tastenbefehle, ein gedachter Drehknopf statt eines Menüs –, deshalb hat sie eine eigene Seite: Mit VoiceOver auf iPhone und iPad testen. Der Rest dieser Seite bleibt beim Mac.

Der Prüfdurchlauf

Er entspricht bewusst dem NVDA-Durchlauf – gleiche Checkliste, anderes Werkzeug. Für eine mittlere Seite braucht man damit rund zwanzig Minuten.

1. Laden und zuhören. Sagt VoiceOver den Seitentitel an (2.4.2)? Klingt der deutsche Text deutsch, oder liest ihn eine englische Stimme (3.1.1)? Falsches lang hört man sofort und sieht man nie.
2. Rotor → Überschriften. Ergibt die Liste allein ein brauchbares Inhaltsverzeichnis? Fehlt eine Ebene, heißen drei Abschnitte gleich, ist die H1 in Wahrheit ein Logo?
3. Rotor → Links. Jeder Linktext für sich verständlich (2.4.4)? Wenn dort fünfmal „Mehr erfahren“ steht, ist der Befund gefunden.
4. An den Bildern entlang. Beschreiben die Alt-Texte, was das Bild an dieser Stelle beiträgt? Bleibt Dekoration still, oder wird ein Dateiname vorgelesen?
5. Formular ausfüllen – mit Bildschirmvorhang. Sagt jedes Feld Beschriftung, Typ und Pflichtstatus an (3.3.2)? Dann absichtlich falsch absenden: Kommt die Fehlermeldung an, benennt sie die Ursache, landet der Fokus beim Problem (3.3.1)?
6. Widgets anfassen. Dialoge, Menüs, Akkordeons, Tabs: Stimmen Rolle und Zustand? Ein zugeklapptes Akkordeon muss „reduziert“ sagen, ein Dialog „Dialog“ – und Esc muss wieder herausführen.
7. Etwas auslösen, das sich still ändert. Warenkorb, Filter, Ladeindikator, Fehlerzähler: Kommt die Änderung als Statusmeldung an, oder passiert sie nur optisch?

Befunde so aufschreiben, dass sie jemand beheben kann

Ein Testprotokoll, das nur „der Screenreader sagt nichts“ enthält, kostet den Entwickler eine Stunde Rätselraten. Vier Angaben genügen, damit ein Befund reproduzierbar ist:

• Umgebung: VoiceOver, macOS 15.4, Safari 18.4 oder VoiceOver, iOS 18.4, Safari. Weil der Accessibility Tree vom Browser gebaut wird, ist ein Test immer der Test eines Paares.
• Weg dorthin: „Startseite → Rotor → Formularelemente → drittes Feld“.
• Erwartete Ansage und tatsächliche Ansage, wörtlich. Das Untertitel-Panel liefert den Text zum Kopieren.
• Kriterium, gegen das der Befund verstößt. Ohne Nummer landet er in der Diskussion, mit Nummer im Backlog.

Die Eigenheiten, die keine Befunde sind

VoiceOver hat ein paar Verhaltensweisen, die beim ersten Test wie Fehler wirken. Bevor du sie meldest:

Kein Lese- und Formularmodus. NVDA und JAWS schalten zwischen zwei Modi um, VoiceOver kennt diese Trennung so nicht – es arbeitet mit Interaktionsebenen (VO+Shift+↓). Wenn Pfeiltasten „nicht wie erwartet“ funktionieren, ist das meist die Interaktion und kein Markup-Problem.

Zahlen und Interpunktion. „1.4.3“ wird je nach Stimme und Ausführlichkeitsstufe als Datum, als Version oder als drei Zahlen gelesen. Das ist eine Einstellung des Nutzers, kein Fehler deiner Seite.

Unterschiedliche Formulierungen. VoiceOver sagt „Schaltfläche“, NVDA „Schalter“, JAWS wieder etwas anderes. Solange Rolle und Name korrekt sind, ist die Wortwahl Sache des Programms.

Gruppierungen. VoiceOver fasst benachbarte Elemente gern zu Gruppen zusammen und sagt „Gruppe, 4 Elemente“. Das wirkt umständlich, ist aber gewollt – erst mit VO+Shift+↓ geht man hinein.

Chrome verhält sich anders. VoiceOver mit Chrome funktioniert, weicht aber in Details ab. Ein Befund, der nur dort auftritt, gehört gemeldet – aber als browserspezifisch markiert, nicht als Grundsatzproblem.

Häufiger Fehler in der Praxis

Mit sehendem Blick testen. Der häufigste Fehler überhaupt. Ohne Bildschirmvorhang ergänzt das Auge alles, was fehlt, und der Test bestätigt nur, was man ohnehin glaubte.

Im Werkstempo bleiben. Bei Standardgeschwindigkeit wirkt eine Seite mit dreißig Wörtern Vorrede geduldig zu ertragen. Bei doppeltem Tempo merkt man erst, wie sehr eine fehlende Sprungmarke stört.

Nur den Mac testen. Das Bedienkonzept am iPhone ist ein anderes, und die mobile Nutzung überwiegt deutlich. Wenn nur eines drin ist, würd ich das iPhone nehmen – so geht der mobile Durchlauf.

„Es wird ja vorgelesen“ als Ergebnis. Ein Screenreader liest auch kaputte Seiten vor. Die Prüffrage ist immer aufgabenbezogen: „Bestelle dieses Produkt“, nicht „klingt das okay?“.

Den Test für den ganzen Test halten. Kontraste, Reflow bei 400 % Zoom, Tastaturfallen für sehende Nutzer und Zeitbegrenzungen findet VoiceOver nicht. Wo der Screenreader-Test in den Gesamtablauf gehört, steht unter Barrierefreiheit selbst testen.

Häufige Fragen

Safari, Chrome oder Firefox für VoiceOver-Tests?

Safari. VoiceOver und Safari werden von Apple gemeinsam entwickelt und sind aufeinander abgestimmt; die Kombination ist auch die, die Nutzer tatsächlich verwenden. Andere Browser funktionieren, weichen aber in Details ab – Abweichungen dort sind kein verlässlicher Befund. Merkformel: NVDA mit Firefox oder Chrome unter Windows, VoiceOver mit Safari bei Apple.

Mac-VoiceOver oder iPhone-VoiceOver – was ist wichtiger?

Wenn nur eines geht: das iPhone. Die mobile Screenreader-Nutzung ist verbreiteter, und der Touch-Test deckt zusätzlich Zielgrößen und Gesten ab; die Anleitung dazu steht unter Mit VoiceOver auf iPhone und iPad testen. Der Mac ist dafür besser zum konzentrierten Protokollieren, weil sich Ansagen über das Untertitel-Panel kopieren lassen.

VoiceOver verhält sich anders als NVDA – ist das ein Fehler bei mir?

Meistens nicht. Unterschiede in Formulierung, Gruppierung und Detailverhalten sind normal und entsprechen den Unterschieden zwischen Browsern. Ein Befund liegt vor, wenn Name, Rolle, Zustand oder Struktur inhaltlich falsch sind oder etwas unbedienbar ist – im Zweifel gegen die Kriterien-Referenz prüfen.

Ersetzt ein VoiceOver-Test einen BITV-Test?

Nein. Ein BITV-Test ist ein formalisiertes Verfahren mit definierten Prüfschritten, dokumentierter Bewertung und einem geprüften Prüfer. Der eigene Screenreader-Durchlauf ist die Stichprobe davor: Er findet die offensichtlichen Probleme, bevor sie Geld kosten.

Ich komme aus VoiceOver nicht mehr raus – was tun?

Cmd+F5 – derselbe Griff wie beim Einschalten. Wenn die Tastatur gerade nicht reagiert, hilft Siri mit „VoiceOver ausschalten“.

Verwandte Themen

• Mit NVDA testen – derselbe Durchlauf unter Windows
• Screenreader-Grundlagen – wie ein Screenreader eine Seite überhaupt erfasst
• Screenreader im Überblick – Verbreitung und Unterschiede der Programme
• Wie Screenreader-Nutzer surfen – die Strategien hinter dem Rotor
• Barrierefreiheit selbst testen – die Reihenfolge aller Prüfschritte
• Tastaturbedienung & sichtbarer Fokus – der Test, der vor dem Screenreader kommt

Quellen

• VoiceOver-Benutzerhandbuch für den Mac (Apple – Befehle, Rotor, Dienstprogramm)
• Using VoiceOver to Evaluate Web Accessibility (WebAIM – Prüfvorgehen und typische Missverständnisse)
• Test and Evaluate Web Accessibility (W3C WAI – Einordnung eigener Tests)