Screenreader-Kompatibilität bedeutet, dass Inhalt, Steuerelemente und Struktur einer Website vollständig von jemandem verstanden und bedient werden können, der assistive Technologie nutzt, die die Seite laut vorliest oder auf einer Braillezeile ausgibt, statt sie anzusehen. Das hängt weit mehr davon ab, wie das zugrunde liegende HTML geschrieben ist, als von irgendeinem einzelnen Feature oder Plugin. Es richtig zu machen bedeutet, semantische Struktur, Lesereihenfolge, Beschriftung und Tastaturbedienbarkeit gemeinsam im Blick zu haben, nicht nur einzeln.

Wie ein Screenreader eine Seite tatsächlich erlebt

Ein Screenreader sieht das Layout nicht so, wie ein sehender Nutzer es tut. Er baut sein eigenes Modell der Seite aus der semantischen Struktur des HTML: Überschriften, Landmarken (wie <nav>, <main>, <footer>), Listen, Formularlabels, Linktext und die Reihenfolge, in der Elemente im DOM erscheinen. Ein Nutzer kann zwischen Überschriften springen, alle Links einer Seite auflisten oder zum nächsten Formularfeld springen, ganz ohne den Bildschirm visuell abscannen zu müssen. Wenn eine Website mit bedeutungslosem <div>-Wirrwarr gebaut ist, Überschriften nur zur visuellen Gestaltung statt zur tatsächlichen Dokumentstruktur genutzt werden, oder Inhalte per CSS visuell in einer Reihenfolge angeordnet sind, die nicht der zugrunde liegenden DOM-Reihenfolge entspricht, bricht dieses gesamte Navigationsmodell zusammen, selbst wenn die Seite für einen sehenden Besucher völlig normal aussieht.

Die Gewohnheiten, die über Kompatibilität entscheiden

Eine Handvoll Gewohnheiten auf Code-Ebene verursacht die meisten realen Screenreader-Probleme. Aussagekräftiger Alt-Text bei Bildern, die Informationen vermitteln (und leerer Alt-Text bei rein dekorativen Bildern), ist der häufigste Fehler und auf der überwiegenden Mehrheit der Seiten zu finden: Die WebAIM-Million-Studie 2026 fand heraus, dass 83,9 % der Startseiten kontrastarmen Text als häufigsten Fehler hatten, dicht gefolgt von fehlendem oder schlechtem Alternativtext und unbeschrifteten Formularfeldern. Über den Alt-Text hinaus sind die weiteren wichtigsten Gewohnheiten: eine logische Überschriftenstruktur ohne übersprungene Ebenen, Formularfelder mit programmatisch verknüpften Labels statt nur Platzhaltertext, eine sichtbare und logische Fokusreihenfolge beim Durchtabben der Seite, und beschreibender Linktext (“lesen Sie unseren EAA-Konformitätsleitfaden” statt “hier klicken”).

Wo ARIA passt und wo nicht

ARIA-Attribute (Accessible Rich Internet Applications) existieren, um individuelle interaktive Komponenten zu beschreiben, etwa ein Tab-Panel oder eine Combobox, für die natives HTML kein eingebautes Element hat. Die wichtigste Regel ist, zuerst natives HTML zu verwenden: Ein echtes <button>-Element behandelt Tastaturaktivierung, Fokus und Rollenansage bereits korrekt, während ein gestyltes <div> mit Klick-Handler all das manuell mit ARIA und JavaScript nachbauen muss, wobei sich leicht subtile Fehler einschleichen. Falsch eingesetztes ARIA, etwa eine Rolle, die nicht zum tatsächlichen Verhalten des Elements passt, ist eine gut dokumentierte Quelle für Screenreader-Verwirrung; es kann ein Element falsch ansagen oder es per Tastatur vollständig unerreichbar machen, was für den Nutzer oft schlimmer ist, als wenn gar kein ARIA hinzugefügt worden wäre.

Die eigene Website testen

Automatisierte Tools sind ein vernünftiger erster Durchgang. Etwas, das auf der weit verbreiteten axe-core-Engine aufbaut, wie Deques axe DevTools, erfasst schnell eine bedeutsame Menge struktureller und Beschriftungsprobleme und lässt sich in den bestehenden Workflow eines Entwicklers einbinden. Aber automatisierte Scans erfassen im Allgemeinen nur einen Teil dessen, was für einen echten Nutzer assistiver Technologie tatsächlich zählt; Dinge wie ob eine Lesereihenfolge laut vorgelesen logisch Sinn ergibt, oder ob eine Fehlermeldung bei einem fehlgeschlagenen Formularversand tatsächlich angesagt wird, erfordern, dass jemand die Seite tatsächlich mit laufendem Screenreader nutzt. Speziell für WordPress-Websites konzentriert sich WebYes darauf, solche Probleme auf Code-Ebene direkt zu identifizieren und zu beheben, statt sie mit einem Overlay zu überdecken, was ein vernünftiger Ansatz ist, wenn Ihr Team bereit ist, die zugrunde liegenden Vorlagen- und Theme-Änderungen selbst vorzunehmen.

