Screenreader-Vorschau

Eine kurze Geschichte der Standards für Web-Barrierefreiheit

Barrierefreiheit im Web wird durch einen kleinen Stapel von Standards der W3C Web Accessibility Initiative (WAI) sowie nationale Gesetze, die darauf verweisen, geregelt. WCAG 1.0 wurde im Mai 1999 veröffentlicht, der erste formale Leitfaden, um Webinhalte barrierefrei zu machen. Er war weitgehend HTML-zentriert und wurde schnell veraltet. WCAG 2.0 (Dezember 2008) war eine umfassende Neufassung, die um vier Prinzipien (Wahrnehmbar, Bedienbar, Verständlich, Robust) und drei Konformitätsstufen (A, AA, AAA) herum organisiert war. Er wurde 2012 zu einer ISO-Norm (ISO/IEC 40500) und ist das Konformitätsziel, auf das die meisten Gesetze noch verweisen. WCAG 2.1 (Juni 2018) fügte 17 neue Erfolgskriterien hinzu, die Mobilität, Sehschwäche und kognitive Behinderungen abdecken. WCAG 2.2 (Oktober 2023) fügte 9 weitere hinzu, insbesondere 2.4.11 Fokus nicht verdeckt und 3.3.8 Barrierefreie Authentifizierung. WAI-ARIA 1.0 wurde im März 2014 finalisiert; 1.2 im Juni 2023 ist die aktuelle Empfehlung. Rechtlich gesehen integrierte die US-Section 508 Refresh (Januar 2018) WCAG 2.0 AA in die US-Bundesbeschaffung. Das Europäische Barrierefreiheitsgesetz (Richtlinie 2019/882) trat am 28. Juni 2025 in Kraft und verlangt, dass die meisten verbraucherorientierten digitalen Produkte in der EU den Barrierefreiheitsstandards entsprechen. Die meisten Länder verweisen auf WCAG, daher ist der Aufbau nach WCAG 2.2 AA das praktische Ziel für jedes globale Produkt heute.

Die Screenreader-Landschaft heute

Die WebAIM Screen Reader User Survey #10 (2024) ist die kanonische Quelle dafür, welche Screenreader Menschen tatsächlich verwenden. Fünf Produkte dominieren Desktop, Mobile und ChromeOS.

• JAWS (Freedom Scientific, erste Veröffentlichung 1989) ist der langjährige kommerzielle Marktführer unter Windows. Kostet ~$1000+. WebAIM 2024 findet ihn als primären Screenreader für etwa 40% der Umfrageteilnehmer, knapp unter NVDA.
• NVDA (NV Access, erste Veröffentlichung 2006, in Python geschrieben) ist die Open-Source-Alternative für Windows. Kostenlos. WebAIM 2024 berichtet ihn als den am häufigsten verwendeten primären Screenreader, etwa 47% der Befragten. NVDAs Aufstieg von einem Nischentool zum Marktführer in 15 Jahren ist eine der großen Open-Source-Erfolgsgeschichten in der assistiven Technologie.
• VoiceOver (Apple, 2005 auf macOS, 2009 auf iOS) ist auf jedem Mac, iPhone, iPad, Apple Watch, Apple TV vorinstalliert. Es ist der am häufigsten verwendete mobile Screenreader. Eng integriert mit Safari und dem iOS-Rotor für die Navigation.
• TalkBack (Google, 2009 auf Android) ist das Android-Pendant. Open-Source seit Android 4. Verwendet Gesten und das Navigationsmenü.
• ChromeVox (Google, 2012) und Narrator (Microsoft, 2000, modernisiert in Windows 10) runden das Bild ab. Jeder hat eine kleine, aber treue Nutzerbasis.

Eine einzelne Seite kann von jedem Produkt unterschiedlich angekündigt werden. Robuste Seiten testen sauber in mindestens zwei: meist NVDA + Firefox oder Chrome und VoiceOver + Safari.

Wann man zu diesem Werkzeug greifen sollte

