Assistive Technologien: So nutzen Menschen mit Behinderungen das Web

Wenn wir Websites gestalten und entwickeln, haben wir meist ein bestimmtes Bild im Kopf: Jemand sitzt vor einem Bildschirm, sieht die ganze Seite auf einen Blick und klickt sich mit Maus oder Finger durch. Für viele Menschen sieht die Nutzung des Webs aber völlig anders aus. Sie hören sich Seiten an, lesen sie mit den Fingerspitzen, sehen immer nur einen kleinen vergrößerten Ausschnitt oder steuern alles mit der Stimme.

Möglich machen das assistive Technologien. Sie sind die Brücke zwischen einem Menschen und deiner Benutzeroberfläche. Doch diese Brücke trägt nur, wenn deine Website die richtigen Informationen liefert. Ein Screenreader kann keinen Button ansagen, der technisch gar kein Button ist. Eine Sprachsteuerung kann kein Element anklicken, dessen Namen sie nicht kennt.

In diesem Artikel lernst du die wichtigsten assistiven Technologien kennen, erfährst, wie Menschen sie im Alltag einsetzen, und bekommst konkrete Hinweise, was daraus für Design und Code folgt.

Was assistive Technologien sind

Assistive Technologien sind Hard- und Software, die Menschen mit Behinderungen helfen, Geräte und Inhalte zu nutzen. Manche sind eigenständige Programme, viele sind heute direkt in Betriebssysteme eingebaut: VoiceOver auf Apple-Geräten, TalkBack auf Android, die Sprachausgabe und die Bildschirmlupe in Windows.

Technisch greifen die meisten dieser Werkzeuge nicht direkt auf dein HTML zu. Der Browser übersetzt den DOM in einen sogenannten Accessibility Tree, also einen Barrierefreiheitsbaum. Darin steht für jedes relevante Element, welche Rolle es hat (Button, Link, Überschrift, Eingabefeld), welchen Namen („Warenkorb öffnen“), welchen Zustand (ausgeklappt, ausgewählt, deaktiviert) und welchen Wert. Assistive Technologien lesen diesen Baum über Schnittstellen des Betriebssystems aus.

Das ist die wichtigste Erkenntnis dieses Artikels: Was nicht im Accessibility Tree steht, existiert für viele Hilfsmittel nicht. Genau deshalb fordern 1.3.1 Info und Beziehungen und 4.1.2 Name, Rolle, Wert, dass Struktur und Bedeutung nicht nur visuell, sondern auch im Code vorhanden sind.

Screenreader: das Web hören

Ein Screenreader liest Inhalte und Bedienelemente per Sprachausgabe vor. Er wird vor allem von blinden Menschen genutzt, aber auch von Menschen mit starker Sehbehinderung oder manchen Lese- und Lernschwierigkeiten. Bekannte Screenreader sind NVDA (kostenlos und quelloffen, Windows), JAWS (kommerziell, Windows), VoiceOver (macOS und iOS) und TalkBack (Android).

Ein verbreitetes Missverständnis: Screenreader-Nutzer:innen hören sich nicht jede Seite von oben bis unten an. Erfahrene Nutzer:innen springen gezielt. In NVDA und JAWS gelangt man zum Beispiel mit der Taste H zur nächsten Überschrift, VoiceOver bietet dafür den Rotor. Sie lassen sich Listen aller Links oder Überschriften anzeigen, springen zwischen Seitenbereichen wie Navigation und Hauptinhalt oder von Formularfeld zu Formularfeld.

Ein Szenario: Eine blinde Nutzerin öffnet ein Rezept. Sie will nicht die Lebensgeschichte des Kochs hören, sondern direkt zu den Zutaten. Gibt es eine Überschrift „Zutaten“, ist sie mit zwei Tastendrücken dort. Ist die Überschrift nur ein fett formatierter Absatz, muss sie sich durch den gesamten Text hören. Derselbe Inhalt, ein völlig anderes Nutzungserlebnis.

Für dich folgt daraus: Echte Überschriften in logischer Hierarchie, Landmarks wie header, nav, main und footer, aussagekräftige Linktexte, sinnvolle Alt-Texte für Bilder und Labels für jedes Formularfeld. Und Statusmeldungen wie „Artikel wurde in den Warenkorb gelegt“ müssen so umgesetzt sein, dass der Screenreader sie mitbekommt, ohne dass der Fokus springt. Wie du selbst einen ersten Test machst, erklärt der Artikel Schnelltest mit Screenreader.

