Screenreader erklärt: Wie blinde Nutzer im Web navigieren

Weltweit gibt es schätzungsweise 36 Millionen blinde Menschen, und etwa 217 Millionen weitere leben mit einer mittelgradigen bis schweren Sehbeeinträchtigung. Dennoch weisen im Jahr 2025 über 96% aller Websites noch mindestens einen erkennbaren Barrierefreiheitsfehler auf. Für eine blinde Person, die auf einen Screenreader angewiesen ist, kann ein einziges fehlendes Label, eine fehlerhafte Überschriftenhierarchie oder ein nicht zugängliches CAPTCHA den Unterschied ausmachen zwischen der eigenständigen Erledigung einer Aufgabe und dem vollständigen Abbruch Ihres Angebots. Zu verstehen, wie Screenreader tatsächlich funktionieren – nicht nur in der Theorie, sondern in der Praxis – ist die Grundlage für den Aufbau eines barrierefreien Webs.

Was ist ein Screenreader und wer benutzt ihn?

Ein Screenreader ist eine unterstützende Softwaretechnologie, die Inhalte auf dem Bildschirm in synthetische Sprache oder in eine aktualisierbare Braille-Ausgabe umwandelt. Anstatt einfach nur Text vorzulesen, interpretieren Screenreader die Struktur, Rollen, Zustände und Beziehungen von Interface-Elementen und vermitteln Nutzerinnen und Nutzern so ein umfassendes Verständnis einer Webseite, ohne sich auf die visuelle Darstellung zu stützen. Denken Sie weniger an einen Vorleser und mehr an eine intelligente Dolmetscherin, die Ihre gesamte visuelle Oberfläche in einen auditiven oder taktilen Informationsstrom übersetzt.

Screenreader werden in erster Linie von Menschen genutzt, die blind sind oder eine Sehbehinderung haben, unterstützen aber auch Personen mit bestimmten kognitiven oder Lesebehinderungen. Laut der 10. Screen Reader User Survey von WebAIM – durchgeführt Ende 2023 und veröffentlicht im Februar 2024 – sind fast 77% der Screenreader-Nutzenden Menschen mit Blindheit, gefolgt von Menschen mit Sehrest oder anderen Sehbeeinträchtigungen mit knapp 20%. Hörverlust, kognitive Beeinträchtigungen und motorische Beeinträchtigungen machen den Rest aus. Dies ist kein Nischenpublikum: 4,9% der Erwachsenen in den USA haben eine Sehbehinderung mit Blindheit oder erheblichen Sehschwierigkeiten, und die weltweite Zahl der sehbehinderten Nutzerinnen und Nutzer liegt im Hunderte-Millionen-Bereich.

Es ist außerdem wichtig zu betonen, dass Screenreader-Nutzende keine homogene Gruppe sind. Forschung zeigt immer wieder eine große Bandbreite an Fähigkeiten, Vorlieben, Navigationsstrategien und Herangehensweisen an Problemlösungen. Eine Person, die seit Geburt blind ist und seit zwanzig Jahren JAWS nutzt, navigiert völlig anders als jemand, der oder die erst vor Kurzem das Sehvermögen verloren hat und unterstützende Technologien noch erlernt. Selbst technisch barrierefreie Websites können erhebliche Hürden darstellen, wenn die mentalen Modelle, die sie voraussetzen, nicht zu den Erwartungen der Nutzenden passen. Designerinnen, Designer und Entwicklerinnen, Entwickler müssen der Versuchung widerstehen, sich eine einzige, archetypische Screenreader-Person vorzustellen.

Wie Screenreader tatsächlich funktionieren: Der Accessibility Tree