• Vor-Launch-Audits. Füge eine wichtige Seite ein (Startseite, Anmeldeformular, Checkout) und lies die linearisierte Ausgabe laut vor. Wenn sie für dich keinen Sinn ergibt, wird sie auch keinen Sinn für einen Screenreader-Benutzer ergeben.
• Code-Reviews. Bevor du einen PR mit erheblichen Markup-Änderungen zusammenführst, füge das gerenderte HTML ein und bestätige, dass Überschriften, Landmarken und Alt-Text intakt sind.
• Design-Übergabe-Verifizierung. Designer können ihr finales HTML einfügen, um zu bestätigen, dass die visuelle Hierarchie mit der semantischen Hierarchie übereinstimmt. Eine Seite, die wie eine Überschrift aussieht, sollte auch eine im DOM sein.
• Barrierefreiheit lehren. Zeige einer Klasse oder einem Team, was ein Screenreader tatsächlich empfängt. Die Kluft zwischen visuellem Layout und linearisierter Ausgabe ist oft das erste Mal, dass nicht behinderte Entwickler verstehen, warum semantisches HTML wichtig ist.
• Konformitätsprüfungen gegen WCAG. Schnelle Stichproben für die vier am häufigsten verletzten Kriterien: 1.1.1 Nicht-Text-Inhalt (Alt-Text), 1.3.1 Informationen und Beziehungen (semantische Struktur), 2.4.4 Linkzweck, 4.1.2 Name, Rolle, Wert.
• CMS- / No-Code-Site-Prüfungen. Visuelle Editoren produzieren oft Divs statt Überschriften oder Links ohne Text. Füge das veröffentlichte HTML ein, sieh, was durchgerutscht ist.
• Barrierefreiheit von E-Mail-Vorlagen. HTML-E-Mails sind notorisch schwer barrierefrei zu machen. Verwende die Vorschau, um Alt-Text auf jedem Bild, eine ordnungsgemäße Überschriftsreihenfolge und einen lesbaren Lesefluss zu überprüfen.

Häufige Fehler, die Screenreader aufdecken

• Fehlender oder nutzloser Alt-Text. alt="image", alt="photo", alt="logo" sind kaum besser als nichts. Lazar et al. (2007) identifizierten fehlenden Alt-Text als die Top-Frustration blinder Web-Nutzer. Schreibe Alt-Text, der den Zweck des Bildes im umliegenden Kontext vermittelt, oder verwende alt="" für rein dekorative Bilder, damit der Screenreader sie überspringt.
• Überschriftsebenen, die überspringen oder neu beginnen. Von h1 auf h3 zu gehen und h2 zu überspringen, verwirrt die Navigation. Die Verwendung mehrerer h1-Elemente auf derselben Seite (ein ziemlich häufiges Muster im komponentengetriebenen Design) bricht die Dokumentgliederung, anhand derer Screenreader-Benutzer navigieren. WebAIM 2024 stellt fest, dass Überschriften die häufigste Navigationsstrategie für Screenreader-Benutzer sind.
• Divitis. Klickbaren Text in <div> mit einem Klick-Handler zu verpacken, anstatt <button> oder <a> zu verwenden, bedeutet keine Tastaturunterstützung, keinen Fokusring, keine Rollenankündigung. Beginne immer mit semantischem HTML und füge ARIA nur hinzu, wenn kein natives Element passt.
• ARIA verwendet, wo HTML reichen würde. Erste Regel von ARIA (gemäß den W3C WAI-ARIA Authoring Practices): «Wenn du ein natives HTML-Element verwenden kannst... tu es». <button role="button"> ist redundant; <div role="button"> ist ein Zeichen, dass du stattdessen einen echten Button verwenden solltest.
• ARIA falsch verwendet. aria-hidden="true" auf einem fokussierbaren Element macht es für Screenreader unsichtbar, aber immer noch tastaturfokussierbar, ein Rezept für eine desorientierende Tab-Reihenfolge. role="button" ohne tabindex="0" und Tastatur-Handler tut nichts Nützliches.
• Formularfelder ohne Labels. Ein <input> ohne ein zugehöriges <label>, aria-label oder aria-labelledby wird als «edit, blank» ohne Kontext angekündigt. Platzhaltertext ist kein Ersatz, er verschwindet beim Fokussieren und versagt oft beim Kontrast.
• «Klick hier»- und «Mehr lesen»-Links. Screenreader-Benutzer navigieren oft, indem sie die Liste aller Links auf der Seite aufrufen. «Klick hier» allein sagt ihnen nichts. Gestalte den Linktext so, dass er das Ziel beschreibt: «Lies die WebAIM-Umfrage 2024» schlägt «Mehr lesen hier».
• Fokusstile entfernen. outline: none ohne einen Ersatz-Fokusindikator ist eines der am häufigsten verletzten WCAG-Kriterien (2.4.7 Fokus sichtbar). Tastaturbenutzer, einschließlich vieler Screenreader-Benutzer, müssen sehen, wo der Fokus ist.

ARIA auf einen Blick: was jede Art von Rolle tut

