Screenreader-Test: So prüfst du deine Website mit VoiceOver und NVDA

Stell dir die neue Website einer Volkshochschule vor. Das Team hat sauber gearbeitet: Das Design ist ruhig, die Kontraste stimmen, der automatische Accessibility-Check meldet nur zwei Kleinigkeiten. Zwei Wochen nach dem Start kommt eine Mail. Eine blinde Frau wollte sich für einen Spanischkurs anmelden und hat aufgegeben. Auf der Kursseite hörte sie fünfmal hintereinander „Mehr erfahren, Link“. Im Anmeldeformular wusste sie nicht, welches Feld gerade aktiv war. Und nach dem Klick auf „Anmelden“ passierte, soweit sie das hören konnte, gar nichts.

Keines dieser Probleme hat das Team gesehen, weil es die Website nie so erlebt hat wie Menschen mit Screenreader: als Abfolge von Wörtern, Rollen und Zuständen, ohne Layout und ohne den schnellen Blick über die Seite. Diesen Perspektivwechsel ermöglicht ein Screenreader-Test. Mit einer Handvoll Befehlen und etwa 20 Minuten pro Seitentyp findest du die meisten groben Fehler selbst.

Dieser Artikel zeigt dir, wie Menschen mit Screenreader eine Website erkunden, wie du VoiceOver und NVDA einschaltest, welche Befehle du wirklich brauchst und wie eine kompakte Testroutine aussieht. Die Volkshochschul-Website dient dabei als durchgehendes Beispiel. Sie ist erfunden, aber typisch.

Was ein Screenreader macht und warum du ihn selbst ausprobieren solltest

Ein Screenreader ist eine Software, die Inhalte und Bedienelemente auf dem Bildschirm in Sprachausgabe oder Braille übersetzt. Er liest dabei nicht das, was du siehst, sondern das, was der Browser ihm über die Seite mitteilt: Texte, Überschriften und ihre Ebenen, Links, Schaltflächen, Formularfelder mit ihren Beschriftungen, Zustände wie „ausgewählt“ oder „erweitert“. Ob diese Informationen stimmen, hängt vom HTML und gegebenenfalls von ARIA ab, also von zusätzlichen Attributen, die Rollen und Zustände für assistive Technologien beschreiben.

Automatische Prüfwerkzeuge finden manches davon, etwa ein fehlendes Alt-Attribut. Ob eine Beschriftung verständlich ist, die Überschriftenstruktur Sinn ergibt oder eine Statusmeldung im richtigen Moment ankommt, können sie nicht beurteilen. Einen Überblick über automatische und manuelle Methoden gibt der Artikel Accessibility-Prüfung: Werkzeuge und Methoden für UX-Designer.

Wie Menschen mit Screenreader eine Website erkunden

Wer sehen kann, überfliegt eine Seite in Sekunden und springt dann gezielt zu dem, was interessant aussieht. Menschen mit Screenreader machen im Prinzip dasselbe, nur mit anderen Mitteln. Statt die Seite von oben nach unten vorlesen zu lassen, springen sie über Tastenkürzel von Überschrift zu Überschrift, von Link zu Link oder von Bereich zu Bereich. Oder sie lassen sich eine Liste aller Überschriften oder Links anzeigen und wählen daraus.

Wie verbreitet diese Strategien sind, zeigt die Screen Reader User Survey von WebAIM, einer Organisation, die zum Institute for Disability Research, Policy & Practice der Utah State University gehört. Die elfte Ausgabe lief im Juli und August 2026 und erhielt 1.780 gültige Antworten. Auf die Frage, wie sie auf einer langen Seite zuerst nach Informationen suchen, antworteten:

• 67,8 Prozent: über die Überschriften navigieren
• 12,5 Prozent: die Suchfunktion des Browsers oder Screenreaders nutzen
• 9,7 Prozent: die Seite durchlesen
• 6,7 Prozent: über die Links navigieren
• 3,4 Prozent: über Landmarks navigieren