Um Screenreader wirklich zu verstehen, müssen Sie verstehen, was sie lesen – und das ist nicht Ihr visuelles Layout. Screenreader arbeiten, indem sie auf den Accessibility Tree zugreifen, eine strukturierte Repräsentation der Seite, die der Browser aus dem HTML-DOM aufbaut. Der Browser stellt diesen Baum über plattformspezifische Accessibility-APIs bereit: UI Automation unter Windows, NSAccessibility unter macOS und AccessibilityService unter Android. Der Screenreader fragt diese API ab, erhält semantische Informationen zu jedem Element und wandelt sie in Sprach- oder Braille-Ausgabe um.

Das hat eine entscheidende Konsequenz: Was Sie auf dem Bildschirm sehen und was ein Screenreader wahrnimmt, kann sich radikal unterscheiden. Wenn Ihr visuelles Design ein <div> verwendet, das wie ein Button gestylt ist, wird ein Screenreader es nicht als Button ankündigen – weil es im Accessibility Tree keine Button-Rolle hat. Der Screenreader kündigt an, was der Code sagt, nicht was die Pixel zeigen. Semantische HTML-Elemente wie <button>, <nav>, <h1> und <form> tragen eingebaute Rollen, die automatisch in den Accessibility Tree übernommen werden. Wenn Entwicklerinnen und Entwickler diese zugunsten generischer Elemente umgehen, die nachträglich mit ARIA-Rollen versehen werden, erzeugen sie unnötige Komplexität und führen häufig neue Fehler ein.

Screenreader liefern außerdem Kontext, der auf dem Bildschirm nicht sichtbar ist. Wenn eine Nutzerin oder ein Nutzer auf eine Liste trifft, kündigt der Screenreader an, wie viele Einträge sie enthält. Bei einer Tabelle kündigt er die Anzahl der Zeilen und Spalten an. Wenn der Fokus in ein Formularfeld wechselt, liest er das Label des Feldes, seinen Typ und seinen aktuellen Zustand vor. Diese kontextuellen Metadaten sind vollständig von gut strukturiertem, semantischem HTML abhängig. Entfernen Sie diese Struktur, nehmen Sie den Nutzenden die Möglichkeit, zu verstehen, womit sie es zu tun haben.

Die wichtigsten Screenreader: JAWS, NVDA, VoiceOver und TalkBack

Der Screenreader-Markt wird von einer Handvoll Werkzeuge dominiert, die jeweils eigene Besonderheiten haben. Zu verstehen, auf welche Tools Ihre Nutzenden wahrscheinlich angewiesen sind, beeinflusst direkt, wie Sie Ihre Website testen sollten.

JAWS (Job Access With Speech), entwickelt von Freedom Scientific und erstmals 1995 veröffentlicht, gilt seit Langem als Goldstandard der Branche, insbesondere im Unternehmensumfeld. In der WebAIM-Umfrage 2024 war JAWS für etwa 41% der Befragten der primäre Screenreader. Es handelt sich um ein kommerzielles Produkt mit Lizenzkosten zwischen 90 und über 1.400 $ pro Jahr. JAWS bietet umfangreiche Anpassungsmöglichkeiten, robuste Kompatibilität mit komplexen Workflows in Microsoft Office und professionellen Anwendungen sowie einen „Browse Mode“, der die Seite in eine navigierbare, lineare Umgebung verwandelt, in der Nutzende mit intuitiven Tastenkombinationen nach Überschriften, Landmarken und Formularfeldern springen können.

NVDA (NonVisual Desktop Access), entwickelt von NV Access und 2006 eingeführt, ist ein kostenloser, Open-Source-Screenreader für Windows. Er war 2024 für etwa 38% der WebAIM-Befragten der primäre Screenreader – nahezu identisch mit JAWS. NVDA hat aufgrund seines kostenfreien Modells, häufiger Updates und robuster Performance deutlich an Popularität gewonnen. 2025 führte NVDA eine verbesserte Behandlung des Fokus-Managements in Single-Page-Anwendungen ein, die Nutzenden hilft zu verstehen, wann sich Inhalte geändert haben und wohin der Fokus gewandert ist. Die empfohlene Browser-Kombination ist Firefox, wobei die Unterstützung für Chrome ebenfalls stark ist.