Braillezeile: das Web ertasten

Eine Braillezeile ist ein Ausgabegerät, das Text in Brailleschrift darstellt. Kleine Stifte heben und senken sich und bilden so Zeichen, die man mit den Fingern liest. Braillezeilen arbeiten zusammen mit einem Screenreader und zeigen immer eine Zeile Text gleichzeitig an. Für taubblinde Menschen sind sie oft der einzige Zugang zu digitalen Inhalten, aber auch viele blinde Menschen nutzen sie, etwa für präzises Lesen, Programmieren oder in ruhigen Umgebungen.

Für die Praxis heißt das: Alles, was als Text kommuniziert wird, muss echter Text sein. Text in Bildern, ASCII-Kunst oder Bedeutungen, die nur über Emojis transportiert werden, kommen auf der Braillezeile nicht oder nur verstümmelt an.

Vergrößerung: das Web in Ausschnitten sehen

Viele Menschen mit Sehbehinderung nutzen keinen Screenreader, sondern vergrößern die Darstellung. Die Möglichkeiten reichen vom Browser-Zoom über größere Systemschriften bis zu Bildschirmlupen wie der Windows-Lupe, dem Zoom in macOS und iOS oder spezialisierter Software. Manche kombinieren Vergrößerung mit invertierten Farben, eigenen Farbschemata oder einer Sprachausgabe.

Bei starker Vergrößerung sieht eine Person immer nur einen kleinen Ausschnitt der Seite, vergleichbar mit dem Blick durch ein Schlüsselloch. Das hat Folgen: Eine Erfolgsmeldung, die oben rechts in der Ecke erscheint, während die Person unten links auf „Speichern“ geklickt hat, wird schlicht übersehen. Ein Tooltip, der beim Bewegen der Maus verschwindet, ist nicht lesbar.

Deshalb verlangt 1.4.10 Reflow, dass Inhalte auch bei einer Breite von 320 CSS-Pixeln ohne horizontales Scrollen nutzbar bleiben, was bei 1280 Pixel Fensterbreite einer Vergrößerung auf 400 Prozent entspricht. Responsive Layouts helfen hier enorm. Platziere außerdem Rückmeldungen in der Nähe der auslösenden Aktion, und verlasse dich nicht darauf, dass jemand die ganze Seite gleichzeitig überblickt.

Ein Sonderfall sind erzwungene Farbmodi wie die Kontrastdesigns in Windows. Sie überschreiben deine Farben. Informationen, die nur über Hintergrundfarben oder Hintergrundbilder transportiert werden, können dabei verschwinden, zum Beispiel ein Fokusindikator, der nur aus einem farbigen Schatten besteht.

Tastatur: das Web ohne Maus

Die Tastatur ist die Grundlage für viele andere Hilfsmittel. Menschen mit motorischen Einschränkungen, die keine Maus präzise führen können, navigieren mit Tab, Umschalt+Tab, Pfeiltasten, Enter, Leertaste und Escape. Screenreader-Nutzer:innen arbeiten ebenfalls mit der Tastatur. Und viele Schalter und Sprachsteuerungen simulieren am Ende Tastatureingaben.

Daraus ergeben sich zwei zentrale Anforderungen. 2.1.1 Tastatur verlangt, dass alle Funktionen per Tastatur nutzbar sind. 2.4.7 Fokus sichtbar verlangt, dass man jederzeit sieht, wo sich der Fokus gerade befindet. Klingt selbstverständlich, scheitert aber oft an Details: an Dropdowns, die sich nur bei Mausbewegung öffnen, an modalen Dialogen, aus denen man nicht mehr herauskommt, oder an einer Zeile outline: none im Stylesheet. Ausführlich geht es darum im Artikel Tastaturbedienung und Fokus.

Sprachsteuerung: das Web mit der Stimme bedienen