Überschriften sind also mit großem Abstand das wichtigste Werkzeug zur Orientierung. 88,3 Prozent der Befragten finden Überschriftenebenen sehr oder eher nützlich. Landmarks, also ausgezeichnete Seitenbereiche wie Kopfbereich, Navigation, Hauptinhalt und Fußbereich, sind als erster Schritt selten, werden aber trotzdem genutzt: 28,3 Prozent springen „immer, wenn verfügbar“ oder „oft“ über Landmarks, weitere 32,7 Prozent manchmal. Sogenannte Skip-Links, die direkt zum Hauptinhalt springen, nutzen 37,7 Prozent immer oder oft.

Zur Einordnung: Die Stichprobe ist nicht kontrolliert und laut WebAIM nicht unbedingt repräsentativ, über die Hälfte der Antworten kam aus Nordamerika. Wie stark solche Zahlen schwanken, zeigt die Vorgängerumfrage von Dezember 2023 und Januar 2024: Damals nannten 40,5 Prozent JAWS als wichtigsten Screenreader auf Desktop und Laptop und 37,7 Prozent NVDA, 2026 waren es 55,0 und 32,9 Prozent. Die Überschriften lagen dagegen auch damals klar vorn (71,6 Prozent), und darauf kommt es für deinen Test an.

Eine weitere Zahl ist für die Praxis wichtig: 91,8 Prozent der Befragten nutzen einen Screenreader auch auf einem Mobilgerät, am häufigsten VoiceOver auf iPhone oder iPad (72,2 Prozent). Wenn du nur am Desktop testest, fehlt dir also ein großer Teil der Realität.

Welchen Screenreader du zum Testen nimmst

Zwei kostenlose Startpunkte liegen nahe:

• NVDA unter Windows: NVDA (NonVisual Desktop Access) ist ein freier Open-Source-Screenreader von NV Access, übersetzt in mehr als 50 Sprachen. Er läuft mit Chrome, Firefox und Edge. In der WebAIM-Umfrage war „NVDA mit Chrome“ die zweithäufigste Kombination nach „JAWS mit Chrome“.
• VoiceOver auf Mac und iPhone: VoiceOver ist in macOS und iOS eingebaut. Auf dem Mac funktioniert er laut WebAIM am besten mit Safari. Auf dem iPhone deckst du damit die häufigste mobile Konstellation ab.

JAWS, in der Umfrage der meistgenutzte Desktop-Screenreader, ist kommerziell und gehört in eine professionelle Prüfung. Für den Einstieg reichen NVDA oder VoiceOver, solange du sie mit den Browsern kombinierst, mit denen sie auch in der Praxis genutzt werden.

NVDA: Einschalten und die wichtigsten Befehle

NVDA lädst du auf der Website von NV Access herunter und installierst es. Danach startet Strg+Alt+N den Screenreader. Fast alle Befehle nutzen die sogenannte NVDA-Taste. Standard ist die Einfügetaste (auf deutschen Tastaturen „Einfg“), alternativ lässt sich die Feststelltaste einstellen. WebAIM empfiehlt, auch auf dem Laptop das Desktop-Tastaturschema zu wählen, weil sonst einige Befehle fehlen, die den Nummernblock nutzen.

Ein Konzept musst du verstehen, bevor du loslegst: NVDA hat einen Lesemodus und einen Fokusmodus. Im Lesemodus springst du mit einzelnen Buchstaben durch die Seite. Im Fokusmodus gehen Tastendrücke an das Formularfeld, damit du tippen kannst. NVDA wechselt meist automatisch, wenn du mit Tab in ein Eingabefeld kommst, und signalisiert das mit einem Ton. Mit NVDA+Leertaste wechselst du manuell.

Für einen ersten Test brauchst du nur diese Befehle:

