Mit einem Screenreader typische Seitenabläufe prüfen

Eine Webseite kann vollständig mit der Tastatur erreichbar sein und für einen Screenreader trotzdem unverständlich bleiben. Ein namenloser Schalter ist erreichbar, aber seine Aufgabe bleibt verborgen. Eine neue Meldung kann im Dokument stehen, aber im entscheidenden Moment unbemerkt bleiben. Eine Prüfung muss deshalb den vollständigen Ablauf einer Aufgabe betrachten: Orientierung, Auswahl, Eingabe, Rückmeldung und den nächsten sinnvollen Schritt.

Dieser Leitfaden zeigt, wie ein Team typische Seitenabläufe strukturiert untersucht. Als Lernfall dient eine kleine Leseliste mit einem bearbeitbaren Titel und einem Hinweisdialog. Dazu gehören konkrete Prüffragen, ein vollständiges HTML-Beispiel und eine Trennung zwischen technischen Browserbefunden und tatsächlicher Screenreaderausgabe. Quellenstand: 9. November 2026. Die Methode unterstützt die Qualitätsprüfung. Sie erteilt keine rechtliche Konformitätsbescheinigung für eine Webseite oder eine bestimmte Dienstleistung.

Eine Aufgabe prüfen statt nur Elemente abzuhaken

Ein brauchbarer Prüffall beginnt mit einer Absicht: „Ändern Sie den Titel des vorhandenen Eintrags und erkennen Sie anschließend, ob die Änderung übernommen wurde.“ Diese Aufgabe benötigt Orientierung, ein verständliches Eingabefeld und eine Rückmeldung. Der Prüfer kennt zwar den technischen Aufbau. Er sollte den Ablauf trotzdem so durchführen, dass die wesentlichen Informationen über die tatsächlich angebotenen Bedienwege auffindbar sein müssen.

Für einen ersten Durchgang sind drei bis fünf geschäftlich wichtige Aufgaben sinnvoll. Dazu können die Suche nach einer Leistung, eine Terminwahl, das Absenden einer Anfrage oder die Korrektur eines Formularfehlers gehören. Es gibt keine allgemeingültige Zahl, die jede Webseite ausreichend abdeckt. Die Auswahl muss unterschiedliche Seitentypen und Zustände berücksichtigen. Eine gut lesbare Startseite beweist noch nicht, dass ein mehrstufiger Abschluss funktioniert.

Die Aufgabe braucht ein klares Ende. Bei einer Anfrage wäre das eine wahrnehmbare und inhaltlich zutreffende Rückmeldung über die Verarbeitung. Bei unserer Leseliste ist es lediglich eine Änderung in der aktuellen Ansicht. Das Beispiel versendet nichts und speichert keinen dauerhaften Eintrag. Eine Sprachausgabe mit einer freundlichen Erfolgsmeldung wäre wertlos, wenn diese Meldung eine tatsächlich nicht erfolgte Speicherung behauptet.

Prüfumgebung und Ausgabekanal festhalten

Dokumentieren Sie Betriebssystem, Browser, Screenreader, jeweilige Version und wichtige Einstellungen. Auch Tastaturlayout, Sprachausgabe und verwendeter Modus können eine Beobachtung beeinflussen. Ein Befund lautet deshalb nicht einfach „Screenreader funktioniert“. Er beschreibt eine konkrete Kombination mit einer reproduzierbaren Aufgabe. Bei späteren Änderungen lässt sich dann nachvollziehen, ob eine Abweichung am Produkt, an einer Einstellung oder an einer aktualisierten Komponente liegt.

NVDA ist ein kostenloser Screenreader für Windows. Das aktuelle NVDA-Benutzerhandbuch beschreibt unter anderem Lesemodus, Fokusmodus und Elementlisten. Andere Kombinationen benötigen eigene Bedienkenntnisse. Die Tasten eines Windows-Screenreaders lassen sich nicht ungeprüft auf VoiceOver oder mobile Bediengesten übertragen. Für ein Unternehmen entscheidet die tatsächlich unterstützte Zielgruppe über die sinnvolle Kombination der Prüfungen.