VoiceOver ist Apples integrierter Screenreader, verfügbar auf macOS, iOS und iPadOS – eine Installation ist nicht erforderlich. Auf dem Desktop nutzt er Tastenkombinationen mit dem VO-Modifikator (Control + Option), während er auf iOS auf Touch-Gesten wie Wischen, Doppeltippen und den Rotor setzt. Auf Mobilgeräten ist VoiceOver der am weitesten verbreitete Screenreader; 70,6% der mobilen Screenreader-Nutzenden verlassen sich auf ihn. Am besten funktioniert er in Kombination mit Safari, dem einzigen Browser, der die macOS/iOS-Accessibility-APIs vollständig an VoiceOver weitergibt.

TalkBack ist der integrierte Screenreader von Android und bietet gesprochene Rückmeldungen und Vibrationen, um Nutzenden bei der Navigation auf ihren Geräten zu helfen. Er ist das Standardwerkzeug für Tests auf Android-Mobilgeräten und funktioniert am besten mit Chrome. Windows wird außerdem mit Narrator ausgeliefert, einem integrierten Screenreader, der sich stetig verbessert hat, aber noch immer einige Funktionen von JAWS und NVDA vermissen lässt. Jedes dieser Tools verhält sich etwas anders – ein Muster, das in NVDA korrekt funktioniert, kann in JAWS scheitern –, weshalb Tests mit mehreren Screenreadern für jedes ernsthafte Barrierefreiheitsprogramm unerlässlich sind.

Wie blinde Nutzende tatsächlich navigieren: Das mentale Modell, das alles verändert

Hier ist die Erkenntnis, die am grundlegendsten verändert, wie Entwicklerinnen und Entwickler über ihre Arbeit nachdenken sollten: Screenreader-Nutzende lesen Seiten nicht linear von oben nach unten. Sie nutzen ein ausgefeiltes Set an Navigationsstrategien, um Inhalte effizient zu scannen und anzuspringen – ähnlich wie sehende Personen Inhalte visuell überfliegen. Wenn Sie diese Strategien nicht unterstützen, wird selbst eine technisch barrierefreie Seite zu einer ermüdenden, unbenutzbaren Erfahrung.

Die verbreitetste Navigationsstrategie ist die Navigation über Überschriften. Die Nutzung von Überschriften zur Informationssuche hat im Laufe der Zeit zugenommen und bleibt die vorherrschende Methode – 88,8% der Befragten finden Überschriftenebenen sehr oder einigermaßen nützlich. Fortgeschrittene Nutzende navigieren deutlich häufiger über Überschriften als Einsteigerinnen und Einsteiger. In der Praxis bedeutet das, dass eine Person in JAWS oder NVDA die Taste H drückt, um zur nächsten Überschrift auf der Seite zu springen und so die Struktur schnell zu erfassen. Durch Drücken von 1 bis 6 springt man direkt zu einer Überschrift dieser Ebene. Wenn Ihre Seite keine Überschriften hat oder Überschriften nur nach visueller Größe statt nach Dokumentstruktur gewählt werden, haben blinde Nutzende keine Orientierungspunkte, zwischen denen sie springen können – sie sind gezwungen, sich die gesamte Seite von Anfang an anzuhören.

Die zweite wichtige Strategie ist die Navigation über Landmarken. HTML5-Landmark-Elemente – <main>, <nav>, <header>, <footer>, <aside> und <section> mit einem Label – erzeugen benannte Bereiche, zwischen denen Screenreader-Nutzende mit ihrem Rotor oder Landmarken-Tastenkürzeln springen können. 2025 hat die Nutzung von ARIA-Landmarken leicht zugenommen, angeführt von der wachsenden Verwendung des nativen <main>-Elements, das inzwischen auf 47% der Seiten vorhanden ist. Während 31,7% der Befragten angeben, Landmarken immer oder häufig zu nutzen, wenn sie vorhanden sind, verwenden nur 3,7% Landmarken als primäre Navigationsmethode – was darauf hindeutet, dass Landmarken ein sekundäres, aber wichtiges Werkzeug zur Orientierung sind.

