# html-einfach.de: Volltext aller Wissensseiten (llms-full.txt) > Digitale Barrierefreiheit nach BFSG, BITV und WCAG 2.2: verständlich erklärt und mit semantischem HTML umgesetzt. Praxiswissen für zugängliche Websites. Diese Datei enthält den vollständigen Text von 214 Wissensseiten zu digitaler Barrierefreiheit nach deutschem Recht (BFSG, BITV, WCAG 2.2), semantischem HTML, barrierefreien Komponenten sowie SEO und KI (inklusive einer Referenz aller 55 WCAG-2.2-Erfolgskriterien der Stufen A und AA). - Stand: 2026-09-07 (bei jedem Build neu erzeugt) - Autor: Jakob Sommer, Webdesigner & Entwickler (https://html-einfach.de/ueber-mich.html) - Kurzfassung mit Linkliste: https://html-einfach.de/llms.txt - Kanonische Fassung jeder Seite: siehe die URL im jeweiligen Abschnitt - Zitieren mit Quellenangabe und Link ist ausdrücklich erwünscht - Rechtsthemen sind Information, keine Rechtsberatung --- # Barrierefreiheit verstehen - URL: https://html-einfach.de/barrierefreiheit-verstehen.html - Themenbereich: Barrierefreiheit verstehen - Zuletzt geändert: 2026-08-17 - Kurzbeschreibung: Barrierefreiheit verstehen: wer auf zugängliche Websites angewiesen ist, mit welchen Hilfsmitteln gesurft wird und warum sich der Aufwand rechnet. **Barrierefreiheit im Web heißt, dass Inhalt und Bedienung auch ohne Sehen, Hören, Maus oder schnelles Lesen funktionieren. Fang bei den Menschen an, dann bei ihren vier Bedienweisen. Der Rest der Website ist die technische Antwort darauf.** Diese vier Bedienweisen sind Screenreader, Vergrößerung, Tastatur und Stimme. Wer sie einmal verstanden hat, liest jede WCAG-Regel danach als Konsequenz statt als Vorschrift. Dieser Bereich beantwortet das „Wer“ und „Warum“, bevor es woanders um Kriterien und Code geht. ## Das Wichtigste in Kürze - Zum Jahresende 2025 lebten in Deutschland gut **7,8 Millionen schwerbehinderte Menschen**, 9,4 % der Bevölkerung (Destatis, Pressemitteilung vom 13. Juli 2026). Weltweit sind es laut WHO 1,3 Milliarden. - **91 % dieser Behinderungen entstehen durch Krankheit**, nur 3 % sind angeboren und 79 % der Betroffenen sind 55 Jahre oder älter. Barrierefreiheit ist damit auch ein Thema alternder Kundschaft, nicht nur einer Minderheit. - Es geht selten um Blindheit allein. Sehbehinderung, Schwerhörigkeit, motorische und kognitive Einschränkungen betreffen zusammen deutlich mehr Menschen und **situative Einschränkungen** treffen jeden: grelles Sonnenlicht, ein Arm im Gips, laute Umgebung ohne Kopfhörer. - Wer eine Seite mit einem Screenreader hört, liest sie nicht von oben nach unten, sondern **springt**: über Überschriften, Landmarks und Linklisten. Gutes Markup wird dabei belohnt, schlechtes fällt sofort auf. - **Ein Nutzer, ein Screenreader** ist die falsche Vorstellung: 71,6 % nutzen mehr als ein Programm, 43 % drei oder mehr (WebAIM-Umfrage, Januar 2024). - **Stand Februar 2026:** 95,9 % von einer Million untersuchten Startseiten hatten erkennbare WCAG-Fehler, im Schnitt 56,1 pro Seite. Sechs Fehlerarten verursachen 96 % davon. Angeführt von zu geringem Textkontrast (83,9 %). - „Unsere Nutzer haben das nicht“ lässt sich nicht belegen: Assistive Technologien geben sich aus Datenschutzgründen **nicht zu erkennen** und tauchen in keiner Statistik auf. - Seit dem 28. Juni 2025 ist Barrierefreiheit für viele private Anbieter zusätzlich Pflicht. Das Recht ist aber der Auslöser, nicht der Grund und dieser Bereich behandelt den Grund. ## Womit du anfängst Mit einer einzigen Seite: [Wie Screenreader-Nutzer surfen](https://html-einfach.de/barrierefreiheit-verstehen/wie-screenreader-nutzer-surfen.html). Kein anderer Artikel verändert den Blick auf das eigene Markup so schnell. Wer einmal nachvollzogen hat, dass eine Seite als Liste von Überschriften, Landmarks und Links wahrgenommen wird und nicht als Bild, trifft danach andere Entscheidungen, ohne eine Regel auswendig gelernt zu haben. Wer dagegen erst Budget oder Team überzeugen muss, startet bei [Zahlen und Business Case](https://html-einfach.de/barrierefreiheit-verstehen/zahlen-und-business-case.html). Dort steht jede Zahl mit Quelle und Stand, sodass sie in einer Präsentation Bestand hat. Und wenn du zwanzig Minuten übrig hast: Installier einen Screenreader und hör dir deine eigene Startseite an. Ich würd dafür NVDA nehmen, das ist kostenlos. Die Erfahrung ist unbequem, beendet aber jede Diskussion schneller als eine Statistik. ## Wie dieser Bereich aufgebaut ist **Menschen und ihre Einschränkungen** steht am Anfang, weil hinter jedem Kriterium eine konkrete Nutzungssituation liegt: [Sehbehinderung und Blindheit](https://html-einfach.de/barrierefreiheit-verstehen/sehbehinderung-und-blindheit.html), [Gehörlosigkeit und Schwerhörigkeit](https://html-einfach.de/barrierefreiheit-verstehen/gehoerlosigkeit-und-schwerhoerigkeit.html), [motorische Einschränkungen](https://html-einfach.de/barrierefreiheit-verstehen/motorische-einschraenkungen.html) sowie [Kognition und Neurodiversität](https://html-einfach.de/barrierefreiheit-verstehen/kognition-und-neurodiversitaet.html). Dazu gehört der oft übersehene Rest von uns: [situative und temporäre Einschränkungen](https://html-einfach.de/barrierefreiheit-verstehen/situative-und-temporaere-einschraenkungen.html): das Baby auf dem Arm, die Sonne auf dem Display, der gebrochene Finger. Den Perspektivwechsel liefert [wie Screenreader-Nutzer tatsächlich surfen](https://html-einfach.de/barrierefreiheit-verstehen/wie-screenreader-nutzer-surfen.html). **Assistive Technologien** sind die Werkzeuge, mit denen diese Menschen arbeiten: [Screenreader wie NVDA, JAWS und VoiceOver](https://html-einfach.de/barrierefreiheit-verstehen/screenreader-ueberblick.html), [Bildschirmvergrößerung](https://html-einfach.de/barrierefreiheit-verstehen/bildschirmvergroesserung.html), [Sprachsteuerung](https://html-einfach.de/barrierefreiheit-verstehen/sprachsteuerung.html), die [Braillezeile](https://html-einfach.de/barrierefreiheit-verstehen/braillezeile.html) und die [Tastatur- und Switch-Bedienung](https://html-einfach.de/barrierefreiheit-verstehen/tastatur-und-switch-bedienung.html). Sie alle haben eines gemeinsam: Sie lesen nicht die Seite, wie sie aussieht, sondern das, was der Browser aus dem Markup ableitet. Wer das verstanden hat, liest jedes HTML-Element anders und begreift, warum [semantisches HTML](https://html-einfach.de/semantisches-html.html) kein Stilmittel ist, sondern die Schnittstelle, über die diese Technik überhaupt funktioniert. **Warum es zählt** liefert die Argumente für alle, die intern überzeugen müssen: [Zahlen und Business Case für Deutschland](https://html-einfach.de/barrierefreiheit-verstehen/zahlen-und-business-case.html), der [Curb-Cut-Effekt und die hartnäckigsten Mythen](https://html-einfach.de/barrierefreiheit-verstehen/curb-cut-effekt-und-mythen.html) und [das Recht als Auslöser](https://html-einfach.de/barrierefreiheit-verstehen/recht-als-ausloeser.html), das von der UN-Behindertenrechtskonvention bis zu BFSG und BITV führt und direkt in [WCAG & BFSG](https://html-einfach.de/wcag-und-bfsg.html) überleitet. > **Randnotiz: warum dieser Bereich zuerst kommt.** Man kann Alt-Texte schreiben, ohne je gehört zu haben, wie ein Screenreader sie vorliest. Aber man schreibt bessere, wenn man es einmal gehört hat. Verstehen macht aus Regelbefolgung Handwerk. Deshalb steht dieser Bereich am Anfang des roten Fadens: Verstehen → Recht → Umsetzung → Testen → Auffindbarkeit. ## Häufige Fragen ### Betrifft Barrierefreiheit wirklich so viele Menschen? Mehr, als die Statistik zeigt. Amtlich erfasst sind 7,8 Millionen schwerbehinderte Menschen in Deutschland, aber der Schwerbehindertenausweis setzt einen Grad von 50 voraus. Leichtere Sehschwächen, Farbfehlsichtigkeit, altersbedingte Einschränkungen und motorische Probleme fallen komplett heraus. Rechnet man situative Einschränkungen hinzu, ist niemand dauerhaft außerhalb der Zielgruppe. ### Reicht es nicht, an blinde Nutzer zu denken? Nein, und es ist sogar die kleinste der betroffenen Gruppen. Der mit Abstand häufigste Fehler im Web ist zu geringer Textkontrast. Das ist ein Problem für Menschen mit Sehschwäche, für ältere Augen und für jeden, der draußen auf ein Display schaut. Danach kommen fehlende Alternativtexte und unbeschriftete Formularfelder. ### Wie merke ich, ob meine Nutzer Hilfsmittel verwenden? Gar nicht. Screenreader, Vergrößerungssoftware und Sprachsteuerung geben sich gegenüber Websites nicht zu erkennen; das ist aus Datenschutzgründen so gewollt. Die Aussage „bei uns nutzt das niemand“ ist deshalb nicht belegbar und zirkulär, weil eine unbedienbare Seite genau die Statistik erzeugt, mit der sie sich rechtfertigt. ### Muss ich Programmieren können, um diesen Bereich zu verstehen? Nein. Die Seiten hier erklären Menschen, Situationen und Hilfsmittel, nicht Code. Wer entscheidet, einkauft oder Inhalte pflegt, findet hier genau die Grundlagen, die in Ausschreibungen und Abstimmungen fehlen. Der Code kommt in den anderen Bereichen. ### Was ist der schnellste Weg zu einem echten Aha-Moment? Die Maus weglegen und versuchen, die eigene Website nur mit der Tabulatortaste zu bedienen. Das dauert fünf Minuten, braucht keine Software und deckt zuverlässig auf, was der Fokus nicht erreicht. --- # Sehbehinderung & Blindheit: So nutzen Betroffene das Web - URL: https://html-einfach.de/barrierefreiheit-verstehen/sehbehinderung-und-blindheit.html - Themenbereich: Barrierefreiheit verstehen - Zuletzt geändert: 2026-07-26 - Kurzbeschreibung: Sehbehinderung und Blindheit im Web: amtlich 558.725 Betroffene, das Spektrum reicht weit über Schwarz-Weiß hinaus. Das bedeutet klare Anforderungen an Kontrast, Zoom, Alt-Text und Struktur. **Sehbeeinträchtigung ist ein Spektrum, kein Schalter: Der weit größere Teil der Betroffenen ist nicht blind, sondern sieht unscharf, ausschnitthaft, blendempfindlich oder farbverschoben. Amtlich erfasst sind in Deutschland 558.725 Menschen, die realistische Zahl liegt deutlich höher. Für Websites folgt daraus keine Sonderbehandlung, sondern vier handfeste Anforderungen: ausreichender Kontrast, verlustfreie Vergrößerung, Textalternativen und eine Struktur, die im Markup steckt statt nur in der Optik.** ## Das Wichtigste in Kürze - Amtlich erfasst (Schwerbehindertenstatistik, Stand 31.12.2021): 71.260 blinde, 46.820 hochgradig sehbehinderte und 440.645 sehbehinderte Menschen. Zusammen sind das 558.725. Der [DBSV](https://www.dbsv.org/zahlen-fakten.html) nennt das eine „gesicherte untere Grenze“, weil längst nicht alle Betroffenen einen Schwerbehindertenausweis beantragen. - Blind im Rechtssinn ist, wer auf dem besseren Auge mit Korrektur höchstens 1/50 (0,02) Sehschärfe erreicht oder ein entsprechend stark eingeschränktes Gesichtsfeld hat. Sehbehindert beginnt bei weniger als 1/3 (0,3). - Rund 8 % der Männer und 0,5 % der Frauen haben eine Farbsinnstörung, meist eine Rot-Grün-Schwäche. Das ist kein Sehen in Graustufen, sondern das Zusammenfallen bestimmter Farbpaare. - Häufigster automatisch messbarer Fehler im Web überhaupt ist zu geringer Textkontrast. Er betrifft 83,9 % von einer Million untersuchten Startseiten, im Schnitt an 34 Stellen pro Seite (WebAIM Million, Februar 2026). - Wer stark vergrößert, sieht die Seite wie durch ein Fernglas. Weit auseinanderliegende Bezüge (Feld links, Fehlermeldung rechts oben) fallen dabei auseinander. - Die Pflichtwerte: 4,5:1 für normalen Text, 3:1 für große Schrift und Bedienelemente, 200 % Textvergrößerung ohne Funktionsverlust, Umbruch bei 320 CSS-Pixeln Breite. - Blinde Nutzer arbeiten mit [Screenreader](https://html-einfach.de/barrierefreiheit-verstehen/screenreader-ueberblick.html) und [Braillezeile](https://html-einfach.de/barrierefreiheit-verstehen/braillezeile.html) und navigieren ausschließlich über die Tastatur. Für sie entscheidet allein das Markup. - Seit dem 28. Juni 2025 sind diese Anforderungen für viele private Angebote über das [BFSG](https://html-einfach.de/wcag-und-bfsg/bfsg-einfach-erklaert.html) verpflichtend, für öffentliche Stellen schon länger über die [BITV 2.0](https://html-einfach.de/wcag-und-bfsg/bitv-2-0-erklaert.html). ## Das Spektrum: viel mehr als Blindheit „Blind oder nicht blind“ ist die falsche Vorstellung und sie führt direkt zu falschen Prioritäten. In Deutschland sind die Stufen sogar juristisch definiert, gemessen wird immer am besseren Auge mit bestmöglicher Korrektur: | Stufe | Sehschärfe | Größenordnung (Stand 31.12.2021) | | --- | --- | --- | | Sehbehinderung | weniger als 1/3 (0,3) | 440.645 | | hochgradige Sehbehinderung | weniger als 1/20 (0,05) | 46.820 | | Blindheit | höchstens 1/50 (0,02) oder Gesichtsfeldausfall | 71.260 | Zwei Dinge fallen an dieser Tabelle auf. Erstens: Blindheit ist die kleinste der drei Gruppen. Zweitens: Auch „blind“ heißt selten „sieht nichts“. Ein großer Teil der gesetzlich blinden Menschen nimmt Hell und Dunkel wahr, manche erkennen Umrisse oder lesen mit extremer Vergrößerung noch einzelne Wörter. Im [WebAIM-Survey #10](https://webaim.org/projects/screenreadersurvey10/) (Januar 2024) bezeichnen sich 76,6 % der Screenreader-Nutzer mit Behinderung als blind. 19,9 % bezeichnen sich aber als sehbehindert. Ein Fünftel derer, die Sprachausgabe nutzen, schaut also nebenbei auf den Bildschirm. Deshalb greifen Kontrast und Struktur bei denselben Menschen ineinander. Dazu kommen die Gruppen, die in keiner Statistik als „behindert“ auftauchen und trotzdem denselben Anforderungen begegnen: Alterssichtigkeit ab etwa Mitte vierzig, Farbsinnstörungen bei rund 8 % der Männer, Blendempfindlichkeit nach einer Augenoperation, trockene Augen am Ende eines Bildschirmtags.
Vier Simulationen derselben Bestellseite mit der Überschrift „Ihre Bestellung“, einer Lieferadresse, einem hellgrauen Hinweistext und einem blauen Knopf „Jetzt kaufen“. Erstens normales Sehen: alles erkennbar. Zweitens Makuladegeneration: ein dunkler Fleck liegt in der Bildmitte genau über Text und Knopf, der Rand bleibt sichtbar. Drittens Glaukom: nur ein kleiner runder Ausschnitt in der Mitte ist sichtbar, der gesamte Rand ist verdeckt. Viertens Grauer Star: die ganze Seite ist milchig und kontrastarm überlagert, der hellgraue Hinweis ist völlig verschwunden. Ein Kasten darunter hält fest, dass keiner dieser vier Fälle durch größere Schrift allein gelöst wird.
Dieselbe Seite, vier Sehsituationen: Bei Makuladegeneration fehlt die Mitte, beim Glaukom der Rand, beim Grauen Star der Kontrast. Kein einziger dieser Fälle wird durch eine größere Schrift allein gelöst.
## Wie sich das Surfen konkret unterscheidet **Mit starker Vergrößerung** sieht man immer nur einen kleinen Ausschnitt. Bei 400 % Zoom passt auf einen Full-HD-Monitor ungefähr so viel Inhalt wie auf ein Smartphone-Display. Der Blick wandert, der Kontext bleibt zurück. Wer in einem Formular das Feld „Postleitzahl“ ausfüllt und die Fehlermeldung erscheint oben rechts im Viewport, erfährt davon schlicht nichts. Details dazu stehen unter [Bildschirmvergrößerung](https://html-einfach.de/barrierefreiheit-verstehen/bildschirmvergroesserung.html). **Mit Sehrest und hohem Kontrastbedarf** wird häufig das Farbschema erzwungen: dunkler Hintergrund, große Schrift, invertierte Farben, teils der Windows-Kontrastmodus. Eine Seite, die Text in ein Hintergrundbild rendert oder Farben per `!important` festnagelt, bricht dabei auseinander. **Ohne Sehrest** wird die Seite gehört oder ertastet. Der Screenreader springt von Überschrift zu Überschrift, listet Links, geht Formulare Feld für Feld durch. Wie das im Detail abläuft, steht unter [wie Screenreader-Nutzer surfen](https://html-einfach.de/barrierefreiheit-verstehen/wie-screenreader-nutzer-surfen.html). Layout und Farbe spielen keine Rolle, Reihenfolge und Beschriftung entscheiden alles. Alle drei brauchen dasselbe Fundament: Bezüge, die im Markup stehen und nicht nur räumlich nebeneinanderliegen. Genau das verlangt [WCAG 1.3.1 „Info und Beziehungen“](https://html-einfach.de/wcag-und-bfsg/kriterien/1-3-1-info-und-beziehungen.html). > **Randnotiz: der Fernglas-Test.** Zoom auf 400 %, dann etwas bestellen. Nach zwei > Minuten weißt du mehr über deine Seite als nach zwei Stunden Checkliste: Erscheinen > Meldungen dort, wo der Blick gerade ist? Bleibt der Warenkorb erreichbar? Bricht die > Seite [ohne horizontales Scrollen um](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-10-reflow.html)?
Gegenüberstellung eines Bestellformulars bei 400 Prozent Zoom. Links, mit rotem Kreuz markiert: Der sichtbare Ausschnitt zeigt das rot umrandete Feld Postleitzahl mit dem Wert 1011 und den Knopf „Weiter zur Zahlung“; die Fehlermeldung „1 Fehler: Bitte prüfen Sie die Postleitzahl“ liegt in einem gerasterten Bereich außerhalb des Ausschnitts. Rechts, mit grünem Haken: Derselbe Ausschnitt, die Meldung „Bitte eine fünfstellige Postleitzahl eingeben, zum Beispiel 10115“ steht direkt unter dem Feld und ist über aria-describedby mit ihm verbunden.
Bei starker Vergrößerung entscheidet die Entfernung: Eine Fehlermeldung am oberen Seitenrand existiert für den vergrößerten Ausschnitt nicht.
## Der teuerste Fehler: zu geringer Kontrast Kontrast ist die mit Abstand häufigste Barriere im Web. 83,9 % der Startseiten in der WebAIM Million (Februar 2026) fallen darüber, im Schnitt an 34 Stellen. Der Grund ist selten Unwissen, sondern Geschmack: Hellgraue Schrift auf Weiß sieht ruhig und modern aus. Sie ist nur eben nicht lesbar. ```css /* Falsch: 2,85:1. Fällt bei 1.4.3 durch, sieht im Designtool aber „luftig“ aus */ .hint { color: #999999; background: #ffffff; } /* Richtig: 4,54:1. Das hellste Grau, das auf Weiß noch besteht */ .hint { color: #767676; background: #ffffff; } /* Große Schrift (ab 24 px, oder ab 18,66 px fett) darf auf 3:1 runter */ .lead { font-size: 1.5rem; color: #8a8a8a; background: #ffffff; } ``` Die Grenzwerte im Klartext: **4,5:1** für normalen Text ([1.4.3](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-3-kontrast-minimum.html)), **3:1** für große Schrift sowie für Bedienelemente und Grafiken ([1.4.11](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-11-nicht-text-kontrast.html)). Der zweite Punkt wird ständig übersehen: Auch der Rahmen eines Eingabefeldes, der Umriss eines Icons und der Fokusring müssen 3:1 gegen ihre Umgebung erreichen. Wo deine Seite steht, zeigt der [Kontrast-Check](https://html-einfach.de/ressourcen/kontrast-check.html) in ein paar Sekunden; die Systematik dahinter steht unter [Farbkontraste](https://html-einfach.de/wcag-und-bfsg/farbkontraste.html). Ich würd den Kontrast zuerst angehen, bevor du irgendetwas anderes anfasst. Kein anderer Punkt bringt so viel Wirkung pro Aufwand und keiner ist so leicht zu messen. ## Vergrößerung: Text muss wachsen, nicht die Seite Zwei Kriterien greifen hier ineinander. [1.4.4 Textgröße ändern](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-4-textgroesse-aendern.html) verlangt, dass Text auf 200 % vergrößert werden kann, ohne dass Inhalt oder Funktion verloren geht. [1.4.10 Reflow](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-10-reflow.html) verlangt, dass die Seite sich bei einer Breite von 320 CSS-Pixeln umbricht, statt horizontales Scrollen zu erzwingen. Das entspricht 400 % Zoom auf einem 1280 Pixel breiten Fenster. ```css /* Falsch: feste Pixelgrößen ignorieren die Nutzereinstellung, die feste Breite erzwingt horizontales Scrollen */ .card { width: 640px; font-size: 14px; } .table { min-width: 900px; } /* Richtig: relative Einheiten skalieren mit, die Breite gibt nach */ .card { max-width: 40rem; font-size: 0.95rem; } .table { display: block; overflow-x: auto; } /* nur die Tabelle scrollt */ ``` Reflow scheitert am häufigsten nicht am Layout, sondern an einem einzelnen Element mit fester Mindestbreite: eine Datentabelle, ein Code-Block, ein eingebettetes Video. Die Lösung ist fast immer ein eigener Scroll-Container für genau dieses Element statt für die ganze Seite. Praxisbeispiele stehen unter [Reflow, Zoom & Textabstände](https://html-einfach.de/wcag-und-bfsg/reflow-zoom-textabstaende.html). ## Farbe darf nie das einzige Signal sein Wer eine Rot-Grün-Schwäche hat, sieht bei einem rot umrandeten Pflichtfeld neben einem grün umrandeten ausgefüllten Feld nur zwei ähnlich graue Rahmen. Deshalb verlangt [WCAG 1.4.1 Benutzung von Farbe](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-1-benutzung-von-farbe.html) ein zweites, farbunabhängiges Merkmal. ```html

Bitte eine fünfstellige Postleitzahl eingeben, zum Beispiel 10115.