Mit Sprachsteuerung bedienen Menschen ihren Computer oder ihr Smartphone per gesprochenem Befehl. Bekannte Lösungen sind Dragon unter Windows, die Sprachsteuerung in macOS und iOS sowie Voice Access unter Android und Windows. Genutzt wird das zum Beispiel von Menschen mit Lähmungen, Muskelerkrankungen, Tremor oder chronischen Schmerzen in Händen und Armen.

Ein typischer Befehl lautet „Klicke Absenden“. Die Software sucht dann ein Element, dessen zugänglicher Name „Absenden“ enthält. Und hier liegt eine häufige Falle: Steht auf dem Button sichtbar „Absenden“, im Code aber aria-label="Formular abschicken", findet die Sprachsteuerung das Element nicht. Die Person sagt, was sie sieht, und nichts passiert.

Deshalb fordert 2.5.3 Label in Name, dass der zugängliche Name den sichtbaren Text enthält, am besten am Anfang. Als Notlösung blenden Sprachsteuerungen Nummern oder ein Raster über die Seite ein, über die man Elemente auswählen kann. Das funktioniert, ist aber mühsam und langsam. Für Icon-Buttons ohne sichtbaren Text hilft ein Tooltip oder eine sichtbare Beschriftung, damit Menschen wissen, welchen Namen sie sagen sollen.

Schalter, Kopf- und Augensteuerung

Manche Menschen können nur sehr wenige, gezielte Bewegungen ausführen. Sie nutzen zum Beispiel einen oder zwei große Taster, die mit Hand, Kopf, Fuß oder einem Saug-Blas-Röhrchen ausgelöst werden. Die Schaltersteuerung in iOS und Switch Access unter Android sind Beispiele dafür. Bei der sogenannten Scan-Methode wandert eine Markierung nacheinander über die Elemente auf dem Bildschirm, und ein Schalterdruck wählt das gerade markierte Element aus.

Andere steuern einen Mauszeiger über Kopfbewegungen oder mit den Augen. Bei der Augensteuerung erfolgt ein Klick oft dadurch, dass man ein Element eine gewisse Zeit fixiert.

Gemeinsam ist diesen Methoden: Jede einzelne Aktion kostet deutlich mehr Zeit und Kraft. Eine Seite mit 40 Links in der Navigation, bevor der Hauptinhalt beginnt, wird beim Scannen zur Geduldsprobe. Kleine, eng beieinanderliegende Ziele sind mit Kopf- oder Augensteuerung kaum zu treffen. Hilfreich sind deshalb eine logische, kurze Fokusreihenfolge, Sprunglinks zum Hauptinhalt, ausreichend große Klickflächen und keine knappen Zeitlimits.

Unterstützung beim Hören, Lesen und Verstehen

Nicht alle assistiven Technologien richten sich an Sehen oder Motorik. Schwerhörige Menschen nutzen Hörgeräte oder Cochlea-Implantate, oft direkt mit dem Smartphone verbunden, und sind bei Videos auf Untertitel und Transkripte angewiesen. Menschen mit Legasthenie oder Konzentrationsschwierigkeiten lassen sich Texte vorlesen, nutzen den Lesemodus des Browsers oder passen Schriftart, Zeilenabstand und Farben an.

All diese Werkzeuge funktionieren nur, wenn Inhalte als echter, gut strukturierter Text vorliegen. Ein PDF aus eingescannten Seiten oder eine Infografik ohne Textversion lässt sie ins Leere laufen.

Was daraus für Design und Code folgt

So unterschiedlich die Hilfsmittel sind, die Anforderungen an deine Website überschneiden sich stark. Die meisten Probleme lassen sich mit ein paar Grundregeln vermeiden:

• Semantisches HTML zuerst: Native Elemente wie button, a, input, select und Überschriften bringen Rolle, Tastaturbedienung und Zustände automatisch mit.
• Jedes Bedienelement braucht einen Namen: sichtbar beschriftet, im Code verknüpft und mit dem sichtbaren Text übereinstimmend.
• Zustände müssen technisch erkennbar sein: ausgeklappt oder eingeklappt, ausgewählt, Pflichtfeld, fehlerhaft.
• Die DOM-Reihenfolge muss sinnvoll sein: Was per CSS anders angeordnet wird, ist für Screenreader und Tastatur trotzdem in Code-Reihenfolge.
• Layouts müssen flexibel sein: Zoom, größere Schrift und schmale Viewports dürfen nichts abschneiden oder überlagern.
• ARIA nur gezielt einsetzen: ARIA kann Lücken schließen, aber falsch eingesetzt richtet es mehr Schaden an, als es nützt.

