Screenreader übersetzen visuelle Webinhalte in gesprochene Sprache oder Braillezeile und sind für blinde und sehbehinderte Menschen das zentrale Werkzeug zur Nutzung des Internets. In Deutschland leben rund 1,2 Millionen (Projekterfahrung) blinde und sehbehinderte Menschen (DBSV, 2024), weltweit sind es über 2,2 Milliarden (WHO, 2024). Doch laut dem WebAIM Million Report (2024) weisen 96,3% (WebAIM, 2024) aller Websites Probleme auf, die die Screenreader-Nutzung erheblich erschweren oder unmöglich machen. Die Screenreader-Optimierung ist ein zentraler Baustein der BFSG-Compliance und verbessert gleichzeitig die SEO und die allgemeine Codequalität.
Wie Screenreader Websites interpretieren
Screenreader analysieren den Accessibility Tree des Browsers, eine von der visuellen Darstellung unabhängige Repräsentation der Seiteninhalte. Dieser Baum wird aus dem DOM und den ARIA-Attributen aufgebaut und enthält für jedes Element eine Rolle, einen Namen und einen Zustand. Ein Button mit der Beschriftung Absenden wird im Accessibility Tree als Rolle: Button, Name: Absenden, Zustand: nicht gedrückt dargestellt.
Die Qualität des Accessibility Trees hängt direkt von der Qualität des HTML-Codes ab. Semantische HTML-Elemente wie Screenreader-Nutzer navigieren grundlegend anders als sehende Nutzer: Sie springen per Tastaturkürzel zwischen Überschriften (H-Taste), Landmarks, Links (K-Taste), Formularen (F-Taste) und Listen. Eine Website, die keine semantischen Überschriften, keine Landmarks und keine beschrifteten Formularfelder hat, ist für diese Navigationsmuster unbenutzbar., , , , und erstellen automatisch die richtigen Rollen. Ein hat automatisch die Rolle button und ist per Tastatur bedienbar, während ein
ARIA Landmarks: Orientierung auf der Seite
ARIA Landmarks definieren die Hauptbereiche einer Webseite und ermöglichen es Screenreader-Nutzern, direkt zu einem bestimmten Bereich zu navigieren. Die wichtigsten Landmarks sind banner (Header), navigation (Navigationsleisten), main (Hauptinhalt), complementary (Seitenleiste), contentinfo (Footer) und search (Suchbereich). Jede Seite sollte genau ein main-Landmark, ein banner-Landmark und ein contentinfo-Landmark haben.
Semantische HTML5-Elemente erstellen diese Landmarks automatisch: banner, zu navigation, zu main, zu complementary und zu contentinfo. Wenn eine Seite mehrere Navigationen enthält, etwa Hauptnavigation und Footer-Navigation, sollte jede per aria-label benannt werden, damit Screenreader-Nutzer sie unterscheiden können.
Ein häufiger Fehler ist das Fehlen des -Elements. Ohne dieses Landmark können Screenreader-Nutzer nicht direkt zum Hauptinhalt springen und müssen bei jedem Seitenaufruf die gesamte Navigation durchlaufen. Das -Element sollte den gesamten seitenspezifischen Inhalt umschließen, aber nicht Header, Footer und Navigation enthalten. Die korrekte Landmark-Struktur ist die Grundlage jeder barrierefreien Webentwicklung.
Überschriftenhierarchie: Die Gliederung der Seite
Die Überschriftenhierarchie ist für Screenreader-Nutzer das wichtigste Navigationswerkzeug. Screenreader-Nutzer können per Tastendruck zwischen allen Überschriften der Seite springen und erhalten so einen schnellen Überblick über die Seitenstruktur. Laut einer Umfrage von WebAIM (2024) nutzen 67,5% (WebAIM, 2024) aller Screenreader-Nutzer Überschriften als primäre Navigationsmethode.
Die Hierarchie muss logisch aufgebaut sein: Jede Seite hat genau ein -Element als Hauptüberschrift. Darunter folgen -Elemente für die Hauptabschnitte, für Unterabschnitte und so weiter. Keine Ebene darf übersprungen werden. Ein darf nicht direkt auf ein folgen, ohne ein dazwischenliegendes . Diese Regel wird häufig verletzt, wenn Überschriftenebenen aus visuellen Gründen gewählt werden statt aus strukturellen.
In der Praxis bedeutet das: Die visuelle Gestaltung der Überschriften wird über CSS gesteuert, nicht über die HTML-Ebene. Wenn eine visuell kleiner aussehen soll als eine , wird das mit CSS-Klassen gelöst. Die HTML-Ebene bleibt strikt an der logischen Dokumentstruktur orientiert. Automatisierte Prüfwerkzeuge prüfen die Überschriftenhierarchie, aber nur ein manueller Test zeigt, ob die Hierarchie auch inhaltlich sinnvoll ist.
ARIA Roles, States und Properties
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) erweitert HTML um Attribute, die assistiven Technologien zusätzliche Informationen über die Rolle, den Zustand und die Eigenschaften von Elementen mitteilen. Die wichtigste Regel bei der Verwendung von ARIA lautet: Natives HTML zuerst. Ein -Element ist immer besser als ein
Die häufigsten ARIA-Attribute in der Praxis sind aria-label für nicht sichtbare Beschriftungen, aria-describedby für zusätzliche Beschreibungen, aria-expanded für aufklappbare Elemente, aria-hidden="true" zum Ausblenden dekorativer Elemente, aria-current für die aktuelle Seite in der Navigation und aria-live für dynamische Inhalte. Jedes dieser Attribute hat einen spezifischen Einsatzzweck und sollte nicht pauschal verwendet werden.
Ein häufiger Fehler ist übermäßiges ARIA: Elemente erhalten Rollen und Attribute, die natives HTML bereits bereitstellt. Das kann zu Konflikten führen, wenn der Screenreader widersprüchliche Informationen erhält. Die zweite Regel von ARIA lautet: Ändere nicht die Semantik eines Elements, wenn es nicht nötig ist. Ein braucht kein role="link", da es diese Rolle bereits hat.
Landmarks und Regionen
banner, navigation, main, complementary, contentinfo, search. Semantische HTML5-Elemente erzeugen diese automatisch.
Überschriftenhierarchie
h1 bis h6 in logischer Reihenfolge. 67,5% (WebAIM, 2024) aller Screenreader-Nutzer navigieren primär über Überschriften.
Live Regions
aria-live=polite für Updates, assertive für dringende Meldungen. Dynamische Inhalte ohne Neuladen ankündigen.
Alt-Texte für Bilder
Informative Bilder mit beschreibendem Alt-Text. Dekorative Bilder mit alt="". 55% (WebAIM, 2024) aller Websites versagen hier.
Aussagekräftige Links
Linktext beschreibt das Ziel. Kein generisches Hier klicken. Bei Icons: aria-label oder visually-hidden Text.
Zugängliche Tabellen
caption, th mit scope, summary. Layouttabellen mit role=presentation. Komplexe Tabellen mit headers/id.
Live Regions: Dynamische Inhalte ankündigen
Moderne Webseiten aktualisieren Inhalte häufig ohne vollständigen Seitenneuladen: Ein Warenkorb-Counter ändert sich, eine Fehlermeldung erscheint, ein Chat-Fenster zeigt eine neue Nachricht. Screenreader-Nutzer bekommen diese Änderungen nicht mit, wenn sie nicht explizit angekündigt werden. ARIA Live Regions lösen dieses Problem, indem sie den Screenreader auffordern, Änderungen in einem bestimmten DOM-Bereich automatisch vorzulesen.
Das Attribut aria-live="polite" wartet, bis der Screenreader die aktuelle Ausgabe beendet hat, und liest dann die Änderung vor. Das ist der richtige Modus für die meisten Updates: Statusmeldungen, Formularvalidierung, Suchvorschläge und Warenkorb-Updates. aria-live="assertive" unterbricht die aktuelle Ausgabe sofort und sollte nur für kritische Meldungen wie Fehlerzustände oder Zeitüberschreitungen verwendet werden.
Die Implementierung erfordert Sorgfalt: Die Live Region muss bereits im DOM existieren, bevor der Inhalt geändert wird. Wenn ein Container erst bei der Änderung erstellt und mit aria-live versehen wird, wird die Änderung nicht angekündigt. Der Container wird einmalig ins DOM eingefügt (kann leer sein), und Inhaltsänderungen werden dann automatisch vorgelesen. Bei Single-Page-Applications ist das Seitennavigation-Update ein typischer Anwendungsfall für eine Live Region.
Alt-Texte: Bilder in Worte fassen
Das alt-Attribut für Bilder ist das bekannteste Barrierefreiheitsmerkmal und gleichzeitig das am häufigsten fehlende. Der WebAIM Million Report (2024) stellt fest, dass 55,4% (WebAIM, 2024) aller getesteten Websites fehlende oder unzureichende Alt-Texte aufweisen. Für Screenreader-Nutzer bedeutet ein fehlendes alt-Attribut, dass der Screenreader den Dateinamen vorliest, was oft kryptisch und nutzlos ist.
Die Qualität des Alt-Texts hängt vom Kontext ab. Ein Produktbild im Online-Shop benötigt einen beschreibenden Alt-Text wie Rote Laufschuhe, Seitenansicht. Ein dekoratives Hintergrundbild benötigt ein leeres alt="", damit der Screenreader es überspringt. Ein Bild in einem Artikel, das eine Grafik oder ein Diagramm zeigt, benötigt einen ausführlichen Alt-Text, der die dargestellte Information in Worte fasst.
Für komplexe Bilder wie Infografiken oder Diagramme reicht das alt-Attribut oft nicht aus. Hier bietet sich aria-describedby an, das auf einen Textblock verweist, der die detaillierte Beschreibung enthält. Alternativ kann ein
Formulare für Screenreader zugänglich machen
Formulare sind für Screenreader-Nutzer besonders herausfordernd. Screenreader wechseln beim Betreten eines Formularfeldes in den Formularmodus, in dem reguläre Navigationskürzel deaktiviert sind. In diesem Modus verlässt sich der Nutzer vollständig auf die programmatische Beschriftung der Felder. Jedes Feld muss ein verknüpftes -Element haben. Gruppierungen wie Anrede (Herr/Frau) benötigen ein mit .
Fehlermeldungen müssen über aria-describedby mit dem betroffenen Feld verknüpft sein, sodass der Screenreader beim Fokussieren des Feldes automatisch die Fehlermeldung vorliest. Pflichtfelder werden mit aria-required="true" oder dem nativen required-Attribut markiert. Der Fehlerstatus wird über aria-invalid="true" kommuniziert. Nach dem Absenden des Formulars muss der Fokus auf die Fehlerzusammenfassung oder das erste fehlerhafte Feld gesetzt werden.
Custom-Widgets wie Datepicker, Autocomplete-Felder und mehrstufige Auswahlen erfordern eine vollständige ARIA-Implementierung. Ein Datepicker benötigt role="dialog", aria-label für die Monatsansicht, Tastaturnavigation mit Pfeiltasten und Escape zum Schließen. Die Komplexität dieser Implementierungen ist ein Hauptgrund, warum die Verwendung nativer HTML-Elemente, wo immer möglich, die bessere Wahl ist.
Mit verschiedenen Screenreadern testen
Screenreader-Tests sind ein unverzichtbarer Teil des WCAG-Audits. Relevant sind die in Windows, macOS, iOS und Android verfügbaren Screenreader -- vom kostenlos verfügbaren Windows-Screenreader über die in macOS und iOS integrierte Vorlesefunktion bis zum kommerziellen Windows-Marktführer. Laut der WebAIM Screen Reader User Survey (2024) entfallen rund 40,5% (WebAIM, 2024) auf den kommerziellen Windows-Screenreader, 37,7% (WebAIM, 2024) auf den kostenlosen Windows-Screenreader und 12,0% (WebAIM, 2024) auf den macOS/iOS-Screenreader als primäres Werkzeug.
Ein systematischer Screenreader-Test umfasst die vollständige Navigation durch die Seite per Tastatur, das Prüfen aller Landmarks und Überschriften per Screenreader-Shortcut, das Durchlaufen aller Formulare im Formularmodus, das Testen dynamischer Inhalte und Live Regions, die Überprüfung aller Bilder und Medieninhalte auf Alt-Texte und die Validierung der Lesereihenfolge.
Jeder Screenreader verhält sich etwas anders: Die Windows-Screenreader nutzen einen virtuellen Cursor im Browse-Modus, der macOS-Screenreader verwendet einen Rotor zur strukturellen Navigation. Was unter Windows korrekt vorgelesen wird, kann unter macOS anders klingen oder fehlen. Deshalb empfehlen wir Tests mit mindestens zwei verschiedenen Screenreadern. Die Kombination aus einem Windows-Screenreader und dem macOS-Screenreader deckt den Großteil der Nutzer ab.
Häufige Screenreader-Probleme und ihre Lösung
Laut der WebAIM Million-Studie (2024) weisen 96,3 Prozent (WebAIM, 2024) der untersuchten Homepages mindestens einen automatisch erkennbaren WCAG-Fehler auf, der Screenreader-Nutzer betrifft. Die fünf häufigsten Probleme sind: fehlende Alternativtexte bei Bildern, fehlende Labels bei Formularfeldern, leere Links, fehlende Dokumentsprache und niedriger Farbkontrast. Während der Kontrast primär sehbehinderte Nutzer betrifft, beeinträchtigen die anderen vier Fehler die Screenreader-Erfahrung direkt und gravierend.
Das häufigste Problem ist der fehlende Zusammenhang zwischen visueller Darstellung und semantischer Struktur. Ein visuelles Kartendesign mit Bild, Überschrift und Link wird oft als Serie von nicht verknüpften Elementen vorgelesen, statt als zusammenhängender Inhalt. Die Lösung: Das gesamte Karten-Element als oder implementieren, sodass der Screenreader den Zusammenhang erkennt.
Ein weiteres häufiges Problem sind modale Dialoge, die den Fokus nicht einfangen. Wenn ein Modal geöffnet wird, aber der Screenreader-Nutzer weiterhin die dahinterliegende Seite erreichen kann, entsteht Verwirrung. Modale Dialoge benötigen role="dialog", aria-modal="true", aria-label oder aria-labelledby, einen Fokustrap, der den Fokus innerhalb des Modals hält, und die Rückkehr zum auslösenden Element beim Schließen.
Icon-Buttons ohne Textbeschriftung sind ein drittes Standardproblem. Ein Schließen-Button, der nur ein X-Symbol zeigt, ein Hamburger-Menü-Button ohne Text und Social-Media-Links mit nur einem Logo sind für Screenreader-Nutzer nicht identifizierbar. Die Lösung: aria-label für den Button oder ein visuell versteckter Text mit der CSS-Klasse .sr-only (oder .visually-hidden), der den Zweck des Elements beschreibt.