Was Accessibility-Widgets hier können und nicht können

Widgets und Overlay-Tools, einschließlich solcher mit KI-gestützten Funktionen wie Wawsomes automatisierter Alt-Text-Erstellung und ARIA-Beschriftung, können wirklich helfen, manche Lücken zu schließen, besonders bei Websites, bei denen eine Korrektur des zugrunde liegenden Codes kurzfristig unrealistisch ist. Was sie im Allgemeinen nicht können, ist, die grundlegende DOM-Reihenfolge einer Seite umzustrukturieren, fehlerhafte Formularverknüpfungen über alle Vorlagen einer Website hinweg umzuschreiben, oder zu garantieren, dass jedes individuelle interaktive Widget mit einem Screenreader korrekt funktioniert. Unabhängige Umfragen unter Accessibility-Fachleuten haben durchgängig echte Skepsis darüber gefunden, wie weit automatisierte Overlay-Korrekturen tatsächlich reichen; eine WebAIM-nahe Umfrage ergab, dass 67 % der Fachleute Overlays als “gar nicht” oder “nicht sehr” wirksam einstuften, ein Wert, der bei Befragten mit eigener Behinderung auf 72 % stieg. Die realistische Erkenntnis ist, dass ein Widget eine Ebene einer Kompatibilitätsstrategie sein kann, echte Screenreader-Kompatibilität aber letztlich von den Code-Entscheidungen abhängt, die beim Bau der Website getroffen wurden.

Dynamische Inhalte und Single-Page-Anwendungen

Moderne Websites, die Inhalte ohne vollständiges Neuladen der Seite aktualisieren, etwa eine gefilterte Produktliste, eine live aktualisierte Warenkorbsumme oder eine eingebettete Validierungsmeldung eines Formulars, brauchen einen konkreten Mechanismus, um assistiven Technologien mitzuteilen, dass sich etwas geändert hat, da ein Screenreader eine stille DOM-Aktualisierung von sich aus nicht bemerkt. ARIA-Live-Regionen übernehmen das: Einen Container mit aria-live="polite" (oder bei dringenden Meldungen wie einem Fehler mit aria-live="assertive") zu markieren, weist den Screenreader an, neue Inhalte anzusagen, sobald sie erscheinen. Das ist eines der auf modernen JavaScript-lastigen Websites am häufigsten übersehenen Muster, da eine Änderung für einen sehenden Nutzer, der auf den Bildschirm schaut, vollständig und offensichtlich wirken kann, während sie für jemanden, der über einen Screenreader zuhört, komplett unbemerkt bleibt.

Mobile Screenreader

Auf mobilen Geräten gelten dieselben Grundsätze, aber die Werkzeuge unterscheiden sich: VoiceOver auf iOS und TalkBack auf Android sind gestengesteuert statt tastaturgesteuert, mit Wischgesten zum Wechseln zwischen Elementen und Tippen zum Aktivieren. Eine Website, die mit einem Desktop-Screenreader getestet wurde, ist damit nicht automatisch auch mobil verifiziert, da Touch-Zielgröße, Gestenkonflikte mit individuellen Wischinteraktionen (wie einem Bildkarussell) und mobilspezifische Layoutänderungen jeweils Probleme verursachen können, die bei einem Desktop-Durchgang nicht auffallen. Wenn ein bedeutender Teil Ihres Traffics mobil ist, was für die meisten E-Commerce- und Verbraucherwebsites heute zutrifft, verdient ein mobiler Screenreader-Durchgang eigene, dedizierte Testzeit, statt als Nachgedanke zum Desktop-Test behandelt zu werden.

Eine grundlegende Testroutine zum Einstieg

Schalten Sie NVDA (kostenlos) oder VoiceOver (in jedem Mac und iPhone integriert) ein, navigieren Sie Ihre Startseite und eine wichtige Conversion-Seite (etwa ein Checkout- oder Kontaktformular) ausschließlich mit Tastatur und den eigenen Navigationsbefehlen des Screenreaders, und notieren Sie sich jede Stelle, an der Sie hängen bleiben, nichts angesagt bekommen oder etwas hören, das keinen Sinn ergibt. Diese dreißigminütige Übung, wiederholt nach jeder größeren Änderung an der Website, fördert mehr echte Probleme zutage als die meisten automatisierten Scans allein.

Es lohnt sich außerdem, das in Ihren Release-Prozess einzubauen, statt es als einmalige Übung zu behandeln. Eine Design- oder Vorlagenänderung, die visuell in Ordnung aussieht, kann heimlich die Überschriftenstruktur, die Fokusreihenfolge oder eine Live-Region-Ansage kaputtmachen, und solche Regressionen sind vor einem Deploy weit günstiger zu erkennen als danach, wenn echte Nutzer darauf stoßen. Selbst eine schlanke Version davon, eine Person, die zwanzig Minuten mit einem Screenreader auf den geänderten Seiten verbringt, konsequent vor jedem Release angewendet, erfasst einen bedeutsamen Teil der Regressionen, die sich sonst unbemerkt anhäufen würden.