Nutzende navigieren außerdem über Links, Formularfelder und Buttons mithilfe von Einzeltasten-Shortcuts und rufen häufig Elementlisten auf – einen Dialog, der alle Überschriften, alle Links oder alle Formularfelder der Seite auf einmal anzeigt –, um zu scannen und direkt zu dem zu springen, was sie benötigen. Dieses Verhalten hat enorme Auswirkungen auf den Linktext. Eine Liste von Links mit der Beschriftung „Read more, Read more, Read more“ bietet keinen Navigationswert. Jeder Link und jeder Button muss einen beschreibenden, eindeutigen zugänglichen Namen haben, der auch aus dem Kontext gerissen Sinn ergibt.

Auf Mobilgeräten verschiebt sich das Paradigma zu Touch-Gesten. VoiceOver- und TalkBack-Nutzende wischen nach rechts, um zum nächsten Element zu gelangen, tippen doppelt, um es zu aktivieren, und nutzen Rotor-Gesten, um zwischen Navigationsmodi zu wechseln. Die Präferenz für die Nutzung mobiler Apps ist 2024 auf 58% gestiegen, gegenüber 51,8% im Jahr 2021. Das bedeutet, dass Ihr responsives Design und Ihre mobile Barrierefreiheit keine optionalen Ergänzungen sind – sie sind primäre Anwendungsfälle für einen großen Teil der Screenreader-Nutzenden.

Die problematischsten Barrieren im Web heute

WebAIMs Umfrage bat die Befragten, die problematischsten Punkte zu benennen, auf die sie stoßen. Die Ergebnisse sind über mehr als ein Jahrzehnt hinweg bemerkenswert konsistent – und sie bilden eine direkte Checkliste dessen, was Ihre Website richtig machen muss.

• CAPTCHA ist mit deutlichem Abstand die häufigste Beschwerde. Screenreader-Nutzende sind sich einig, dass CAPTCHA seit über vierzehn Jahren in Folge der problematischste Punkt ist. Der Einsatz eines traditionellen CAPTCHA ist für blinde Menschen offensichtlich problematisch, da die Screenreader, auf die sie angewiesen sind, das Bild nicht verarbeiten können und sie so die vom Formular geforderte Information nicht erhalten. Selbst Audio-CAPTCHAs scheitern bei vielen Nutzenden – absichtliche Verzerrungen machen sie unverständlich. Die praktische Empfehlung: Verwenden Sie nach Möglichkeit unsichtbare, verhaltensbasierte Verifikationsmethoden wie reCAPTCHA v3 oder Honeypot-Techniken.
• Interaktive Elemente mit unerwartetem Verhalten – Menüs, Tabs, Dialogfenster und benutzerdefinierte Widgets, die etablierten Tastatur-Interaktionsmustern nicht folgen – liegen dicht hinter CAPTCHA. Diese Elemente werden häufig mit übermäßig vielen ARIA-Attributen gebaut und weisen unregelmäßiges Interaktionsverhalten sowie Kompatibilitätsprobleme zwischen Browsern und Screenreadern auf.
• Mehrdeutige Links und Buttons frustrieren Nutzende ständig. Formulierungen wie „click here“, „learn more“ oder „read more“ geben keinen Hinweis auf Ziel oder Aktion, wenn sie isoliert in einer Linkliste gehört werden.
• Unerwartete Bildschirmänderungen – dynamische Inhaltsaktualisierungen, die ohne Vorwarnung stattfinden – desorientieren blinde Nutzende, die keinen visuellen Hinweis darauf haben, dass sich etwas geändert hat. Dies ist besonders ausgeprägt in Single-Page-Anwendungen, die mit React, Vue oder Angular gebaut sind, wo sich Inhalte ohne Seitenneuladen verschieben können.
• Fehlerhafte Überschriftenhierarchien untergraben die wichtigste Navigationsstrategie der meisten fortgeschrittenen Nutzenden. Etwa 39% der Websites haben fehlerhafte Überschriftenhierarchien, was es Screenreader-Nutzenden erschwert, Inhalte sinnvoll zu durchqueren.
• Fehlender oder unzureichender Alt-Text bei Bildern. Wenn Alt-Text fehlt, kann ein Screenreader lediglich das Vorhandensein eines Bildes anzeigen, ohne dessen Inhalt zu beschreiben, oder – schlimmer noch – einen bedeutungslosen Dateinamen wie „IMG_4823.jpg“ vorlesen.