• Strg: Sprachausgabe sofort stoppen
• NVDA+Pfeil nach unten: ab der aktuellen Position alles vorlesen
• H: nächste Überschrift, 1 bis 6: nächste Überschrift dieser Ebene
• D: nächste Landmark
• K: nächster Link
• F: nächstes Formularfeld, B: nächste Schaltfläche
• G: nächste Grafik, T: nächste Tabelle
• Umschalt plus einer dieser Buchstaben: in die Gegenrichtung springen
• NVDA+F7: Elementliste mit allen Links, Überschriften und Landmarks
• NVDA+Q: NVDA beenden

Ein Tipp für den Testalltag: Im NVDA-Menü (NVDA+N) findest du unter den Werkzeugen den Speech Viewer. Er zeigt alles, was NVDA spricht, als Text in einem Fenster. So kannst du Befunde wörtlich in dein Protokoll kopieren.

VoiceOver auf dem Mac und dem iPhone

Auf dem Mac schaltest du VoiceOver mit Befehlstaste+F5 ein und aus. Hat dein Mac oder deine Tastatur Touch ID, geht es auch so: Befehlstaste halten und Touch ID dreimal schnell drücken. Alternativ findest du VoiceOver in den Systemeinstellungen unter „Bedienungshilfen“.

VoiceOver-Befehle beginnen mit den VO-Tasten. Standard ist Control+Option gemeinsam gedrückt, alternativ die Feststelltaste. Die Befehle, die du brauchst:

• Control: Sprachausgabe pausieren, erneut drücken setzt sie fort
• VO+A: vorlesen
• VO+Pfeil nach rechts und VO+Pfeil nach links: zum nächsten oder vorigen Element
• VO+Befehlstaste+H: nächste Überschrift, mit Umschalt zur vorigen
• VO+Befehlstaste+L: nächster Link
• VO+Befehlstaste+J: nächstes Bedienelement
• VO+Befehlstaste+G: nächste Grafik
• VO+U: den Rotor öffnen

Der Rotor ist das Gegenstück zur Elementliste von NVDA. Mit den Pfeiltasten links und rechts wechselst du zwischen Listen wie Überschriften, Links oder Formularsteuerelementen, mit Return springst du zum gewählten Eintrag. In den meisten Listen kannst du tippen, um zu filtern. In der Überschriftenliste zeigt etwa die Eingabe „3“ nur Überschriften der dritten Ebene. Auch Landmarks lassen sich über den Rotor ansteuern, sofern die Seite welche hat.

Zwei Funktionen helfen beim Testen besonders: Das Untertitelfenster zeigt den gesprochenen Text auf dem Bildschirm an, ähnlich dem Speech Viewer bei NVDA. Und der Bildschirmvorhang (VO+Umschalt+Fn+F11) schaltet die Anzeige schwarz, sodass du dich wirklich nur auf die Sprachausgabe verlassen kannst. WebAIM empfiehlt genau das für ehrliche Tests.

Auf dem iPhone schaltest du VoiceOver unter Einstellungen, Bedienungshilfen, VoiceOver ein. Wichtig, bevor du das tust: Richte dir die Kurzbefehle der Bedienungshilfen ein, damit du VoiceOver per Dreifachklick auf die Seitentaste wieder ausschalten kannst. Mit VoiceOver ändern sich nämlich alle Gesten. Die wichtigsten:

• Einmal tippen wählt ein Element aus und liest es vor, Doppeltippen aktiviert es.
• Nach rechts oder links wischen springt zum nächsten oder vorigen Element.
• Mit zwei Fingern auf dem Bildschirm drehen, wie an einem Drehregler, öffnet den Rotor. Dort wählst du etwa „Überschriften“ oder „Links“ und springst dann mit Wischen nach oben oder unten.
• Mit zwei Fingern nach oben wischen liest alles ab dem Seitenanfang vor, Tippen mit zwei Fingern stoppt die Ausgabe.

Die 20-Minuten-Routine