``` Dasselbe gilt für Links im Fließtext (unterstreichen, nicht nur einfärben), für Statusspalten in Tabellen (Wort statt Punkt) und für Diagramme. Dort helfen zusätzlich Muster und direkte Beschriftungen, siehe [barrierefreie Diagramme](https://html-einfach.de/barrierefreie-komponenten/barrierefreie-diagramme.html). ## Textalternativen: was das Bild sagt, nicht was es zeigt Ein Alt-Text beschreibt nicht das Bild, sondern seine Funktion an dieser Stelle. Dasselbe Foto braucht in einem Produktkatalog einen anderen Alt-Text als in einem Reisebericht. ```html Laufschuh von der Seite, dunkelblau mit oranger Sohle Warenkorb, 3 Artikel ``` Die Regel dahinter ist [WCAG 1.1.1 Nicht-Text-Inhalte](https://html-einfach.de/wcag-und-bfsg/kriterien/1-1-1-nicht-text-inhalte.html); wie man in Zweifelsfällen entscheidet, steht unter [Alt-Texte schreiben](https://html-einfach.de/barrierefreie-komponenten/alt-texte-schreiben.html). Nebenbei: Fehlende Alt-Texte sind mit 53,1 % der zweithäufigste Fehler der WebAIM Million und der am schnellsten behobene. Derselbe Text erfüllt gleich zwei Aufgaben: Er ist die Bildbeschreibung für blinde Nutzerinnen und zugleich die einzige Textinformation, die Suchmaschinen und KI-Systeme über das Bild haben. Wie man beides in einem Satz unterbringt, ohne ihn zum Schlagwortlager zu machen, steht unter [Bild-SEO](https://html-einfach.de/seo-und-ki/bild-seo.html). ## So testest du es 1. **Kontrast messen**, nicht schätzen: Seite in den [Kontrast-Check](https://html-einfach.de/ressourcen/kontrast-check.html) geben oder in den DevTools unter „Barrierefreiheit“ die berechneten Werte prüfen. Achte besonders auf Platzhaltertext, deaktivierte Buttons und Text auf Bildern. 2. **Auf 400 % zoomen** (`Strg`/`Cmd` und `+`, fünfmal) und den wichtigsten Ablauf durchspielen (Suche, Warenkorb, Kontaktformular). Es darf kein horizontales Scrollen für die Seite als Ganzes nötig sein. 3. **Nur die Textgröße erhöhen**: in Firefox unter „Einstellungen → Allgemein → Sprache und Erscheinungsbild → Zoom → Nur Text zoomen“, dann auf 200 % stellen. Überlappt etwas oder wird abgeschnitten? 4. **In Graustufen umschalten**: in den Chrome DevTools über „Rendering → Emulate vision deficiencies“. Bleibt jede Information erkennbar, wenn die Farbe wegfällt? 5. **Screenshot verstecken:** Bildschirm dunkel schalten und dieselbe Aufgabe mit einem [Screenreader](https://html-einfach.de/wcag-und-bfsg/mit-nvda-testen.html) lösen. Was du dann nicht findest, fehlt im Markup. ## Häufiger Fehler in der Praxis **Der „Kontrast-Modus“ als Alibi.** Ein Umschalter für hohen Kontrast wirkt fürsorglich und verschiebt das Problem nur: Die Standardansicht bleibt unlesbar, der Sondermodus wird nie gepflegt, und die Vielfalt der Bedürfnisse (mehr Kontrast, *weniger* Kontrast bei Blendempfindlichkeit, eigene Farben, eigene Schriftgröße) bedient er ohnehin nicht. Robuster ist eine Seite, die die Systemeinstellungen respektiert. **Alt-Text als Dateiname.** `alt="IMG_2043.jpg"` oder `alt="Bild"` ist schlimmer als gar kein Alt-Attribut, weil es die Prüfwerkzeuge zufriedenstellt und die Nutzer nicht. **Fokus wegformatiert.** `outline: none` im Reset, weil der Ring „stört“. Für alle, die mit Vergrößerung arbeiten, ist er die einzige Orientierung, wo sie gerade sind. Was stattdessen zu tun ist, steht unter [Tastaturbedienung & sichtbarer Fokus](https://html-einfach.de/wcag-und-bfsg/tastatur-und-fokus.html). **Text als Bild.** Preistabellen, Öffnungszeiten und Infografiken als PNG sind für Vergrößerung unbrauchbar (sie werden unscharf) und für Screenreader unsichtbar. [WCAG 1.4.5](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-5-bilder-von-text.html) verbietet das mit wenigen Ausnahmen und Suchmaschinen lesen den Inhalt ebenso wenig. ## Häufige Fragen ### Wie viele blinde und sehbehinderte Menschen gibt es in Deutschland? Amtlich erfasst sind 71.260 blinde, 46.820 hochgradig sehbehinderte und 440.645 sehbehinderte Menschen (Schwerbehindertenstatistik, Stand 31.12.2021). Der DBSV nennt das ausdrücklich eine gesicherte untere Grenze, weil viele Betroffene keinen Ausweis beantragen; ältere WHO-Hochrechnungen kommen auf rund 1,2 Millionen. Eine amtliche Zählung blinder und sehbehinderter Menschen gibt es in Deutschland nicht. ### Nutzen blinde Menschen wirklich Onlineshops? Ja, und überdurchschnittlich intensiv. Gerade weil der Weg in ein Ladengeschäft aufwendiger ist, sind Onlineshop, Banking und Behördengang im Netz für viele die bevorzugte Variante (sofern sie funktionieren). Eine unbedienbare Seite bedeutet hier nicht Unbequemlichkeit, sondern Ausschluss. Deshalb nimmt das [BFSG](https://html-einfach.de/wcag-und-bfsg/bfsg-einfach-erklaert.html) genau solche Dienste in die Pflicht. ### Reicht ein Overlay-Widget mit Kontrast- und Vorlesefunktion? Nein. Overlays legen eine Schicht über die Seite, statt die Ursachen im Markup zu beheben. Fehlende Rollen, falsche Reihenfolgen und nichtssagende Linktexte bleiben. Viele Betroffene schalten sie ab, weil sie mit ihrer eigenen, fein eingestellten Hilfstechnik kollidieren. Warum ich davon abrate, steht unter [Tools](https://html-einfach.de/ressourcen/tools.html). ### Was ist mit Menschen, die „nur“ eine Lesebrille brauchen? Die profitieren von exakt denselben Maßnahmen: guter Kontrast, großzügige Schrift, sauberer Zoom, klare Struktur. Das ist der [Curb-Cut-Effekt](https://html-einfach.de/barrierefreiheit-verstehen/curb-cut-effekt-und-mythen.html): was für wenige unverzichtbar ist, macht es für alle anderen angenehmer. Bei Alterssichtigkeit betrifft das ab Mitte vierzig praktisch jeden. ### Muss ich für Farbenblinde eine eigene Palette anbieten? Nein. Es reicht, dass keine Information allein über Farbe transportiert wird und die Kontrastwerte stimmen. Eine Umschaltung auf Sonderfarben löst das Problem nicht, weil Farbsinnstörungen unterschiedlich ausfallen. Prüfen lässt sich das in wenigen Sekunden mit der Graustufen-Emulation der Browser-DevTools. ## Verwandte Themen - [Bildschirmvergrößerung](https://html-einfach.de/barrierefreiheit-verstehen/bildschirmvergroesserung.html): wie Lupe, Zoom und ZoomText im Alltag arbeiten - [Screenreader im Überblick](https://html-einfach.de/barrierefreiheit-verstehen/screenreader-ueberblick.html): NVDA, JAWS und VoiceOver im Vergleich - [Braillezeile](https://html-einfach.de/barrierefreiheit-verstehen/braillezeile.html): taktiles Lesen und was es für sparsames Markup bedeutet - [Farbkontraste](https://html-einfach.de/wcag-und-bfsg/farbkontraste.html): Berechnung, Grenzwerte und typische Ausreden - [Alt-Texte schreiben](https://html-einfach.de/barrierefreie-komponenten/alt-texte-schreiben.html): Entscheidungsbaum für informativ, dekorativ und funktional - [Überschriften-Hierarchie](https://html-einfach.de/semantisches-html/ueberschriften-hierarchie.html): die Struktur, in der Screenreader-Nutzer springen ## Quellen --- # Gehörlosigkeit & Schwerhörigkeit im Web - URL: https://html-einfach.de/barrierefreiheit-verstehen/gehoerlosigkeit-und-schwerhoerigkeit.html - Themenbereich: Barrierefreiheit verstehen - Zuletzt geändert: 2026-07-21 - Kurzbeschreibung: Gehörlosigkeit und Schwerhörigkeit im Web: rund 16 % Prävalenz, 80.000 Gehörlose, sowie die Pflichten für Untertitel, Transkripte, DGS und Kontaktwege. **Menschen mit Hörbeeinträchtigung sind die größte Gruppe, an die im Web zuletzt gedacht wird. Nach der HÖRSTAT-Studie liegt die Prävalenz von Schwerhörigkeit in Deutschland bei rund 16 %, und nur etwa 37 % der Betroffenen tragen ein Hörgerät. Für Websites entscheidet sich Zugänglichkeit an vier Stellen: Untertitel für jedes Video mit Ton, Transkripte für Audio, sichtbare Alternativen für akustische Signale und ein Kontaktweg, der nicht das Telefon ist.** ## Das Wichtigste in Kürze - Prävalenz von Schwerhörigkeit in Deutschland nach WHO-Klassifikation: rund **16 %** (HÖRSTAT, hochgerechnet auf Bundesebene). Nur etwa **37 %** der Betroffenen tragen ein Hörgerät. Die Barriere bleibt also meist bestehen. - Der Deutsche Schwerhörigenbund schätzt für 2018 **15,7 Millionen** hörbeeinträchtigte Menschen über 14 Jahre; davon rund 958.000 hochgradig und 213.000 an Taubheit grenzend. - In Deutschland leben etwa **80.000 gehörlose Menschen**; die Deutsche Gebärdensprache (DGS) nutzen rund **200.000** Personen. - Für viele gehörlose Menschen ist DGS die Erstsprache und Deutsch eine früh gelernte **Zweitsprache**. Untertitel helfen deshalb nicht allen gleich gut. - DGS ist seit 2002 über **§ 6 BGG** als eigenständige Sprache anerkannt. **§ 4 BITV 2.0** verpflichtet Bundesbehörden zu Erläuterungen in DGS und Leichter Sprache auf der Startseite. Private Anbieter unter dem BFSG trifft diese Pflicht nicht. - Pflicht nach WCAG: Untertitel für aufgezeichnete Videos ab Stufe A ([1.2.2](https://html-einfach.de/wcag-und-bfsg/kriterien/1-2-2-untertitel-aufgezeichnet.html)), für Live-Inhalte ab AA ([1.2.4](https://html-einfach.de/wcag-und-bfsg/kriterien/1-2-4-untertitel-live.html)), Textalternative für reine Audioinhalte ab A ([1.2.1](https://html-einfach.de/wcag-und-bfsg/kriterien/1-2-1-nur-audio-nur-video.html)). - Gebärdensprach-Videos sind in den WCAG erst auf Stufe **AAA** verlangt (1.2.6). Für die gesetzliche Konformität nach AA sind sie also nicht erforderlich. - Ein akustisches Signal darf nie allein stehen: Jede Tonrückmeldung braucht ein sichtbares Gegenstück ([1.4.1](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-1-benutzung-von-farbe.html) gilt sinngemäß, technisch umgesetzt über [Statusmeldungen](https://html-einfach.de/wcag-und-bfsg/kriterien/4-1-3-statusmeldungen.html)). ## Das Spektrum: gehörlos ist nicht gleich schwerhörig Solange das Web aus Text bestand, war es für diese Gruppe fast barrierefrei. Mit Video, Podcast, Webinar, Erklärvideo im Checkout und Sprachassistent hat sich das gedreht. Und zwar schnell. | Stufe | Größenordnung (DSB, Basis 2018) | Was im Web hilft | | --- | --- | --- | | leichtgradig | rund 7,51 Mio. | guter Ton, Untertitel als Option | | mittelgradig | rund 4,68 Mio. | Untertitel, Transkript | | hochgradig | rund 958.000 | Untertitel zwingend, Transkript, visuelle Signale | | an Taubheit grenzend / gehörlos | rund 213.000 | Untertitel **und** Textalternativen, teils DGS | Zur Einordnung: Diese Zahlen sind Fortschreibungen einer Studie von 1999 und werden vom Verband selbst als Schätzung gekennzeichnet. Belastbarer ist die klinische Erhebung. HÖRSTAT kommt auf rund 16 % Prävalenz, die Gutenberg-Gesundheitsstudie untersucht denselben Bereich für Rheinland-Pfalz. Alle Quellen zeigen dasselbe Muster: Die Zahl steigt mit dem Alter steil an, und die Versorgung mit Hörgeräten hinkt weit hinterher. **Gehörlose Menschen** hören von Geburt an oder seit früher Kindheit nicht. Für viele ist die Deutsche Gebärdensprache die Erstsprache (eine vollwertige Sprache mit eigener Grammatik, nicht eine Übersetzung des Deutschen mit den Händen). Deutsch ist dann eine Zweitsprache, und Schriftdeutsch liest sich entsprechend wie eine Fremdsprache. **Spätertaubte und schwerhörige Menschen** sind lautsprachlich aufgewachsen. Sie brauchen vor allem verlässliche Untertitel und die Möglichkeit, Ton zu verstärken oder durch Text zu ersetzen. Solange keine Hintergrundmusik, kein Hall und keine schlechte Aufnahmequalität dazwischenfunken, verstehen **Hörgeräte- und CI-Träger** (Cochlea-Implantat) Sprache oft gut. Ein sauber abgemischter Ton ist hier die halbe Barrierefreiheit, und der kostet in der Produktion praktisch nichts extra.
Ein waagerechtes Stufendiagramm mit vier blauen Blöcken, deren Breite die Größenordnung darstellt: leichtgradig rund 7,51 Millionen, mittelgradig rund 4,68 Millionen, hochgradig rund 958.000, an Taubheit grenzend rund 213.000. Ein durchgehendes grünes Band unter allen vier Blöcken trägt die Beschriftung „Untertitel wirken über das gesamte Spektrum“. Darunter steht zu jedem Block die passende Maßnahme: guter Ton mit Sprache deutlich über dem Musikbett, Untertitel plus Transkript in geprüfter Fassung, sichtbare Signale statt Hinweisen nur als Ton und ganz rechts zusätzlich Deutsche Gebärdensprache für zentrale Inhalte. Ein Kasten am Ende nennt rund 16 Prozent Prävalenz nach HÖRSTAT und rund 37 Prozent Hörgeräteversorgung.
Je größer die Gruppe, desto einfacher die Maßnahme: Untertitel wirken über das ganze Spektrum, DGS-Videos erreichen gezielt die kleinste und am stärksten betroffene Gruppe.
## Warum Untertitel nicht für alle reichen Ein Punkt, den viele Ratgeber auslassen: Untertitel setzen sichere Lesekompetenz im Deutschen voraus. Wer Deutsch als Zweitsprache über die Schriftform gelernt hat, liest langsamer und verliert bei Untertiteln, die im Videotempo laufen, schnell den Anschluss. Die [Bundesfachstelle Barrierefreiheit](https://www.bundesfachstelle-barrierefreiheit.de/DE/Fachwissen/Information-und-Kommunikation/Gebaerdensprache/gebaerdensprache.html) formuliert es deutlich: Schriftsprache funktioniert für gehörlose Menschen wie eine Fremdsprache. Daraus folgt eine Abstufung, die sich in Projekten bewährt hat: 1. **Untertitel**: Pflicht, wirken über das gesamte Spektrum, günstig. 2. **Transkript**: zusätzlicher Nutzen: durchsuchbar, im eigenen Tempo lesbar, auch per [Braillezeile](https://html-einfach.de/barrierefreiheit-verstehen/braillezeile.html) zugänglich. 3. **Klare, kurze Sprache**: hilft hier genauso wie bei [kognitiven Einschränkungen](https://html-einfach.de/wcag-und-bfsg/kognitive-barrierefreiheit.html): kurze Sätze, ein Gedanke pro Absatz, keine Schachtelsätze. 4. **DGS-Video**: teuer und aufwendig, aber für zentrale, selten geänderte Inhalte die einzige Lösung, die die gehörlose Community wirklich erreicht. Ich würd bei einem normalen Unternehmensauftritt bei Punkt 1 bis 3 bleiben und DGS gezielt dort einsetzen, wo es zählt: auf der Kontaktseite, bei der Erklärung des Bestellprozesses, bei Sicherheitshinweisen. ## Untertitel richtig machen Technisch braucht es kein Framework. Das ``-Element liefert Untertitel nativ, und jeder Browser hat die Umschaltung eingebaut: ```html ``` Wichtig ist `kind="captions"`, nicht `kind="subtitles"`: **Subtitles** übersetzen nur die Sprache (etwa für einen fremdsprachigen Film), **Captions** enthalten zusätzlich die akustische Information, die zum Verständnis nötig ist (Geräusche, Sprecherwechsel, Musikeinsatz). ```text WEBVTT 00:00:04.000 --> 00:00:07.500 [Türklingel] Guten Tag, ich komme wegen der Wohnung. 00:00:07.500 --> 00:00:11.200 -Frau Berger: Kommen Sie herein. -Herr Klein: Danke, gern. 00:00:11.200 --> 00:00:14.000 [nachdenkliche Klaviermusik setzt ein] ``` Woran gute Untertitel erkennbar sind: höchstens zwei Zeilen gleichzeitig, ungefähr Lesetempo statt Sprechtempo, Sprecherwechsel gekennzeichnet, relevante Geräusche in eckigen Klammern, korrekte Namen und Zahlen. Automatisch erzeugte Untertitel sind dafür ein brauchbarer Rohentwurf und kein Endzustand. Ein verschlucktes „nicht“ kehrt den Sinn eines Satzes um. Die vollständige Praxisanleitung steht unter [Untertitel, Transkripte & Audiodeskription](https://html-einfach.de/wcag-und-bfsg/untertitel-und-transkripte.html), die Player-Seite unter [Media-Player](https://html-einfach.de/barrierefreie-komponenten/media-player.html).
Eine Tabelle mit drei Spalten für Untertitel im Video, Transkript als Text und Gebärdensprachvideo sowie vier Zeilen für die Nutzergruppen schwerhörig, spätertaubt, gehörlos mit DGS als Erstsprache und Menschen ohne Hörbeeinträchtigung im Zug oder Großraumbüro. Grüne Haken zeigen zuverlässige Wirkung, orange Haken eingeschränkte Wirkung, graue Striche keinen zusätzlichen Nutzen: Untertitel und Transkript wirken in allen vier Zeilen, in der Zeile gehörlos jedoch nur eingeschränkt, weil Schriftdeutsch dort Zweitsprache ist. Das Gebärdensprachvideo wirkt allein in der Zeile gehörlos. Die letzte Zeile nennt den Produktionsaufwand: Untertitel niedrig, Transkript niedrig, Gebärdensprachvideo hoch. Darunter zwei Karten mit der WCAG-Pflicht ab Stufe A und AA und der Kür auf Stufe AAA.
Wirkung gegen Aufwand: Untertitel decken alle vier Gruppen ab, DGS-Videos erreichen eine (dafür diejenige, die von Untertiteln am wenigsten hat).
## Transkripte: der unterschätzte Doppelnutzen Ein Transkript ist kein Ersatz für Untertitel, sondern etwas anderes: Untertitel laufen synchron und im Tempo des Videos, ein Transkript lässt sich überfliegen, durchsuchen, im eigenen Tempo lesen und kopieren. Für Podcasts und reine Audioinhalte ist es sogar die geforderte Textalternative ([WCAG 1.2.1](https://html-einfach.de/wcag-und-bfsg/kriterien/1-2-1-nur-audio-nur-video.html)). Der Nebeneffekt ist beträchtlich: Suchmaschinen und KI-Systeme [lesen Text, keinen Ton](https://html-einfach.de/seo-und-ki/semantik-und-seo.html). Eine Stunde Podcast ohne Transkript ist für die Suche eine leere Seite; mit Transkript sind es rund 8.000 Wörter zitierfähiger Inhalt. Wer das Transkript zusätzlich mit Überschriften und Zeitmarken gliedert, bekommt Sprungziele (für Lesende und für [KI-Antworten](https://html-einfach.de/seo-und-ki/geo-grundlagen.html) gleichermaßen). ## Ton darf nie das einzige Signal sein Der Klassiker aus Buchungsstrecken: Der Termin ist gebucht, es macht „pling“, sonst passiert nichts Sichtbares. ```html

Termin für den 14. August um 10:30 Uhr gebucht.