Die Mehrheit – 67% – der Screenreader-Nutzenden kontaktiert Website-Betreibende nie oder nur selten wegen Barrieren. Sie gehen einfach. Sie erhalten keine Beschwerde. Sie verlieren einfach eine Nutzerin oder einen Nutzer.

Code schreiben, den Screenreader tatsächlich interpretieren können

Das Verständnis der Navigationsmuster der Nutzenden macht die technischen Anforderungen deutlich greifbarer. Jede Entscheidung, die Sie in Markup und JavaScript treffen, hat direkte, hörbare Konsequenzen für blinde Menschen. Hier sind die wichtigsten Prinzipien.

Semantisches HTML ist Ihr erstes und mächtigstes Werkzeug. Die erste ARIA-Regel lautet: „Wenn Sie ein natives HTML-Element oder Attribut mit der Semantik und dem Verhalten verwenden können, die Sie benötigen, anstatt ein Element zweckzuentfremden und ihm eine ARIA-Rolle, einen Zustand oder eine Eigenschaft hinzuzufügen, um es zugänglich zu machen, dann tun Sie das.“ Elemente wie <button>, <nav>, <header> und <form> bringen Barrierefreiheit von Haus aus mit. Die Verwendung nativer Steuerelemente stellt die Kompatibilität mit Browsern und unterstützender Technologie ohne zusätzlichen Code sicher.

ARIA ist eine Ergänzung, kein Ersatz. ARIA (Accessible Rich Internet Applications) ist ein Satz von HTML-Attributen, der dazu dient, Barrierefreiheitslücken zu schließen, wenn HTML allein die erforderliche Semantik nicht ausdrücken kann – etwa um einen benutzerdefinierten Slider zugänglich zu machen, dynamische Inhaltsänderungen anzukündigen oder anzugeben, dass ein ausklappbares Menü derzeit aufgeklappt ist. Die Gefahr liegt im Missbrauch. Startseiten mit ARIA weisen im Durchschnitt mehr als doppelt so viele Barrierefreiheitsfehler auf wie Seiten ohne ARIA. Mehr ARIA bedeutet nicht mehr Barrierefreiheit – oft bedeutet es mehr Fehler. Seiten, die ARIA falsch verwendeten, zeigten 70% mehr erkennbare Fehler als solche, die es nicht nutzten. Setzen Sie ARIA gezielt ein, dort, wo kein natives Element die Aufgabe übernehmen kann.

Das folgende Codebeispiel veranschaulicht den Unterschied zwischen einem nicht zugänglichen benutzerdefinierten Button und einem korrekt zugänglichen:

<!-- Inaccessible: a div with click handler, no role, no keyboard support -->
<div class='btn' onclick='submitForm()'>Submit</div>

<!-- Accessible: native button with built-in role, keyboard support, and focus -->
<button type='submit'>Submit</button>

<!-- If you must use a non-button element, add role, tabindex, and keyboard event -->
<div role='button' tabindex='0'
     aria-label='Submit the registration form'
     onkeydown='handleKey(event)'
     onclick='submitForm()'>
  Submit
</div>