Die Geschwindigkeit einer Stimme ist keine Qualitätskennzahl. Für die Einarbeitung darf sie langsamer eingestellt werden. Erfahrene Nutzer arbeiten häufig anders als Personen, die ein Werkzeug gerade kennenlernen. Ein Entwicklerdurchlauf kann technische Probleme finden. Er bildet damit noch nicht die gesamte Erfahrung geübter blinder Nutzer ab. Ergänzende Tests mit passenden Personen sollten echte Aufgaben und eine faire Vorbereitung erhalten statt sie nur als nachträgliche Bestätigung einzusetzen.

Lesemodus, Fokusmodus und Tastaturfokus unterscheiden

Beim Lesen einer Webseite bewegt sich ein Screenreader nicht ausschließlich entlang der mit Tab erreichbaren Elemente. Er kann Überschriften, Bereiche, Links oder normalen Text auf anderen Wegen erschließen. Der virtuelle Lesepunkt und der tatsächliche Tastaturfokus sind deshalb unterschiedliche Konzepte. Wenn ein Prüfer nur auf den sichtbaren Fokusrahmen schaut, übersieht er einen wichtigen Teil der Bedienung.

Im NVDA-Lesemodus führen beispielsweise einzelne Buchstaben zu bestimmten Elementarten. Die Eingabe eines Buchstabens in einem Formularfeld muss dagegen beim Feld ankommen. Der Fokusmodus ermöglicht diese direkte Eingabe. Automatische Umschaltungen hängen vom Bedienelement und von Einstellungen ab. Die Modusumschaltung mit der NVDA-Taste und Leertaste ist ein Werkzeug zur Diagnose. Sie ist kein Ersatz für eine verständliche Oberfläche und sollte nicht als geheime Voraussetzung einer normalen Aufgabe versteckt bleiben.

Prüfen Sie eine schwierige Stelle deshalb in zwei Schritten. Zuerst wird festgehalten, in welchem Modus und an welcher Position die Situation entstand. Danach wird untersucht, ob der erwartete Bedienweg verständlich angeboten wird. Ein nicht geschriebener Buchstabe kann durch einen falschen Modus entstehen. Ein Schalter ohne Funktion kann dagegen eine tatsächliche Implementierungslücke sein. Die Unterscheidung verhindert sowohl falsche Entwarnung als auch unnötige Fehlerberichte.

Orientierung über Titel, Überschriften und Bereiche untersuchen

Beginnen Sie nach einem frischen Aufruf mit der Frage, welche Seite vorliegt und welche Hauptaufgabe sie anbietet. Der Dokumenttitel sollte den konkreten Inhalt erkennbar machen. Danach werden Hauptüberschrift, weitere Überschriften und benannte Bereiche betrachtet. Eine rein optische große Zeile ist noch keine programmatisch erkennbare Überschrift. Umgekehrt kann eine überladene Struktur aus vielen gleich benannten Bereichen die Orientierung erschweren.

Im Lernfall heißen die beiden Abschnitte „Eintrag verstehen“ und „Titel ändern“. Die Navigation hat einen unterscheidbaren Namen. Der Sprunglink führt zum Hauptinhalt. Bei der Prüfung wird nicht nur gezählt, ob solche Elemente vorhanden sind. Es wird gefragt, ob man damit die Aufgabe versteht und den nächsten Abschnitt findet. Ein übersprungener Überschriftenrang ist ein Anlass zur inhaltlichen Prüfung und nicht automatisch das einzige entscheidende Problem.

Die ersten Prüfungen der W3C Web Accessibility Initiative bieten einen Einstieg. Sie sind ausdrücklich keine vollständige Bewertung. Für unsere Aufgabenplanung ist dieser Unterschied wichtig: Eine leicht erkennbare Hauptüberschrift kann bestehen, während Fehlerkorrektur oder Dialogbedienung weiterhin scheitern. Der Prüfumfang muss daher über den ersten Eindruck hinausreichen.

Namen, Rollen und Zustände im Zusammenhang bewerten

Ein interaktives Element benötigt einen passenden Namen, eine passende Rolle und nachvollziehbare Zustände. Die W3C-Erläuterung zu Name, Rolle und Wert beschreibt diese Anforderungen. Für die praktische Prüfung reicht eine Liste technisch vorhandener Attribute jedoch nicht. Der Name muss zur tatsächlichen Funktion passen. „Weiter“ kann im Ablauf verständlich sein, in einer isolierten Liste vieler gleich benannter Schalter aber zu wenig erklären.

