Assistive Technologien, Tastatur, Kontraste, Semantik/ARIA und Formulare.
Assistive Technologien und Screenreader
Begriffe vorab
Braillezeile: ein Gerät, das Bildschirmtext in tastbarer Brailleschrift ausgibt.
Bildschirmlupe: vergrößert Bildschirmbereiche.
Sprachsteuerung: Bedienung per gesprochenen Befehlen.
Rotor / Elementliste: Screenreader-Funktion, die Überschriften, Links oder Formularfelder auflistet.
Assistive Technologien sind Hilfsmittel, die Menschen mit Behinderungen die Nutzung digitaler Inhalte ermöglichen. Wer für Barrierefreiheit entwickelt, sollte die wichtigsten Werkzeuge zumindest einmal ausprobiert haben.
Screenreader
Screenreader lesen Bildschirminhalte vor oder geben sie in Braille-Schrift aus. Verbreitete Programme:
JAWS – kommerziell, Windows, in Unternehmen und Behörden verbreitet.
VoiceOver – in macOS und iOS integriert.
TalkBack – in Android integriert.
Der jährliche WebAIM Screen Reader Survey erhebt, welche Programme Nutzerinnen und Nutzer bevorzugen und in Kombination mit welchen Browsern; die Ergebnisse verschieben sich leicht von Jahr zu Jahr, weshalb die aktuelle Erhebung die verlässlichste Quelle ist.
Weitere Hilfsmittel
Vergrößerungssoftware und Betriebssystem-Zoom für Sehbehinderungen.
Schalter- und Augensteuerung für Menschen ohne Feinmotorik in Händen.
Spracheingabe (z. B. Diktierfunktionen) als Alternative zur Tastatur.
Browser-Erweiterungen für Lesehilfen, etwa angepasste Schriftarten oder Vorlesefunktionen.
Wie Screenreader Webseiten „sehen“
Screenreader nutzen nicht das visuelle Layout, sondern den Accessibility Tree, eine aus dem DOM abgeleitete Struktur mit Rollen, Namen und Zuständen jedes Elements. Fehlt einem Button ein zugänglicher Name, meldet der Screenreader nur „Schaltfläche“ ohne weitere Information.
Der beste erste Test: Maus beiseitelegen, Bildschirm ausschalten oder abdecken, und versuchen, die eigene Website allein mit Tastatur und Screenreader zu bedienen. Vieles fällt dabei sofort auf, was am Bildschirm unsichtbar bleibt.
Wie Screenreader-Nutzende navigieren
Sie lesen nicht Zeile für Zeile, sondern springen gezielt: von Überschrift zu Überschrift, von Link zu Link, zu Formularfeldern oder zu Seitenbereichen (Landmarks). Deshalb sind korrekte Überschriftenhierarchie, aussagekräftige Linktexte und Landmarks entscheidend. Ein Link „hier klicken“ sagt in einer Linkliste nichts; „Preisliste herunterladen“ dagegen schon.
Eine Seite aus Sicht eines Screenreaders
Der Screenreader liest: „Schaltfläche“ – ohne Namen, weil ein Icon-Button kein Textlabel hat. Mit einem zugänglichen Namen wie „Warenkorb öffnen“ wird daraus „Warenkorb öffnen, Schaltfläche“. Kleine Ergänzungen entscheiden, ob ein Element nutzbar ist.
Selbst ausprobieren
Den eingebauten Screenreader des Betriebssystems aktivieren (VoiceOver, TalkBack) oder NVDA unter Windows.
Eine eigene Seite mit Tastatur und ausgeschaltetem Bildschirm bedienen.
Auf Stellen achten, an denen nichts oder Unverständliches angesagt wird.
Zum Selbermachen: ein Screenreader-Kurztest
Aktiviere VoiceOver (macOS/iOS) oder TalkBack (Android).
Rufe eine eigene Seite auf und navigiere nur über Überschriften.
Gehe ein Formular durch und achte darauf, ob jedes Feld verständlich benannt ist.
Notiere Stellen, an denen Unverständliches oder nichts angesagt wird.
Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.
Quellen
WebAIM – „Screen Reader User Survey“ (jährliche Erhebung) (allgemeine Referenz, nicht Zeile für Zeile geprüft)
W3C WAI – „Accessible Rich Internet Applications (WAI-ARIA)“, Abschnitt zum Accessibility Tree (allgemeine Referenz, nicht Zeile für Zeile geprüft)
NV Access – Dokumentation zu NVDA; Apple – VoiceOver-Dokumentation (allgemeine Referenz, nicht Zeile für Zeile geprüft)
Tastaturbedienung und Fokus-Management
Begriffe vorab
Fokus: das Element, das gerade per Tastatur bedient werden kann.
Fokusreihenfolge: die Reihenfolge, in der Elemente per Tab angesprungen werden.
Fokus-Falle: ein Bereich, aus dem man per Tastatur nicht herauskommt.
Nicht jede Nutzerin bedient eine Website mit der Maus: Menschen mit motorischen Einschränkungen, Screenreader-Nutzende und Power-User arbeiten häufig ausschließlich mit der Tastatur.
Die Grundregel (WCAG 2.1.1)
Jede Funktion muss über die Tastatur erreichbar sein, meist mit Tab (vorwärts), Umschalt+Tab (rückwärts), Enter/Leertaste (aktivieren) und den Pfeiltasten (innerhalb von Komponenten wie Menüs oder Tabs).
Keine Tastatur-Fallen
WCAG 2.1.2 verlangt, dass der Fokus eine Komponente immer wieder verlassen kann. Ein schlecht gebautes Modal, aus dem Tab nicht mehr herausführt, ist eine klassische Tastatur-Falle.
Sichtbarer Fokus (2.4.7 / 2.4.11)
Der Browser zeigt den Fokus standardmäßig mit einem Umriss (outline) an. Ein verbreiteter, aber problematischer Fehler ist *:focus { outline: none; } ohne Ersatz – damit verschwindet jede Orientierung für Tastaturnutzende. Seit WCAG 2.2 verlangt Kriterium 2.4.11 zusätzlich, dass der Fokusindikator nicht durch andere Inhalte verdeckt wird, etwa durch eine fixierte Kopfzeile.
Logische Reihenfolge
Die Tab-Reihenfolge sollte der visuellen und inhaltlichen Reihenfolge entsprechen (WCAG 2.4.3). Positives tabindex (z. B. tabindex="5") erzwingt eine eigene Reihenfolge und sollte vermieden werden; tabindex="0" reiht ein Element sinnvoll in die natürliche Reihenfolge ein, tabindex="-1" macht es nur programmatisch fokussierbar.
Skip-Links
Ein „Zum Inhalt springen“-Link am Anfang der Seite erlaubt es, die Navigation zu überspringen (WCAG 2.4.1 Bypass Blocks). Er ist oft visuell versteckt und erscheint erst beim Fokussieren.
Schneller Praxistest: gesamte Seite nur mit Tab, Umschalt+Tab und Enter durchgehen. Jede Stelle, an der man nicht mehr weiterkommt oder den Fokus nicht mehr sieht, ist ein Fund.
Ein Beispiel: Dialog richtig bauen
Öffnet sich ein Dialog, muss der Fokus hineinwandern, und Tab darf nur innerhalb des Dialogs wechseln, solange er offen ist. Mit Escape lässt er sich schließen, danach kehrt der Fokus zum auslösenden Element zurück. Fehlt das, verliert man als Tastaturnutzer die Orientierung oder bleibt ungewollt hinter dem Dialog hängen.
Eigene Bedienelemente
Baut man statt eines echten Buttons ein anderes Element nach, muss man Fokussierbarkeit, Enter- und Leertastenbedienung, Rolle und Fokusanzeige selbst ergänzen. Natives HTML bringt all das mit – ein Grund mehr, es zu bevorzugen.
Typische Fehler
Den Fokusrahmen per CSS ohne Ersatz entfernen.
Elemente mit positivem tabindex in eine eigene Reihenfolge zwingen.
Menüs, die nur bei Mausberührung aufklappen.
Fixierte Kopfzeilen, die den fokussierten Inhalt verdecken.
Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.
W3C WAI-ARIA Authoring Practices Guide (APG) – Abschnitt „Keyboard Interface“ (allgemeine Referenz, nicht Zeile für Zeile geprüft)
Farben, Kontraste und Wahrnehmbarkeit
Begriffe vorab
Kontrastverhältnis: Verhältnis der Helligkeiten von Vorder- und Hintergrundfarbe, von 1:1 (kein Kontrast) bis 21:1.
Großer Text: nach WCAG ab etwa 18 pt bzw. 14 pt fett.
Nicht-Text-Kontrast: Mindestkontrast für Bedienelemente und wichtige Grafiken (3:1).
Von angeborener Rot-Grün-Sehschwäche sind in Bevölkerungen nordeuropäischer Herkunft bis zu etwa 8 % der Männer und 0,5 % der Frauen betroffen; in anderen Bevölkerungen sind die Anteile geringer. Kontrast und Farbgestaltung betreffen aber auch Sehbehinderungen allgemein und die Nutzung bei grellem Licht.
Kontrastanforderungen nach WCAG 1.4.3 und 1.4.6
AA, normaler Text: mindestens 4,5:1 Kontrastverhältnis zum Hintergrund.
AA, großer Text (ab ca. 18pt bzw. 14pt fett): mindestens 3:1.
Reiner Dekor-Text und rein dekorative Bilder sind von der Kontrastanforderung ausgenommen.
Farbe niemals als einziges Merkmal (WCAG 1.4.1)
Ein Pflichtfeld nur rot zu umrahmen oder einen Link nur farblich (ohne Unterstreichung oder anderes Merkmal) vom Fließtext abzuheben, schließt Menschen mit Farbfehlsichtigkeit aus. Zusätzliche Merkmale wie Symbole, Text („* Pflichtfeld“) oder Unterstreichung sind nötig.
Kontrast praktisch prüfen
Werkzeuge wie der WebAIM Contrast Checker oder die Kontrastprüfung in Browser-Entwicklertools berechnen aus zwei Farbwerten automatisch das Kontrastverhältnis und zeigen, welche WCAG-Stufe erreicht wird.
Weitere Wahrnehmbarkeits-Kriterien
1.4.4 Textgröße ändern: Text muss sich bis 200 % vergrößern lassen, ohne Inhalt oder Funktion zu verlieren.
1.4.10 Reflow: Inhalte müssen bis 400 % Zoom ohne horizontales Scrollen lesbar bleiben (mit definierten Ausnahmen wie Tabellen und Karten).
1.4.12 Textabstand: Nutzende dürfen Zeilenhöhe und Buchstabenabstand selbst vergrößern können, ohne dass Inhalte abgeschnitten werden.
Farbkontrast wird oft erst spät im Projekt geprüft, wenn das Designsystem schon feststeht. Kontraste gehören in die Farbpalette selbst, nicht nur in eine spätere Korrekturschleife.
Ein Beispiel: Grau auf Weiß
Ein mittleres Grau wie #999999 auf Weiß erreicht nur etwa 2,8:1 und besteht WCAG AA für normalen Text nicht. Ein dunkleres Grau wie #767676 erreicht gerade 4,5:1. Der Unterschied ist für viele Menschen mit normaler Sicht kaum auffällig, für Menschen mit Sehbehinderung oder bei Sonnenlicht aber entscheidend.
Auch Bedienelemente brauchen Kontrast
WCAG 2.1 verlangt zusätzlich mindestens 3:1 für Ränder von Eingabefeldern, Symbole und Zustände wie „ausgewählt“. Ein hellgrauer Feldrand auf weißem Grund kann das Formular unsichtbar machen.
Ein Ablauf für Designsysteme
Kontrast bereits beim Festlegen der Farbpalette prüfen.
Erlaubte Kombinationen dokumentieren (Text auf Hintergrund).
Helle und dunkle Darstellung getrennt prüfen.
Zustände wie Hover, Fokus und deaktiviert mitprüfen.
Zum Selbermachen: Kontraste prüfen
Wähle fünf Farbkombinationen deiner Website (Fließtext, Links, Buttons, Platzhalter, Fehlermeldung).
Prüfe sie mit einem Kontrastrechner.
Notiere, welche unter 4,5:1 (Text) bzw. 3:1 (Bedienelemente) liegen.
Passe die Palette an und teste in hellem und dunklem Modus erneut.
Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind. Die Kontrastwerte der Beispiele (#999999 ≈ 2,85:1, #767676 ≈ 4,54:1 auf Weiß) habe ich nachgerechnet.
WebAIM – „Contrast Checker“ und „Visual Disabilities: Color Blindness“ (allgemeine Referenz, nicht Zeile für Zeile geprüft)
Semantisches HTML und WAI-ARIA
Begriffe vorab
Semantik: Bedeutung von Elementen, nicht nur ihr Aussehen.
Rolle: Art des Elements (Button, Link, Tab).
Zustand: veränderliche Eigenschaft wie „aufgeklappt“.
Zugänglicher Name: der Name, den assistive Technik für ein Element ausgibt.
Die wirkungsvollste Barrierefreiheits-Maßnahme ist oft die unspektakulärste: korrektes, semantisches HTML.
Die erste ARIA-Regel
Der WAI-ARIA Authoring Practices Guide formuliert es als „No ARIA is better than Bad ARIA“ und als erste Regel: Wenn ein natives HTML-Element oder -Attribut mit der benötigten Semantik existiert, sollte es verwendet werden, statt ein generisches Element mit ARIA nachzubauen.
<!-- Gut -->
<button>Absenden</button>
<!-- Unnötig aufwendig und fehleranfällig -->
<div role="button" tabindex="0" onclick="..." onkeydown="...">Absenden</div>
Ein natives <button> ist automatisch per Tastatur fokussierbar und auslösbar und wird von Screenreadern korrekt als Schaltfläche angesagt. Der div muss all das händisch nachbilden und vergisst dabei leicht Details wie Leertaste als Auslöser.
Landmark-Rollen und Strukturelemente
HTML5-Elemente wie <header>, <nav>, <main>, <aside> und <footer> erzeugen automatisch ARIA-Landmarks, über die Screenreader-Nutzende direkt zwischen Seitenbereichen springen können. Überschriften (<h1> bis <h6>) müssen eine sinnvolle, nicht rein optisch motivierte Hierarchie bilden – sie sind die wichtigste Navigationshilfe für Screenreader-Nutzende.
Wann ARIA sinnvoll ergänzt
Für Komponenten, die HTML nicht nativ abdeckt (Tabs, Akkordeons, komplexe Comboboxen), definiert WAI-ARIA Rollen, Zustände und Eigenschaften:
role – z. B. role="tablist", role="dialog".
aria-expanded – zeigt an, ob ein Element auf- oder zugeklappt ist.
aria-label / aria-labelledby – liefert einen zugänglichen Namen, wenn kein sichtbarer Text ausreicht.
aria-live – meldet dynamische Inhaltsänderungen (z. B. eine Statusmeldung), ohne dass der Fokus wechseln muss.
Der WAI-ARIA Authoring Practices Guide (APG) liefert für Standardmuster wie Tabs, Akkordeons und Dialoge fertige Referenzimplementierungen inklusive Tastaturverhalten.
ARIA-Attribute ändern nur, was assistive Technologien ansagen – sie ändern nichts am tatsächlichen Verhalten. aria-hidden="true" auf einem fokussierbaren Element versteckt es zwar vor Screenreadern, per Tastatur bleibt es aber trotzdem erreichbar. Beides muss zusammenpassen.
Ein Beispiel: Akkordeon
Ein Akkordeon besteht aus einer Schaltfläche, die einen Bereich auf- und zuklappt. Mit einem echten <button>, dem Attribut aria-expanded (wahr/falsch) und aria-controls, das auf den Bereich verweist, erfährt ein Screenreader-Nutzer: „Versand, Schaltfläche, eingeklappt“. Das Zustandsattribut muss beim Klick mit dem tatsächlichen Zustand aktualisiert werden, sonst sagt die Seite etwas Falsches an.
Der Namensbaustein
Ein zugänglicher Name entsteht in dieser Reihenfolge aus sichtbarem Text, aria-labelledby, aria-label oder dem Label. Sichtbarer Text ist der beste Name, weil er mit dem übereinstimmt, was alle sehen; Sprachsteuerungsnutzer sprechen, was sie sehen.
Heading- und Landmark-Gerüst
Genau eine h1 je Seite, darunter logisch gestaffelte Überschriften.
Jeder Hauptbereich in ein passendes Landmark (main, nav, footer).
Mehrere Navigationen durch Namen unterscheiden.
Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.
Quellen
W3C – WAI-ARIA 1.2 Spezifikation und „WAI-ARIA Authoring Practices Guide (APG)“ (allgemeine Referenz, nicht Zeile für Zeile geprüft)
MDN Web Docs – „ARIA“ und „HTML-Elemente nach Kategorie“ (Referenz zu semantischem HTML) (allgemeine Referenz, nicht Zeile für Zeile geprüft)
Barrierefreie Formulare und Fehlermeldungen
Begriffe vorab
Label: die sichtbare Beschriftung eines Formularfelds.
Fehlermeldung: Hinweis, was falsch ist und wie es behoben wird.
Autovervollständigung: Vorschläge des Browsers anhand gespeicherter Daten.
Formulare sind eine der fehleranfälligsten Stellen für Barrierefreiheit, weil hier Eingabe, Beschriftung, Fehlerprüfung und Fokus zusammenspielen müssen.
Ein <label> mit passendem for/id-Paar verknüpft Beschriftung und Feld fest. Ein bloßer Platzhaltertext (placeholder) ist kein Ersatz: Er verschwindet bei der Eingabe, hat oft zu wenig Kontrast und wird von manchen Screenreadern nicht zuverlässig vorgelesen (WCAG 3.3.2, 1.3.1).
Fehler klar benennen
WCAG 3.3.1 verlangt, dass Fehler in Text identifiziert und beschrieben werden, nicht nur farblich markiert. Eine gute Fehlermeldung nennt das betroffene Feld und erklärt, was zu tun ist:
<p id="email-error" role="alert">E-Mail-Adresse: Bitte ein gültiges Format wie name@beispiel.de eingeben.</p>
<input type="email" id="email" aria-describedby="email-error" aria-invalid="true">
aria-describedby verknüpft die Fehlermeldung mit dem Feld, aria-invalid="true" signalisiert den fehlerhaften Zustand, und role="alert" (bzw. eine aria-live-Region) sorgt dafür, dass Screenreader die neue Meldung automatisch ansagen.
Gruppierung und Pflichtfelder
<fieldset> mit <legend> gruppiert zusammengehörige Felder, etwa eine Reihe von Radiobuttons, und gibt der Gruppe eine gemeinsame Beschriftung. Pflichtfelder sollten nicht nur farblich, sondern auch textlich oder mit einem Symbol plus Erläuterung gekennzeichnet sein (siehe Lektion zu Farben).
Ausfüllhilfen (WCAG 2.2, Kriterium 1.3.5 und 3.3.7/3.3.8)
WCAG empfiehlt, den Zweck von Eingabefeldern zusätzlich maschinenlesbar zu machen, etwa über autocomplete-Attribute (autocomplete="email", autocomplete="tel"), damit Browser und Hilfsmittel beim Ausfüllen unterstützen können. Neuere WCAG-2.2-Kriterien verlangen außerdem, dass bereits bekannte Informationen nicht erneut abgefragt werden müssen und dass Authentifizierung nicht allein auf einem Gedächtnis- oder Rechentest beruht, wenn es zugänglichere Alternativen gibt.
Praxistest: das komplette Formular nur mit der Tastatur ausfüllen und bewusst einen Fehler erzeugen (z. B. ungültige E-Mail). Wird die Fehlermeldung vom Screenreader angesagt, und ist danach klar, welches Feld korrigiert werden muss?
Ein Beispiel für eine gute Fehlerbehandlung
Nach dem Absenden erscheint oben eine Zusammenfassung: „2 Fehler: E-Mail-Adresse fehlt, Postleitzahl ungültig.“ Die Einträge sind Links zu den Feldern. Direkt am Feld steht eine verständliche Meldung („Bitte eine fünfstellige Postleitzahl eingeben“). Der Fokus springt zur Zusammenfassung, die Screenreader automatisch ansagen. So erfährt jede Person, was los ist und wo.
Verständlich statt technisch
Meldungen wie „Fehler 27“ oder „Ungültige Eingabe“ helfen nicht. Besser: sagen, was erwartet wird, möglichst mit Beispiel. Die Anweisung vor dem Feld zu nennen („Format: TT.MM.JJJJ“) ist hilfreicher, als erst danach zu beanstanden.
Weitere Stolpersteine
Automatisches Weiterspringen zwischen Feldern.
Zeitlimits ohne Verlängerungsmöglichkeit.
CAPTCHAs ohne zugängliche Alternative.
Pflichtangaben nur farblich gekennzeichnet.
Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.