Barrierefreiheit auf deiner Website: Was ein Screenreader wirklich liest und was er nicht findet

Keine weitere Überschrift anklickbar
Grafik ohne Label
Wenn du fehlende Bildbeschreibungen abrufen möchtest, öffne das Kontextmenü.

Einzelperson Auswahlschalter Nicht aktiviert 1 von 2
Mehrere Personen Auswahlschalter Nicht aktiviert 2 von 2

Bitte wählen Kombinationsfeld Bitte wählen eingeklappt Liste öffnen
Bitte wählen Kombinationsfeld Bitte wählen eingeklappt Liste öffnen
z.B. 8000 Kombinationsfeld eingeklappt mit AutoVervollständigung einstellbar Leer
Eingabefeld Leer
TT.MM.JJJJ Kombinationsfeld eingeklappt einstellbar Dialogfeld öffnen Leer

Vermutlich hast du nach ein paar Zeilen gemerkt, dass es sich um ein Formular handelt. Doch wenn es darum geht, es auszufüllen, beginnt das Ratespiel. Nicht nur für dich.

Was soll in das erste «Bitte wählen»? Was ins zweite? Welche Postleitzahl ist gemeint, welches Datum? Das Formular gibt keine Antworten. Es schweigt.

Das ist kein konstruiertes Worst-Case-Szenario. Es ist ein echter Transkript von dem, was blinde Personen hören, aufgerufen auf der öffentlich zugänglichen Website einer Schweizer Versicherung. Der Screenreader liest vor, was im Code steht. Und im Code stehen keine Labels.

Ein anderes Beispiel. Auf einer Newsseite passiert nach mehrmaligem Drücken der Taste H folgendes:

Keine weitere Überschrift
Keine weitere Überschrift
Keine weitere Überschrift

Screenreader-Nutzende verwenden beim Aufrufen einer neuen Website gerne Tastaturkürzel, um sich schnell zu orientieren. Die Taste H springt von Überschrift zu Überschrift, damit Nutzende eine Seite querlesen können. Die aufgerufene News-Website hat visuell durchaus Überschriften. Gross, fett, prominent. Doch auf Code-Ebene sind es schlicht keine. Vielleicht wurde <div class="titel"> verwendet statt <h2>. Vielleicht hat ein CMS die Struktur geschluckt. Der Screenreader findet nichts, weil nichts da ist, was er finden könnte. Für jemanden, der mit dem Screenreader navigiert, ist die Seite ein einziger unstrukturierter Textblock.

Wer hat diese Formulare gebaut? Wer hat entschieden, dass <div class="titel"> reicht? Vermutlich niemand mit böser Absicht. Barrierefreiheit scheitert selten an Gleichgültigkeit, sondern meistens an fehlendem Wissen.

Doch das Thema bekommt Druck von aussen. Seit Juni 2025 gilt in der EU der European Accessibility Act (EAA), in Deutschland umgesetzt als Barrierefreiheitsstärkungsgesetz (BFSG). Schweizer KMUs, die Kundinnen und Kunden in der EU bedienen oder für den deutschen Markt produzieren, sind davon nicht ausgenommen.

Was ist der EAA und was hat die Schweiz damit zu tun?

Der EAA verpflichtet Unternehmen, digitale Produkte und Dienstleistungen barrierefrei anzubieten. Konkret betrifft das E-Commerce, Banking, E-Books, Ticketing und digitale Kommunikationsdienste. In Deutschland ist der EAA seit Juni 2025 als Barrierefreiheitsstärkungsgesetz in Kraft.

Ausgenommen sind Kleinstunternehmen mit weniger als zehn Mitarbeitenden und unter zwei Millionen Franken Jahresumsatz. Für alle anderen gilt: Wer Produkte oder Dienstleistungen in EU-Länder verkauft, fällt unter den EAA. Und zwar unabhängig davon, wo das Unternehmen seinen Sitz hat.

«Barrierefrei» bedeutet dabei konkret: Websites und Apps müssen den Web Content Accessibility Guidelines (WCAG) 2.1 auf Stufe AA entsprechen. Das ist kein vages Qualitätsziel, sondern ein prüfbarer technischer Standard mit über fünfzig Erfolgskriterien.

Die häufigsten Baustellen im Projektalltag

Barrierefreiheit wird oft mit schlechtem Design in Schwarz-Weiss, Screenreadern und Textwüsten ohne Bilder gleichgesetzt. Dabei trifft genau das Gegenteil zu. Barrierefreie Websites sind besser gestaltet, nicht schlechter. Sie helfen älteren Nutzenden mit nachlassender Sehkraft, Menschen mit motorischen Einschränkungen und jemandem, der das Video im Zug ohne Ton schaut. Die folgenden fünf Probleme begegnen im Projektalltag am häufigsten.

1.  Fehlende semantische Strukturen

Visuell sieht die Seite strukturiert aus: grosse Titel, kleinere Zwischentitel, fliessender Text. Im Code findet sich ein Textbandwurm. Gross, farbig, oben, unten: Das alles interessiert den Screenreader nicht. Das Vorleseprogramm liest wie bereits erwähnt nur vor, was auf Code-Ebene korrekt ausgezeichnet ist. Wenn diese Strukturen fehlen, können Screenreader-Nutzende nicht von Überschrift zu Überschrift springen. Wenn Tabellen nicht über korrekte Spalten- und Zeilenüberschriften verfügen, müssen Nutzer:innen mühsam mit den Pfeiltasten navigieren, um die Daten zu verstehen. Und wenn eine Seite keinen Sprunglink anbietet, gibt es keinen Weg, die Navigation zu überspringen und direkt zum Hauptinhalt zu gelangen. Wer die Seite täglich besucht, hört so jedes Mal die vollständige Navigation von vorne.