Ein typisches Beispiel ist ein Menü-Button in der mobilen Navigation:

<!-- Vorher: kein Button, kein Zustand -->
<div onclick="toggleMenu()">☰</div>

<!-- Nachher: echter Button mit Name und Zustand -->
<button type="button" aria-expanded="false" aria-controls="hauptmenue">
  Menü
</button>

Die Vorher-Variante ist für Tastatur, Screenreader und Sprachsteuerung praktisch unsichtbar. Ein Screenreader liest im schlimmsten Fall ein Sonderzeichen vor. Die Nachher-Variante wird als „Menü, Schalter, reduziert“ angesagt, lässt sich mit Tab erreichen, mit Enter oder Leertaste auslösen und per „Klicke Menü“ steuern. Beim Öffnen setzt dein Skript aria-expanded auf true.

Ein Formular, vier Perspektiven

Wie unterschiedlich dieselbe Barriere wirkt, zeigt ein realistisches Beispiel: ein Online-Formular zur Terminbuchung beim Bürgeramt.

Ein blinder Nutzer hört an einem Feld nur „Eingabefeld, bearbeiten“, weil das Label fehlt und nur ein Platzhaltertext gesetzt ist, der beim Tippen verschwindet. Eine Nutzerin mit Bildschirmlupe klickt auf „Weiter“ und bemerkt nicht, dass oben auf der Seite eine Fehlermeldung erschienen ist. Ein Nutzer mit Sprachsteuerung kann den Weiter-Button nicht ansprechen, weil er nur aus einem Pfeil-Icon besteht. Und eine Nutzerin mit Schaltersteuerung braucht für die Auswahl eines Datums im selbstgebauten Kalender Dutzende Schalterbetätigungen, weil es kein einfaches Datumsfeld zur Eingabe gibt.

Die Lösungen sind dieselben, die allen helfen: sichtbare, verknüpfte Labels, Fehlermeldungen direkt am Feld und mit Fokus auf die erste Fehlermeldung, Buttons mit Textbeschriftung und eine Datumseingabe, die auch per Tastatur schnell funktioniert.

Checkliste

• Sind Überschriften, Listen, Landmarks und Tabellen im Code korrekt ausgezeichnet?
• Hat jedes Bedienelement einen zugänglichen Namen, der den sichtbaren Text enthält?
• Lässt sich alles per Tastatur erreichen und bedienen, mit sichtbarem Fokus?
• Bleibt die Seite bei 400 Prozent Zoom ohne horizontales Scrollen nutzbar?
• Erscheinen Rückmeldungen nahe der Aktion und werden sie von Screenreadern angesagt?
• Sind Klickflächen groß genug und nicht zu eng beieinander?
• Funktionieren Fokusindikatoren und Icons auch in erzwungenen Farbmodi?
• Hast du die wichtigsten Abläufe mindestens einmal mit einem Screenreader getestet?

Fazit

Assistive Technologien sind so vielfältig wie die Menschen, die sie nutzen. Screenreader, Braillezeilen, Bildschirmlupen, Sprachsteuerungen und Schalter funktionieren sehr unterschiedlich, stellen an deine Website aber überraschend ähnliche Anforderungen: saubere Semantik, klare Namen, erkennbare Zustände, eine logische Reihenfolge und flexible Layouts.

Der beste Weg, das zu verinnerlichen, ist ausprobieren. Schalte einmal den Screenreader deines Systems ein, navigiere eine Viertelstunde nur mit der Tastatur oder steuere eine Seite per Sprache. Du wirst Barrieren danach mit anderen Augen sehen und sie schon im Entwurf vermeiden.

Quellen

• W3C WAI: How People with Disabilities Use the Web (öffnet in neuem Tab)
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (öffnet in neuem Tab)
• MDN Web Docs: Accessibility tree (öffnet in neuem Tab)
• NV Access: NVDA Screenreader (öffnet in neuem Tab)
• Apple Support: VoiceOver-Benutzerhandbuch für Mac (öffnet in neuem Tab)