Die folgende Routine ist für eine einzelne Seite oder einen Seitentyp gedacht, etwa Startseite, Kursdetailseite oder Anmeldeformular. Nimm pro Durchgang eine Kombination aus Screenreader und Browser, notiere beide mit Version und schalte den Bildschirm möglichst aus.

1. Erster Eindruck: Titel und Sprache (1 Minute)

Lade die Seite und hör zu, was der Screenreader zuerst sagt. Normalerweise ist das der Seitentitel. „Startseite“ oder „Unbenannt“ hilft niemandem, der mehrere Tabs offen hat. Achte außerdem auf die Aussprache: Klingt der deutsche Text wie mit englischem Akzent vorgelesen, ist die Sprache der Seite falsch ausgezeichnet.

Auf der Volkshochschul-Website hieß jede Kursseite nur „Kursdetails | VHS“. Nach der Überarbeitung steht der Kursname vorn: „Spanisch A1 am Abend | VHS Musterstadt“.

2. Überschriften (4 Minuten)

Öffne die Elementliste (NVDA+F7) oder den Rotor (VO+U) und lass dir alle Überschriften anzeigen. Dann springst du einmal mit H oder VO+Befehlstaste+H durch die Seite. Drei Fragen:

• Ergibt die Liste der Überschriften für sich allein ein sinnvolles Inhaltsverzeichnis?
• Gibt es genau eine Überschrift der ersten Ebene, die sagt, worum es auf der Seite geht?
• Passen die Ebenen zur inhaltlichen Gliederung, oder wurden sie nach Schriftgröße vergeben?

Auf der Kursseite fand das Team zwei typische Fehler. Der Kursname war optisch groß, aber technisch nur fett formatierter Text, also keine Überschrift. Und „Termine“, „Kursleitung“ und „Kosten“ waren zwar Überschriften, aber auf Ebene vier, weil das Design dafür eine kleine Schrift vorsah. Vorher hörte eine Person mit Screenreader in der Überschriftenliste „Newsletter abonnieren“ als erste Überschrift. Nachher beginnt die Liste mit dem Kursnamen auf Ebene eins, darunter folgen die Abschnitte auf Ebene zwei. Wie du Inhalte grundsätzlich gliederst, beschreibt der Artikel Wie man Inhalte richtig strukturiert.

3. Landmarks (2 Minuten)

Spring mit D bei NVDA oder über den Rotor bei VoiceOver durch die Landmarks. Erwartbar sind mindestens ein Kopfbereich, eine Navigation, ein Hauptinhalt und ein Fußbereich. Gibt es mehrere Navigationen, sollten sie unterscheidbar benannt sein, etwa „Hauptnavigation“ und „Navigation im Fußbereich“. Prüf außerdem, ob es einen Skip-Link gibt, der direkt zum Hauptinhalt führt.

Die Volkshochschule hatte zunächst gar keine Landmarks, weil das Layout ausschließlich aus generischen Containern bestand. Nach der Überarbeitung landet man mit einem Sprung im Hauptinhalt, statt sich an 40 Navigationslinks vorbeizuhören.

4. Links und Schaltflächen (3 Minuten)

Lass dir die Linkliste anzeigen. Jeder Link sollte allein verständlich sein, denn genau so nehmen ihn Menschen in dieser Liste wahr. „Mehr erfahren“, „Hier“ oder „Weiter“ sind ohne Umgebung bedeutungslos.

Achte zugleich auf die Rollen: Was eine Aktion auf der Seite auslöst, sollte als Schaltfläche angesagt werden, was zu einer anderen Seite führt, als Link. Und Symbol-Buttons brauchen einen Namen. Ein Herz-Symbol, das nur „Schaltfläche“ ansagt, verrät nicht, dass man damit einen Kurs merken kann.

• Vorher: In der Kursübersicht fünfmal „Mehr erfahren, Link“, dazu „Schaltfläche“ ohne Namen für das Merk-Symbol.
• Nachher: „Spanisch A1 am Abend, Link“ und „Spanisch A1 auf Merkliste setzen, Schaltfläche“. Visuell hat sich kaum etwas verändert, denn der Kurstitel ist jetzt selbst der Link.