Unser Beispiel verwendet native Schaltflächen und ein sichtbares mit dem Feld verbundenes Label. Der Hinweisdialog erhält seinen Namen über seine eigene Überschrift. Ein Fehlerzustand wird am Eingabefeld kenntlich gemacht. Wer stattdessen ein klickbares allgemeines Element nur mit einer Rolle versieht, muss weitere erwartete Bedienung selbst herstellen. Die Rolle erzeugt weder automatisch eine Tastaturaktion noch eine funktionierende Fokusführung.

Der ARIA Authoring Practices Guide behandelt genau diese Verantwortung. Zusätzliche ARIA-Angaben können hilfreiche Semantik ergänzen oder vorhandene Bedeutung überschreiben. Deshalb ist „mehr ARIA“ kein sinnvolles Abnahmeziel. Prüfen Sie die wahrnehmbare Funktion und die tatsächliche Bedienung. Ein korrekter technischer Name mit einer falschen Aktion bleibt ein Fehler.

Formularfehler bewusst auslösen und korrigieren

Ein erfolgreicher Durchlauf zeigt nur einen Teil der Bedienung. Lassen Sie das erforderliche Titelfeld zunächst leer. Nach dem Übernehmen muss erkennbar werden, welches Feld betroffen ist und was daran fehlt. Die Erläuterung zur Fehleridentifikation betont eine Beschreibung in Text. Eine rote Umrandung allein genügt nicht, um eine nicht visuell arbeitende Person zu informieren.

Das Beispiel zeigt eine Fehlerzusammenfassung und setzt den Fokus auf deren Überschrift. Ein Link führt gezielt zum Titelfeld. Das Feld ist mit dem Hinweistext und der Fehlermeldung verbunden. Für die Prüfung entstehen konkrete Fragen: Wird die Zusammenfassung wahrgenommen? Ist der Rückweg zum Feld verständlich? Bleibt die Eingabe erhalten? Verschwindet der ungültige Zustand nach erfolgreicher Korrektur? Ein stehen gebliebenes Fehlerattribut kann eine bereits gelungene Eingabe weiterhin falsch beschreiben.

Ein Fokuswechsel zur Zusammenfassung ist eine gewählte Strategie. Nicht jedes Formular muss dieselbe Strategie verwenden. Bei einem kurzen Formular kann eine andere Anordnung geeigneter sein. Entscheidend sind verständliche Information, erreichbare Korrektur und ein konsistenter Ablauf. Das Beispiel schaltet die automatische Browservalidierung bewusst aus, um seine eigene Fehlerfolge zu zeigen. Daraus folgt keine pauschale Empfehlung, native Validierung in jedem Produkt zu deaktivieren.

Statusmeldungen ohne unnötige Unterbrechung prüfen

Nach einer gültigen Eingabe erscheint eine kurze Rückmeldung. Im Lernfall bleibt der Fokus auf der auslösenden Schaltfläche. Die Meldung steht in einem vorhandenen Statusbereich. Die W3C-Erläuterung zu Statusmeldungen unterscheidet solche Informationen von einem Wechsel des Kontexts. Nicht jede neu eingefügte Ergebnisliste ist selbst eine Statusmeldung. Eine kurze Information über den Abschluss einer Suche kann dagegen eine solche Aufgabe haben.

Beim tatsächlichen Screenreadertest wird beobachtet, ob die wichtige Rückmeldung in der gewählten Kombination wahrnehmbar wird. Die genaue Wortfolge kann sich durch Einstellungen und Ausführlichkeit unterscheiden. Ein Prüfprotokoll sollte deshalb die wesentliche übermittelte Bedeutung festhalten. „Der neue Titel wurde genannt“ ist etwas anderes als eine aus dem DOM kopierte Zeichenkette mit der Behauptung, sie sei genau so gesprochen worden.

Der Statusbereich sollte nicht ungefragt die gesamte Seite erneut vorlesen lassen. Auch mehrere gleichzeitig aktualisierte Livebereiche können die Aufgabe unnötig erschweren. Prüfen Sie einen zweiten gültigen Durchlauf und eine anschließende ungültige Eingabe. Alte Erfolgsmeldungen dürfen einen neuen Fehler nicht verdecken. Das Lernbeispiel entfernt eine frühere Rückmeldung vor der nächsten Bewertung und zeigt ausschließlich eine zur aktuellen Aktion passende Aussage.

