Die häufigsten Barrierefreiheits-Fehler auf Websites – und wie du sie behebst
Die meisten Barrierefreiheits-Probleme im Web sind nicht exotisch. Es sind immer wieder dieselben Handvoll Fehler – und genau das ist die gute Nachricht: Wenn du diese kennst, hast du den Großteil schon im Griff. Wir betreiben selbst sieben eigene Marken live in Produktion, darunter einen Barrierefreiheits-Scanner, und sehen täglich, welche Punkte auf realen Websites schiefgehen. Hier sind die häufigsten – mit konkreter Lösung statt Theorie.
1. Zu schwacher Farbkontrast
Hellgrauer Text auf weißem Hintergrund sieht im Designtool elegant aus, ist aber für viele Menschen schlicht nicht lesbar. Das ist der mit Abstand häufigste Befund. Die WCAG verlangen für normalen Text ein Kontrastverhältnis von mindestens 4,5:1, für großen Text 3:1.
- So behebst du es: Prüfe deine Farbkombinationen mit einem Kontrast-Checker (z. B. dem WebAIM Contrast Checker). Dunkle deine graue Schrift ab, bis der Wert passt.
- Verlasse dich nie allein auf Farbe, um Bedeutung zu transportieren – etwa „rote Felder sind Pflicht". Ergänze immer Text oder Symbole.
2. Fehlende oder sinnlose Alt-Texte bei Bildern
Screenreader lesen den Alternativtext vor, wenn ein Bild nicht gesehen werden kann. Fehlt er, hören Nutzer nur den Dateinamen wie „IMG_4821.jpg" – nutzlos. Genauso schlecht: ein Alt-Text wie „Bild" oder eine Aneinanderreihung von Keywords.
- So behebst du es: Beschreibe den Inhalt und die Funktion des Bildes knapp und sachlich. „Mitarbeiterin berät Kunden am Empfangstresen" statt „Beratung".
- Rein dekorative Bilder bekommen ein leeres
alt="", damit der Screenreader sie überspringt. Das ist hier ausdrücklich richtig – nicht jedes Bild braucht eine Beschreibung.
3. Website nicht per Tastatur bedienbar
Viele Menschen nutzen keine Maus – wegen motorischer Einschränkungen, Sehbehinderung oder einfach aus Gewohnheit. Wenn man mit der Tab-Taste nicht durch Menü, Links und Formulare kommt oder ein Dropdown sich nicht mit der Tastatur öffnen lässt, ist die Seite für sie unbenutzbar.
- So testest du es: Klick die Maus weg und bediene deine Seite nur mit Tab, Shift+Tab und Enter. Kommst du überall hin? Kannst du jedes Element auslösen?
- So behebst du es: Nutze echte HTML-Elemente wie
undstatt anklickbarer. Diese sind von Haus aus tastaturbedienbar. Interaktive Custom-Komponenten brauchen passende ARIA-Rollen und Tastatur-Handler.4. Unsichtbarer Fokus-Indikator
Eng verwandt mit Punkt 3: Wer per Tastatur navigiert, muss sehen, wo er gerade steht. Viele Designs entfernen den Fokusrahmen mit
outline: none, weil er „stört" – und machen die Seite damit unbenutzbar.- So behebst du es: Entferne den Fokus nie ersatzlos. Gestalte stattdessen einen gut sichtbaren eigenen Fokus-Stil mit klarem Kontrast.
5. Formulare ohne verknüpfte Labels
Eingabefelder, deren Beschriftung nur als Platzhaltertext im Feld steht, sind ein Klassiker. Der Platzhalter verschwindet beim Tippen, und Screenreader können das Feld oft gar nicht zuordnen.
- So behebst du es: Verbinde jedes Feld über das
for-Attribut mit einem sichtbaren. - Gib bei Fehlern klaren Text aus – „Bitte gib eine gültige E-Mail-Adresse ein" – statt nur das Feld rot zu färben.
6. Fehlende oder durcheinandergewürfelte Überschriften-Struktur
Screenreader-Nutzer springen oft von Überschrift zu Überschrift, um eine Seite zu erfassen. Wenn Überschriften nur visuell „groß und fett" gestaltet sind, aber keine echten
bissind, oder wenn Ebenen übersprungen werden, geht diese Orientierung verloren.- So behebst du es: Verwende eine logische Hierarchie: eine
pro Seite, darunterfür Hauptabschnitte,für Unterpunkte. Größe regelst du über CSS, nicht über die falsche Ebene.
7. Nichtssagende Linktexte
„Hier klicken" oder „mehr erfahren" sind aus dem Kontext gerissen wertlos. Screenreader können sich alle Links einer Seite als Liste vorlesen lassen – zehnmal „mehr erfahren" hilft niemandem.
- So behebst du es: Schreibe Linktexte, die auch allein verständlich sind: „Leistungen ansehen" statt „mehr".
8. Videos ohne Untertitel, fehlende Sprachauszeichnung
Audio- und Videoinhalte brauchen Untertitel, damit gehörlose Menschen sie nutzen können. Und im
-Tag fehlt erstaunlich oft das Attributlang="de"– ohne das spricht der Screenreader deutschen Text womöglich mit englischer Aussprache vor.- So behebst du es: Setze
lang="de"und hinterlege bei Videos eine Untertitelspur.
Wie du systematisch vorgehst
Ein automatischer Scanner (etwa axe oder unser eigenes Tool) findet rund die Hälfte dieser Probleme zuverlässig – Kontraste, fehlende Alt-Attribute, fehlende Labels. Die andere Hälfte erfordert einen manuellen Test: Tastatur-Durchlauf, Screenreader-Stichprobe, Blick auf die Logik. Verlass dich also nicht allein auf ein grünes Tool-Ergebnis.
Sei ehrlich zu dir selbst über den Umfang: Für eine kleine Visitenkarten-Website reicht es oft, diese acht Punkte sauber abzuarbeiten. Wer rechtlich unter das Barrierefreiheitsstärkungsgesetz (BFSG) fällt – etwa Online-Shops oder bestimmte Dienstleistungen – sollte das Thema strukturierter und mit dokumentiertem Test angehen. Die meisten Fehler sind aber kein Hexenwerk, sondern Sorgfalt im Detail.
Brauchst du selbst eine Website, ein Tool oder eine SaaS?Wir bauen sie zum Festpreis - vom Team, das sieben eigene Marken live betreibt. Klarer Scope, klarer Preis, klarer Zeitrahmen.
Projekt startenLeistungen & PreiseAutomatische Tests und manuelle Prüfung
Ein Barrierefreiheits-Checker findet etwa 50% der Probleme automatisch: Kontraste, Alt-Text, Labels. Die andere Hälfte braucht einen Menschen: Ist das Formular wirklich mit Tastatur bedienbar? Funktioniert der Screenreader? Ist der Focus sichtbar? Das kann nur ein echten Test zeigen. Oft braucht dafür jemand NVDA (kostenlos) zu installieren und probieren.
Die Kombination ist wichtig: Tool-Report 15 Minuten durcharbeiten, dann 30 Minuten Tastatur- und Screenreader-Test. Das ist auf unter einer Stunde gemacht und gut genug für kleine Seiten.
Farbe allein ist nicht genug
Eine rote Fehlermeldung bringt nichts, wenn jemand farbenblind ist. Die WCAG verlangt, dass Information nicht nur durch Farbe vermittelt wird. Das heißt: Ein X oder ein "Fehler" Text neben rot. Ein rotes Feld für Pflichtfelder ist OK, aber zusätzlich sollte ein Asterisk oder "erforderlich" stehen. Diese Redundanz ist nicht busy, sie ist zugänglich.
Die Faustregel: Wenn ein farbenblinder Nutzer die Seite in Graustufen sieht, sollte er verstehen, was Fehler und was OK ist. Das erreichst du durch Symbole, Text und Struktur — nicht nur Farbe.
Dynamische Inhalte und Modals
Wenn du mit JavaScript einen "Laden"-Button hast der neue Inhalte lädt, kriegt ein Screenreader das oft nicht mit. Es muss explizit eine Ankündigung geben, dass neue Inhalte erschienen sind. Das ist technisch einfach, wird aber ständig übersehen.
Ebenso bei Modals (Pop-ups): Sie müssen den Focus auf sich selbst legen und sperren den Zugang zum Hintergrund. Ein Modal, das sich öffnet und du kannst trotzdem durch die alte Seite navigieren, ist ein Bug. Viele JavaScript-Frameworks haben das nicht eingebaut.
Häufig gestellte Fragen
Muss ich WCAG 2.1 AA konform sein?
Das hängt davon ab, ob du unter das Barrierefreiheitsstärkungsgesetz fällst. Große Seiten müssen AA sein. Ein Info-Blog kann sich auf einfachere Standards beschränken.
Ist WCAG AAA notwendig?
Nein, nicht für die meisten. AA ist das Standard-Ziel. AAA ist noch extremer und wird nur bei spezialisierten Seiten verlangt.
Welche Kontrast-Verhältnisse sind sauber?
Normal-Text: 4,5:1. Großer Text (18px+): 3:1. Das ist nicht über Gefühl messbar — nutze einen Contrast Checker online.
Brauche ich einen Screenreader selbst zu testen?
Ja, kurz. Zumindest NVDA 30 Minuten Zeit nehmen und hören, wie die Seite klingt. Ein automatischer Test sagt, ob das Label verknüpft ist, ein Screenreader zeigt, ob das wirklich funktioniert.
Machen Alt-Texte bei dekorativen Bildern Sinn?
Nein. Ein Schmuck-Bild sollte mit alt="" markiert werden, damit der Screenreader es überspringt. Ein informativer Absatz muss beschrieben werden.
Kann ich Accessibility nachträglich implementieren?
Ja, aber schwerer. Am besten ist es, das während der Entwicklung einzuplanen. Nachträglich sind es technische Anpassungen, die aufwändiger sind.
Verliere ich Rankings, wenn ich meine Seite zugänglicher mache?
Nein, das Gegenteil. Google liebt barrierefreie Websites. Bessere HTML-Struktur, schneller Aufbau — das rankt automatisch besser. Es ist ein Win-Win.