5. Bilder (2 Minuten)

Spring mit G oder VO+Befehlstaste+G durch die Grafiken. Informative Bilder brauchen einen Alternativtext, der ihre Aussage wiedergibt. Dekorative Bilder sollten gar nicht angesagt werden. Typische Befunde sind Dateinamen wie „IMG_4711.jpg“, Alternativtexte wie „Bild“ und Grafiken mit Text, etwa ein Banner mit dem Anmeldeschluss, dessen Information im Alternativtext fehlt.

Auf der Kursseite sagte der Screenreader vorher „Kurs-Header-final-2, Grafik“. Nachher ist das Stimmungsbild als dekorativ markiert und wird übersprungen, während das Banner „Anmeldeschluss 15. März“ seinen Text auch als Alternativtext trägt.

6. Formulare (4 Minuten)

Formulare sind die Stelle, an der Screenreader-Tests die meisten ernsten Probleme zutage fördern. Geh das Anmeldeformular einmal mit Tab und einmal mit F durch und füll es vollständig aus. Pro Feld sollte der Screenreader Beschriftung, Feldtyp und gegebenenfalls „Pflichtfeld“ ansagen. Platzhaltertext im Feld ersetzt keine Beschriftung. Danach schickst du das Formular absichtlich fehlerhaft ab und hörst, was passiert: Wird der Fehler angesagt? Kommst du zum fehlerhaften Feld? Ist die Fehlermeldung mit dem Feld verknüpft, sodass sie beim Fokussieren mit vorgelesen wird?

• Vorher: „Eingabefeld, leer“, dreimal hintereinander. Die Beschriftungen „Vorname“, „Nachname“ und „E-Mail“ standen nur als grauer Platzhaltertext im Feld. Nach dem Absenden wurden fehlerhafte Felder rot umrandet, angesagt wurde nichts.
• Nachher: „Vorname, Pflichtfeld, Eingabefeld“. Nach dem Absenden springt der Fokus zu einer Fehlerübersicht am Formularanfang, die Fehler sind dort als Links zum jeweiligen Feld aufgeführt, und jedes Feld liest seine Fehlermeldung beim Fokussieren mit vor.

Weitere Regeln für gute Formulare, die auch Menschen ohne Screenreader helfen, findest du im Artikel Formulare, die niemand abbricht.

7. Dynamische Inhalte und Statusmeldungen (2 Minuten)

Viele Websites ändern Inhalte, ohne die Seite neu zu laden: Ein Filter aktualisiert die Trefferliste, ein Button legt etwas in den Warenkorb, ein Formular meldet „Erfolgreich gesendet“. Menschen mit Screenreader erfahren davon nur, wenn die Meldung als sogenannte Live-Region ausgezeichnet ist, also als Bereich, dessen Änderungen der Screenreader von selbst ansagt. Das Erfolgskriterium 4.1.3 der WCAG („Statusmeldungen“) verlangt genau das: Statusmeldungen müssen von assistiven Technologien angesagt werden können, ohne dass der Fokus dorthin springt.

Teste deshalb jede Interaktion, die etwas auf der Seite verändert, und hör hin. Bei der Volkshochschule passierte nach dem Klick auf „Anmelden“ für Screenreader-Nutzende scheinbar nichts. Die Bestätigung erschien oberhalb des Formulars, wurde aber nicht angesagt. Nachher sagt der Screenreader direkt „Anmeldung erfolgreich. Wir haben dir eine Bestätigung an deine E-Mail-Adresse geschickt.“ Umgekehrt gilt: Nicht jede Kleinigkeit gehört in eine Live-Region. Wer bei jedem Tastendruck „3 Vorschläge verfügbar“ hört, ist schnell genervt.