Einen Dialog öffnen, verstehen und wieder verlassen

Der Hinweisdialog ist absichtlich klein. Die öffnende Schaltfläche beschreibt seinen Inhalt. Beim Öffnen muss eine sinnvolle Position im Dialog erreicht werden. Sein Name erklärt, was sich geöffnet hat. Eine sichtbare Schaltfläche schließt ihn wieder. Auch der Rückweg mit Escape wird geprüft. Nach dem Schließen soll die ursprüngliche Aufgabe ohne Suche nach einer verlorenen Position fortsetzbar sein.

Das W3C-Dialogmuster beschreibt Fokus und modales Verhalten. Unser Beispiel nutzt das native HTML-Element dialog und showModal(). Es baut keine zusätzliche künstliche Fokusfalle aus einer festen Liste von Feldern. Solche Listen werden leicht falsch, sobald Inhalte verschwinden oder hinzukommen. Auch bei nativen Elementen muss die tatsächlich eingesetzte Browserkombination geprüft werden.

Unterscheiden Sie den nicht bedienbaren Hintergrund der Webseite von der weiterhin erreichbaren Browseroberfläche. Eine Prüfung darf nicht jede Bewegung zur Browserleiste fälschlich als Sprung auf ein Hintergrundfeld bewerten. Im technischen Edge-Durchlauf erreichte Tab kein Feld der Hintergrundseite. Der Rückweg führte wieder in den Dialog. Welche Informationen ein Screenreader dabei anbietet, ist zusätzlich mit diesem Screenreader zu untersuchen.

Die vollständige Lernseite

Die folgende Seite benötigt keinen Server für fachliche Verarbeitung und führt keinen Versand aus. Für eine reproduzierbare Browserprüfung kann sie dennoch über einen eigenen kleinen Webserver geladen werden. Die Felder verändern nur die aktuelle Ansicht. Die Ausgabe verwendet Textinhalt statt HTML aus der Eingabe. Das Beispiel ist ein begrenzter Bedienfall und keine Vorlage für eine vollständige Kontakt- oder Kontoverwaltung.