``` Dasselbe gilt für Warnungen, Zeitablauf-Signale, eingehende Chat-Nachrichten und Videos, die automatisch mit Ton starten. Letzteres ist über [WCAG 1.4.2](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-2-audio-steuerelement.html) ohnehin geregelt. Wie Statusmeldungen so ausgezeichnet werden, dass sie ankommen, steht unter [Status, Fortschritt und Benachrichtigungen](https://html-einfach.de/barrierefreie-komponenten/status-fortschritt-benachrichtigungen.html). ## Kontaktwege ohne Telefonzwang Der am häufigsten übersehene Punkt hat nichts mit Medien zu tun: „Rufen Sie uns einfach an!“ hilft niemandem, der nicht telefonieren kann. Und es betrifft ausgerechnet die Situationen, in denen es wehtut (Stornierung, Reklamation, Terminvereinbarung, Support). Gleichwertig heißt: gleiche Erreichbarkeit, gleiche Antwortzeit, gleiche Befugnisse. Ein Kontaktformular, das nach drei Tagen beantwortet wird, während die Hotline sofort hilft, ist keine Alternative. Praktisch bewährt haben sich E-Mail plus Formular plus (wo vorhanden) Text-Chat mit echten Menschen. Seit [WCAG 3.2.6 „Konsistente Hilfe“](https://html-einfach.de/wcag-und-bfsg/kriterien/3-2-6-konsistente-hilfe.html) ist auch die Position dieser Kontaktwege ein Prüfpunkt: Sie müssen auf allen Seiten an derselben Stelle stehen. ## So testest du es 1. **Ton aus.** Stelle den Rechner stumm und arbeite die Seite durch, als wäre das der Normalzustand. Was bekommst du nicht mit? 2. **Jedes Video prüfen:** Gibt es einen Untertitel-Schalter? Sind die Untertitel manuell geprüft (Namen, Zahlen, Fachbegriffe)? Steht ein Transkript dabei? 3. **Automatische Untertitel gegenlesen**, mindestens die ersten zwei Minuten. Der Fehlerteppich zeigt sich fast immer sofort. 4. **Alle akustischen Signale auflisten** (Erfolgstöne, Warnungen, Chat-Benachrichtigung) und für jedes prüfen, ob es ein sichtbares Gegenstück gibt. 5. **Kontaktseite lesen wie jemand, der nicht telefonieren kann.** Gibt es einen zweiten Weg, ist er gleich prominent, nennt er eine Antwortzeit? 6. **Live-Formate mitdenken:** Webinar, Sprechstunde, Livestream. Ohne Live-Untertitelung fällt hier eine ganze Gruppe raus. Wege dazu stehen unter [Untertitel und Transkripte](https://html-einfach.de/wcag-und-bfsg/untertitel-und-transkripte.html). ## Häufiger Fehler in der Praxis **Untertitel eingebrannt.** Fest ins Bild gerenderte Untertitel lassen sich nicht abschalten, nicht vergrößern, nicht in Farbe und Position anpassen und sind für Suchmaschinen unsichtbar. Eine `.vtt`-Datei kostet dieselbe Arbeit und kann alles davon. **„Wir haben ja Untertitel“: für ein Video von vieren.** Barrierefreiheit von Medien ist eine Redaktionsroutine, kein Projekt. Wenn im Freigabeprozess kein Punkt „Untertitel geprüft“ steht, entsteht die Lücke bei jedem neuen Video von Neuem. **Musik unter der Sprache.** Ein dramatischer Score unter dem Erklärtext klingt professionell und macht die Sprache für Hörgeräte- und CI-Träger unverständlich. Faustregel aus der Produktion: Sprache deutlich lauter als Musikbett, im Zweifel Musik ganz weg. **DGS als Aushängeschild.** Ein Gebärdensprachvideo auf der Startseite, während der Bestellprozess keine Untertitel hat, ist sichtbare Bemühung ohne Wirkung. Erst die Pflichten erfüllen, dann das Zusätzliche. **Der Chatbot als Ersatz für alles.** Ein Bot, der bei jeder komplexeren Frage auf die Hotline verweist, ist kein alternativer Kontaktweg, sondern eine Warteschleife mit Tastatur. ## Häufige Fragen ### Reichen die automatischen Untertitel von YouTube und Co.? Als Rohentwurf ja, als Endzustand nein. Die Spracherkennung ist heute erstaunlich gut, scheitert aber verlässlich an Eigennamen, Fachbegriffen, Zahlen und Dialekt und ein verschlucktes „nicht“ kehrt die Aussage um. Rechne mit ungefähr der doppelten Videolänge fürs Korrekturlesen. Das ist der günstigste Punkt im ganzen Thema. ### Muss ich Gebärdensprache anbieten? Für private Angebote unter dem [BFSG](https://html-einfach.de/wcag-und-bfsg/bfsg-einfach-erklaert.html): nein. Gebärdensprach-Videos sind in den WCAG erst auf Stufe AAA verlangt (1.2.6), und die gesetzliche Latte liegt bei AA. Bundesbehörden trifft dagegen § 4 BITV 2.0: Erläuterungen in DGS und Leichter Sprache auf der Startseite. Wer freiwillig mehr tut, erreicht die gehörlose Community deutlich besser. ### Sind Untertitel und Transkript nicht doppelt gemoppelt? Nein, sie bedienen verschiedene Situationen. Untertitel laufen synchron im Video und sind für das Verstehen der Handlung da; ein Transkript lässt sich überfliegen, durchsuchen, im eigenen Tempo lesen und per Braillezeile ertasten. Für reine Audioinhalte ist das Transkript sogar die einzige mögliche Alternative. Ein Podcast hat kein Bild, in das Untertitel passen. ### Wie viele gehörlose Menschen gibt es in Deutschland? Rund 80.000 gehörlose Menschen, und etwa 200.000 Personen nutzen die Deutsche Gebärdensprache. Darin enthalten sind hörende Angehörige, Dolmetscherinnen und Fachkräfte. Die Zahl der Menschen mit Hörbeeinträchtigung insgesamt liegt um ein Vielfaches höher: rund 16 % Prävalenz nach HÖRSTAT, was mehreren Millionen entspricht. ### Helfen Untertitel auch Menschen ohne Hörbeeinträchtigung? Ja, und zwar in großem Umfang: im Zug ohne Kopfhörer, im Großraumbüro, neben schlafenden Kindern, beim Lernen einer Fremdsprache, bei starkem Dialekt. Untertitel sind das Lehrbuchbeispiel für den [Curb-Cut-Effekt](https://html-einfach.de/barrierefreiheit-verstehen/curb-cut-effekt-und-mythen.html) (entwickelt für wenige, benutzt von sehr vielen). ## Verwandte Themen - [Untertitel, Transkripte & Audiodeskription](https://html-einfach.de/wcag-und-bfsg/untertitel-und-transkripte.html): die Praxisseite mit Formaten und Werkzeugen - [Semantische Medien](https://html-einfach.de/semantisches-html/semantische-medien.html): `video`, `audio` und `track` richtig aufbauen - [Media-Player](https://html-einfach.de/barrierefreie-komponenten/media-player.html): bedienbare Steuerung ohne Maus - [Kognitive Barrierefreiheit](https://html-einfach.de/wcag-und-bfsg/kognitive-barrierefreiheit.html): klare Sprache, die hier genauso hilft - [Situative und temporäre Einschränkungen](https://html-einfach.de/barrierefreiheit-verstehen/situative-und-temporaere-einschraenkungen.html): warum Untertitel im Alltag aller landen - [Status, Fortschritt und Benachrichtigungen](https://html-einfach.de/barrierefreie-komponenten/status-fortschritt-benachrichtigungen.html): sichtbare Gegenstücke für akustische Signale ## Quellen --- # Motorische Einschränkungen: Bedienung ohne Maus - URL: https://html-einfach.de/barrierefreiheit-verstehen/motorische-einschraenkungen.html - Themenbereich: Barrierefreiheit verstehen - Zuletzt geändert: 2026-07-10 - Kurzbeschreibung: Motorische Einschränkungen im Web: 11 % der schwerbehinderten Menschen sind betroffen. Was Tastatur, Zielgröße, Zeitpuffer und Klickverhalten leisten müssen. **Bei motorischen Einschränkungen ist nicht der Inhalt einer Website die Barriere, sondern der Weg dorthin: Die Maus verlangt ruhige Hände, präzise Zielbewegungen und schnelle Doppelklicks. Genau das fehlt bei Tremor, Spastik, Lähmung oder Arthrose. Zugänglich wird eine Seite dadurch, dass jede Funktion ohne Maus erreichbar ist, Ziele groß genug sind, niemand unter Zeitdruck steht und ein danebengegangener Klick folgenlos bleibt.** ## Das Wichtigste in Kürze - Von den rund [7,9 Millionen schwerbehinderten Menschen in Deutschland](https://www.destatis.de/DE/Presse/Pressemitteilungen/2024/07/PD24_281_227.html) (Statistisches Bundesamt, Stand Ende 2023) ist bei **11 %** die Funktion von Armen oder Beinen eingeschränkt, bei weiteren **10 %** Wirbelsäule und Rumpf. - Dazu kommen große Krankheitsgruppen: rund **400.000** Menschen mit Parkinson (bis 2040 werden 50 % mehr erwartet) und über **280.000** mit Multipler Sklerose (DMSG). - Die Tastatur ist der gemeinsame Nenner: Mundmaus, Kopfmaus, Eye-Tracking, Taster und die meisten Sprachsteuerungen erzeugen darunter Fokus- und Aktivierungsereignisse. - Pflicht ab Stufe A: alles per Tastatur bedienbar ([2.1.1](https://html-einfach.de/wcag-und-bfsg/kriterien/2-1-1-tastatur.html)), keine Tastaturfalle ([2.1.2](https://html-einfach.de/wcag-und-bfsg/kriterien/2-1-2-keine-tastaturfalle.html)), Aktion beim Loslassen statt beim Drücken ([2.5.2](https://html-einfach.de/wcag-und-bfsg/kriterien/2-5-2-zeiger-abbruch.html)). - Neu in WCAG 2.2 und für diese Gruppe zentral: Zielgröße mindestens **24 × 24 CSS-Pixel** ([2.5.8](https://html-einfach.de/wcag-und-bfsg/kriterien/2-5-8-zielgroesse-minimum.html)) und Ziehbewegungen nur mit Alternative ([2.5.7](https://html-einfach.de/wcag-und-bfsg/kriterien/2-5-7-ziehbewegungen.html)). - Fitts' Gesetz gilt für alle: Je kleiner und weiter entfernt ein Ziel, desto länger dauert der Weg dorthin. Bei Tremor dauert er überproportional länger, weil jeder Fehlversuch eine neue Bewegung kostet. - Zeit ist eine Barriere: Ein Session-Timeout mitten im Formular trifft genau die Menschen, die am längsten zum Ausfüllen brauchen ([2.2.1](https://html-einfach.de/wcag-und-bfsg/kriterien/2-2-1-zeitbegrenzungen-anpassbar.html)). - Der Selbsttest kostet nichts: Maus weglegen und den wichtigsten Ablauf nur mit `Tab`, `Enter` und Pfeiltasten durchspielen. ## Wer betroffen ist und wie viele „Motorisch eingeschränkt“ klingt nach Rollstuhl. Fürs Web entscheidet aber die Feinmotorik der Hände, und die ist aus sehr unterschiedlichen Gründen beeinträchtigt: - **Tremor** kommt bei Parkinson, essenziellem Tremor, als Nebenwirkung von Medikamenten oder schlicht altersbedingt vor. Der Zeiger zittert mit; kleine Ziele werden zum Glücksspiel. - **Spastik und Bewegungsstörungen** kommen bei Cerebralparese, nach einem Schlaganfall, bei Multipler Sklerose vor. Bewegungen setzen verzögert ein oder schießen über das Ziel hinaus. - **Kraft- und Ausdauerverlust** kommt bei Muskelerkrankungen, ALS, Rheuma vor. Nicht die einzelne Bewegung ist das Problem, sondern hundert Bewegungen hintereinander. - **Schmerz und Gelenksteife** entstehen durch Arthrose, Arthritis, Karpaltunnelsyndrom, Sehnenscheidenentzündung. Betrifft Millionen, wird selten als Behinderung eingeordnet und wirkt sich am Bildschirm trotzdem genauso aus. - **Lähmungen und Amputationen** lassen die Maus vollständig ausfallen. Gearbeitet wird dann mit alternativer Hardware. Zwei Dinge sind daran wichtig. Erstens ist der Übergang zur übrigen Nutzerschaft fließend: [Situative Einschränkungen](https://html-einfach.de/barrierefreiheit-verstehen/situative-und-temporaere-einschraenkungen.html) wie eine Hand am Haltegriff im Bus erzeugen dieselben Probleme. Zweitens steigt die Häufigkeit mit dem Alter steil an und die Nutzerschaft der meisten Websites altert mit. ## Wie Betroffene bedienen
Diagramm mit fünf Eingabewegen auf der linken Seite: Tastatur, Sprachsteuerung, Kopf- oder Mundmaus, Eye-Tracking und Taster. Pfeile führen von allen fünf auf zwei gemeinsame Kästen in der Mitte mit den Beschriftungen Fokus setzen und Element aktivieren. Von dort führt ein Pfeil auf einen Kasten rechts mit der Aussage, dass die Website in allen fünf Fällen dasselbe sieht. Darunter der Hinweis, dass es kein eigenes Markup für Kopfmaus oder Eye-Tracking gibt.
Fünf sehr verschiedene Geräte, zwei Ereignisse: Deine Seite muss keine Hardware kennen. Sie muss Fokus und Aktivierung sauber unterstützen.
**Nur Tastatur.** Wer nicht zielen kann, navigiert mit `Tab`, `Umschalt+Tab`, `Enter`, Leertaste und Pfeiltasten. Das ist präzise, weil jede Taste ein eindeutiges Ereignis auslöst (kein Millimeter dazwischen). Wie das im Detail abläuft, steht unter [Tastatur- und Switch-Bedienung](https://html-einfach.de/barrierefreiheit-verstehen/tastatur-und-switch-bedienung.html). **Sprachsteuerung.** Dragon, Voice Control und Voice Access führen Klicks per Befehl aus. Dafür müssen sichtbare Beschriftung und technischer Name zusammenpassen. Die Details stehen unter [Sprachsteuerung](https://html-einfach.de/barrierefreiheit-verstehen/sprachsteuerung.html). **Spezialhardware.** Kopfmaus, Mundmaus, große Trackballs, Eye-Tracking, Taster. Fast alle verhalten sich gegenüber der Website wie Tastatur oder Zeiger. Ein eigenes „Eye-Tracking-HTML“ gibt es nicht. **Touch mit Einschränkungen.** Auf dem Smartphone wird mit dem Daumen, dem Handballen oder einem Stift getroffen: zittrig, ungenau, oft einhändig. Genau deshalb ist Zielgröße kein reines Desktop-Thema. Ein Punkt, der dabei gern übersehen wird: Wer langsam zielt, trifft auch langsam und trifft dann auf eine Seite, die noch mit dem Laden beschäftigt ist. Verzögerte Reaktionen auf Eingaben trifft die Gruppe doppelt, weil ein nicht quittierter Klick zum zweiten Klick verleitet. Gemessen wird das als INP; wie man es senkt, steht unter [LCP & INP gezielt optimieren](https://html-einfach.de/seo-und-ki/lcp-und-inp-optimieren.html). ## Fitts' Gesetz: warum Zielgröße kein Detail ist Fitts' Gesetz beschreibt, wie lange eine Zeigebewegung dauert: Sie wächst mit der Entfernung und schrumpft mit der Zielgröße. Bei Tremor verschiebt sich diese Kurve dramatisch, weil jeder Fehlversuch eine komplett neue Bewegung verlangt. Das kostet wieder Zeit und Kraft.
Drei nebeneinandergestellte Fassungen derselben Icon-Leiste mit den Schaltflächen Teilen, Merken und Löschen. Links, rot markiert: Trefferflächen von 16 mal 16 Pixeln ohne Abstand dazwischen, mit dem Vermerk, dass 2.5.8 nicht erfüllt ist. In der Mitte, gelb: 24 mal 24 Pixel mit 4 Pixeln Abstand, Mindestmaß erfüllt. Rechts, grün: 44 mal 44 Pixel mit 8 Pixeln Abstand, komfortabel auch bei Tremor. Über jeder Fassung ist ein zittriger Zeigerpfad eingezeichnet, der links zweimal danebentrifft und rechts sicher landet.
Die 24 Pixel aus WCAG 2.2 sind die Untergrenze, nicht das Ziel. Ab etwa 44 Pixeln wird die Bedienung auch mit zitternder Hand entspannt.
Die gute Nachricht: Die Trefferfläche muss nicht so groß aussehen, wie sie ist. Ein kleines Symbol darf klein bleiben, solange der klickbare Bereich darum herum wächst. ```css /* Falsch: 16 × 16 px echte Trefferfläche, dicht an dicht */ .icon-btn { width: 16px; height: 16px; padding: 0; } /* Richtig: Optik bleibt klein, die Trefferfläche wächst auf 44 × 44 px */ .icon-btn { position: relative; width: 16px; height: 16px; padding: 0; } .icon-btn::after { content: ''; position: absolute; inset: -14px; /* 16 + 2 × 14 = 44 px */ } .icon-btn + .icon-btn { margin-left: 12px; } /* Ziele nicht verkleben */ ``` Die Ausnahmen des Kriteriums (etwa Links im Fließtext) stehen unter [2.5.8 Zielgröße (Minimum)](https://html-einfach.de/wcag-und-bfsg/kriterien/2-5-8-zielgroesse-minimum.html). ## Die Muster, die am häufigsten scheitern **Aktion beim Drücken statt beim Loslassen.** Wer danebenklickt, muss den Fehler zurücknehmen können, indem er den Zeiger vor dem Loslassen wegzieht. Genau das verlangt [2.5.2 Zeiger-Abbruch](https://html-einfach.de/wcag-und-bfsg/kriterien/2-5-2-zeiger-abbruch.html). ```js // Falsch: löst schon beim Aufsetzen des Fingers aus und lässt kein Zurück mehr zu el.addEventListener('pointerdown', loeschen); // Richtig: click feuert erst, wenn Drücken und Loslassen auf dem Element passieren el.addEventListener('click', loeschen); ``` **Ziehen ohne Alternative.** Dazu zählen etwa das Umsortieren einer Liste, das Bewegen eines Reglers oder das Verschieben einer Karte. Jede Ziehbewegung braucht seit [2.5.7](https://html-einfach.de/wcag-und-bfsg/kriterien/2-5-7-ziehbewegungen.html) einen zweiten Weg über einfache Zeigeraktionen. ```html
  • Kapitel 3: Formulare
    • ``` **Menüs, die nur auf Hover reagieren.** Ein Untermenü, das sich nur öffnet, solange der Zeiger ruhig darauf steht, ist bei Tremor unbedienbar. Menüs gehören auf Klick und `Enter`. Muster dazu stehen unter [Menüs und Dropdowns](https://html-einfach.de/barrierefreie-komponenten/menues-und-dropdowns.html). **Doppelklick als einziger Weg.** Ein Doppelklick verlangt zwei Klicks in unter 500 Millisekunden auf demselben Punkt. Als einzige Möglichkeit, eine Funktion zu erreichen, schließt er aus. **Timeouts.** Ein Warenkorb, der nach 15 Minuten leer ist, bestraft Langsamkeit. Die Verlängerung muss vor dem Ablauf angeboten werden, nicht danach. **Eingaben, die verloren gehen.** Wenn ein Formular bei einem Fehler geleert wird, kostet das jemanden mit Tremor unter Umständen zwanzig Minuten Arbeit. Eingaben bleiben stehen und was schon bekannt ist, wird [nicht noch einmal abgefragt](https://html-einfach.de/wcag-und-bfsg/kriterien/3-3-7-redundante-eingabe.html). ## So testest du es 1. **Maus weglegen** und den wichtigsten Ablauf komplett mit `Tab`, `Enter`, Leertaste und Pfeiltasten durchspielen (Suche, Filter, Warenkorb, Formular). 2. **Zielgrößen messen:** In den DevTools ein Symbol auswählen und im Box-Modell prüfen, ob die klickbare Fläche mindestens 24 × 24 CSS-Pixel misst, Abstand zum Nachbarn eingerechnet. 3. **Mit der anderen Hand bedienen.** Klingt albern, wirkt sofort: Maus auf die andere Seite legen, dann die Seite benutzen. Jede zu kleine Fläche fällt in Sekunden auf. 4. **Klick abbrechen:** Auf einer Schaltfläche die Maustaste drücken, den Zeiger wegziehen, loslassen. Passiert trotzdem etwas, ist 2.5.2 verletzt. 5. **Ziehen umgehen:** Jede Drag-Funktion einmal ohne Ziehen erledigen. Geht es nicht, fehlt die Alternative. 6. **Warten:** Ein Formular öffnen, zwanzig Minuten liegen lassen, dann absenden. Sind die Eingaben noch da, oder war alles umsonst? ## Häufiger Fehler in der Praxis **Zielgröße nur mobil geprüft.** Viele Teams halten am Smartphone 44 Pixel ein und bauen am Desktop 16-Pixel-Symbole dicht an dicht. Für eine Kopfmaus oder eine zitternde Hand ist der Desktop aber der schwierigere Fall, nicht der leichtere. **Der Symbol-Teppich in Tabellen.** Bearbeiten, Duplizieren, Löschen als drei winzige Zeichen ohne Abstand in jeder Zeile und Löschen liegt direkt neben Bearbeiten. Wenn schon eng, dann wenigstens die zerstörerische Aktion räumlich trennen und [bestätigen lassen](https://html-einfach.de/wcag-und-bfsg/kriterien/3-3-4-fehlervermeidung.html). **`outline: none` im CSS-Reset.** Ohne sichtbaren Fokus ist Tastaturbedienung Raten. Was stattdessen zu tun ist, steht unter [Tastaturbedienung & sichtbarer Fokus](https://html-einfach.de/wcag-und-bfsg/tastatur-und-fokus.html). **Selbstgebaute Regler und Scrollbars.** Beide setzen präzises Ziehen voraus und sind fast nie tastaturbedienbar. Der native `` kann beides von Haus aus. Siehe [Slider und Karussells](https://html-einfach.de/barrierefreie-komponenten/slider-und-karussells.html). **Nur mit der Maus getestet.** Der häufigste Fehler überhaupt und der billigste zu beheben. Ich würd jede Abnahme mit fünf Minuten Tastaturbedienung beginnen lassen. Danach ist die Prioritätendiskussion meist vorbei. ## Häufige Fragen ### Ist Tastaturbedienung nicht ein Nischen-Feature? Nein, sie ist der gemeinsame Nenner fast aller assistiven Technologien. Screenreader, Switch-Systeme, Kopfmäuse und viele Sprachsteuerungen setzen auf denselben Fokus- und Aktivierungsmechanismen auf. Wer den Tastatur-Durchlauf besteht, hat einen Großteil der motorischen Barrieren beseitigt und nebenbei jede Power-Userin glücklich gemacht. ### Reicht eine kleine Verzögerung, damit Hover-Menüs offen bleiben? Sie hilft, ersetzt aber keine Klick-Bedienung. Ein Menü sollte per Klick beziehungsweise `Enter` öffnen und schließen; Hover darf Komfort obendrauf sein, nie Voraussetzung. Zusätzlich gilt für alles, was bei Hover erscheint, [1.4.13](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-13-inhalt-bei-hover-oder-fokus.html): Es muss wegdrückbar bleiben und stehen bleiben, wenn man mit dem Zeiger hineinfährt. ### Was ist mit Touch-Gesten wie Wischen oder Zwei-Finger-Zoom? Komplexe Gesten brauchen eine einfache Alternative. Das regelt [2.5.1 Zeigergesten](https://html-einfach.de/wcag-und-bfsg/kriterien/2-5-1-zeigergesten.html). Ein Karussell braucht sichtbare Vor- und Zurück-Schaltflächen, eine Karte Zoom-Schaltflächen neben der Pinch-Geste. Für Menschen, die nur einen Finger sicher aufsetzen können, ist alles andere unerreichbar. ### Muss ich 24 × 24 Pixel einhalten oder 44 × 44? Rechtlich reichen 24 × 24 CSS-Pixel, weil EN 301 549 auf die WCAG verweist und [2.5.8](https://html-einfach.de/wcag-und-bfsg/kriterien/2-5-8-zielgroesse-minimum.html) dort auf Stufe AA steht; 44 × 44 ist die Empfehlung der Plattform-Richtlinien und die AAA-Variante. Meine Praxisregel: 24 als harte Grenze in dichten Werkzeugleisten, 44 überall dort, wo eine Aktion Geld, Daten oder Zeit kostet. ### Hilft ein Barrierefreiheits-Overlay bei motorischen Einschränkungen? Nein. Overlays vergrößern manchmal Zeiger oder Schrift, ändern aber nichts an Trefferflächen, Fokusreihenfolge oder Drag-Zwang und sie kollidieren regelmäßig mit Sprachsteuerung und Switch-Systemen. Die Ursachen liegen im Markup, nicht in einer Zusatzschicht; warum ich davon abrate, steht unter [Tools](https://html-einfach.de/ressourcen/tools.html). ## Verwandte Themen - [Tastatur- und Switch-Bedienung](https://html-einfach.de/barrierefreiheit-verstehen/tastatur-und-switch-bedienung.html): wie Scanning funktioniert und welche Tastenkonventionen gelten - [Sprachsteuerung](https://html-einfach.de/barrierefreiheit-verstehen/sprachsteuerung.html): bedienen mit der Stimme, wenn die Hände ausfallen - [Situative und temporäre Einschränkungen](https://html-einfach.de/barrierefreiheit-verstehen/situative-und-temporaere-einschraenkungen.html): dieselben Barrieren, deutlich mehr Betroffene - [Tastaturbedienung & sichtbarer Fokus](https://html-einfach.de/wcag-und-bfsg/tastatur-und-fokus.html): die Praxisseite mit CSS-Rezepten - [Buttons vs. Links](https://html-einfach.de/barrierefreie-komponenten/buttons-vs-links.html): warum das richtige Element die halbe Arbeit spart - [WCAG 2.2 Kriterien](https://html-einfach.de/wcag-und-bfsg/wcag-2-2-kriterien.html): die neuen Kriterien zielen fast alle auf diese Gruppe ## Quellen --- # Kognition & Neurodiversität: verständliche Websites - URL: https://html-einfach.de/barrierefreiheit-verstehen/kognition-und-neurodiversitaet.html - Themenbereich: Barrierefreiheit verstehen - Zuletzt geändert: 2026-07-15 - Kurzbeschreibung: Kognition und Neurodiversität im Web: 6,2 Mio. gering literalisierte Erwachsene, 1,8 Mio. mit Demenz und wie du die kognitive Last deiner Seite senkst. **Kognitive Barrieren sind die häufigsten im Web und zugleich die unsichtbarsten: Sie entstehen nicht durch fehlenden Kontrast oder fehlendes Markup, sondern durch zu viel Text, zu viele Optionen, unerwartetes Verhalten und Aufgaben, die das Gedächtnis überlasten. Die Gegenmaßnahme lässt sich in einen Satz fassen. Sie senkt die kognitive Last: weniger merken müssen, weniger entschlüsseln müssen, weniger überrascht werden.** ## Das Wichtigste in Kürze - Rund **6,2 Millionen** deutschsprechende Erwachsene zwischen 18 und 64 Jahren sind gering literalisiert und haben Mühe mit zusammenhängenden Texten. Das sind **12,1 %** dieser Altersgruppe ([LEO-Studie 2018](https://leo.blogs.uni-hamburg.de/leo-2018-62-millionen-gering-literalisierte-erwachsene/), Universität Hamburg). - Etwa **1,8 Millionen** Menschen in Deutschland leben mit einer Demenz; 2023 kamen bis zu 445.000 Neuerkrankungen ab 65 Jahren hinzu, rechnerisch rund 900 pro Tag (Deutsche Alzheimer Gesellschaft). - Neurodiversität bündelt Autismus, ADHS, Legasthenie und weitere neurologische Unterschiede. Das ist kein Defizit, sondern eine Ausprägung menschlicher Vielfalt. Fürs Web zählt daraus vor allem: Vorhersehbarkeit und Ruhe. - Der gemeinsame Nenner aller Gruppen ist **kognitive Last**. Jede Entscheidung, jede gemerkte Zahl und jede Überraschung kostet Kapazität, die dann für die eigentliche Aufgabe fehlt. - Harte Sprachanforderungen stehen in den WCAG erst auf Stufe AAA. Auf AA greifen Konsistenz ([3.2.3](https://html-einfach.de/wcag-und-bfsg/kriterien/3-2-3-konsistente-navigation.html), [3.2.4](https://html-einfach.de/wcag-und-bfsg/kriterien/3-2-4-konsistente-erkennung.html)), Vorhersehbarkeit ([3.2.1](https://html-einfach.de/wcag-und-bfsg/kriterien/3-2-1-bei-fokus.html), [3.2.2](https://html-einfach.de/wcag-und-bfsg/kriterien/3-2-2-bei-eingabe.html)) und Fehlerbehandlung ([3.3.1](https://html-einfach.de/wcag-und-bfsg/kriterien/3-3-1-fehlererkennung.html), [3.3.3](https://html-einfach.de/wcag-und-bfsg/kriterien/3-3-3-fehlervorschlag.html)). - WCAG 2.2 zielt mit zwei neuen Kriterien direkt aufs Gedächtnis: [3.3.7 Redundante Eingabe](https://html-einfach.de/wcag-und-bfsg/kriterien/3-3-7-redundante-eingabe.html) und [3.3.8 Zugängliche Authentifizierung](https://html-einfach.de/wcag-und-bfsg/kriterien/3-3-8-zugaengliche-authentifizierung.html). - Automatische Prüfwerkzeuge finden hier praktisch nichts. Kognitive Barrierefreiheit entscheidet sich in Texten, Abläufen und Timing. Also in Redaktion und Konzept. - Für Bundesbehörden geht die [BITV 2.0](https://html-einfach.de/wcag-und-bfsg/bitv-2-0-erklaert.html) weiter als die WCAG: § 4 verlangt Erläuterungen in Leichter Sprache auf der Startseite. > **Abgrenzung: Hier geht es um die Menschen.** Diese Seite beschreibt kognitive > Einschränkungen und was daraus für die Gestaltung folgt. Die Anforderungen der WCAG > und die acht COGA-Ziele stehen unter > [Kognitive Barrierefreiheit](https://html-einfach.de/wcag-und-bfsg/kognitive-barrierefreiheit.html). ## Das Spektrum: sehr verschieden, ein gemeinsames Prinzip - **Lernschwierigkeiten und geistige Behinderung.** Schachtelsätze, Fachsprache und Abstraktion sind die Barriere. Hier helfen [Leichte Sprache](https://html-einfach.de/wcag-und-bfsg/leichte-sprache.html) und Einfache Sprache, Bilder als Verständnisstütze und kurze, klar getrennte Schritte. - **ADHS und Aufmerksamkeitsstörungen.** Alles, was blinkt, rotiert oder sich von selbst bewegt, zieht Aufmerksamkeit ab. Deshalb müssen sich [bewegte Inhalte pausieren lassen](https://html-einfach.de/wcag-und-bfsg/kriterien/2-2-2-pausieren-beenden-ausblenden.html), und deshalb wirken Aufzählungen besser als Textblöcke. - **Autismus.** Die Hürde ist Unvorhersehbarkeit: Seiten, die bei [Fokus](https://html-einfach.de/wcag-und-bfsg/kriterien/3-2-1-bei-fokus.html) oder [Eingabe](https://html-einfach.de/wcag-und-bfsg/kriterien/3-2-2-bei-eingabe.html) den Kontext wechseln, Menüs, die auf jeder Unterseite anders aussehen, Formulierungen, die etwas anderes meinen, als sie sagen. Auch grelle Reize und Bewegung können überfordern. - **Legasthenie.** Lange Zeilen, Blocksatz, enge Zeilenabstände und Großbuchstaben erschweren das Lesen. Angepasste [Textabstände](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-12-textabstaende.html) müssen möglich bleiben, ohne dass das Layout zerfällt. - **Gedächtnis-Einschränkungen, unter anderem Demenz.** Codes abtippen, Passwörter erinnern, Informationen zwischen zwei Schritten im Kopf behalten. Jede dieser Anforderungen schließt aus. - **Psychische Erkrankungen.** Angststörungen und Depressionen stehen selten auf der Liste, wirken sich aber aus: Countdown-Timer, Druckformulierungen und unklare Folgen erhöhen die Hürde, einen Vorgang überhaupt zu beginnen.
    Schema mit einem waagerechten Balken, der die verfügbare geistige Kapazität darstellt. Von oben drücken vier beschriftete Blöcke darauf: Text entschlüsseln, Optionen abwägen, Dinge merken und Überraschungen verarbeiten. Rechts bleibt nur ein schmaler Rest übrig, beschriftet mit Kapazität für die eigentliche Aufgabe. Unter jedem der vier Blöcke steht die passende Gegenmaßnahme: kurze Sätze und bekannte Wörter, weniger und klarer benannte Optionen, Eingaben übernehmen statt erneut abfragen, sowie konsistente Navigation ohne Kontextwechsel.
    Kognitive Last ist ein Budget: Was Entschlüsseln, Abwägen, Merken und Überrascht-Werden verbrauchen, fehlt für die Aufgabe, wegen der jemand überhaupt gekommen ist.
    ## Sprache: drei Stufen, ein Zweck Verständlichkeit wird oft mit „Leichter Sprache“ gleichgesetzt. Tatsächlich gibt es drei unterscheidbare Stufen, und die mittlere reicht in der Praxis am weitesten: | Stufe | Merkmale | Wofür | | --- | --- | --- | | **Standardsprache, gut gemacht** | kurze Hauptsätze, bekannte Wörter, aktive Formulierungen | der Normalfall für alle Inhalte | | **Einfache Sprache** | etwa 15 Wörter pro Satz, keine Schachtelsätze, Fachbegriffe erklärt | Kernseiten, Formulare, Hilfetexte | | **Leichte Sprache** | ein Gedanke pro Satz, große Schrift, Bilder, festes Regelwerk | Pflichtangaben bei Behörden, Zielgruppenangebote | Der Schritt von Stufe eins zu zwei kostet fast nichts und wirkt sofort. „Die Antragstellung erfolgt ausschließlich in elektronischer Form“ wird zu „Sie stellen den Antrag online“ (gleiche Aussage, halbe Last). Ich würd damit immer bei den Texten anfangen, die im kritischen Pfad stehen: Formularhilfen, Fehlermeldungen, Checkout, Kontaktseite. Die sprachliche Seite vertieft [Kognitive Barrierefreiheit](https://html-einfach.de/wcag-und-bfsg/kognitive-barrierefreiheit.html). Die stark regulierte Variante beschreibt [Leichte Sprache im Web](https://html-einfach.de/wcag-und-bfsg/leichte-sprache.html). ## Fehlermeldungen: der teuerste Satz deiner Seite Nirgends entscheidet sich schneller, ob jemand einen Vorgang abschließt. Eine Fehlermeldung muss drei Fragen beantworten: Was ist passiert, wo, und was soll ich jetzt tun?
    Gegenüberstellung zweier Formularfehler. Links, rot markiert: ein Eingabefeld mit der Meldung Eingabe ungültig, Fehlercode 4711, darunter drei offene Fragen: welches Feld, was ist falsch, was soll ich tun. Rechts, grün markiert: dasselbe Feld mit dem Hinweis Format TT Punkt MM Punkt JJJJ über dem Feld und der Meldung Bitte das Datum im Format TT.MM.JJJJ eingeben, zum Beispiel 24.08.2026, darunter dieselben drei Fragen als beantwortet abgehakt.
    Dieselbe Prüfung, zwei Meldungen: Die rechte nennt Ort, Ursache und Lösung und spart damit den Anruf bei der Hotline.
    ```html

    Eingabe ungültig (Fehlercode 4711)

    Format: TT.MM.JJJJ

    Bitte das Datum im Format TT.MM.JJJJ eingeben, zum Beispiel 24.08.2026.

    ``` Zwei Details machen den Unterschied. Der **Hinweis steht vor der Eingabe**, nicht erst im Fehlerfall. Dann muss ihn niemand aus einer Meldung rekonstruieren. Und das **Beispiel ersetzt die Regel**: „TT.MM.JJJJ“ ist eine Formel, „24.08.2026“ ist ein Muster zum Abschauen. Mehr dazu unter [Fehlermeldungen barrierefrei](https://html-einfach.de/barrierefreie-komponenten/fehlermeldungen-barrierefrei.html). ## Gedächtnis entlasten statt abfragen WCAG 2.2 hat zwei Kriterien ergänzt, die genau auf diese Gruppe zielen. **[3.3.7 Redundante Eingabe](https://html-einfach.de/wcag-und-bfsg/kriterien/3-3-7-redundante-eingabe.html):** Was im selben Vorgang schon eingegeben wurde, wird nicht noch einmal verlangt. Die Lieferadresse wird also vorbelegt oder ist auswählbar, nicht neu abgefragt. **[3.3.8 Zugängliche Authentifizierung](https://html-einfach.de/wcag-und-bfsg/kriterien/3-3-8-zugaengliche-authentifizierung.html):** Kein Login-Schritt darf einen kognitiven Test verlangen. Passwörter auswendig tippen, Zeichenrätsel lösen, Codes aus einer anderen App abschreiben. All das braucht eine Alternative, und das Einfügen aus der Zwischenablage muss erlaubt bleiben. ```html ``` Das `autocomplete`-Attribut ist hier kein Komfort, sondern Kern der Barrierefreiheit: Es lässt Browser und Passwortmanager die Arbeit übernehmen und deckt nebenbei [1.3.5 Eingabezweck bestimmen](https://html-einfach.de/wcag-und-bfsg/kriterien/1-3-5-eingabezweck-bestimmen.html) ab. Die vollständige Attributliste steht unter [Formular-Semantik](https://html-einfach.de/semantisches-html/formular-semantik.html). ## Ruhe ins Layout Bewegung ist für Menschen mit ADHS, Autismus, Migräne oder vestibulären Störungen keine Deko, sondern Störung. Zwei Regeln decken das meiste ab: Alles, was länger als fünf Sekunden automatisch läuft, braucht eine Pause-Möglichkeit ([2.2.2](https://html-einfach.de/wcag-und-bfsg/kriterien/2-2-2-pausieren-beenden-ausblenden.html)) und die Systemeinstellung für reduzierte Bewegung wird respektiert. ```css /* Animation nur, wenn niemand ausdrücklich Ruhe eingestellt hat */ @media (prefers-reduced-motion: no-preference) { .karte { transition: transform 0.25s ease; } .karte:hover { transform: translateY(-4px); } } /* Sicherheitsnetz für alles, was doch animiert wird */ @media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; scroll-behavior: auto !important; } } ``` Dazu gehört, künstlichen Druck wegzulassen: Countdown im Checkout, „Nur noch 2 verfügbar!“, Pop-up nach drei Sekunden. Was als Konversionshebel gedacht ist, wirkt bei Angststörungen und Konzentrationsschwierigkeiten als Abbruchgrund. ## So testest du es 1. **Lies deine Fehlermeldungen laut vor.** Beantwortet jede die Fragen „was, wo, was nun“? Meldungen mit Fehlercode ohne Klartext fallen sofort durch. 2. **Zähle die Entscheidungen** auf der Startseite: konkurrierende Banner, Slider, Pop-ups, Handlungsaufforderungen. Mehr als drei gleichrangige Angebote sind eine Barriere, keine Auswahl. 3. **Aktiviere „Bewegung reduzieren“** (macOS: Bedienungshilfen → Anzeige; Windows: Einstellungen → Barrierefreiheit → Visuelle Effekte) und lade die Seite neu. Steht danach wirklich alles still? 4. **Mach den Formular-Test:** halb ausfüllen, absichtlich einen Fehler einbauen, absenden. Bleiben die Eingaben stehen? Springt der Fokus zur Meldung? Steht ein Beispiel dabei? 5. **Prüfe den Login:** Lässt sich das Passwort einfügen? Arbeitet der Passwortmanager? Gibt es einen Weg ohne Zeichenrätsel? 6. **Lass jemand Fachfremden eine Aufgabe lösen** und schau nur zu. Jede Stelle, an der nachgefragt wird, ist eine Stelle, an der der Text nicht reicht. ## Häufiger Fehler in der Praxis **Verständlichkeit an der Konformitätsstufe festgemacht.** Weil die harten Sprachkriterien auf AAA stehen, fällt Verständlichkeit aus dem Prüfumfang und damit aus dem Projekt. Dabei verhindert sie die meisten Abbrüche und kostet praktisch nichts. **Leichte Sprache als Alibi-Unterseite.** Eine separate Seite in Leichter Sprache, während das Hauptangebot Behördendeutsch bleibt, verschiebt das Problem nur. Sinnvoller ist, den Hauptinhalt auf Einfache Sprache zu heben und Leichte Sprache dort einzusetzen, wo sie vorgeschrieben oder wirklich passend ist. **Platzhalter statt Label.** Grauer Text im Feld verschwindet beim Tippen und mit ihm die Information, was dort hingehört. Für Menschen mit Gedächtniseinschränkungen ist das der klassische Abbruchpunkt; siehe [Labels und Beschriftungen](https://html-einfach.de/barrierefreie-komponenten/labels-und-beschriftungen.html). **Fortschritt ohne Ziel.** Ein mehrstufiges Formular ohne sichtbare Schrittanzeige zwingt dazu, den Überblick im Kopf zu behalten. „Schritt 2 von 4“ kostet eine Zeile und nimmt spürbar Last. Mehr dazu unter [mehrstufige Formulare](https://html-einfach.de/barrierefreie-komponenten/mehrstufige-formulare.html). **Symbole ohne Text.** Ein Zahnrad, ein Herz oder drei Punkte entschlüsseln geübte Nutzer automatisch, andere raten. Eine Beschriftung neben dem Symbol ist die günstigste Verständlichkeitsmaßnahme überhaupt. ## Häufige Fragen ### Verlangen die WCAG überhaupt verständliche Sprache? Nur begrenzt. Das Prinzip „Verständlich“ liefert auf A und AA Kriterien zu Konsistenz, Vorhersehbarkeit und Fehlerbehandlung; harte Sprachanforderungen wie ein maximales Leseniveau stehen auf Stufe AAA. Die [BITV 2.0](https://html-einfach.de/wcag-und-bfsg/bitv-2-0-erklaert.html) geht für öffentliche Stellen weiter und verlangt Erläuterungen in Leichter Sprache. Mein Rat: Verständlichkeit nicht an der Konformitätsstufe festmachen. ### Ist das nicht einfach gutes UX-Design? Ja, und das ist der Punkt. Kognitive Barrierefreiheit und gute Usability überschneiden sich fast vollständig. Der Unterschied liegt in der Folge: Was für andere „nervig“ ist, beendet für Betroffene den Vorgang, weil ihnen die Ausweichstrategie fehlt. ### Was ist der Unterschied zwischen Leichter und Einfacher Sprache? Leichte Sprache folgt einem festen Regelwerk: ein Gedanke pro Satz, keine Nebensätze, große Schrift, erklärende Bilder, oft geprüft von Menschen aus der Zielgruppe. Einfache Sprache ist freier: kurze Hauptsätze, gängige Wörter, erklärte Fachbegriffe, etwa 15 Wörter pro Satz. Für die meisten Websites ist Einfache Sprache der richtige Standard, Leichte Sprache das Zusatzangebot. ### Hilft eine serifenlose Schrift bei Legasthenie? Sie schadet nicht, ist aber weit weniger wichtig als Zeilenlänge, Zeilenabstand und Flattersatz. Wirksamer sind 60 bis 80 Zeichen pro Zeile, ein Zeilenabstand um 1,5, linksbündiger Satz statt Blocksatz und keine Großbuchstaben im Fließtext. Und vor allem: Nutzereinstellungen nicht blockieren, damit eigene Schriften und [Textabstände](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-12-textabstaende.html) greifen können. ### Wo fange ich an, wenn ich wenig Zeit habe? Bei den Texten im kritischen Pfad: Formularhilfen, Fehlermeldungen, Checkout, Kontaktseite. Danach der Login, dann Bewegung und Konsistenz. Das sind drei Nachmittage mit mehr Wirkung als jedes Overlay und automatisch prüfen lässt sich davon nichts, weshalb es sonst niemand macht. ## Verwandte Themen - [Kognitive Barrierefreiheit](https://html-einfach.de/wcag-und-bfsg/kognitive-barrierefreiheit.html): die sprachliche Vertiefung mit Regelwerk - [Fehlermeldungen barrierefrei](https://html-einfach.de/barrierefreie-komponenten/fehlermeldungen-barrierefrei.html): Aufbau, Verknüpfung und Ansage - [Mehrstufige Formulare](https://html-einfach.de/barrierefreie-komponenten/mehrstufige-formulare.html): Fortschritt zeigen, Eingaben bewahren - [Situative und temporäre Einschränkungen](https://html-einfach.de/barrierefreiheit-verstehen/situative-und-temporaere-einschraenkungen.html): warum Müdigkeit und Stress dieselben Barrieren erzeugen - [Überschriften-Hierarchie](https://html-einfach.de/semantisches-html/ueberschriften-hierarchie.html): die Struktur, die Überfliegen erst möglich macht - [Semantik und SEO](https://html-einfach.de/seo-und-ki/semantik-und-seo.html): warum klare Sprache auch Suchmaschinen und KI-Systeme hilft ## Quellen --- # Farbfehlsichtigkeit: was Betroffene wirklich sehen - URL: https://html-einfach.de/barrierefreiheit-verstehen/farbfehlsichtigkeit.html - Themenbereich: Barrierefreiheit verstehen - Zuletzt geändert: 2026-08-10 - Kurzbeschreibung: Farbfehlsichtigkeit verstehen: die vier Typen, wie viele Menschen betroffen sind, welche Farbpaare zusammenfallen und wie Bedeutung ohne Farbe funktioniert. **Etwa 8 Prozent der Männer und 0,5 Prozent der Frauen mit nordeuropäischer Herkunft haben eine angeborene Farbfehlsichtigkeit. In einer typischen Nutzergruppe ist das also jeder zwölfte Mann. Das ist kein Sehen in Graustufen: Betroffene sehen Farben, aber bestimmte Paare fallen zusammen. Rot und Grün sind der bekannte Fall, Blau und Violett oder Orange und Hellgrün die weniger bekannten. Die Lösung ist nie eine andere Palette, sondern ein zweites Signal neben der Farbe.** Farbfehlsichtigkeit ist auf dieser Website bislang ein Teilaspekt von [Sehbehinderung & Blindheit](https://html-einfach.de/barrierefreiheit-verstehen/sehbehinderung-und-blindheit.html) gewesen. Sie verdient eine eigene Seite, weil sie eine andere Nutzergruppe betrifft, andere Designentscheidungen auslöst und mit den Kontrastregeln der WCAG nur teilweise erfasst wird. ## Das Wichtigste in Kürze - **Rund 8 % der Männer** und 0,5 % der Frauen sind betroffen; die Vererbung läuft über das X-Chromosom. - **Vier Typen:** Deuteranomalie und Protanomalie (Rot-Grün, zusammen die große Mehrheit), Tritanomalie (Blau-Gelb, sehr selten) und Achromatopsie (kein Farbsehen, extrem selten). - **Es ist kein Graustufensehen.** Betroffene sehen Farben. Nur bestimmte Paare unterscheiden sie nicht. - **Die WCAG-Kontrastformel erfasst das nicht.** Zwei Farben können 4,5:1 erreichen und trotzdem ununterscheidbar sein. - **Zuständig ist [1.4.1 Benutzung von Farbe](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-1-benutzung-von-farbe.html)** (Stufe A): Farbe darf nie das einzige Mittel sein. - **Die Lösung ist immer ein zweites Signal:** Symbol, Muster, Beschriftung, Position. - **Der schnellste Test** ist ein Graustufen-Screenshot: Was dann seine Bedeutung verliert, ist der Befund. ## Die vier Typen und was tatsächlich zusammenfällt Das menschliche Farbsehen beruht auf drei Zapfentypen für langwelliges (Rot), mittelwelliges (Grün) und kurzwelliges Licht (Blau). Eine Farbfehlsichtigkeit entsteht, wenn einer davon verschoben ist (Anomalie) oder fehlt (Anopie). | Typ | Betroffen | Häufigkeit | Fällt zusammen | | --- | --- | --- | --- | | **Deuteranomalie / Deuteranopie** | Grün-Zapfen | häufigste Form, rund 5 % der Männer | Rot-Grün, Orange-Hellgrün, Braun-Grün | | **Protanomalie / Protanopie** | Rot-Zapfen | rund 2 % der Männer | Rot-Grün, zusätzlich wirkt Rot dunkler | | **Tritanomalie / Tritanopie** | Blau-Zapfen | sehr selten, unter 0,01 % | Blau-Grün, Gelb-Violett | | **Achromatopsie** | alle Zapfen | extrem selten | sämtliche Farben, meist mit starker Blendempfindlichkeit | Zwei Punkte daraus sind für die Praxis wichtig. Erstens ist die **Protanopie der unangenehmere Fall**, weil Rot nicht nur verwechselt, sondern auch deutlich dunkler wahrgenommen wird. Eine rote Warnfarbe auf dunklem Grund kann dabei fast verschwinden. Zweitens ist **Rot-Grün nicht die einzige Falle**: Orange gegen Hellgrün und Braun gegen Dunkelgrün trennen viele Betroffene ebenfalls nicht, und genau diese Paare tauchen in Diagrammpaletten regelmäßig auf. ## Warum Kontrast allein nicht reicht Ein verbreiteter Irrtum lautet, ausreichender Kontrast löse das Thema mit. Er löst es nicht, weil die [WCAG-Kontrastformel](https://html-einfach.de/wcag-und-bfsg/farbkontraste.html) mit der relativen Helligkeit rechnet und den Farbton ignoriert. Zwei Farben mit gleicher Helligkeit und unterschiedlichem Ton (etwa ein mittleres Rot und ein mittleres Grün) erreichen gegeneinander praktisch keinen Kontrast, gegen Weiß aber beide dieselben 4,5:1. Umgekehrt heißt das: Wer Bedeutung über zwei Farben transportiert, muss zusätzlich einen **Helligkeitsunterschied** einbauen (besser noch ein zweites, nicht farbliches Signal). Genau das verlangt [1.4.1 Benutzung von Farbe](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-1-benutzung-von-farbe.html) auf Stufe A, und zwar unabhängig vom erreichten Kontrastwert. ## Die fünf Stellen, an denen es in der Praxis scheitert **Formularvalidierung.** Ein rot umrandetes Pflichtfeld neben einem grün umrandeten korrekten Feld sieht für viele Betroffene identisch aus. Es braucht ein Symbol und einen Text. Die Umsetzung steht unter [Fehlermeldungen barrierefrei](https://html-einfach.de/barrierefreie-komponenten/fehlermeldungen-barrierefrei.html). **Status- und Ampelanzeigen.** „Grün = verfügbar, rot = vergriffen“ ist die häufigste Einzelbarriere in Onlineshops. Ein Wort daneben löst sie vollständig. **Diagramme.** Serien, die sich nur farblich unterscheiden, sind das klassische Problem. Wirksam sind Muster, direkte Beschriftungen an den Linien und unterschiedliche Linienformen. Siehe dazu [Barrierefreie Diagramme](https://html-einfach.de/barrierefreie-komponenten/barrierefreie-diagramme.html). **Links im Fließtext.** Ein Link, der sich nur durch die Farbe vom Text abhebt, ist für Betroffene nicht als Link erkennbar. Die WCAG erlauben das nur, wenn der Farbunterschied mindestens 3:1 zum umgebenden Text beträgt **und** beim Hover oder Fokus ein zweites Signal erscheint. Die haltbarere Lösung ist die Unterstreichung. **Karten und Heatmaps.** Rot-Grün-Skalen sind der Standard und die schlechteste Wahl. Farbverläufe von Hell nach Dunkel innerhalb eines Farbtons funktionieren für alle. ## So testest du es Vier Schritte, keiner davon dauert länger als fünf Minuten: 1. **Graustufen-Screenshot machen.** In den Chrome-DevTools über „Rendering“ → „Emulate vision deficiencies“ → „Achromatopsia“. Alles, was jetzt seine Bedeutung verliert, ist ein Befund nach 1.4.1. 2. **Die drei Simulationen durchgehen.** Dieselbe DevTools-Funktion bietet Protanopie, Deuteranopie und Tritanopie. Achte besonders auf Diagramme, Statusanzeigen und Formulare. 3. **Den Text lesen, nicht die Seite ansehen.** Kommt „der rote Kasten“, „siehe grün markiert“ oder „die Felder in Orange“ im Inhalt vor, fehlt eine zweite Kennzeichnung. Das ist zugleich ein Verstoß gegen [1.3.3 Sensorische Eigenschaften](https://html-einfach.de/wcag-und-bfsg/kriterien/1-3-3-sensorische-eigenschaften.html). 4. **Kontrast trotzdem messen.** Die Simulation ersetzt die Zahlen nicht; die Werte prüfst du mit dem [Kontrast-Check](https://html-einfach.de/ressourcen/kontrast-check.html). Was die Simulation **nicht** kann: Sie zeigt eine Annäherung, keine Erfahrung. Anomalien (die Mehrheit der Fälle) sind schwächer ausgeprägt als die simulierten Anopien. Ein Befund in der Simulation ist trotzdem einer, aber das Umgekehrte gilt nicht automatisch. ## Häufiger Fehler in der Praxis **Eine eigene „Farbenblind-Palette“ anbieten.** Das ist gut gemeint und löst nichts: Niemand findet einen versteckten Umschalter, und die verschiedenen Typen bräuchten verschiedene Paletten. Ein zweites Signal hilft allen, ohne Umschalter. **Rot und Grün durch Blau und Orange ersetzen** und das Thema für erledigt halten. Die Kombination ist besser unterscheidbar, aber Bedeutung hängt weiterhin allein an der Farbe. **Die Ampel behalten und ein Icon in derselben Farbe danebensetzen.** Ein rotes Kreuz neben einem roten Feld fügt nichts hinzu, solange die Form nicht unterscheidbar ist. **Nur mit Achromatopsie testen.** Sie ist der härteste Fall und findet fast alles, aber sie verdeckt, dass Protanopie zusätzlich die Helligkeit verschiebt. ## Häufige Fragen ### Sehen farbfehlsichtige Menschen alles in Grau? Nein, das ist der verbreitetste Irrtum. Sie sehen Farben, unterscheiden aber bestimmte Paare nicht. Vollständige Farbenblindheit (Achromatopsie) betrifft weit weniger als ein Promille der Bevölkerung. ### Muss ich Rot und Grün ganz vermeiden? Nein. Du musst nur sicherstellen, dass die Information nicht allein an der Farbe hängt. Eine rote Fehlermeldung mit Symbol und Text ist vollkommen in Ordnung. ### Reicht es, wenn der Kontrast stimmt? Nein. Die Kontrastformel rechnet mit Helligkeit, nicht mit Farbton. Zwei gleich helle Farben können ununterscheidbar sein und trotzdem gegen Weiß bestehen. ### Zählt Farbfehlsichtigkeit als Behinderung? Rechtlich meist nicht, für die Barrierefreiheit sehr wohl: Die WCAG erfassen sie über 1.4.1, unabhängig von jeder Einstufung. Praktisch ist sie die häufigste Wahrnehmungseinschränkung überhaupt. ## Verwandte Themen - [Sehbehinderung & Blindheit](https://html-einfach.de/barrierefreiheit-verstehen/sehbehinderung-und-blindheit.html): das größere Spektrum, in dem Farbfehlsichtigkeit ein Sonderfall ist - [Farbkontraste richtig einstellen](https://html-einfach.de/wcag-und-bfsg/farbkontraste.html): die Werte und die Grenzen der Formel - [Barrierefreiheit im UX- und UI-Design](https://html-einfach.de/barrierefreiheit-verstehen/fuer-das-design.html): wo diese Entscheidungen fallen - [Barrierefreie Diagramme](https://html-einfach.de/barrierefreie-komponenten/barrierefreie-diagramme.html): der Anwendungsfall mit dem größten Hebel ## Quellen --- # Alter: die größte Gruppe mit Einschränkungen - URL: https://html-einfach.de/barrierefreiheit-verstehen/alter-und-barrierefreiheit.html - Themenbereich: Barrierefreiheit verstehen - Zuletzt geändert: 2026-08-14 - Kurzbeschreibung: Ältere Menschen sind die größte Gruppe mit Einschränkungen (meist mehreren zugleich). Was sich mit dem Alter ändert und welche acht Maßnahmen wirklich wirken. **Mit dem Alter ändern sich Sehschärfe, Kontrastempfindlichkeit, Feinmotorik, Reaktionsgeschwindigkeit, Gehör und Arbeitsgedächtnis und zwar in aller Regel gleichzeitig und schleichend. Das macht ältere Menschen zur größten Gruppe mit Einschränkungen und zugleich zu der, die sich am wenigsten als betroffen versteht: Mit 70 sagt niemand „ich bin sehbehindert“. Man hält die Seite für kaputt und geht.** Auf dieser Website ist Alter bislang ein Nebensatz unter [situative und temporäre Einschränkungen](https://html-einfach.de/barrierefreiheit-verstehen/situative-und-temporaere-einschraenkungen.html) gewesen. Es verdient eine eigene Seite, weil die Kombination mehrerer leichter Einschränkungen andere Anforderungen stellt als jede einzelne für sich. ## Das Wichtigste in Kürze - **Über 22 Millionen Menschen in Deutschland sind 65 oder älter** (rund ein Viertel der Bevölkerung, mit steigendem Anteil). - **Mehrere leichte Einschränkungen gleichzeitig** wirken stärker als eine schwere: kleine Schrift plus geringer Kontrast plus knappes Zeitfenster. - **Kontrastempfindlichkeit sinkt deutlich.** Die 4,5:1 der WCAG sind hier eine Untergrenze, kein Zielwert. - **Feinmotorik und Zielgenauigkeit lassen nach:** Zielgrößen und Abstände wirken unmittelbar. - **Zeitfenster sind das unterschätzte Thema:** Sitzungs-Timeouts und automatische Karussells treffen diese Gruppe zuerst. - **Betroffene nutzen selten Hilfsmittel.** Sie kompensieren mit Systemeinstellungen, Zoom und Geduld, bis sie abbrechen. - **Kein einziges eigenes WCAG-Kriterium**, aber ein Dutzend bestehender wirkt hier besonders stark. ## Was sich mit dem Alter tatsächlich ändert **Sehen.** Ab etwa dem 40. Lebensjahr lässt die Nahakkommodation nach (Presbyopie), später sinkt die Kontrastempfindlichkeit, die Linse vergilbt leicht (wodurch Blautöne schwerer zu unterscheiden sind), und der Lichtbedarf steigt. Praktisch heißt das: hellgrauer Text auf Weiß, 14-Pixel-Schrift und dünne Schriftschnitte fallen zuerst aus. Das größere Spektrum steht unter [Sehbehinderung & Blindheit](https://html-einfach.de/barrierefreiheit-verstehen/sehbehinderung-und-blindheit.html). **Motorik.** Zittern, Gelenkbeschwerden und langsamere Zielbewegungen machen kleine Bedienelemente zur Hürde (nicht unmöglich, aber anstrengend genug, dass ein Vorgang abgebrochen wird). Warum ein paar Pixel hier so viel ausmachen, steht unter [Motorische Einschränkungen](https://html-einfach.de/barrierefreiheit-verstehen/motorische-einschraenkungen.html). **Hören.** Altersschwerhörigkeit betrifft zuerst die hohen Frequenzen. Also genau den Bereich, in dem Konsonanten liegen. Videos ohne [Untertitel](https://html-einfach.de/wcag-und-bfsg/untertitel-und-transkripte.html) sind dann nicht leise, sondern unverständlich. **Kognition.** Arbeitsgedächtnis und Verarbeitungsgeschwindigkeit nehmen ab, während Erfahrungswissen zunimmt. Das ist der Grund, warum vertraute Muster so viel wichtiger sind als originelle: Ein Warenkorbsymbol oben rechts wird sofort verstanden, ein neuartiges Bedienkonzept nicht. Die Systematik dazu steht unter [Kognitive Barrierefreiheit](https://html-einfach.de/wcag-und-bfsg/kognitive-barrierefreiheit.html). ## Warum die Kombination das Eigentliche ist Jede dieser Veränderungen für sich ist mild. Was sie schwierig macht, ist ihr Zusammentreffen. Ein Beispiel aus einem ganz normalen Buchungsvorgang: Die Schrift ist klein (Sehen), das Zeitfenster für die Reservierung beträgt zehn Minuten (Verarbeitungsgeschwindigkeit), der Bestätigungscode kommt per SMS und muss abgetippt werden (Arbeitsgedächtnis plus Feinmotorik), und der Absenden-Button ist 32 Pixel hoch (Zielgenauigkeit). Jede einzelne Hürde wäre zu bewältigen. Zusammen führen sie zuverlässig zum Abbruch und zwar ohne dass jemand eine Fehlermeldung sieht oder eine Beschwerde schreibt. Genau deshalb ist diese Gruppe in Statistiken unsichtbar: Sie meldet sich nicht, sie verschwindet. Was das wirtschaftlich bedeutet, steht unter [Zahlen & Business Case](https://html-einfach.de/barrierefreiheit-verstehen/zahlen-und-business-case.html). ## Die acht Maßnahmen mit der größten Wirkung Keine davon ist neu. Sie sind nur in dieser Gruppe besonders wirksam: 1. **Text ab 16 Pixel** und relative Einheiten, damit die Systemeinstellung greift. Der häufigste Einzelbefund überhaupt. 2. **Kontrast über der Untergrenze.** Wo möglich 7:1 statt 4,5:1. Das ist [1.4.6 auf Stufe AAA](https://html-einfach.de/wcag-und-bfsg/wcag-aaa-kriterien.html) und hier die Maßnahme mit dem besten Verhältnis von Aufwand zu Wirkung. 3. **Zielgrößen großzügig:** 24 × 24 CSS-Pixel sind das Minimum nach [2.5.8](https://html-einfach.de/wcag-und-bfsg/kriterien/2-5-8-zielgroesse-minimum.html), 44 × 44 die spürbare Verbesserung. 4. **Zeitfenster verlängerbar machen** oder ganz weglassen. [2.2.1 Zeitbegrenzungen anpassbar](https://html-einfach.de/wcag-und-bfsg/kriterien/2-2-1-zeitbegrenzungen-anpassbar.html) ist Stufe A und wird trotzdem regelmäßig verletzt. 5. **Keine Gedächtnistests bei der Anmeldung.** Einfügen aus dem Passwortmanager erlauben ist eine Zeile (siehe [3.3.8 Zugängliche Authentifizierung](https://html-einfach.de/wcag-und-bfsg/kriterien/3-3-8-zugaengliche-authentifizierung.html)). 6. **Vertraute Muster statt Erfindungen.** Ein unterstrichener Link, ein Button, der wie ein Button aussieht, eine Navigation an der erwarteten Stelle. 7. **Fehler benennen statt einfärben.** Ein roter Rahmen ohne Text ist für diese Gruppe doppelt problematisch (siehe [Farbfehlsichtigkeit](https://html-einfach.de/barrierefreiheit-verstehen/farbfehlsichtigkeit.html)). 8. **Keine automatische Bewegung.** Karussells, die weiterspringen, während jemand liest, sind der zuverlässigste Weg, einen Vorgang abzubrechen. ## Wie diese Gruppe tatsächlich bedient Ein verbreiteter Denkfehler ist, ältere Nutzende mit Screenreader-Nutzenden gleichzusetzen. Tatsächlich verwenden sie fast nie [assistive Technologie](https://html-einfach.de/barrierefreiheit-verstehen/screenreader-ueberblick.html). Zum einen sind die Einschränkungen dafür zu mild, zum anderen verstehen sie sich nicht als behindert und suchen den Zugang zu Hilfsmitteln deshalb nie. Stattdessen kompensieren sie mit den Mitteln, die das Betriebssystem ohnehin bietet: größere Systemschrift, Browser-Zoom, höherer Kontrast, größerer Mauszeiger. Daraus folgt eine praktische Konsequenz: **Deine Seite muss auf Systemeinstellungen reagieren**, nicht eigene anbieten. Wer Schriftgrößen in Pixeln festnagelt oder bei 200 Prozent Zoom zusammenbricht, schließt genau die Gruppe aus, die sich am wenigsten beschweren wird (siehe [Reflow, Zoom & Textabstände](https://html-einfach.de/wcag-und-bfsg/reflow-zoom-textabstaende.html) und [Bildschirmvergrößerung](https://html-einfach.de/barrierefreiheit-verstehen/bildschirmvergroesserung.html)). ## Häufiger Fehler in der Praxis **Eine „Seniorenversion“ anbieten.** Eine zweite, vereinfachte Fassung wird nicht gepflegt, nicht gefunden und als herablassend empfunden. Die Hauptseite muss funktionieren. **Vom Alter auf mangelnde Technikkompetenz schließen.** Die heutige Gruppe der über 65-Jährigen arbeitet seit Jahrzehnten mit Computern. Das Problem ist nicht das Verständnis, sondern die Wahrnehmung und die Zeit. **Mit dem eigenen Team testen.** Ein Entwicklungsteam mit Durchschnittsalter 34 auf einem kalibrierten 27-Zoll-Bildschirm ist der denkbar schlechteste Maßstab. **Größere Schrift anbieten statt größere Schrift ausliefern.** Ein Umschalter auf der Seite hilft nur denen, die ihn finden. Die Systemeinstellung gilt überall. ## Häufige Fragen ### Gibt es WCAG-Kriterien speziell für ältere Menschen? Nein, und das ist Absicht: Die WCAG beschreiben Anforderungen, keine Nutzergruppen. Das W3C hat die Überschneidung aber untersucht und kommt zu dem Ergebnis, dass die bestehenden Kriterien die alterstypischen Bedarfe weitgehend abdecken, wenn man sie tatsächlich erfüllt. ### Ist Alter eine Behinderung? Rechtlich nicht per se. Für die Gestaltung ist die Frage unerheblich: Die Anforderungen sind dieselben, und das [BFSG](https://html-einfach.de/wcag-und-bfsg/bfsg-einfach-erklaert.html) knüpft ohnehin an das Angebot an, nicht an die Nutzergruppe. ### Was ist die eine Maßnahme mit der größten Wirkung? Wenn nur eine möglich ist: Schriftgröße und Kontrast. Beide betreffen jede Seite, beide sind in einer Designentscheidung erledigt, und beide wirken sofort für alle. ### Wie teste ich für diese Gruppe? Am nächsten kommt eine Kombination: Systemschrift auf die größte Stufe, Browser-Zoom auf 200 Prozent, Kontrastsimulation an und den Vorgang einhändig auf dem Smartphone durchspielen. Der vollständige Ablauf steht unter [Barrierefreiheit selbst testen](https://html-einfach.de/wcag-und-bfsg/selbst-testen.html). ## Verwandte Themen - [Situative & temporäre Einschränkungen](https://html-einfach.de/barrierefreiheit-verstehen/situative-und-temporaere-einschraenkungen.html): dasselbe Prinzip, andere Ursache - [Farbfehlsichtigkeit](https://html-einfach.de/barrierefreiheit-verstehen/farbfehlsichtigkeit.html): die zweite große, unsichtbare Gruppe - [Curb-Cut-Effekt & Mythen](https://html-einfach.de/barrierefreiheit-verstehen/curb-cut-effekt-und-mythen.html): warum Maßnahmen für wenige vielen nützen - [Zahlen & Business Case](https://html-einfach.de/barrierefreiheit-verstehen/zahlen-und-business-case.html): die wirtschaftliche Seite der stillen Abbrüche ## Quellen --- # Situative & temporäre Einschränkungen - URL: https://html-einfach.de/barrierefreiheit-verstehen/situative-und-temporaere-einschraenkungen.html - Themenbereich: Barrierefreiheit verstehen - Zuletzt geändert: 2026-07-20 - Kurzbeschreibung: Situative und temporäre Einschränkungen (gebrochener Arm, grelle Sonne, laute Bahn) sind dieselben Barrieren wie bei dauerhafter Behinderung, nur häufiger. **Die Grenze zwischen „behindert“ und „nicht behindert“ ist keine Linie, sondern ein Verlauf und jeder von uns bewegt sich täglich darauf: Wer mit dem Baby auf dem Arm einhändig tippt, hat situativ eine motorische Einschränkung, wer im Zug ohne Kopfhörer ein Video schaut, ist situativ gehörlos. Für deine Website ist die Ursache unsichtbar und belanglos: Sie erfährt nur, dass jemand zoomt, Untertitel einschaltet oder nur die Tastatur benutzt. Den Grund erfährt sie nie.** ## Das Wichtigste in Kürze - Zu jeder dauerhaften Einschränkung gibt es eine **temporäre** und eine **situative** Entsprechung. Das Modell heißt Persona Spectrum und stammt aus dem [Inclusive Design Toolkit](https://inclusive.microsoft.design/) von Microsoft. - Microsofts Standardbeispiel für „Berühren“: dauerhaft ein Arm, temporär ein Armbruch, situativ ein Elternteil mit Baby auf dem Arm. Dieselbe Anforderung, drei sehr unterschiedlich große Gruppen. - Der Browser meldet keinen Grund. Es gibt kein Signal für „blind“, „im Gips“ oder „Sonne auf dem Display“. Deshalb lässt sich für diese Fälle nichts gesondert ausliefern. - Eine Seite, die für den dauerhaften Fall gebaut ist, bedient alle drei Spalten automatisch mit. Umgekehrt gilt das nicht. - Rechtlich zählen situative Fälle nicht: [BFSG](https://html-einfach.de/wcag-und-bfsg/bfsg-einfach-erklaert.html) und [BITV](https://html-einfach.de/wcag-und-bfsg/bitv-2-0-erklaert.html) schützen Menschen mit Behinderungen. Praktisch profitieren situative Fälle von jeder Maßnahme. - Am stärksten wirkt das Modell auf die **Priorisierung**: Barrierefreiheit hört auf, eine Nischeninvestition zu sein, und wird Qualitätsarbeit für die gesamte Nutzerschaft. - Fürs Testen liefert es fünf konkrete Brillen: draußen im Hellen, einhändig, ohne Ton, nur mit Tastatur, auf 400 % gezoomt. - Der Effekt ist ein Zusatzargument, kein Ersatz. Für Menschen mit dauerhafter Behinderung ist Barrierefreiheit Teilhabe-Voraussetzung, für alle anderen Komfort. ## Das Modell: dauerhaft, temporär, situativ
    Eine Tabelle mit drei Spalten (dauerhaft, temporär und situativ) und fünf Zeilen für die Bereiche Berühren, Sehen, Hören, Verstehen und Ruhige Hand. Beispiele: ein Arm, gebrochener Arm im Gips, Baby auf dem Arm. Blindheit, geweitete Pupillen nach dem Augenarzt, grelle Sonne auf dem Display. Gehörlosigkeit, Mittelohrentzündung, laute Bahnhofshalle ohne Kopfhörer. Kognitive Einschränkung, Gehirnerschütterung oder Migräne, Stress und Übermüdung. Tremor, Nebenwirkung einer Therapie, wackelnder Bus und kalte Hände. Über den drei Spalten zeigt ein breiter werdender Keil, dass die Zahl der Betroffenen von links nach rechts stark zunimmt, während die Anforderung an die Website in allen drei Spalten identisch bleibt.
    Dieselbe Anforderung, drei Spalten: Von links nach rechts wächst die Zahl der Betroffenen um Größenordnungen. Die technische Lösung bleibt exakt dieselbe.
    | Bereich | Dauerhaft | Temporär | Situativ | | --- | --- | --- | --- | | Berühren | ein Arm | gebrochener Arm im Gips | Baby oder Einkaufstasche auf dem Arm | | Sehen | Blindheit | geweitete Pupillen nach dem Augenarzt | grelle Sonne auf dem Display | | Hören | Gehörlosigkeit | Mittelohrentzündung | laute Bahnhofshalle, Kopfhörer vergessen | | Verstehen | kognitive Einschränkung | Gehirnerschütterung, Migräne | Stress, Übermüdung, fremde Sprache | | Ruhige Hand | Tremor | Nebenwirkung einer Therapie | wackelnder Bus, Kälte, Handschuhe | Der Punkt des Modells ist nicht, dauerhafte Behinderung zu relativieren. Er ist, die Anforderung von der Person zu lösen: Eine Schaltfläche, die einhändig zu treffen ist, funktioniert für alle drei Spalten und das Team muss sich nicht drei Zielgruppen merken, sondern eine Anforderung. ## Fünf Alltagsszenen **Die Sonne.** Auf dem Displayglas spiegelt der Himmel, aus dem eleganten Hellgrau wird Unsichtbarkeit. Was hilft, ist derselbe [Mindestkontrast von 4,5:1](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-3-kontrast-minimum.html), der bei Sehbehinderung Pflicht ist. Wer je versucht hat, an einem Julitag ein Ticket zu kaufen, braucht dazu keine weitere Begründung. **Die Bahn.** Ruckelnde Fahrt, eine Hand am Griff, die andere am Handy. Kleine Symbole werden zum Glücksspiel. Die [24-Pixel-Zielgröße](https://html-einfach.de/wcag-und-bfsg/kriterien/2-5-8-zielgroesse-minimum.html) und [abbrechbare Klicks](https://html-einfach.de/wcag-und-bfsg/kriterien/2-5-2-zeiger-abbruch.html) sind hier plötzlich sehr einleuchtend. **Das Großraumbüro.** Video ohne Kopfhörer, also ohne Ton. Untertitel entscheiden, ob der Inhalt ankommt. Für [gehörlose Menschen](https://html-einfach.de/barrierefreiheit-verstehen/gehoerlosigkeit-und-schwerhoerigkeit.html) sind genau dieselben Untertitel Pflicht. Streaming-Anbieter berichten seit Jahren, dass ein erheblicher Teil des Publikums Untertitel dauerhaft einschaltet. **Der Feierabend.** Müde, unkonzentriert, nebenbei läuft der Fernseher. Das Formular, das Eingaben beim ersten Fehler wegwirft, verliert genau hier seine Nutzer. [Fehlertolerante Formulare](https://html-einfach.de/barrierefreie-komponenten/fehlermeldungen-barrierefrei.html) behalten sie. **Die zweite Sprache.** Jemand liest deine Seite auf Deutsch, denkt aber auf Polnisch, Türkisch oder Englisch. Schachtelsätze und Fachsprache kosten dann dieselbe Mühe wie bei [kognitiven Einschränkungen](https://html-einfach.de/barrierefreiheit-verstehen/kognition-und-neurodiversitaet.html) und betreffen in Deutschland Millionen. ## Warum du für diese Fälle nichts Eigenes bauen kannst Das ist der praktisch wichtigste Punkt und der am häufigsten missverstandene. Es gibt **kein Signal**, das dir sagt, in welcher Situation jemand gerade ist: ```js // Existiert nicht und wird nie existieren if (navigator.userHasBrokenArm) { … } if (navigator.sunlight > 50000) { … } ``` Was es gibt, sind Nutzereinstellungen, die Menschen selbst setzen. Sie decken beide Welten ab, die dauerhafte wie die situative: ```css /* Bewegung reduzieren: gesetzt bei vestibulären Störungen und von allen, die im Bus schnell seekrank werden */ @media (prefers-reduced-motion: reduce) { … } /* Dunkles Schema: gewählt bei Blendempfindlichkeit und von allen, die abends im Bett lesen */ @media (prefers-color-scheme: dark) { … } /* Erhöhter Kontrast: gesetzt bei Sehbehinderung und von allen, die draußen arbeiten */ @media (prefers-contrast: more) { … } ``` Diese drei Media Queries zu respektieren kostet wenig und bedient beide Spalten gleichzeitig. Alles andere bleibt eine Frage der Grundqualität: Kontrast, Zielgröße, Tastaturbedienbarkeit, Textalternativen. Ich würd deshalb nie versuchen, für situative Fälle etwas Eigenes zu bauen. Sie fallen ab, wenn die Basis stimmt. ## Was das für deine Arbeit ändert Strategisch ändert das Modell zwei Dinge. **Die Priorität.** Barrierefreiheit ist keine Nischeninvestition, sondern Qualitätsarbeit für die gesamte Nutzerschaft. Das ist das Kernargument im [Business Case](https://html-einfach.de/barrierefreiheit-verstehen/zahlen-und-business-case.html) und der Grund, warum sich der [Curb-Cut-Effekt](https://html-einfach.de/barrierefreiheit-verstehen/curb-cut-effekt-und-mythen.html) im Web so zuverlässig wiederholt. **Die Testbrille.** Teste deine Seite in den Situationen deiner Nutzer statt in Laborbedingungen. Jede dieser Proben entspricht einem Block der [WCAG-Kriterien](https://html-einfach.de/wcag-und-bfsg/kriterien.html) und kostet keine fünf Minuten. **Die Messgröße.** Die häufigste situative Einschränkung ist keine körperliche, sondern eine technische: schlechtes Netz, altes Gerät, überlastete Zelle im Zug. Genau das messen die [Core Web Vitals](https://html-einfach.de/seo-und-ki/core-web-vitals.html) an echten Nutzerdaten, nicht im Labor. Eine Seite, die auf einem Mittelklasse-Handy im Mobilfunknetz vier Sekunden bis zum LCP braucht, schließt dieselben Menschen aus wie ein zu geringer Kontrast, nur unauffälliger. Wo die Hebel liegen, steht unter [LCP & INP gezielt optimieren](https://html-einfach.de/seo-und-ki/lcp-und-inp-optimieren.html).
    Fünf Karten mit je einer Testsituation, dem Zeitaufwand und den passenden WCAG-Kriterien. Erstens draußen im Hellen, zwei Minuten, deckt 1.4.3 Kontrast und 1.4.11 Nicht-Text-Kontrast ab. Zweitens einhändig mit dem Daumen, drei Minuten, deckt 2.5.8 Zielgröße und 2.5.1 Zeigergesten ab. Drittens Ton aus, zwei Minuten, deckt 1.2.2 Untertitel und 4.1.3 Statusmeldungen ab. Viertens nur Tastatur, fünf Minuten, deckt 2.1.1 Tastatur und 2.4.7 Fokus sichtbar ab. Fünftens auf 400 Prozent gezoomt, drei Minuten, deckt 1.4.10 Reflow und 1.4.4 Textgröße ab. Darunter eine dunkle Summenzeile: fünfzehn Minuten für fünf Proben und sieben Kriterien, ohne Werkzeugkauf.
    Fünfzehn Minuten, fünf Kriterienblöcke: Diese Proben brauchen kein Werkzeug und keine Schulung (nur die Bereitschaft, den Schreibtisch kurz zu verlassen).
    ## So testest du es 1. **Geh mit dem Laptop nach draußen** und benutze deine Seite in der Sonne. Was du dort nicht lesen kannst, ist ein Kontrastproblem. Messen kannst du es danach mit dem [Kontrast-Check](https://html-einfach.de/ressourcen/kontrast-check.html). 2. **Bediene die mobile Ansicht nur mit dem Daumen**, das Handy in derselben Hand. Jedes Ziel, das du zweimal antippen musst, ist zu klein. 3. **Stell den Ton ab** und schau ein Video oder durchlaufe einen Bezahlvorgang. Fehlt Information, fehlen Untertitel oder eine sichtbare Statusmeldung. 4. **Leg die Maus weg** und spiele den wichtigsten Ablauf mit `Tab`, `Enter` und Pfeiltasten durch. Die Anleitung dazu steht unter [Tastaturbedienung & sichtbarer Fokus](https://html-einfach.de/wcag-und-bfsg/tastatur-und-fokus.html). 5. **Zoome auf 400 %** und wiederhole denselben Ablauf. Kein horizontales Scrollen für die Seite als Ganzes, nichts abgeschnitten, alles bedienbar? 6. **Setz die Systemeinstellungen um:** „Bewegung reduzieren“ an, dunkles Schema an, erhöhter Kontrast an. Reagiert die Seite, oder ignoriert sie alle drei? ## Häufiger Fehler in der Praxis **Das Modell als Ersatz für Betroffene.** Wenn im Team nur noch von „Menschen mit Kinderwagen“ die Rede ist, ist die Perspektive gekippt. Situative Fälle sind das zusätzliche Argument, nicht das eigentliche. **Testen unter Idealbedingungen.** Ein großer Monitor, gutes Licht, schnelles Netz und volle Konzentration beschreiben nicht, wie Menschen eine Website tatsächlich benutzen. Die fünf Proben oben kosten zusammen eine Viertelstunde und finden mehr als der halbe Testplan. **Nutzereinstellungen überschreiben.** `prefers-reduced-motion` abfragen und trotzdem animieren, ein eigenes Dark-Mode-Widget bauen, das die Systemeinstellung ignoriert. Damit verlierst du beide Gruppen gleichzeitig. **Situative Barrieren als Ausrede.** „Das betrifft ja alle mal kurz“ wird gelegentlich umgedreht zu „also nicht so schlimm“. Der Unterschied: Wer im Bus danebentippt, versucht es einfach noch mal. Bei Tremor klappt das oft nicht. ## Häufige Fragen ### Ersetzt das Argument „hilft allen“ die Perspektive der Betroffenen? Nein, und das ist mir wichtig. Der Curb-Cut-Effekt ist ein zusätzliches Argument, kein Ersatz: Für Menschen mit dauerhafter Behinderung ist Barrierefreiheit Teilhabe-Voraussetzung, für alle anderen Komfort. Beides zählt, aber nicht gleich schwer. Die Perspektive der dauerhaft Betroffenen steht deshalb in den Artikeln zu [Sehen](https://html-einfach.de/barrierefreiheit-verstehen/sehbehinderung-und-blindheit.html), [Hören](https://html-einfach.de/barrierefreiheit-verstehen/gehoerlosigkeit-und-schwerhoerigkeit.html), [Motorik](https://html-einfach.de/barrierefreiheit-verstehen/motorische-einschraenkungen.html) und [Kognition](https://html-einfach.de/barrierefreiheit-verstehen/kognition-und-neurodiversitaet.html) an erster Stelle. ### Zählt „situativ eingeschränkt“ auch rechtlich? Nein. BFSG und BITV schützen Menschen mit Behinderungen; situative Fälle sind kein Prüfmaßstab. Praktisch profitieren sie trotzdem von jeder Maßnahme. Das Gesetz definiert das Minimum, der Nutzen reicht weiter. ### Woher kommt das Persona-Spectrum-Modell? Aus dem Inclusive Design Toolkit von Microsoft, entwickelt unter anderem von Kat Holmes. Es unterscheidet für jeden Bereich (Berühren, Sehen, Hören, Sprechen) dauerhafte, temporäre und situative Ausprägungen und macht damit sichtbar, dass eine Lösung für die kleinste Gruppe der größten zugutekommt. ### Kann ich für situative Fälle etwas gesondert ausliefern? Nein, und das ist eher eine Erleichterung. Es gibt kein Signal für „Sonne“, „Bus“ oder „müde“. Was es gibt, sind Nutzereinstellungen wie `prefers-reduced-motion`, `prefers-color-scheme` und `prefers-contrast`. Sie zu respektieren ist der einzige Weg, und er bedient dauerhafte wie situative Fälle gleichzeitig. ### Was ist der schnellste Einstieg für ein Team, das noch nie darüber nachgedacht hat? Die fünf Proben aus dem Abschnitt „So testest du es“, gemeinsam in einem Termin. Nichts überzeugt so schnell wie der Moment, in dem jemand den eigenen Checkout einhändig im Sonnenlicht nicht abschließen kann. Danach ist die Diskussion über Prioritäten meistens vorbei. ## Verwandte Themen - [Curb-Cut-Effekt und Mythen](https://html-einfach.de/barrierefreiheit-verstehen/curb-cut-effekt-und-mythen.html): das Muster hinter dem Modell und die häufigsten Einwände - [Zahlen und Business Case](https://html-einfach.de/barrierefreiheit-verstehen/zahlen-und-business-case.html): Reichweite und Kosten mit Quellen - [Motorische Einschränkungen](https://html-einfach.de/barrierefreiheit-verstehen/motorische-einschraenkungen.html): die dauerhafte Entsprechung zur einhändigen Bedienung - [Kognition und Neurodiversität](https://html-einfach.de/barrierefreiheit-verstehen/kognition-und-neurodiversitaet.html): warum Müdigkeit dieselben Barrieren erzeugt wie ADHS - [Barrierefreiheit selbst testen](https://html-einfach.de/wcag-und-bfsg/selbst-testen.html): die vollständige Testroutine ohne Werkzeugkauf - [Reflow, Zoom & Textabstände](https://html-einfach.de/wcag-und-bfsg/reflow-zoom-textabstaende.html): der Zoom-Test im Detail ## Quellen --- # Wie Screenreader-Nutzer surfen: Strategien & Zahlen - URL: https://html-einfach.de/barrierefreiheit-verstehen/wie-screenreader-nutzer-surfen.html - Themenbereich: Barrierefreiheit verstehen - Zuletzt geändert: 2026-08-10 - Kurzbeschreibung: Wie Screenreader-Nutzer surfen: 71,6 % springen per Überschrift, nur 6,4 % lesen linear (WebAIM 2024). Die Zahlen und was dein Markup liefern muss. **Screenreader-Nutzer lesen Websites nicht von oben nach unten. Sie springen: 71,6 % navigieren auf langen Seiten primär über Überschriften, nur 6,4 % lesen linear durch (WebAIM Screen Reader Survey #10, Januar 2024). Die Sprünge laufen über Schnelltasten, Elementlisten und Touch-Gesten, die direkt auf deinem HTML aufsetzen. Navigierbar ist also genau das, was du semantisch auszeichnest.** ## Das Wichtigste in Kürze - Stand Januar 2024 (WebAIM-Survey #10, 1.539 Befragte): 71,6 % suchen Inhalte per Überschriften-Navigation, 13,6 % per Seitensuche, 6,4 % lesen linear, 4,8 % springen über Links, 3,7 % über Landmarken. - 88,8 % finden Überschriftenebenen nützlich. Per Taste erreichbar sind aber nur echte `h1` bis `h6`; gestylter Fett-Text ist für Hilfstechnik unsichtbar. - Meistgenutzte Desktop-Screenreader: JAWS 40,5 %, NVDA 37,7 %, VoiceOver 9,7 % (Survey #10). - 91,3 % nutzen Screenreader auch mobil: primäre Plattform bei 70,6 % Apple, bei 27,6 % Android; genutzt werden VoiceOver (70,6 %) und TalkBack (34,7 %). - Geübte hören Sprachausgabe mit rund 350 Wörtern pro Minute (gut das doppelte Sprechtempo). - Mythos widerlegt: 99,4 % surfen mit aktiviertem JavaScript (WebAIM-Survey #9, 2021). - Passende WCAG-Kriterien: 1.3.1, 2.4.1, 2.4.4, 2.4.6 und 1.1.1. Über das BFSG sind sie seit dem 28.06.2025 für viele Websites verpflichtend. > **Abgrenzung: Hier geht es um Verhalten, nicht um Technik.** Diese Seite wertet aus, > **wie** Menschen mit Screenreader navigieren. Die Programme selbst vergleicht die > [Screenreader-Übersicht](https://html-einfach.de/barrierefreiheit-verstehen/screenreader-ueberblick.html), den > technischen Unterbau erklären die > [Screenreader-Grundlagen](https://html-einfach.de/wcag-und-bfsg/screenreader-grundlagen.html). ## Was ein Screenreader wirklich vorliest Ein Screenreader gibt Bildschirminhalte als synthetische Sprache aus oder taktil über eine [Braillezeile](https://html-einfach.de/barrierefreiheit-verstehen/braillezeile.html), mit der sich komplett stumm arbeiten lässt. Ausgegeben wird nie das Layout, sondern der Accessibility-Tree aus dem HTML: Zu jedem Element gehört eine Rolle, und die wird mitgesprochen: „Überschrift Ebene 2, Öffnungszeiten“, „Link, Speisekarte“, „Liste mit 3 Einträgen“. Welche Programme das tun, sortiert der [Screenreader-Überblick](https://html-einfach.de/barrierefreiheit-verstehen/screenreader-ueberblick.html), die Grundlagen beschreibt das W3C in [Tools and Techniques](https://www.w3.org/WAI/people-use-web/tools-techniques/). Daraus folgt der Klassiker, den Jan Eric Hellbusch vor über fünfzehn Jahren aufgeschrieben hat: Großer fetter Text macht noch keine Überschrift. Ein `div` mit `font-size: 2rem` ist im Accessibility-Tree ein Textknoten wie jeder andere. Per Überschriften-Taste ist er unerreichbar und in keiner Überschriftenliste vorhanden. Nur echte `h1` bis `h6` sind zugleich generiertes Inhaltsverzeichnis und Werkzeug zum Überfliegen; wie die [Überschriften-Hierarchie](https://html-einfach.de/semantisches-html/ueberschriften-hierarchie.html) dafür aussehen muss, ist ein eigenes Kapitel. Dazu das Tempo: Reale Nutzer stellen ihre Sprachausgabe deutlich schneller ein, als Demo-Videos vermitteln. Darauf weist die [TU Dortmund](https://alternativtexte.tu-dortmund.de/informationen-und-anleitungen-1/screenreadernutzung/) hin. [Domingos de Oliveira](https://www.netz-barrierefrei.de/) nennt rund 150 Wörter pro Minute als durchschnittliches Sprech- und Vorlesetempo und stellt selbst 350 ein. „Alles vorlesen lassen“ ist trotzdem keine Strategie: Auch bei doppeltem Tempo bleibt eine unstrukturierte Seite quälend. ## Springen statt lesen: die Zahlen Die beste Datenquelle sind die [Screen-Reader-Umfragen von WebAIM](https://webaim.org/projects/screenreadersurvey10/). Stand Juli 2026 ist Survey #10 die jüngste Ausgabe (Erhebung Dezember 2023/Januar 2024, 1.539 Befragte, davon 76,6 % blind und 19,9 % sehbehindert). So wird auf einer langen Seite gesucht: 71,6 % per Überschriften-Navigation, 13,6 % per Seitensuche, 6,4 % linear durchlesen, 4,8 % Link-Navigation, 3,7 % Landmarken. Überschriftenebenen finden 88,8 % nützlich, 57,0 % sogar „sehr nützlich“. Zwei Details sind Design-Argumente. Der Kompetenz-Split: 78 % der Fortgeschrittenen, aber nur 47 % der Anfänger navigieren primär per Überschrift. Eine Seite muss beides bieten, Sprungstruktur und lineare Lesbarkeit. Und die Landmarken: nur 3,7 % primäre Strategie, 36,7 % nutzen sie selten oder nie. `main`, `nav`, `header` und `footer` bleiben Pflicht-Grundgerüst, das Arbeitstier sind Überschriften. Weil ein Fünftel der Befragten einen Sehrest hat, hilft dasselbe Markup auch bei [Sehbehinderung, wo Screenreader Vergrößerung ergänzen](https://html-einfach.de/barrierefreiheit-verstehen/sehbehinderung-und-blindheit.html). Die Gegenprobe liefert die [WebAIM Million](https://webaim.org/projects/million/), Ausgabe Februar 2026: 95,9 % von einer Million Startseiten haben automatisch erkennbare WCAG-Fehler, im Schnitt 56,1 pro Seite; 41,8 % überspringen Überschriftenebenen, 7,5 % haben gar keine Überschriften, 18,1 % mehrere `h1`. ARIA rettet das nicht: Seiten mit ARIA (82,7 %, im Schnitt 133 Attribute) haben mehr Fehler (59,1) als Seiten ohne (42). Dazu die Stimmung im Survey: nur 34,6 % finden das Web zugänglicher geworden, 18,6 % unzugänglicher; meistgenannt werden CAPTCHAs, unerwartet reagierende Elemente, nichtssagende Links und Buttons sowie unerwartet wechselnde Seitenbereiche, danach fehlende Tastaturbedienbarkeit. Schon 2021 surften 99,4 % mit aktiviertem JavaScript (Survey #9). Auch dieser Mythos ist erledigt. ## Drei Strategien, ein Werkzeugkasten In der Praxis lassen sich drei Navigationsstrategien unterscheiden, die sich in Nutzertests immer wieder zeigen: 1. **Unstrukturiert:** mit `Tab` und Pfeiltasten Element für Element vorarbeiten, typisch auf schlecht ausgezeichneten Seiten. `Tab` erreicht nur fokussierbare Elemente wie Links und Formularfelder, reiner Text wird übersprungen; die Pfeiltasten lesen zeilenweise. 2. **Strukturiert:** Schnelltasten im Lesemodus, die Semantik voraussetzen. In NVDA und ähnlich in JAWS: `H` nächste Überschrift, `1` bis `6` Überschrift der jeweiligen Ebene, `K` Link, `D` Landmarke, `G` Grafik, `F` Formularfeld, `B` Button, `T` Tabelle, `L` Liste. Mit `Umschalt` geht es jeweils rückwärts. 3. **Zielgerichtet:** Elementlisten und Suche. `NVDA+F7` öffnet die Liste aller Überschriften, Links, Landmarken, Schaltflächen oder Formularfelder, filterbar über ein Suchfeld; `NVDA+Strg+F` durchsucht die Seite. Eine Maus kommt in keiner Strategie vor: Am Desktop läuft alles über die Tastatur. In Formularen wechselt der Screenreader in den Fokusmodus, der Tastendrücke ans Feld durchreicht und dessen zugänglichen Namen ansagt. Das setzt ein [programmatisch verknüpftes Label](https://html-einfach.de/barrierefreie-komponenten/labels-und-beschriftungen.html) voraus. Alle Befehle zum Nachmachen zeigt [mit NVDA testen](https://html-einfach.de/wcag-und-bfsg/mit-nvda-testen.html), die Referenz ist der [NVDA User Guide](https://www.nvaccess.org/files/nvda/documentation/userGuide.html). ## Der Praxistest: Öffnungszeiten finden Dieselbe Aufgabe, zwei Restaurant-Websites. Auf der strukturierten Seite drücke ich dreimal `H`: zuerst „Überschrift Ebene 1, Restaurant Seeblick“, dann „Überschrift Ebene 2, Speisekarte“ und dann „Überschrift Ebene 2, Öffnungszeiten“. Pfeil nach unten: „Montag bis Freitag, 11:30 bis 22 Uhr“. Erledigt, unter zehn Sekunden. ```html

    Öffnungszeiten

    Mo bis Fr 11:30 bis 22:00 Uhr, Sa ab 17:00 Uhr

    ``` Auf der unstrukturierten Seite meldet `H` nur: „Keine weitere Überschrift“. Alle „Überschriften“ sind gestylte `div`s. Bleibt die Linkliste: In einem dokumentierten Nutzertest von Gehirngerecht Digital zählte sie auf einer realen Startseite 111 Einträge, darunter „Weitere Informationen, Link. Weitere Informationen, Link.“ Jede Teaser-Karte ist dreifach verlinkt, alle zum selben Ziel. Letzter Ausweg Seitensuche: Sie findet „Öffnungszeiten“ nicht, die Zeiten stecken in einer Grafik ohne [Alt-Text](https://html-einfach.de/barrierefreie-komponenten/alt-texte-schreiben.html). Der Anruf im Restaurant ist schneller. ```html
    Öffnungszeiten
    Teller Speisekarte Weitere Informationen
    ``` Die Reparatur: die Karte [einmal verlinken](https://html-einfach.de/barrierefreie-komponenten/klickbare-cards.html), der Linktext benennt das Ziel ([WCAG 2.4.4 Linkzweck](https://html-einfach.de/wcag-und-bfsg/kriterien/2-4-4-linkzweck-im-kontext.html)), das Karten-Grid wird eine [echte Liste](https://html-einfach.de/semantisches-html/listen-richtig-nutzen.html): „Liste mit 3 Einträgen“ sagt vorab, was kommt, ein `div`-Grid sagt nichts. ## Mobil: dieselbe Semantik, andere Gesten 91,3 % der Survey-Teilnehmer nutzen Screenreader auch mobil, primär 70,6 % auf Apple-Geräten, 27,6 % auf Android (Survey #10, 2024). Dort navigieren Gesten statt Tasten: Bei VoiceOver stellt der Rotor (eine Zwei-Finger-Drehgeste) die Einheit „Überschriften“ ein, danach springt Wischen nach unten zur nächsten Überschrift; TalkBack macht dasselbe über die [Lesesteuerung](https://support.google.com/accessibility/android/answer/6006598), deren Modus per Drei-Finger-Wischen nach links/rechts oder per Winkelgeste wechselt. Danach springt Wischen nach unten und oben zwischen den Überschriften. Entscheidend: Dieselbe Semantik treibt Tasten und Gesten an. Ein sauberes `

    ` bedient die `H`-Taste unter NVDA genauso wie den Rotor unter iOS. Ausprobieren lässt sich das mit der Anleitung [mit VoiceOver testen](https://html-einfach.de/wcag-und-bfsg/mit-voiceover-testen.html). ## Was das für deine Website heißt - **Schlüssige Überschriften-Hierarchie ohne Ebenensprünge**: das Inhaltsverzeichnis, in dem 71,6 % springen. Absicherung: [2.4.6 Überschriften und Beschriftungen](https://html-einfach.de/wcag-und-bfsg/kriterien/2-4-6-ueberschriften-und-beschriftungen.html) und [1.3.1 Info und Beziehungen](https://html-einfach.de/wcag-und-bfsg/kriterien/1-3-1-info-und-beziehungen.html). - **Landmarken komplett, aber sparsam:** `header`, `nav`, `main`, `footer` (Aufbau siehe [Landmarks und Outline](https://html-einfach.de/semantisches-html/landmarks-und-outline.html)); zu viele benannte Regionen desorientieren. - **Ein [Skip-Link](https://html-einfach.de/barrierefreie-komponenten/skip-links.html)** beschleunigt den Einstieg ([2.4.1 Blöcke umgehen](https://html-einfach.de/wcag-und-bfsg/kriterien/2-4-1-bloecke-umgehen.html)). - **Alt-Texte für informative Bilder** ([1.1.1 Nicht-Text-Inhalte](https://html-einfach.de/wcag-und-bfsg/kriterien/1-1-1-nicht-text-inhalte.html)); dekorative Icons ohne `alt=""` liest die Sprachausgabe absurd vor: „nach rechts zeigendes spitzes Anführungszeichen“ hinter jedem Menüpunkt. - **Datentabellen mit ausgezeichneten Zeilen- und Spaltenköpfen** ([Tabellen semantisch aufbauen](https://html-einfach.de/semantisches-html/tabellen-semantisch-aufbauen.html)). Ohne `th` ist eine Preistabelle nur eine Zahlenwolke. - **[Slider und Karussells](https://html-einfach.de/barrierefreie-komponenten/slider-und-karussells.html) sowie eingebettete Karten brauchen eine Text-Alternative.** Google Maps ohne Adressliste ist unbenutzbar. - **ARIA ergänzt Beschriftungen, ersetzt aber keine Struktur.** Die ARIA-Fehlerzahlen der WebAIM Million sind die Warnung dazu. Was an dieser Liste auffällt: Es ist dieselbe Liste, die man aufschreiben würde, wenn es um Suchmaschinen und KI-Systeme ginge. Auch ein Crawler springt von Überschrift zu Überschrift, auch ein Sprachmodell zerlegt eine Seite in Abschnitte, und auch beide haben von einem Bild nur den Alt-Text. Der Zusammenhang ist kein netter Nebeneffekt, sondern dieselbe Ursache. Nachzulesen ist das unter [Semantik & SEO](https://html-einfach.de/seo-und-ki/semantik-und-seo.html) und, für die KI-Seite, unter [GEO-Grundlagen](https://html-einfach.de/seo-und-ki/geo-grundlagen.html). Seit dem 28. Juni 2025 ist das keine Kür mehr: Das [BFSG](https://html-einfach.de/wcag-und-bfsg/bfsg-einfach-erklaert.html) verlangt für viele Websites die WCAG 2.1 AA (über die EN 301 549). Die Prüf-Checkliste dazu enthält mein [kostenloses E-Book](https://html-einfach.de/gratis-ebook.html). ## So testest du es 1. Starte einen Screenreader: Windows-Sprachausgabe mit `Win+Strg+Enter`, VoiceOver am Mac mit `Cmd+F5` oder für den gründlichen Test [NVDA](https://html-einfach.de/wcag-und-bfsg/mit-nvda-testen.html) (kostenlos, Open Source). 2. Dunkle den Bildschirm ab und springe nur mit `H` durch deine Startseite: Ergibt die Folge der Überschriften ein schlüssiges Inhaltsverzeichnis? 3. Öffne die Elementliste (`NVDA+F7` oder den VoiceOver-Rotor) und lies nur die Linktexte: Verrät jeder ohne Kontext sein Ziel? 4. Drücke `D` für die Landmarken: genau ein `main`, die Navigation als `nav`? 5. Stelle dir eine echte Aufgabe (Öffnungszeiten oder Kontakt finden) und stoppe die Zeit. Deutlich über 30 Sekunden heißt: Es fehlt Struktur, nicht Geduld. ## Häufiger Fehler in der Praxis **Die Überschriftenebene nach Optik gewählt.** Im CMS nehmen Redakteure die Ebene, deren Schriftgröße gefällt. Unter einer `h2` folgt plötzlich eine `h6`. Wer den Sprung hört, sucht die fehlenden Zwischenebenen und verliert das Modell der Seite. Die Ebene beschreibt die Gliederung, die Größe regelt das CSS. **Regionen-Inflation.** Gut gemeint jede Sektion als benannte Region ausgezeichnet. In einem meiner Tests waren es 14 auf einer Seite. Die Landmarken-Liste ist dann so unübersichtlich wie die Seite selbst; vier bis sechs Landmarken reichen fast immer. **Die Hauptnavigation nur per Hover.** Ein [Mega-Menü](https://html-einfach.de/barrierefreie-komponenten/mega-menues.html), das nur auf den Mauszeiger reagiert, existiert für Tastatur- und Screenreader-Nutzung nicht. Wer so surft, erfährt nie, was die Website anbietet. **Mit Demo-Tempo getestet.** Das Team hört einmal die Standardstimme in gemütlichem Tempo und hält die Seite für „gut vorlesbar“. Reale Nutzer hören doppelt so schnell und springen. Entscheidend ist nicht der Klang, sondern ob es Sprungziele gibt. ## Häufige Fragen ### Lesen Screenreader die ganze Seite von oben nach unten vor? Nein. Vorgelesen wird nur auf Befehl. Nutzer springen per Überschriften-Taste, Elementliste oder Suche gezielt zum Inhalt; im WebAIM-Survey #10 (2024) lesen nur 6,4 % lange Seiten linear. Lineares Hören kommt danach: erst zum Abschnitt springen, dann Absatz für Absatz lesen, oft mit doppeltem Sprechtempo. Beides setzt echte Struktur im HTML voraus. ### Welcher Screenreader wird am meisten genutzt? Am Desktop liegt JAWS mit 40,5 % knapp vor NVDA (37,7 %) und VoiceOver (9,7 %). Das zeigt der WebAIM-Survey #10, Januar 2024. JAWS ist kostenpflichtig und in Deutschland als Hilfsmittel anerkannt (teils kassenfinanziert), NVDA kostenlos und Open Source. Mobil dominiert VoiceOver (70,6 %) vor TalkBack (34,7 %). Für eigene Tests reicht NVDA vollkommen. ### Wie kann ich meine Website selbst mit einem Screenreader testen? Am schnellsten mit Bordmitteln: Windows-Sprachausgabe mit `Win+Strg+Enter`, VoiceOver am Mac mit `Cmd+F5`. Gründlicher ist NVDA. Der Fünf-Minuten-Test: mit `H` durch die Überschriften springen, mit `NVDA+F7` die Linkliste lesen, eine echte Aufgabe lösen. Eine Testroutine ohne Werkzeugkauf beschreibt [selbst testen](https://html-einfach.de/wcag-und-bfsg/selbst-testen.html). ### Wie viele blinde und sehbehinderte Menschen gibt es in Deutschland? Amtlich erfasst sind 71.260 blinde, 46.820 hochgradig sehbehinderte und 440.645 sehbehinderte Menschen (Schwerbehindertenstatistik, Stand 31.12.2021). Der [DBSV](https://www.dbsv.org/zahlen-fakten.html) nennt das eine „gesicherte untere Grenze“, weil viele Betroffene keinen Ausweis beantragen; die WHO-Hochrechnung liegt bei rund 1,2 Millionen. Eine amtliche Zählung gibt es nicht. ## Verwandte Themen - [Screenreader im Überblick](https://html-einfach.de/barrierefreiheit-verstehen/screenreader-ueberblick.html): JAWS, NVDA, VoiceOver und TalkBack im Vergleich - [Braillezeile](https://html-einfach.de/barrierefreiheit-verstehen/braillezeile.html): wie taktile Ausgabe auf den Fingerspitzen funktioniert - [Sehbehinderung und Blindheit](https://html-einfach.de/barrierefreiheit-verstehen/sehbehinderung-und-blindheit.html): Vergrößerung, Kontrast und Screenreader als ergänzende Strategien - [Überschriften-Hierarchie](https://html-einfach.de/semantisches-html/ueberschriften-hierarchie.html): das Inhaltsverzeichnis, in dem gesprungen wird - [Mit NVDA testen](https://html-einfach.de/wcag-und-bfsg/mit-nvda-testen.html): Schritt-für-Schritt-Anleitung für den eigenen Test - [Tastatur- und Switch-Bedienung](https://html-einfach.de/barrierefreiheit-verstehen/tastatur-und-switch-bedienung.html): warum Tastaturbedienbarkeit die Basis von allem ist ## Quellen --- # Screenreader im Überblick: NVDA, JAWS, VoiceOver & Co. - URL: https://html-einfach.de/barrierefreiheit-verstehen/screenreader-ueberblick.html - Themenbereich: Barrierefreiheit verstehen - Zuletzt geändert: 2026-08-13 - Kurzbeschreibung: NVDA, JAWS, VoiceOver, TalkBack und Orca im Vergleich: Verbreitung laut WebAIM 2024, echte Unterschiede und die zwei, mit denen du testest. **Für eigene Tests reichen zwei Programme: NVDA unter Windows und VoiceOver auf dem iPhone. Sie decken die Kombinationen ab, in denen laut WebAIM-Survey #10 (Januar 2024) die große Mehrheit unterwegs ist. Am Desktop teilen sich JAWS (40,5 %) und NVDA (37,7 %) den Markt, mobil führt VoiceOver mit 70,6 % klar vor TalkBack. Alle anderen Programme musst du kennen, aber nicht besitzen.** ## Das Wichtigste in Kürze - Ein Screenreader sagt zu jedem Element Name, Rolle und Zustand an: „Nachricht senden, Schalter“ statt „blauer Kasten unten rechts“. Was er sagt, entsteht im Accessibility Tree, nicht im CSS. - Stand Januar 2024 (WebAIM-Survey #10, 1.539 Befragte) als primärer Desktop-Screenreader: JAWS 40,5 %, NVDA 37,7 %, VoiceOver 9,7 %, Dolphin SuperNova 3,7 %, ZoomText/Fusion 2,7 %, Orca 2,4 %. - 71,6 % nutzen mehr als einen Desktop-Screenreader, 43 % drei oder mehr. „Ein Nutzer, ein Screenreader“ ist die falsche Vorstellung. - 91,3 % nutzen zusätzlich einen mobilen Screenreader. Dort führt VoiceOver mit 70,6 % vor TalkBack (34,7 %). - 38 % lassen sich die Ausgabe parallel über eine Braillezeile geben, arbeiten also zeitweise völlig lautlos. - Häufigste Browser-Kombination ist JAWS mit Chrome (24,7 %), gefolgt von NVDA mit Chrome (21,3 %) und JAWS mit Edge (11,4 %). - Für Deutschland gibt es keine belastbare Statistik. Die WebAIM-Umfrage erreicht überwiegend den englischsprachigen Raum; JAWS ist hierzulande als kassenfinanziertes Hilfsmittel verbreiteter, als der weltweite Schnitt vermuten lässt. - Ein Screenreader ist kein Prüfwerkzeug: Er liest auch kaputte Seiten vor. Die Testfrage lautet nicht „wird etwas vorgelesen?“, sondern „komme ich allein mit dieser Ansage ans Ziel?“. > **Abgrenzung: drei Seiten, drei Fragen.** Diese Seite ist die Übersicht: **welche** > Screenreader es gibt, wie verbreitet sie sind und mit welchen zwei du testest. Wie ein > Screenreader technisch aus HTML eine Ansage macht, steht unter > [Screenreader-Grundlagen](https://html-einfach.de/wcag-und-bfsg/screenreader-grundlagen.html). Wie Menschen > damit tatsächlich navigieren (Überschriftensprünge, Elementliste, Vorlesereihenfolge), > steht unter [Wie Screenreader-Nutzer > surfen](https://html-einfach.de/barrierefreiheit-verstehen/wie-screenreader-nutzer-surfen.html). ## Kurz erklärt: Wie die Ansage entsteht Der verbreitetste Irrtum steckt schon im Namen: Ein Screenreader liest keinen Screen. Er fragt Betriebssystem und Browser nach dem **Accessibility Tree** ab, einer gefilterten Fassung des DOM, in der jedes Element einen Namen, eine Rolle und einen Zustand trägt. Aus diesen drei Angaben entsteht die Ansage „Nachricht senden, Schalter“. CSS hat auf diesem Weg keine Haltestelle, weshalb ein `div`, das wie ein Button aussieht, im Baum ein stummer Textknoten bleibt. Welchen Namen ein Element bekommt, regelt [WCAG 4.1.2 „Name, Rolle, Wert“](https://html-einfach.de/wcag-und-bfsg/kriterien/4-1-2-name-rolle-wert.html). Diese Kette im Detail (welche Technik ein Element aus dem Baum entfernt, welche es nur unsichtbar macht und was ein Screenreader-Test damit belegen kann) steht unter [Screenreader-Grundlagen](https://html-einfach.de/wcag-und-bfsg/screenreader-grundlagen.html). Auf dieser Seite geht es um die Programme selbst: welche es gibt, wie verbreitet sie sind und wo sie sich im Alltag tatsächlich unterscheiden. Nebenbei erklärt derselbe Mechanismus, warum sauberes Markup auch außerhalb der Barrierefreiheit zählt: Ein Suchmaschinen-Crawler und ein Sprachmodell lesen ebenfalls Struktur statt Optik und stehen vor demselben stummen `div`. Mehr dazu unter [Semantik & SEO](https://html-einfach.de/seo-und-ki/semantik-und-seo.html).
    Ablaufdiagramm in drei nummerierten Stufen. Erstens dein HTML mit einem button-Element und dem Text „Nachricht senden“. Zweitens der vom Browser erzeugte Accessibility Tree mit den drei Angaben Name gleich Nachricht senden, Rolle gleich Schaltfläche und Zustand gleich aktiviert. Drittens der Screenreader (NVDA, JAWS oder VoiceOver) mit der Sprachausgabe „Nachricht senden, Schalter“ und darunter derselben Ausgabe als Punktmuster einer Braillezeile. Ein abgesetzter Kasten am unteren Rand zeigt CSS mit einem Pfeil auf den Hinweis, dass CSS nur das sichtbare Layout betrifft und ein div, das wie ein Button aussieht, im Accessibility Tree weder Name noch Rolle hat.
    Der Weg vom Markup zur Ansage: Was im Accessibility Tree fehlt, kann kein Screenreader vorlesen. CSS hat auf diesem Weg keine Haltestelle.
    ## Die Programme, die zählen | Screenreader | Plattform | Kosten | Typisches Umfeld | | --- | --- | --- | --- | | **JAWS** | Windows | kommerziell (Lizenz + Wartung) | Arbeitsplatz, Behörde, Ausbildung | | **NVDA** | Windows | kostenlos, Open Source | privat, Entwicklung, Tests | | **VoiceOver** | macOS, iOS, iPadOS | im System enthalten | Apple-Geräte, dominant am Smartphone | | **TalkBack** | Android | im System enthalten | Android-Smartphones | | **Orca** | Linux | kostenlos, Open Source | Linux-Desktops | | **Dolphin SuperNova** | Windows | kommerziell | Kombination Vergrößerung + Sprache | | **Erzähler (Narrator)** | Windows | im System enthalten | Ersthilfe, Setup, Notfall | **JAWS** ist der Veteran und in Deutschland stark verbreitet, weil er als Hilfsmittel anerkannt und damit unter Umständen über Krankenkasse oder Integrationsamt finanzierbar ist. Für Nutzer bedeutet das: kein Preisschild. Für dich als Entwickler bedeutet es, dass die JAWS-Ansage im deutschen Arbeitsumfeld wahrscheinlich häufiger vorkommt, als die weltweite Statistik nahelegt. **NVDA** von NV Access hat den Markt verändert, weil es nichts kostet. Es ist damit der einzige vollwertige Desktop-Screenreader, den du ohne Beschaffungsvorgang installieren kannst und verhält sich nah genug an JAWS, dass sich die meisten Befunde übertragen. **VoiceOver** ist zweigeteilt: Am Mac ein solides, aber eigenwilliges Programm mit eigener Modifier-Logik (`VO` = `Ctrl+Alt`), auf dem iPhone der mit Abstand meistgenutzte Screenreader überhaupt. Wer nur mobil testen kann, testet trotzdem etwas sehr Relevantes. **TalkBack** liegt mobil auf Platz zwei und weicht in Details ab, etwa bei Überschriftennavigation und Live-Regionen. **Orca** und **Dolphin SuperNova** sind Nischen, die du kennen, aber nicht testen musst. Der **Windows-Erzähler** spielt als Hauptwerkzeug kaum eine Rolle; er ist die Notlösung, mit der man einen frisch aufgesetzten Rechner überhaupt bedienen kann.
    Zwei nebeneinanderstehende Balkendiagramme aus dem WebAIM Screen Reader User Survey Nummer 10 von Januar 2024. Links der primäre Desktop-Screenreader: JAWS 40,5 Prozent, NVDA 37,7 Prozent, VoiceOver 9,7 Prozent, SuperNova 3,7 Prozent, ZoomText 2,7 Prozent, Orca 2,4 Prozent. Rechts die mobile Nutzung mit Mehrfachnennung: VoiceOver 70,6 Prozent, TalkBack 34,7 Prozent, Jieshuo 10,1 Prozent. Darunter drei hervorgehobene Werte: 71,6 Prozent nutzen mehr als einen Desktop-Screenreader und 43 Prozent sogar drei oder mehr, 91,3 Prozent nutzen zusätzlich einen Screenreader auf dem Smartphone, 38 Prozent lassen sich die Ausgabe parallel über eine Braillezeile geben. Eine Fußnote weist darauf hin, dass es für Deutschland keine vergleichbare Erhebung gibt.
    Desktop und Smartphone sind zwei verschiedene Welten: Am Desktop teilen sich JAWS und NVDA den Markt, mobil ist VoiceOver die Referenz.
    ## Verbreitung: was die Zahlen hergeben und was nicht Die einzige regelmäßige Erhebung ist der [WebAIM Screen Reader User Survey](https://webaim.org/projects/screenreadersurvey10/), Stand Juli 2026 zuletzt als Ausgabe #10 (Dezember 2023/Januar 2024, 1.539 gültige Antworten, davon 89,9 % Menschen mit Behinderung). Drei Befunde daraus sind für die Praxis wichtiger als die Rangliste selbst. **Erstens: Fast alle nutzen mehrere Programme.** 71,6 % geben an, mehr als einen Desktop-Screenreader zu verwenden, 43 % drei oder mehr, 17,4 % vier oder mehr. Wer sich auf eine Software festlegt, kommt bei manchen Websites nicht weiter. Die Nutzer haben sich längst darauf eingestellt und wechseln. Für dich heißt das: Ein Fehler, der nur unter JAWS auftritt, ist trotzdem ein Fehler, aber selten ein Totalausfall. **Zweitens: Die Browser-Kombination zählt mit.** Häufigste Paarung ist JAWS mit Chrome (24,7 %), dann NVDA mit Chrome (21,3 %), JAWS mit Edge (11,4 %), NVDA mit Firefox (10,0 %) und VoiceOver mit Safari (7,0 %). Der Accessibility Tree wird vom Browser gebaut. Chrome, Firefox und Safari legen manche Regeln unterschiedlich aus. Ein Test ist immer ein Test des Paares, nie eines einzelnen Programms. **Drittens: Die Zahlen sind nicht deutsch.** Die Umfrage läuft auf Englisch und erreicht vor allem den anglo-amerikanischen Raum. Domingos de Oliveira, der seit Jahren aus der deutschen Perspektive schreibt, hält fest, dass es hier schlicht keine validen offiziellen Statistiken gibt und JAWS und NVDA sich auf dem Desktop ungefähr die Waage halten. Ich würd deshalb keine Priorisierung allein auf Prozentwerte stützen: Der Unterschied zwischen 40 % und 38 % Marktanteil ändert an deiner Arbeit exakt nichts. ## Zwei Konzepte, an denen sich die Programme scheiden **Die Moduslogik.** Unter Windows arbeitet ein Screenreader auf Webseiten in einer eigenen Dokumentansicht, in der Schnelltasten navigieren: `H` nächste Überschrift, `K` Link, `D` Landmarke. Sobald der Fokus in ein Eingabefeld springt, gehen Tastendrücke stattdessen ins Feld. NVDA und JAWS schalten dabei automatisch um; VoiceOver kennt diese Trennung so nicht, sondern steuert über eine Interaktionsebene. Das erklärt einen guten Teil der Verhaltensunterschiede zwischen Windows und Apple. Die Mechanik dahinter steht unter [Screenreader-Grundlagen](https://html-einfach.de/wcag-und-bfsg/screenreader-grundlagen.html), die Tastenstrategien unter [Wie Screenreader-Nutzer surfen](https://html-einfach.de/barrierefreiheit-verstehen/wie-screenreader-nutzer-surfen.html). **Der zugängliche Name.** Er entsteht nach einer festen Rangfolge: `aria-labelledby` schlägt `aria-label`, das wiederum den sichtbaren Textinhalt schlägt. Diese Reihenfolge ist im W3C-Standard genormt und einer der wenigen Punkte, an denen sich alle Programme gleich verhalten. Deshalb überschreibt ein `aria-label` einen völlig korrekten Linktext in jedem Screenreader. Das ist ein Fehler, den man beim Lesen des Codes nicht sieht, beim Hören aber sofort. Custom-Widgets, die [Rollen und Zustände](https://html-einfach.de/barrierefreie-komponenten/rollen-states-properties.html) falsch setzen, versagen dagegen je nach Programm unterschiedlich (dieselbe Ursache, drei verschiedene Symptome). > **Randnotiz: ARIA an generischen Elementen verpufft.** Ein `aria-label` braucht eine > Rolle, an der es hängen kann. An einem `div` ohne `role` wird es je nach Screenreader > ignoriert oder inkonsistent ausgegeben. Das ist kein Bug, sondern die Spezifikation: > Ohne Rolle gibt es kein Element, das benannt werden könnte. ```html
    ``` ## Wo sich die Programme wirklich unterscheiden Screenreader interpretieren Grenzfälle unterschiedlich (nicht anders als Browser vor zwanzig Jahren). Die Unterschiede, die mir in Tests am häufigsten begegnen: - **Listen und Tabellen.** JAWS und NVDA kündigen „Liste mit 3 Einträgen“ an, verschachtelte Listen aber unterschiedlich ausführlich. Bei Tabellen entscheidet allein die Auszeichnung: Ohne `` und `scope` ist eine Preistabelle in jedem Programm eine Zahlenwolke. Mehr dazu unter [Tabellen semantisch aufbauen](https://html-einfach.de/semantisches-html/tabellen-semantisch-aufbauen.html). - **Interpunktion und Zahlen.** „1.4.3“ wird je nach Stimme und Einstellung als Datum, als Version oder als drei Zahlen gelesen. Verlass dich nie darauf, dass eine Zeichenkette so klingt, wie sie aussieht. - **Live-Regionen.** Was `aria-live="polite"` wann meldet, ist der wohl uneinheitlichste Bereich überhaupt: Timing, Wiederholungen und die Frage, ob eine Änderung überhaupt bemerkt wird, unterscheiden sich deutlich. Praxisregeln dazu stehen unter [Live-Regionen](https://html-einfach.de/barrierefreie-komponenten/live-regionen.html). - **VoiceOver-Rotor statt Schnelltasten.** Am iPhone gibt es keine `H`-Taste. Die Navigationseinheit wird über eine Zwei-Finger-Drehgeste eingestellt. Dieselbe Überschrift, ein völlig anderes Bedienkonzept. Daraus folgt die einzige Regel, die stabil bleibt: **Nah am Standard bleiben.** Natives HTML wird überall am konsistentesten unterstützt. Je exotischer das ARIA-Konstrukt, desto größer die Streuung. Das ist der praktische Kern der [ersten Regel von ARIA](https://html-einfach.de/barrierefreie-komponenten/erste-regel-von-aria.html). ## So testest du es 1. **Installiere NVDA** (kostenlos, rund 100 MB) und starte es mit `Strg+Alt+N`. Alternative ohne Installation: die Windows-Sprachausgabe mit `Win+Strg+Enter`, am Mac VoiceOver mit `Cmd+F5`. 2. **Schalte den Sprachausgaben-Betrachter ein** (im NVDA-Menü unter „Werkzeuge → Der Sprachausgaben-Betrachter“). Er zeigt jede Ansage zusätzlich als Text in einem Fenster; das erspart dir am Anfang das Mithören und macht die Ausgabe kopierbar. 3. **Springe nur mit `H` durch deine Startseite.** Ergibt die Folge der Überschriften ein schlüssiges Inhaltsverzeichnis, ohne dass du auf den Bildschirm schaust? 4. **Öffne die Elementliste mit `NVDA+F7`** und lies nur die Linktexte. Verrät jeder davon sein Ziel, oder steht dort dreimal „Weitere Informationen“? 5. **Bediene ein Formular komplett blind.** Dunkle den Bildschirm ab. Sagt jedes Feld seinen Namen, seinen Zustand („Pflichtfeld“) und im Fehlerfall die Ursache an? 6. **Wiederhole Schritt 3 bis 5 mit VoiceOver am iPhone** (Einstellungen → Bedienungshilfen → VoiceOver; wer den Bedienungshilfen-Kurzbefehl belegt, schaltet ihn per Dreifachklick auf die Seitentaste). Was in beiden funktioniert, funktioniert fast überall. Die ausführlichen Anleitungen dazu stehen unter [mit NVDA testen](https://html-einfach.de/wcag-und-bfsg/mit-nvda-testen.html), [mit JAWS testen](https://html-einfach.de/wcag-und-bfsg/mit-jaws-testen.html), [mit VoiceOver am Mac testen](https://html-einfach.de/wcag-und-bfsg/mit-voiceover-testen.html) sowie (für die mobile Seite) [VoiceOver auf iPhone und iPad](https://html-einfach.de/wcag-und-bfsg/mit-voiceover-ios-testen.html) und [TalkBack](https://html-einfach.de/wcag-und-bfsg/mit-talkback-testen.html). ## Häufiger Fehler in der Praxis **Marktanteile als Testplan lesen.** Aus 40,5 % gegen 37,7 % lässt sich keine Reihenfolge ableiten. Der Abstand liegt innerhalb dessen, was eine Selbstauswahl-Umfrage hergibt. Die verwertbare Zahl steht daneben: 71,6 % nutzen ohnehin mehrere Programme. Wer ein Formular in einem Screenreader sauber bedienbar macht, hilft der Mehrheit auch dann, wenn er das „falsche“ getestet hat. **Mit Standardtempo getestet.** Die Werkseinstellung der Sprachausgabe ist quälend langsam; geübte Nutzer hören mit rund dem doppelten Sprechtempo. Wer im Demo-Tempo testet, überschätzt die Geduld für lange Vorreden und unterschätzt, wie sehr eine fehlende Sprungmarke wehtut. **Am Mac getestet und Windows-Verhalten angenommen.** VoiceOver hat keine Trennung in Lese- und Formularmodus. Genau an dieser Weiche versagen unter NVDA und JAWS aber die meisten selbstgebauten Widgets. Ein Mac-Test ist ein guter Anfang, aber kein Abschluss: Die häufigste Fehlerklasse sieht er gar nicht. **Den Windows-Erzähler für gleichwertig halten.** Er ist an Bord und deshalb verlockend, aber er ist als Notlösung gebaut, nicht als Arbeitsgerät: In der WebAIM-Erhebung nutzt ihn praktisch niemand als primären Screenreader. „Funktioniert im Erzähler“ ist kein Befund, auf den sich eine Abnahme stützen lässt. ## Häufige Fragen ### Mit welchem Screenreader soll ich als Entwickler testen? Mit **NVDA** unter Windows und **VoiceOver** auf dem iPhone. NVDA kostet nichts, liegt mit 37,7 % fast gleichauf mit JAWS und verhält sich ähnlich genug, dass sich Befunde übertragen lassen. VoiceOver deckt die mobile Seite ab, wo es mit 70,6 % die klare Nummer eins ist. Wer nur einen Mac hat, startet mit VoiceOver am Mac. Ein Screenreader ist unendlich viel besser als keiner. ### Muss meine Seite in jedem Screenreader identisch klingen? Nein. Wie bei Browsern gilt: Das Verhalten muss funktionieren, nicht identisch sein. Ziel ist, dass Name, Rolle, Zustand und Struktur überall korrekt ankommen. Wie die Ansage formuliert wird, entscheidet der Screenreader und die persönliche Einstellung des Nutzers. Eine unterschiedliche Wortwahl ist kein Fehler, eine fehlende Rolle schon. ### Erkenne ich Screenreader-Nutzer in meiner Statistik? Nein, und das ist gewollt. Assistive Technologien geben sich aus Datenschutzgründen nicht zu erkennen; es gibt keinen zuverlässigen User-Agent und keinen Analytics-Wert dafür. Das Argument „unsere Nutzer haben das nicht“ lässt sich also gar nicht belegen. Die belastbare Grundlage sind stattdessen die [Zahlen zur Verbreitung](https://html-einfach.de/barrierefreiheit-verstehen/zahlen-und-business-case.html). ### Ersetzt ein automatischer Test den Screenreader? Nein. Automatische Prüfwerkzeuge finden fehlende Alt-Attribute, kaputte Label-Verknüpfungen und Kontrastfehler. Das ist also grob die Hälfte der WCAG-Kriterien. Ob ein Alt-Text sinnvoll ist, ob eine Reihenfolge logisch klingt oder ob ein Dialog die Aufmerksamkeit richtig lenkt, entscheidet nur ein Mensch mit Screenreader. Welche Werkzeuge was können, steht unter [Tools](https://html-einfach.de/ressourcen/tools.html). ### Brauche ich JAWS, wenn meine Zielgruppe Behörden sind? Nützlich ja, zwingend nein. Im deutschen Arbeitsumfeld (Verwaltung, Ausbildung, große Unternehmen) ist JAWS über die Hilfsmittelversorgung stark vertreten. Wenn du für öffentliche Stellen baust und die Abnahme über einen [BITV-Test](https://html-einfach.de/wcag-und-bfsg/bitv-test-und-audit.html) läuft, prüft ohnehin ein Profi mit seiner eigenen Ausstattung. Für die tägliche Entwicklung reicht NVDA. ## Verwandte Themen - [Wie Screenreader-Nutzer surfen](https://html-einfach.de/barrierefreiheit-verstehen/wie-screenreader-nutzer-surfen.html): die Navigationsstrategien hinter den Schnelltasten - [Braillezeile](https://html-einfach.de/barrierefreiheit-verstehen/braillezeile.html): wie 38 % der Befragten zusätzlich taktil lesen - [Sehbehinderung und Blindheit](https://html-einfach.de/barrierefreiheit-verstehen/sehbehinderung-und-blindheit.html): wer diese Programme nutzt und warum - [Screenreader-Grundlagen](https://html-einfach.de/wcag-und-bfsg/screenreader-grundlagen.html): was ein Test leisten kann und was nicht - [Mit NVDA testen](https://html-einfach.de/wcag-und-bfsg/mit-nvda-testen.html): Schritt für Schritt zum ersten eigenen Test; für die anderen Programme [JAWS](https://html-einfach.de/wcag-und-bfsg/mit-jaws-testen.html), [VoiceOver am Mac](https://html-einfach.de/wcag-und-bfsg/mit-voiceover-testen.html), [VoiceOver mobil](https://html-einfach.de/wcag-und-bfsg/mit-voiceover-ios-testen.html) und [TalkBack](https://html-einfach.de/wcag-und-bfsg/mit-talkback-testen.html) - [Landmarks und Outline](https://html-einfach.de/semantisches-html/landmarks-und-outline.html): das Gerüst, das die `D`-Taste überhaupt erst füllt ## Quellen --- # Bildschirmvergrößerung & ZoomText - URL: https://html-einfach.de/barrierefreiheit-verstehen/bildschirmvergroesserung.html - Themenbereich: Barrierefreiheit verstehen - Zuletzt geändert: 2026-08-21 - Kurzbeschreibung: Bildschirmvergrößerung erklärt: Browser-Zoom, Systemlupe und ZoomText im Vergleich und warum bei 400 % nur noch 320 CSS-Pixel Breite übrig bleiben. **Zwischen „sieht normal“ und „nutzt einen Screenreader“ liegt die größte und leiseste Nutzergruppe der Barrierefreiheit: Menschen, die vergrößern (manche um 25 %, manche um das Zehnfache). Ihre Anforderung ist eine einzige und sehr klare: Vergrößerung darf nichts kaputt machen, weder das Layout noch die Bedienbarkeit noch die Nähe zwischen einer Aktion und ihrer Rückmeldung.** ## Das Wichtigste in Kürze - Vier Werkzeuge, vier Wirkungsweisen: Browser-Zoom skaliert das Layout, Nur-Text-Vergrößerung nur die Schrift, die Systemlupe vergrößert Pixel, und Spezialsoftware wie ZoomText kombiniert alles mit Farbfiltern und Sprachausgabe. - **ZoomText** vergrößert 1- bis 60-fach und gibt es in zwei Ausführungen: nur Vergrößerung oder Vergrößerung plus Sprachausgabe. Viele Nutzer arbeiten dauerhaft im Bereich 4- bis 10-fach. - Der WCAG-Maßstab ist doppelt: **200 % Textvergrößerung** ohne Funktionsverlust ([1.4.4](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-4-textgroesse-aendern.html)) und **Umbruch bei 320 CSS-Pixeln** Breite ([1.4.10](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-10-reflow.html)). - 320 CSS-Pixel entsprechen 400 % Zoom in einem 1280 Pixel breiten Fenster. Auf einem Full-HD-Bildschirm bleibt bei 400 % ungefähr so viel sichtbar wie auf einem Smartphone-Display. - Das Kernproblem heißt **Ausschnitt**: Zusammengehöriges, das weit auseinanderliegt, fällt auseinander. Die Fehlermeldung steht oben, das Feld unten. Im Ausschnitt sieht man immer nur eines von beidem. - `user-scalable=no` und `maximum-scale=1` im Viewport-Meta sind die ärgerlichste Einzelbarriere überhaupt und verstoßen gegen [1.4.4](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-4-textgroesse-aendern.html). - Reflow scheitert selten am Gesamtlayout, sondern an einem einzelnen Element mit fester Mindestbreite: Datentabelle, Code-Block, eingebettete Karte. - Der Test dauert zwei Minuten: `Strg`/`Cmd` und `+` fünfmal drücken, dann den wichtigsten Ablauf durchspielen. ## Die vier Werkzeuge
    Vier Karten nebeneinander, jeweils mit einer kleinen Vorschau derselben Beispielseite. Erstens Browser-Zoom: Das ganze Layout ist größer und einspaltig umgebrochen, Hinweis: die Seite merkt es und kann reagieren. Zweitens Nur-Text-Vergrößerung: nur die Schrift ist größer, das Layout bleibt, Hinweis: funktioniert nur bei relativen Einheiten. Drittens Systemlupe: ein rechteckiger Ausschnitt der Seite ist stark vergrößert, der Rest liegt außerhalb, Hinweis: die Seite merkt nichts davon. Viertens ZoomText: starke Vergrößerung mit invertierten Farben, hervorgehobenem Fokusrahmen und einem Lautsprechersymbol für die Sprachausgabe, Hinweis: 1- bis 60-fach.
    Nur die ersten beiden Werkzeuge kann deine Seite überhaupt bemerken. Systemlupe und ZoomText arbeiten außerhalb des Browsers. Dort hilft nur ein Layout, das schon vorher stimmt.
    **Browser-Zoom** (`Strg`/`Cmd` und `+`) skaliert das gesamte Layout inklusive Bildern. Die Seite bekommt das über Media Queries mit und kann umbrechen. Der Maßstab der WCAG sind 400 % Zoom beziehungsweise 320 CSS-Pixel Breite. **Nur-Text-Vergrößerung** skaliert ausschließlich die Schrift und lässt das Layout in Ruhe. Sie greift nur, wenn Schriftgrößen in relativen Einheiten definiert sind. Bei `font-size: 14px` passiert nichts. **Systemlupe** (Windows-Bildschirmlupe, macOS-Zoom) vergrößert Bildschirmpixel wie eine physische Lupe. Der Browser merkt davon nichts, die Nutzerin sieht immer nur einen Ausschnitt, und Schrift wird je nach Verfahren unscharf. **Vergrößerungssoftware wie ZoomText** ist das Profi-Werkzeug: 1- bis 60-fache Vergrößerung, geglättete Schriftkanten, eigene Farbschemata, hervorgehobener Zeiger- und Fokusrahmen und optional Sprachausgabe. In der Kombination mit Sprache wird der Übergang zum [Screenreader](https://html-einfach.de/barrierefreiheit-verstehen/screenreader-ueberblick.html) fließend. ## Das Ausschnitts-Problem Rechnen wir es einmal durch. Ein Fenster ist 1280 CSS-Pixel breit. Bei 200 % Zoom bleiben 640 CSS-Pixel sichtbar, bei 400 % nur noch 320 (die Breite eines kleinen Smartphones, aber auf einem 27-Zoll-Bildschirm). Wer zusätzlich mit einer Systemlupe arbeitet, sieht noch weniger.
    Drei ineinandergelegte Rechtecke, die dasselbe 1280 Pixel breite Browserfenster darstellen. Das äußere zeigt 100 Prozent Zoom mit 1280 sichtbaren CSS-Pixeln, das mittlere 200 Prozent mit 640 CSS-Pixeln, das innerste 400 Prozent mit nur noch 320 CSS-Pixeln. Dieses ist zusätzlich mit dem Hinweis Breite eines kleinen Smartphones beschriftet. Rechts daneben eine Beispielseite, bei der ein Eingabefeld und die dazugehörige Fehlermeldung so weit auseinanderliegen, dass beide nie gleichzeitig im 320-Pixel-Ausschnitt liegen.
    Bei 400 % Zoom bleibt von einem 1280 Pixel breiten Fenster ein Viertel übrig. Alles, was weiter als dieser Ausschnitt auseinanderliegt, ist nie gleichzeitig sichtbar.
    Daraus folgen die typischen Stolperfallen: - **Zusammengehöriges liegt weit auseinander.** Fehlermeldung oben rechts, Feld unten links. Meldungen gehören [direkt ans Feld](https://html-einfach.de/barrierefreie-komponenten/fehlermeldungen-barrierefrei.html). - **Dinge erscheinen außerhalb des Sichtfelds.** Ein Toast am oberen Rand, ein Warenkorb- Badge in der Kopfzeile, ein [Tooltip](https://html-einfach.de/barrierefreie-komponenten/tooltips-und-popover.html), der woanders aufgeht. Für Zoom-Nutzer passiert das unbemerkt. Rückmeldungen gehören nahe an die Aktion, zusätzlich als [Live-Region](https://html-einfach.de/barrierefreie-komponenten/live-regionen.html). - **Sticky-Header fressen den Bildschirm.** Eine fixierte Kopfzeile, die bei 100 % 80 Pixel hoch ist, belegt bei 400 % ein Drittel der Höhe. Ab einer bestimmten Vergrößerung sollte sie mitscrollen statt kleben. - **Hover-Inhalte verdecken den Kontext.** Eingeblendetes muss [wegdrückbar bleiben und stehen bleiben](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-13-inhalt-bei-hover-oder-fokus.html), wenn man mit dem Zeiger hineinfährt. ## Was die 320-Pixel-Regel im Alltag bedeutet [1.4.10 Reflow](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-10-reflow.html) verlangt, dass Inhalte sich bei 320 CSS-Pixeln Breite umbrechen, ohne dass man in **zwei** Richtungen scrollen muss. Die Herleitung dieser Zahl steht im [Understanding-Dokument des W3C](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html). Als Regel klingt das technisch. Aus der Nutzungsperspektive ist es eine Aussage über Arbeitsspeicher im Kopf: Wer in zwei Richtungen scrollen muss, verliert bei jeder Bewegung den Bezugspunkt und muss sich merken, wo er herkam. Deshalb ist die Erlaubnis, einzelne Elemente waagerecht scrollen zu lassen, kein Schlupfloch, sondern die bessere Lösung. Eine Preistabelle in einem eigenen scrollbaren Bereich hat einen Rahmen, einen Anfang und ein Ende. Man weiß, worin man sich bewegt. Dieselbe Tabelle, die stattdessen die ganze Seite in die Breite zieht, macht jede Kopfzeile und jeden Fließtext daneben unlesbar. Wie man einen solchen Bereich baut und auch per Tastatur erreichbar hält, steht unter [Reflow, Zoom & Textabstände](https://html-einfach.de/wcag-und-bfsg/reflow-zoom-textabstaende.html). Die eine Barriere, die sich davon nicht abhandeln lässt, steckt im Viewport-Meta und findet sich in jedem zweiten CMS-Template: ```html ``` Der Unterschied ist nicht theoretisch. Wer am Smartphone auf Vergrößerung angewiesen ist, kann mit der ersten Fassung schlicht nichts anfangen: Kein Reflow der Welt hilft, wenn die eingebaute Vergrößerung des Betriebssystems abgeschaltet wurde. Bemerkenswert daran: Es ist derselbe Zustand, den Google seit der Umstellung auf Mobile-First-Indexing bewertet. Indexiert wird, was in der schmalen Ansicht im DOM steht. Inhalte, die dort per `display: none` verschwinden, fehlen beiden Seiten gleichermaßen. Wer also aus Layoutgründen einen Abschnitt „nur auf dem Desktop“ zeigt, entfernt ihn nicht nur für Menschen mit Vergrößerung, sondern auch aus dem Index; wie Suchmaschinen aus dem Markup lesen, steht unter [Semantik & SEO](https://html-einfach.de/seo-und-ki/semantik-und-seo.html). ## Wie Vergrößerungssoftware dem Blick folgt Der Punkt, den man ohne eigene Erfahrung kaum errät: Eine Lupe muss wissen, **wohin** sie schauen soll. ZoomText und die Systemlupen folgen dem Mauszeiger, dem Textcursor und dem Tastaturfokus. Der Ausschnitt springt also genau dorthin, wo eine dieser drei Marken landet und nirgendwo anders hin. Daraus folgen zwei Anforderungen, die auf keiner Kontrast- oder Layout-Checkliste stehen: - **Wer den Fokus nicht setzt, bewegt den Ausschnitt nicht.** Öffnet ein Dialog, ohne dass der Fokus hineinwandert, bleibt die Lupe auf der alten Stelle stehen. Auf dem Bildschirm liegt ein Fenster, das die Person nie zu sehen bekommt. Sie sucht weiter im leeren Hintergrund. Dasselbe gilt für Fehlermeldungen nach dem Absenden eines Formulars und für Inhalte, die per „mehr laden“ nachrücken. - **Ein unsichtbarer Fokus ist ein verlorener Ausschnitt.** Bei 6-facher Vergrößerung ist der Fokusring nicht Zierde, sondern das einzige Merkmal, an dem man den eigenen Standort erkennt. Was der übliche CSS-Reset `outline: none` bei Tastaturnutzung anrichtet, trifft diese Gruppe genauso hart. Mehr dazu steht unter [Tastaturbedienung & sichtbarer Fokus](https://html-einfach.de/wcag-und-bfsg/tastatur-und-fokus.html). Umgekehrt gilt: Alles, was den Fokus ungefragt versetzt, reißt den Ausschnitt mit. Ein Karussell, das den Fokus an sich zieht, oder ein Skript, das nach dem Laden in ein Feld springt, katapultiert den sichtbaren Bereich an eine Stelle, die niemand angesteuert hat. ## Farbfilter: der zweite Grund, warum Text kein Bild sein darf ZoomText und die Bedienungshilfen von Windows und macOS bringen eigene Farbschemata mit (invertiert, kontrastverstärkt, auf zwei Farben reduziert). Viele Nutzerinnen arbeiten dauerhaft in einem solchen Schema, weil Weiß auf großer Fläche blendet. Das erklärt zwei Anforderungen, die sonst willkürlich wirken. Erstens: **Text in Grafiken** bleibt von jedem Farbfilter unberührt. Eine Preistabelle als PNG wird invertiert zu einem Negativ, das schlechter lesbar ist als vorher. Deshalb erlaubt [1.4.5 Bilder von Text](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-5-bilder-von-text.html) das nur in wenigen Ausnahmen. Zweitens: **Bedeutung, die nur an Farbe hängt**, überlebt keinen Filter. Der rote Rahmen um das fehlerhafte Feld ist nach der Umschaltung vielleicht grau wie alle anderen. Deshalb verlangt [1.4.1 Benutzung von Farbe](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-1-benutzung-von-farbe.html) ein zweites Merkmal. Ein häufiger Reflex an dieser Stelle ist der eigene Dark-Mode-Umschalter. Er hilft, aber er ersetzt die Systemschemata nicht: Wer eine Vergrößerungssoftware mit eigenem Farbmodus fährt, bekommt deine Umschaltung gar nicht zu sehen. Sie liegt eine Ebene tiefer. ## Textabstände: der zweite, leisere Test [1.4.12 Textabstände](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-12-textabstaende.html) verlangt, dass Inhalte lesbar bleiben, wenn Nutzer Zeilenhöhe, Absatz-, Wort- und Buchstabenabstände erhöhen. Das trifft weitgehend dieselbe Gruppe: Wer vergrößert, stellt oft auch Abstände hoch, weil eng gesetzte Zeilen beim Ausschnittslesen ineinanderlaufen. Auch Menschen mit Legasthenie greifen regelmäßig zu Browser-Erweiterungen, die genau diese vier Werte verändern. Die vier Testwerte und die Bruchstellen, die sie sichtbar machen, stehen bei [1.4.12 im Detail](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-12-textabstaende.html). Für das Verständnis reicht der Kern: Deine Seite muss diese Einstellungen nicht anbieten, sondern nur überstehen. Sie geht fast immer an derselben Stelle kaputt (an einer festen Höhe, die für genau drei Textzeilen gerechnet war). ## So testest du es 1. **Fünfmal `Strg`/`Cmd` und `+`.** Das entspricht in einem 1280 Pixel breiten Fenster ungefähr 400 %. Danach den wichtigsten Ablauf durchspielen: Suche, Warenkorb, Kontaktformular. 2. **Mit der Systemlupe arbeiten** (Windows: `Win` und `+`; macOS: Bedienungshilfen → Zoom). Fünf Minuten reichen, um das Ausschnitts-Gefühl zu verstehen. Das ist die lehrreichste Übung im ganzen Thema. 3. **Ein Formular absenden, das Fehler enthält** (bei laufender Lupe). Springt der Ausschnitt zur Meldung, oder bleibt er stehen? 4. **Ein Farbschema des Betriebssystems einschalten** (Windows: Kontrastdesigns; macOS: Farben umkehren) und die Seite noch einmal durchgehen. Was verschwindet? 5. **Auf dem Smartphone Pinch-Zoom versuchen.** Geht es nicht, steht ein `user-scalable=no` im Viewport-Meta. Das vollständige Prüfrezept inklusive Textabstands-Test und Messwerten steht unter [Reflow, Zoom & Textabstände](https://html-einfach.de/wcag-und-bfsg/reflow-zoom-textabstaende.html). ## Häufiger Fehler in der Praxis **Nur die Breite geprüft.** Reflow wird meist mit einem schmalen Browserfenster getestet. Das ist nicht dasselbe wie Zoom: Beim Zoomen schrumpft auch die Höhe, und plötzlich belegen Sticky-Header, Cookie-Leiste und Chat-Widget zusammen den halben Bildschirm. **Die Rückmeldung ist da, aber nicht hier.** Der Toast erscheint oben rechts, gearbeitet wird unten links. Technisch alles korrekt, praktisch unbemerkt. Rückmeldungen gehören nahe an die auslösende Aktion und zusätzlich in eine [Live-Region](https://html-einfach.de/barrierefreie-komponenten/live-regionen.html), damit sie auch ohne Blick ankommt. **Modals mit fester Größe.** Ein Dialog mit `width: 600px; height: 400px` ist bei 400 % Zoom größer als der Bildschirm und meist ohne Scrollmöglichkeit gebaut. Siehe [Dialoge und Modals](https://html-einfach.de/barrierefreie-komponenten/dialoge-und-modals.html). **Vergrößerung mit Sehbehinderung gleichgesetzt.** Ein großer Teil dieser Gruppe würde sich nie als behindert bezeichnen: Kollegen um die sechzig, Menschen nach einer Augen-OP, jemand mit Migräne. Sie melden keine Barrieren, sie geben auf. Deshalb fehlt diese Gruppe in fast jeder Statistik, obwohl sie die größte ist. ## Häufige Fragen ### Browser-Zoom oder Textvergrößerung: was muss ich unterstützen? Beides, und die gute Nachricht: Ein sauber responsives Layout mit `rem`-basierten Schriftgrößen erfüllt beide Anforderungen nebenbei. Kritisch wird es nur bei pixelfixierten Schriften, festen Breiten und festen Höhen. Formal sind es zwei getrennte Kriterien: [1.4.4](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-4-textgroesse-aendern.html) für Text, [1.4.10](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-10-reflow.html) für Reflow. ### Wie viel Prozent Zoom entsprechen 320 CSS-Pixeln? 400 % in einem Fenster von 1280 CSS-Pixeln Breite. Ist dein Fenster breiter, brauchst du entsprechend mehr Zoom, um denselben Zustand zu erreichen oder du stellst im Responsive-Modus der DevTools schlicht 320 Pixel Breite ein. Das ist der genauere Weg. ### Hilft Dark Mode dieser Gruppe? Oft ja. Blendempfindlichkeit ist bei vielen Augenerkrankungen ein Thema, und ZoomText und Co. bringen deshalb eigene Farbschemata mit. Wichtig ist, dass auch das dunkle Schema die [Kontrastwerte](https://html-einfach.de/wcag-und-bfsg/farbkontraste.html) einhält und die Seite mit erzwungenen Systemfarben (etwa dem Windows-Kontrastmodus) nicht auseinanderfällt. Ich würd Dark Mode nie als Ersatz für gute Kontraste im hellen Schema verkaufen. ### Was ist mit großen Datentabellen, die sich nicht umbrechen lassen? Die sind ausdrücklich ausgenommen: 1.4.10 erlaubt zweidimensionales Scrollen für Inhalte, die es zwingend brauchen. Wichtig ist, dass nur die Tabelle scrollt und nicht die ganze Seite. Außerdem muss der Scroll-Container per Tastatur erreichbar sein. Alternativ hilft eine Kartenansicht für schmale Breiten, siehe [komplexe Datentabellen](https://html-einfach.de/barrierefreie-komponenten/komplexe-datentabellen.html). ### Merkt meine Seite, dass jemand eine Systemlupe benutzt? Nein. Systemlupe und ZoomText arbeiten außerhalb des Browsers. Es gibt kein Ereignis, keine Media Query, keinen User-Agent. Deshalb lässt sich für diese Gruppe nichts „ausliefern“: Es hilft nur ein Layout, das kurze Wege zwischen Aktion und Rückmeldung hat und schon bei normaler Nutzung aufgeräumt ist. ## Verwandte Themen - [Sehbehinderung und Blindheit](https://html-einfach.de/barrierefreiheit-verstehen/sehbehinderung-und-blindheit.html): das Spektrum hinter der Vergrößerung - [Reflow, Zoom & Textabstände](https://html-einfach.de/wcag-und-bfsg/reflow-zoom-textabstaende.html): die Praxisseite mit Messwegen - [Farbkontraste](https://html-einfach.de/wcag-und-bfsg/farbkontraste.html): der zweite große Hebel für diese Gruppe - [Screenreader im Überblick](https://html-einfach.de/barrierefreiheit-verstehen/screenreader-ueberblick.html): wohin der Weg bei sehr starker Vergrößerung führt - [Fehlermeldungen barrierefrei](https://html-einfach.de/barrierefreie-komponenten/fehlermeldungen-barrierefrei.html): Rückmeldung dort platzieren, wo der Blick ist - [Komplexe Datentabellen](https://html-einfach.de/barrierefreie-komponenten/komplexe-datentabellen.html): die häufigste Reflow-Falle und ihre Lösung ## Quellen --- # Sprachsteuerung: Dragon, Voice Control & Voice Access - URL: https://html-einfach.de/barrierefreiheit-verstehen/sprachsteuerung.html - Themenbereich: Barrierefreiheit verstehen - Zuletzt geändert: 2026-07-17 - Kurzbeschreibung: Sprachsteuerung im Web: wie Dragon, Voice Control und Voice Access klicken und warum sichtbare Beschriftung und zugänglicher Name zusammenpassen müssen. **Sprachsteuerung klickt nicht auf Pixel, sondern auf Namen: Wer „Klicke Warenkorb“ sagt, lässt die Software nach einem Bedienelement suchen, dessen zugänglicher Name zum gesprochenen Wort passt. Deshalb hat diese Technik die vielleicht überraschendste Anforderung an dein HTML: sichtbare Beschriftung und technischer Name müssen zusammenpassen, sonst existiert die Schaltfläche für den Befehl nicht.** ## Das Wichtigste in Kürze - Nutzer sind Menschen, die ihre Hände nicht oder nur eingeschränkt einsetzen können: nach Unfällen, bei Muskelerkrankungen, Lähmungen, starkem Tremor oder chronischen Sehnenscheidenproblemen. Dazu kommen alle, die aus Zeit- oder Schmerzgründen diktieren. - Die drei relevanten Programme: **Dragon** (Windows, kommerziell), **Voice Control** (macOS, iOS, iPadOS) und **Voice Access** (Android). Die beiden letzten sind im System enthalten und kosten nichts. - Drei Bedienwege decken fast alles ab: beim Namen rufen, Nummern-Overlay einblenden, im Notfall das Bildschirmraster. - Zentrales Kriterium ist [WCAG 2.5.3 „Beschriftung im Namen“](https://html-einfach.de/wcag-und-bfsg/kriterien/2-5-3-beschriftung-im-namen.html) auf Stufe A: Der sichtbare Text muss im zugänglichen Namen enthalten sein. - Die häufigste Fehlerquelle ist gut gemeintes ARIA: Ein `aria-label` **ersetzt** den sichtbaren Text, statt ihn aufzunehmen. Danach findet kein Sprachbefehl das Element mehr. - Ein klickbares `
    ` ohne Rolle taucht im Nummern-Overlay nicht auf. Sprachsteuerung prüft damit unbestechlich, ob deine interaktiven Elemente echte Elemente sind. - Praxisbefund aus deutschen Tests: Dragon verlangt in Kombination mit Chrome den vollständigen zugänglichen Namen, nicht nur die sichtbare Beschriftung. Identische Namen sind deshalb sicherer als bloß enthaltene. - Testen kostet nichts: Voice Control am Mac oder Voice Access am Android-Gerät einschalten und die eigenen Kernabläufe per „Klicke …“ durchspielen. ## Die Werkzeuge | Programm | Plattform | Kosten | Besonderheit | | --- | --- | --- | --- | | **Dragon** | Windows | kommerziell | Diktat und Steuerung in einem, sehr mächtige Makros | | **Voice Control** | macOS, iOS, iPadOS | im System enthalten | Nummern- und Rastermodus, arbeitet offline | | **Voice Access** | Android | im System enthalten | Nummern-Overlay, eng mit TalkBack verzahnt | | **Windows-Spracherkennung** | Windows | im System enthalten | Basis-Funktionen, für Diktat brauchbar | Wichtig fürs Verständnis: Sprachsteuerung tritt selten allein auf. Viele Nutzer kombinieren sie mit [Bildschirmvergrößerung](https://html-einfach.de/barrierefreiheit-verstehen/bildschirmvergroesserung.html), mit einer Restnutzung der Tastatur oder mit einer Kopfmaus. Wer für [motorische Einschränkungen](https://html-einfach.de/barrierefreiheit-verstehen/motorische-einschraenkungen.html) baut, baut deshalb fast immer für mehrere Techniken gleichzeitig. ## Wie per Stimme geklickt wird
    Drei nebeneinanderstehende Darstellungen derselben Produktseite für einen Laufschuh. Erstens Beim Namen rufen: Der gesprochene Befehl „Klicke In den Warenkorb“ steht in einer Sprechblase, die passende Schaltfläche ist grün hervorgehoben. Zweitens Nummern-Overlay: Über den Bedienelementen liegen kleine gelbe Marken mit den Nummern eins bis vier, der Befehl lautet „Zeige Nummern“ und dann „Klicke 3“; das als klickbares div gebaute Element „Bewertungen“ trägt keine Nummer, ist rot gestrichelt umrandet und durchgestrichen. Drittens Raster-Modus: Der Bildschirm ist in neun nummerierte Zonen geteilt, die mittlere ist markiert, der Befehl lautet „5“, „5“, „8“, „Klicken“.
    Die ersten beiden Wege setzen sauberes Markup voraus. Wer seine Nutzer in den Rastermodus zwingt, hat vorher etwas falsch gemacht.
    **1. Beim Namen rufen.** „Klicke Warenkorb“: die Software durchsucht den Accessibility Tree nach einem Bedienelement, dessen zugänglicher Name zum gesprochenen Wort passt, und löst es aus. Das ist der schnellste Weg und der, den alle bevorzugen. **2. Nummern-Overlay.** Auf Kommando („Zeige Nummern“, „Show numbers“) blendet die Software über jedem erkannten Bedienelement eine Nummer ein: „Klicke 14“. Der Haken: Nummern bekommt nur, was als interaktiv erkennbar ist. Echte [Buttons und Links](https://html-einfach.de/barrierefreie-komponenten/buttons-vs-links.html) tauchen auf, klickbare `
    `s nicht. **3. Raster-Modus.** Die Notlösung: Der Bildschirm wird in nummerierte Zonen geteilt, die sich nach jedem Befehl weiter unterteilen, bis der Zeiger auf dem Ziel steht. Drei bis vier Schritte für einen einzigen Klick (mühsam, aber der letzte Ausweg bei Oberflächen, die nichts preisgeben). ## Die Falle: wenn `aria-label` den Namen überschreibt Am häufigsten scheitert Sprachsteuerung ausgerechnet an gut gemeintem ARIA. ```html ``` Das Prinzip regelt [WCAG 2.5.3 „Beschriftung im Namen“](https://html-einfach.de/wcag-und-bfsg/kriterien/2-5-3-beschriftung-im-namen.html): Der sichtbare Text muss im zugänglichen Namen enthalten sein. Am sichersten ist es, wenn beide identisch sind und zwar aus einem praktischen Grund. > **Randnotiz: „enthalten“ reicht nicht immer.** In > [deutschen Praxistests](https://www.fronta11y.org/digitale-barrierefreiheit-und-spracheingabe/) > zeigte sich, > dass Dragon zusammen mit Chrome den **vollständigen zugänglichen Namen** erwartet, nicht > nur den sichtbaren Anteil. Bei `aria-label="Suche starten"` auf einem Button mit dem > Text „Suchen“ ist die WCAG formal erfüllt. Gesagt werden muss trotzdem „Klicke Suche > starten“. Wer sich Diskussionen sparen will, macht sichtbaren Text und Namen gleich. Wenn ein `aria-label` unvermeidbar ist, gehört der sichtbare Text an den **Anfang**: `aria-label="Jetzt kaufen: Warenkorb mit 3 Artikeln"` funktioniert, umgekehrt nicht. ## Wo Sprachsteuerung sonst noch scheitert **Fünfmal „Mehr“ auf einer Seite.** Wenn mehrere Elemente denselben Namen tragen, fragt die Software nach oder nummeriert durch: jedes Mal ein zusätzlicher Schritt. Das ist derselbe Grund, aus dem [Linktexte ihr Ziel benennen](https://html-einfach.de/wcag-und-bfsg/kriterien/2-4-4-linkzweck-im-kontext.html) sollen. **Platzhalter statt Label.** „Gehe zu E-Mail“ funktioniert nur, wenn das Feld einen zugänglichen Namen hat. Ein grauer Text im Feld ist keiner (siehe [Labels und Beschriftungen](https://html-einfach.de/barrierefreie-komponenten/labels-und-beschriftungen.html) und [3.3.2](https://html-einfach.de/wcag-und-bfsg/kriterien/3-3-2-beschriftungen-oder-anweisungen.html)). ```html ``` **Einzeltasten-Kürzel.** Wer diktiert, erzeugt laufend Buchstaben. Reagiert die Seite auf ein einzelnes „s“ mit dem Öffnen der Suche, wird jedes Diktat zum Glücksspiel. Deshalb verlangt [2.1.4](https://html-einfach.de/wcag-und-bfsg/kriterien/2-1-4-tastenkuerzel.html), dass solche Kürzel abschaltbar, umbelegbar oder nur bei Fokus aktiv sind. **Text in Grafiken.** Was als Bild vorliegt, hat keinen Namen zum Rufen. Eine Schaltfläche als PNG mit eingebranntem „Jetzt buchen“ ist per Stimme unerreichbar und verstößt nebenbei gegen [1.4.5 Bilder von Text](https://html-einfach.de/wcag-und-bfsg/kriterien/1-4-5-bilder-von-text.html). **Selbstgebaute Auswahlfelder.** Ein Dropdown aus `
    `s mit JavaScript hat weder Rolle noch Zustand. Voice Control kann es weder anspringen noch aufklappen. Das native ` ``` **Implizit durch Umschließen:** Das Feld liegt im `