• Landmark-Rollen (banner, navigation, main, complementary, contentinfo, search) teilen die Seite in Regionen, zwischen denen ein Screenreader-Benutzer springen kann. Die meisten haben native HTML-Äquivalente (<header>, <nav>, <main>, <aside>, <footer>). Verwende zuerst das native Element.
• Widget-Rollen (button, checkbox, combobox, menu, tabpanel usw.) beschreiben interaktive Steuerelemente. Widget-Rollen implizieren Tastatur-Interaktionsmuster, die der W3C ARIA Authoring Practices Guide (APG) im Detail dokumentiert. Wenn du die APG-Spezifikation nicht genau abgleichen kannst, bevorzuge natives HTML.
• Dokumentstruktur-Rollen (article, list, listitem, row, cell usw.) beschreiben nicht-interaktive Inhalte. Die meisten haben auch native HTML-Äquivalente. Verwende sie nur, wenn das native Element nicht verfügbar ist (z. B. beim Erstellen eines benutzerdefinierten Datengitters, bei dem <table> nicht passt).
• Live-Regionen (aria-live="polite", aria-live="assertive", role="status", role="alert") sagen Screenreadern, dass sie dynamische Updates ankündigen sollen, ohne den Fokus zu verschieben. Wird für Chat-Nachrichten, Formularfehler, Ladezustände verwendet. Übermäßiger Gebrauch verursacht Benachrichtigungsmüdigkeit; reserviere assertive für echte Notfälle wie Fehlerzustände.

Weitere häufig gestellte Fragen

Passt diese Vorschau dazu, was NVDA / JAWS / VoiceOver tatsächlich sagen werden?

Sie nähert sich an. Dieses Werkzeug liest den Accessibility-Tree des Browsers (dieselbe Struktur, die Screenreader verwenden) und produziert eine linearisierte Version dessen, was angekündigt würde. Echte Screenreader fügen produktspezifische Verhaltensweisen hinzu: Ankündigungen von Fokuswechseln, Tabellennavigation, Tabellenüberschriften, Listenelementzählungen, ARIA-Live-Höflichkeitshandhabung, benutzerdefinierte Verbositäts-Einstellungen. Behandle die Vorschau als ersten Vernunftscheck; für Produktionsveröffentlichungen teste mit mindestens einem echten Screenreader auf den Betriebssystemen, die dein Publikum verwendet.

Was ist der Unterschied zwischen WCAG und ARIA?

WCAG (Web Content Accessibility Guidelines) ist eine Liste von Anforderungen: «jeder Nicht-Text-Inhalt muss eine Textalternative haben». Es sagt dir was zu erreichen ist, aber nicht immer wie. ARIA (Accessible Rich Internet Applications) ist eines der Werkzeuge, um WCAG zu erfüllen: ein Satz von HTML-Attributen (Rollen, Zustände, Eigenschaften), die der assistiven Technologie Semantik offenlegen, wenn natives HTML unzureichend ist. Du kannst WCAG ganz ohne ARIA erfüllen, wenn dein HTML ausreichend semantisch ist. ARIA ist für die Fälle, in denen es das nicht ist.

Wie schreibe ich guten Alt-Text?

Drei Regeln aus dem W3C An alt Decision Tree: (1) Wenn das Bild rein dekorativ ist, verwende alt="", damit der Screenreader es vollständig überspringt. (2) Wenn das Bild Informationen vermittelt, die nicht bereits im umliegenden Text enthalten sind, beschreibe diese Informationen prägnant (typischerweise unter 125 Zeichen). (3) Wenn das Bild funktional ist (z. B. ein Logo, das auf die Startseite verlinkt, oder ein Icon-Button), beschreibe die Aktion statt das Aussehen. «Suchen» schlägt «Lupensymbol». Vermeide «Bild von...», «Foto von...», Screenreader kündigen bereits an, dass das Element ein Bild ist.

Meine Seite verwendet Divs überall. Wo soll ich anfangen?

Beginne damit, die fünf Landmark-Elemente hinzuzufügen: <header>, <nav>, <main>, <aside>, <footer>. Ersetze dann klickbare Divs durch <button> (für Aktionen) oder <a> (für Navigation). Dann auditiere Überschriften: jede Seite sollte ein <h1> haben und der Rest in verschachtelter Reihenfolge. Diese drei Schritte beheben vielleicht 70% der Barrierefreiheitsprobleme auf einer typischen div-lastigen Seite. ARIA und JavaScript-Fokusmanagement kommen danach, sobald die semantische Grundlage steht.

Wird das HTML, das ich hier einfüge, irgendwohin gesendet?

Nein. Das Parsing verwendet den eingebauten DOMParser des Browsers und die Analyse läuft vollständig clientseitig. Öffne den Netzwerk-Tab in DevTools und klicke auf Analysieren, du wirst null ausgehende Anfragen während der Linearisierung sehen. Sicher für interne Vorlagen, unveröffentlichte Seiten oder HTML, das Kundendaten enthält.