<!doctype html>
<html lang="de"><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>Leseliste bearbeiten: Screenreader-Lernseite</title>
<style>body{font:20px/1.5 system-ui;margin:2rem;max-width:55rem;background:#fff9ef;color:#252528}a{color:#922139}button,input{font:inherit;padding:.7rem}button{margin:.7rem .7rem .7rem 0}label{font-weight:bold;display:block}input{max-width:100%;width:28rem}*:focus-visible{outline:3px solid #ba1743;outline-offset:4px}.skip{position:absolute;top:-100px}.skip:focus{position:static}.error{border-left:5px solid #ac183b;padding:1rem;margin:1rem 0}dialog{max-width:35rem}dialog::backdrop{background:#17171a99}</style>
<a class="skip" href="#main">Zum Inhalt</a><header><p>Leseliste</p><nav aria-label="Hauptnavigation"><a href="#overview">Übersicht</a> · <a href="#edit">Eintrag bearbeiten</a></nav></header>
<main id="main" tabindex="-1"><h1>Leseliste bearbeiten</h1><p>Auf dieser Lernseite wird nur eine Beispielansicht geändert. Es werden keine Angaben versendet oder dauerhaft gespeichert.</p>
<section id="overview"><h2>Eintrag verstehen</h2><p>Die Leseliste enthält einen Eintrag: Semantisches HTML.</p><button id="details" type="button">Hinweise zum Eintrag öffnen</button></section>
<section id="edit"><h2>Titel ändern</h2><div id="errors" class="error" hidden><h3 id="error-heading" tabindex="-1">Titel prüfen</h3><p><a href="#title" id="error-link">Geben Sie einen Titel mit mindestens drei Zeichen ein.</a></p></div>
<form novalidate><label for="title">Titel (erforderlich)</label><p id="title-help">Mindestens drei Zeichen, höchstens 100 Zeichen.</p><input id="title" name="title" type="text" required maxlength="100" aria-describedby="title-help"><button type="submit">Titel übernehmen</button></form><p id="result" role="status"></p></section>
</main><footer><p>Beispiel einer Leseliste</p></footer>
<dialog id="info" aria-labelledby="info-title"><h2 id="info-title">Hinweise zum Eintrag</h2><p>Ein verständlicher Titel beschreibt den Inhalt des Eintrags.</p><form method="dialog"><button autofocus>Hinweise schließen</button></form></dialog>
<script>
const title=document.querySelector('#title'),errors=document.querySelector('#errors'),result=document.querySelector('#result'),info=document.querySelector('#info');
document.querySelector('#details').addEventListener('click',()=>info.showModal());
document.querySelector('#error-link').addEventListener('click',event=>{event.preventDefault();title.focus();});
document.querySelector('main form').addEventListener('submit',event=>{
 event.preventDefault();result.textContent='';const value=title.value.trim();
 if(value.length<3||value.length>100){errors.hidden=false;title.setAttribute('aria-invalid','true');title.setAttribute('aria-describedby','title-help error-link');document.querySelector('#error-heading').focus();return;}
 errors.hidden=true;title.removeAttribute('aria-invalid');title.setAttribute('aria-describedby','title-help');result.textContent='Titel in dieser Ansicht übernommen: '+value;
});
</script></html>

Technische Befunde und tatsächliche Ausgabe sauber trennen

Für diese Lernseite wurden 40 technische Browserprüfungen mit Edge ausgeführt. Sie betreffen unter anderem erkannte Namen und Rollen, den Sprung zum Hauptinhalt, das fokussierte Fehlerziel, die Verbindung des Felds mit seinem Hinweis und den Rückweg nach dem Dialog. Nach der gültigen Eingabe wurde der Statusinhalt geprüft. Ein Titel mit HTML-Zeichen wurde als Text ausgegeben. Es entstand kein entsprechendes Bildelement und keine Formularübertragung.

Diese Ergebnisse sind keine protokollierte Sprachausgabe. Ein zugänglicher Browserbaum zeigt, welche Informationen der Browser anbietet. Er beweist nicht, wann ein bestimmter Screenreader sie ansagt, ob eine virtuelle Navigation verständlich funktioniert oder wie angenehm die Aufgabe gelingt. Für eine positive Aussage über diese Punkte benötigt man den zusätzlich ausgeführten Durchlauf mit dokumentierter Ausgabe. Eine abgebrochene oder nicht ausgeführte Prüfung bleibt offen.

Auch ein bestandener Durchlauf einer Kombination ist keine universelle Freigabe. Eine spätere Änderung der Fehlerbehandlung, ein anderes Skript für Dialoge oder eine neue Version des Browsers kann einen erneuten gezielten Test erfordern. Die WAI-Hilfe zur Auswahl von Prüfwerkzeugen unterstreicht die Grenzen automatisierter Aussagen. Menschliche Bewertung und technische Werkzeuge ergänzen sich. Eine einzige Punktzahl ersetzt die Aufgabenprüfung nicht.

Ein nachvollziehbares Protokoll mit offenen Punkten führen

Ein Befund sollte Startzustand, ausgeführte Schritte, erwartete wesentliche Information und tatsächliche Beobachtung enthalten. Dazu kommen die Prüfumgebung und ein klarer Beleg. Bei Sprachausgabe kann eine Sprachansicht helfen. Sie muss tatsächlich von der verwendeten Hilfstechnik stammen. Eine nachträglich geschriebene Sprechblase ist nur eine Illustration und kein Nachweis. Vertrauliche Eingaben oder personenbezogene Inhalte gehören nicht ungeprüft in öffentlich geteilte Protokolle.

Verwenden Sie Zustände wie bestanden, nicht bestanden, nicht anwendbar und nicht geprüft mit einer klaren Bedeutung. „Nicht geprüft“ darf nicht durch einen grünen Standardwert ersetzt werden. Ein tatsächlicher Fehler erhält eine verständliche Auswirkung: „Nach der Ablehnung bleibt unklar, welches Feld korrigiert werden muss.“ Diese Beschreibung hilft einem Entwicklungsteam mehr als eine isolierte Liste von Attributnamen ohne den betroffenen Ablauf.

Checkliste für die regelmäßige Aufgabenprüfung

Für die Reihenfolge der Korrekturen zählt die tatsächliche Auswirkung. Ein nicht erreichbarer Abschluss kann eine Aufgabe vollständig verhindern. Ein unklarer Schaltername kann zusätzliche Suche verursachen. Eine zu ausführliche Statusmeldung kann die Bedienung verlangsamen. Diese Auswirkungen sollten konkret beschrieben werden. Eine selbst erfundene pauschale Prozentzahl würde weder den Umfang des Problems noch den betroffenen Personenkreis zuverlässig ausdrücken.

Bei einem erneuten Durchlauf nach einer Korrektur beginnt die Prüfung wieder am ursprünglichen Startpunkt. Der direkte Sprung zum reparierten Feld könnte eine davor liegende Barriere verdecken. Halten Sie früheren Befund, vorgenommene Änderung und neue Beobachtung auseinander. So bleibt nachvollziehbar, warum eine Aufgabe nun anders bewertet wird. Ein Protokoll ist dann brauchbar, wenn eine andere Person den Ablauf ohne Erinnerung an das ursprüngliche Gespräch wiederholen kann.

Lesereihenfolge und inhaltliche Verständlichkeit mitprüfen

Die optische Anordnung kann Zusammenhänge vermitteln, die beim linearen Lesen fehlen. Eine kurze Angabe wie „verfügbar“ ist nur dann hilfreich, wenn klar bleibt, zu welchem Angebot sie gehört. Lesen Sie deshalb einen relevanten Abschnitt auch fortlaufend. Prüfen Sie anschließend die Navigation nach Elementarten. Ein guter Ablauf sollte nicht ausschließlich funktionieren, wenn der Prüfer bereits weiß, an welcher Stelle ein wichtiger Zusatz steht.

Auch Sprache und Abkürzungen verdienen Beachtung. Der Dokumentcode sollte die tatsächlich verwendete Sprache ausweisen. Eine falsch zugeordnete Sprache kann die Verständlichkeit der Ausgabe beeinträchtigen. Ob eine konkrete Stimme einzelne Produktnamen passend ausspricht, ist wiederum von einer fehlenden Beschriftung zu unterscheiden. Für die Fehlerbeschreibung hilft die Frage, welche wesentliche Information verloren geht und ob sich die Aufgabe dadurch noch selbstständig abschließen lässt.

Bei einer längeren Seite sollte der Prüfer außerdem zwischen dem Inhaltsbereich und wiederholten Seitenteilen wechseln können. Sprunglinks und benannte Bereiche sind dabei mögliche Hilfen. Sie müssen zur wirklichen Struktur passen. Eine Vielzahl unnötiger Bereiche mit identischen Namen erzeugt zusätzliche Arbeit. Das Lernbeispiel bleibt bewusst klein, damit die Beziehung zwischen Orientierung, Eingabe und Rückmeldung leicht untersucht werden kann.

Neue dynamische Inhalte benötigen ebenfalls einen verständlichen Zusammenhang. Ein Status sollte die Bedeutung der Aktion erklären und nicht nur ein isoliertes „fertig“ ausgeben. Gleichzeitig darf die Meldung keine unwahre dauerhafte Speicherung suggerieren. Im Lernfall wird ausdrücklich die aktuelle Ansicht genannt. Für eine echte Anwendung muss die Rückmeldung stattdessen zum tatsächlichen fachlichen Ergebnis und gegebenenfalls zum noch laufenden Verarbeitungsschritt passen.

• Geschäftlich wichtige Abläufe und relevante Zustände auswählen.
• Versionen, Einstellungen und Bedienkombination dokumentieren.
• Orientierung und direkte Tastaturbedienung getrennt untersuchen.
• Namen, Rollen und Zustände mit der tatsächlichen Aktion vergleichen.
• Mindestens einen fachlich sinnvollen Fehler auslösen und korrigieren.
• Rückmeldungen auf Wahrnehmbarkeit und sachliche Richtigkeit prüfen.
• Dialoge einschließlich Schließen und Rückkehr testen.
• Technischen Baum, sichtbaren Fokus und tatsächliche Ausgabe unterscheiden.
• Offene Prüfungen als offen erhalten und Belege passend beschriften.
• Nach relevanten Änderungen genau die betroffenen Aufgaben erneut prüfen.

Eine solche Routine macht Barrieren reproduzierbar und Korrekturen überprüfbar. Sie hilft zugleich, falsche Erfolgsaussagen zu vermeiden. Gute Screenreader-Prüfung bewertet nicht allein, ob etwas vorgelesen werden könnte. Sie untersucht, ob die wichtigen Schritte einer echten Aufgabe verständlich und verlässlich angeboten werden.