ARIA-Live-Regionen sind der richtige Mechanismus, um dynamische Inhaltsänderungen anzukündigen. Wenn Ihre Seite Inhalte ohne vollständiges Neuladen aktualisiert – eine Formular-Validierungsmeldung, ein Warenkorb-Gesamtbetrag, eine Benachrichtigung –, bleibt diese Änderung für Screenreader-Nutzende stumm, sofern Sie keine Live-Region verwenden. Das Attribut aria-live='polite' weist den Screenreader an, die Änderung anzukündigen, nachdem die aktuelle Aktivität der Nutzenden abgeschlossen ist, während aria-live='assertive' sofort unterbricht – verwenden Sie Letzteres sparsam, nur für dringende Warnungen. 2025 nutzen etwa 33% der Websites das Attribut aria-live, ein Anstieg um 4% gegenüber 2024, aber die Verbreitung ist angesichts der Vielzahl eingesetzter dynamischer Interfaces noch viel zu gering.

Fokus-Management in interaktiven Komponenten – modale Dialoge, Flyout-Menüs, Akkordeons – muss explizit gehandhabt werden. Wenn ein Modal geöffnet wird, muss der Fokus in dieses Modal wechseln. Wenn es geschlossen wird, muss der Fokus zu dem Element zurückkehren, das es ausgelöst hat. Eine Screenreader-Nutzerin oder ein -Nutzer, die oder der ein Modal öffnet und feststellt, dass der Fokus weiterhin auf dem Button dahinter liegt, ist faktisch von den Inhalten des Dialogs ausgeschlossen.

Ihre Website mit einem Screenreader testen

Automatisierte Barrierefreiheits-Scanner sind wertvoll, aber begrenzt. Automatisierte Tools erfassen 30–40% der WCAG-Verstöße, aber Tests mit realer unterstützender Technologie zeigen, wie Nutzende Ihre Website tatsächlich erleben – fehlender Kontext, verwirrende Navigation und Interaktionen, die schlicht nicht funktionieren. Kein Scanner wird Ihnen sagen, dass die Überschrift Ihres Modals ohne den visuellen Kontext keinen Sinn ergibt oder dass Ihr benutzerdefiniertes Dropdown seinen Zustand in einer bestimmten Browser-Screenreader-Kombination falsch ankündigt, in einer anderen aber nicht.

Der praktische Ausgangspunkt für die meisten Teams ist NVDA mit Firefox – kostenlos, weit verbreitet und effektiv, um die große Mehrheit typischer Probleme aufzudecken. Ergänzen Sie VoiceOver mit Safari, um macOS- und iOS-Nutzende abzudecken. In Unternehmenskontexten oder bei Kundschaft mit hohen Compliance-Anforderungen sollten Sie JAWS mit Chrome oder Edge einbeziehen. Jeder Screenreader funktioniert am besten mit einer bestimmten Browser-Kombination; die falsche Kombination kann irreführende Testergebnisse liefern.

Übernehmen Sie beim Testen die Navigationsmuster, die echte Nutzende verwenden. Nutzen Sie keine Maus. Navigieren Sie mit der Taste H über Überschriften. Rufen Sie die Linkliste auf und prüfen Sie, ob jeder Link auch aus dem Kontext gerissen verständlich ist. Tabben Sie durch Formularfelder und prüfen Sie, ob jedes Label korrekt angekündigt wird. Öffnen Sie modale Dialoge und vergewissern Sie sich, dass der Fokus in sie hineinwandert. Füllen Sie Formulare aus und senden Sie sie ab, und hören Sie sich jede Validierungsmeldung an. Schalten Sie Ihren Monitor aus und versuchen Sie, eine repräsentative Nutzeraufgabe von Anfang bis Ende zu erledigen – diese Erfahrung, so unangenehm sie für sehende Testende sein mag, ist der Alltag Ihrer blinden Nutzenden.

Es ist außerdem wichtig, mit echter unterstützender Technologie zu testen und nicht mit Browser-Emulatoren oder Simulatoren. Die Accessibility-Panels der Browser-Entwicklertools zeigen Ihnen den Accessibility Tree, was beim Debugging hilfreich ist, aber sie reproduzieren nicht die auditive Erfahrung und decken keine Interaktionsbesonderheiten auf, die nur mit echter Screenreader-Software sichtbar werden.