2.  Schlechte Farbkontraste

Hellgrauer Text auf weissem Hintergrund sieht minimalistisch aus. Im Büro mit gutem Monitor kaum ein Problem. Draussen in der Sonne, auf einem älteren Display oder mit einer Sehschwäche macht das schwache Kontrastverhältnis das Lesen eines Textes zur Geduldsprobe. Die WCAG schreiben ein Kontrastverhältnis von mindestens 4.5:1 für normalen Text vor. Mit Werkzeugen wie dem Colour Contrast Analyser kannst du das sekundenschnell messen. Aber Kontrast ist nicht alles. Das höchste mögliche Kontrastverhältnis beträgt 21:1, also Schwarz auf Weiss. Für Menschen mit bestimmten Sehbehinderungen kann diese Kombination stark blenden. Und Mindestkontraste gelten nicht nur für Text. Auch Bedienelemente wie Buttons, Eingabefelder und Icons müssen ausreichend kontrastreich sein.

3.  Fehlende Label-Verknüpfung bei Formularen

Das haben wir am Anfang gehört. Wenn ein Formularfeld nicht korrekt mit der Beschriftung verknüpft ist, sind diese Formulare für blinde Personen kaum ausfüllbar. Aber auch Nutzende ohne Hilfsmittel profitieren von korrekt verknüpften Labels. Wenn eine Beschriftung korrekt verknüpft ist, springt der Fokus direkt ins Feld, wenn man die Beschriftung anklickt oder auf einem Touchscreen antippt.

Nicht alle Nutzenden verwenden eine Maus. Menschen mit motorischen Einschränkungen, Nutzende mit Tremor, aber auch Power-User navigieren per Tastatur. Wenn Buttons, Links oder Menüs per Tabulator-Taste nicht erreichbar sind, oder wenn jemand den Fokus-Rahmen per CSS entfernt hat, müssen Nutzende raten, welches Element sie gerade fokussiert haben. Tab, Tab, Tab und keine Ahnung, wo man gerade ist? Das Aufrufen des korrekten Links gleicht dann einem Link-Roulette.

4.  Fehlende Tastaturbedienbarkeit

Informationen, die nur über einen Sinneskanal vermittelt werden, schliessen aus. Ein Erklärvideo ohne Untertitel erreicht niemanden, der sich in einer lauten Umgebung befindet, der gehörlos ist oder der die Sprache nicht gut versteht. Ein Podcast ohne Transkript ist für gehörlose Menschen schlicht nicht zugänglich. Eine komplexe Infografik ohne gleichwertige Textalternative ebenfalls nicht. Das Zwei-Sinne-Prinzip verlangt, dass Inhalte immer über mindestens zwei Kanäle zugänglich sind: Bild und Text, Ton und Untertitel.

5.  Das Zwei-Sinne-Prinzip

Wie lassen sich diese Barrieren vermeiden oder beheben?

Barrierefreiheit ist kein einmaliges Projekt, sondern ein Prozess. Sogenannte Accessibility-Overlays versprechen, eine Website mit einem einzigen Script barrierefrei zu machen. In der Praxis kollidieren sie mit Screenreadern, überlagern Inhalte und wiegen Betreiber in falscher Sicherheit. Ein einfaches Vier-Schritte-Modell hilft, den Einstieg zu strukturieren.

Schritt 1: Audit

Um Barrieren zu beseitigen, musst du zuerst verstehen, was fehlt. Tools wie axe DevTools, WAVE oder Lighthouse liefern einen ersten Überblick. Aber Achtung: Automatische Scans finden nur etwa 30 Prozent aller Probleme. Der Rest braucht manuelle Prüfung. Keyboard-Navigation testen, Screenreader einschalten, Seite mit 200 Prozent Zoom laden, Formulare ausfüllen. Wer noch nie mit einem Screenreader gearbeitet hat, wird überrascht sein, wie anders sich eine vertraute Website anfühlt – oder besser: anhört.

Schritt 2: Priorisieren

Nicht alle Probleme sind gleich kritisch. Die zentrale Frage lautet: Was ist nutzungshindernd, was erschwert die Nutzung und was ist vielleicht nur ein Schönheitsfehler? Was viele blockiert und du schnell beheben kannst, solltest du zuerst beheben. Kritisch sind in der Regel Formulare, Navigation und Fehlermeldungen. Nicht alles, was im Audit auftaucht, muss sofort ins Backlog. Manche Probleme lösen sich durch eine redaktionelle Schulung, nicht durch Code.

Schritt 3: Umsetzen

Barrierefreiheit betrifft das gesamte Team. Entwickler:innen beheben Code-Probleme, das Design-Team überarbeitet Kontraste und Fokus-Styles, die Content-Redaktion schreibt Alternativtexte und strukturiert Inhalte mit echten Überschriften.

Schritt 4: Erneut Testen

Ein grünes Lighthouse-Ergebnis bedeutet nicht, dass die Website barrierefrei ist. Manuelles Testen heisst: Tastatur nehmen, Maus weglegen, durch die Website navigieren. Kommt man zu jedem Element? Ist der Fokus sichtbar? Kann man Formulare ausfüllen und absenden?

Habt ihr schon mal die Tabulatortaste auf eurer eigenen Website gedrückt? Was habt ihr gefunden? Schreibt es in die Kommentare.

Titelbild: Andrej Lišakov / Unsplash