8. Dialoge und Overlays (2 Minuten)

Öffne jedes Modal auf der Seite, typischerweise Cookie-Banner, Newsletter-Overlays oder Bestätigungsdialoge. Das Dialog-Muster im ARIA Authoring Practices Guide des W3C beschreibt, was dabei passieren sollte: Beim Öffnen springt der Fokus in den Dialog. Tab und Umschalt+Tab bleiben im Dialog. Escape schließt ihn. Beim Schließen kehrt der Fokus zu dem Element zurück, das den Dialog geöffnet hat. Inhalte hinter dem Dialog sind währenddessen nicht erreichbar, und der Dialog hat einen Namen, meist seine sichtbare Überschrift.

Im Screenreader-Test hörst du die Fehler sofort. Bei der Volkshochschule öffnete sich der Dialog „Kurs auf Merkliste gesetzt“, der Fokus blieb aber hinter dem Overlay, und der Screenreader las munter die Seite weiter vor. Nach dem Schließen landete der Fokus am Seitenanfang. Nachher sagt der Screenreader beim Öffnen „Kurs gemerkt, Dialog“, liest den kurzen Text vor, und nach dem Schließen geht es an derselben Stelle der Kursliste weiter.

Befunde so festhalten, dass jemand sie beheben kann

Ein Befund wie „Screenreader geht nicht“ hilft niemandem. Notiere pro Befund, was du getan hast, was du gehört hast, was du erwartet hättest und mit welcher Kombination. Zum Beispiel: „Kursseite, mit K durch die Links. Gehört: fünfmal ‚Mehr erfahren, Link‘. Erwartet: Kursname im Linktext. NVDA mit Firefox.“

Ein Verweis auf das WCAG-Kriterium macht die Dringlichkeit nachvollziehbar, etwa 1.1.1 für Alternativtexte, 1.3.1 für Überschriften und Formularbeschriftungen, 2.4.4 für Linkzwecke oder 4.1.2 für Name, Rolle und Wert von Bedienelementen. Das hilft besonders, wenn das BFSG im Spiel ist (siehe BFSG in der Praxis). Priorisiere nach Auswirkung: Ein Formular, das sich nicht abschicken lässt, ist kritischer als eine übersprungene Überschriftenebene.

Grenzen: Was ein Screenreader-Test nicht leisten kann

So nützlich der eigene Test ist, er hat klare Grenzen, und die solltest du kennen.

Dir fehlt die tägliche Routine. In der WebAIM-Umfrage stufen 57,8 Prozent ihre Screenreader-Kenntnisse als fortgeschritten ein. Wer täglich mit Screenreader arbeitet, nutzt Abkürzungen, hohe Sprechgeschwindigkeiten und eigene Strategien. Du wirst manche Probleme übersehen, die für erfahrene Menschen offensichtlich sind, und manche Hürden für schlimmer halten, als sie in der Praxis sind.

Jede Kombination verhält sich anders. NVDA mit Firefox, JAWS mit Chrome und VoiceOver mit Safari können dieselbe Seite unterschiedlich ansagen. Ein Test mit einer Kombination ist ein Ausschnitt, kein Beweis.

Ein Screenreader-Test ist keine vollständige Prüfung. Er sagt wenig über Kontraste, Zoom, Bewegungen, verständliche Sprache oder die Bedienung per Tastatur ohne Screenreader. Menschen mit Sehbehinderung, motorischen Einschränkungen oder kognitiven Beeinträchtigungen haben andere Bedürfnisse. Warum Barrierefreiheit breiter gedacht werden muss, beschreibt der Artikel Warum Barrierefreiheit mehr als Kontrast und Größe ist.