Die geschäftliche und rechtliche Argumentation, die Sie nicht ignorieren können

Wenn das moralische Argument für Barrierefreiheit durch wirtschaftliche Realität untermauert werden muss, sind die Zahlen eindeutig. Allein in den Vereinigten Staaten gibt es etwa 7 Millionen Menschen mit Sehbeeinträchtigungen – eine bedeutende Konsumentengruppe. Weltweit haben 26% der Erwachsenen in den USA Behinderungen und repräsentieren ein geschätztes Marktpotenzial von 13 Billionen $. Wenn unzugängliches Design blinde Nutzende von Ihrer Website ausschließt, verfehlen Sie nicht nur eine moralische Verpflichtung – Sie weisen Kundschaft ab und setzen Ihre Organisation rechtlichen Risiken aus.

WCAG 2.2 ist inzwischen der rechtliche Referenzstandard in Tausenden von ADA-Klagen, und der European Accessibility Act, der im Juni 2025 für privatwirtschaftliche Unternehmen vollständig in Kraft getreten ist, erweitert die Compliance-Anforderungen in der gesamten EU. Die Mehrheit der Screenreader-Nutzenden kontaktiert Website-Betreibende nie wegen Barrieren – sie gehen einfach und nehmen ihr Geschäft mit. Die 67% der Nutzenden, die Probleme nie melden, sind nicht zufrieden; sie sind entmutigt. Wenn Sie Screenreader-Kompatibilität von Anfang an in Ihren Entwicklungsprozess integrieren, vermeiden Sie kostspielige Nachbesserungen, reduzieren rechtliche Risiken und öffnen Ihre Produkte für ein Publikum, das aktiv nach digitalen Angeboten sucht, die es tatsächlich nutzen kann.

Wesentliche Erkenntnisse

• Screenreader navigieren Struktur, nicht Visuals. Sie fragen den Accessibility Tree des Browsers über Plattform-Accessibility-APIs ab. Semantisches HTML – korrekte Überschriften, Landmarken, native Steuerelemente – ist die wirkungsvollste Investition, die Sie in Screenreader-Kompatibilität tätigen können.
• Blinde Nutzende navigieren über Überschriften, Landmarken und Elementlisten – nicht linear. Über 88% der Screenreader-Nutzenden finden Überschriftenebenen für die Navigation sehr oder einigermaßen nützlich. Eine fehlerhafte oder fehlende Überschriftenhierarchie ist eine der häufigsten und gravierendsten Barrierefreiheitsverletzungen im Web.
• ARIA verstärkt sowohl gutes als auch schlechtes Markup. Seiten mit ARIA weisen im Durchschnitt mehr als doppelt so viele Barrierefreiheitsfehler auf wie Seiten ohne. Verwenden Sie ARIA nur dort, wo natives HTML die erforderliche Semantik nicht ausdrücken kann, und testen Sie nach der Implementierung immer mit realer unterstützender Technologie.
• CAPTCHA, mehrdeutige Links und nicht angekündigte dynamische Inhaltsänderungen sind die wichtigsten Barrieren in der Praxis. Das Ersetzen visueller CAPTCHA durch verhaltensbasierte Verifikation, das Schreiben beschreibender Link- und Buttontexte und die Implementierung von ARIA-Live-Regionen für dynamische Aktualisierungen haben einen unmittelbaren, messbaren Einfluss auf die Nutzbarkeit für blinde Menschen.
• Testen Sie mit echten Screenreadern über mehrere Browser-Kombinationen hinweg. Automatisierte Scanner erfassen nur 30–40% der WCAG-Verstöße. NVDA mit Firefox und VoiceOver mit Safari decken den Großteil Ihrer Nutzerschaft ohne Kosten ab, und die Erfahrung, Ihre Website ohne Maus zu navigieren, offenbart Probleme, die kein automatisiertes Tool aufdecken kann.