Er ersetzt keine Tests mit behinderten Menschen. Die Web Accessibility Initiative des W3C betont, dass Evaluationen mit Menschen mit Behinderungen Probleme sichtbar machen, die eine reine Konformitätsprüfung übersieht, und dass dabei oft auch allgemeine Usability-Probleme auftauchen. Sie warnt zugleich davor, die Rückmeldung einer einzelnen Person auf alle Menschen mit derselben Behinderung zu übertragen. Der eigene Test ist deshalb die Vorbereitung, damit ein Usability-Test mit Screenreader-Nutzenden nicht an Banalitäten hängen bleibt.

Fazit

Menschen mit Screenreader lesen Websites nicht von oben nach unten, sondern springen über Überschriften, Landmarks, Links und Formularfelder. Ob das funktioniert, entscheidet sich an Dingen, die im Layout unsichtbar sind: an der Überschriftenstruktur, an verständlichen Linktexten, an Beschriftungen, an Statusmeldungen und am Fokus in Dialogen.

Mit NVDA oder VoiceOver, einer Handvoll Befehlen und 20 Minuten pro Seitentyp findest du die gröbsten Fehler selbst. Bei der Volkshochschule hat keine der Korrekturen das Design verändert, und trotzdem funktioniert die Anmeldung jetzt für deutlich mehr Menschen.

Der eigene Test ist ein Anfang. Wirklich wissen, ob deine Website funktioniert, wirst du erst, wenn Menschen sie testen, die jeden Tag mit einem Screenreader arbeiten.

Checkliste

• Screenreader und Browser sind passend kombiniert und mit Version notiert, zum Beispiel NVDA mit Chrome oder Firefox, VoiceOver mit Safari.
• Der Seitentitel nennt den konkreten Inhalt, die Sprache der Seite stimmt.
• Die Überschriftenliste ergibt allein ein sinnvolles Inhaltsverzeichnis mit genau einer Überschrift der ersten Ebene.
• Kopfbereich, Navigation, Hauptinhalt und Fußbereich sind als Landmarks erreichbar, ein Skip-Link führt zum Hauptinhalt.
• Jeder Link ist in der Linkliste ohne Umgebung verständlich, Symbol-Buttons haben einen Namen.
• Informative Bilder haben aussagekräftige Alternativtexte, dekorative Bilder werden übersprungen.
• Jedes Formularfeld sagt Beschriftung, Typ und Pflichtstatus an, Fehler werden angesagt und sind mit dem Feld verknüpft.
• Statusmeldungen wie Bestätigungen oder Trefferzahlen werden angesagt, ohne den Fokus zu verschieben.
• Dialoge holen den Fokus, halten ihn, schließen mit Escape und geben ihn danach zurück.
• Die Routine ist auch mit VoiceOver auf dem iPhone durchgespielt.
• Befunde sind mit Aktion, Gehörtem, Erwartung und Kombination dokumentiert.
• Ein Test mit Menschen, die täglich einen Screenreader nutzen, ist eingeplant.

Quellen

• WebAIM (2026): Screen Reader User Survey #11 Results. WebAIM, Utah State University
• WebAIM (2024): Screen Reader User Survey #10 Results. WebAIM, Utah State University
• WebAIM: Using NVDA to Evaluate Web Accessibility
• WebAIM: Using VoiceOver to Evaluate Web Accessibility
• NV Access (2026): NVDA 2026.2 User Guide
• NV Access: About NVDA
• Apple: Turn VoiceOver on or off on Mac
• Apple: VoiceOver search commands on Mac
• Apple: Use the VoiceOver rotor on Mac
• Apple: Navigate web pages by landmarks with VoiceOver on Mac
• Apple: Use the screen curtain with VoiceOver on Mac
• Apple: About the VoiceOver rotor on iPhone or iPad
• Apple: About the Accessibility Shortcut for iPhone, iPad, and iPod touch
• W3C (2024): Understanding Success Criterion 4.1.3: Status Messages
• W3C (2024): Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, 12. Dezember 2024
• W3C: ARIA Authoring Practices Guide, Dialog (Modal) Pattern
• Shawn Lawton Henry, W3C WAI (2024): Involving Users in Evaluating Web Accessibility