Barrierefreiheit von Websites: Was zuerst zu beheben ist
Barrierefreiheitsarbeit hat eine lange Checkliste und eine kurze Liste von Dingen, die den Großteil der tatsächlichen Barrieren ausmachen. Mit der kurzen Liste zu beginnen bringt echte Nutzer schnell auf Ihre Website; mit einem vollständigen Audit zu beginnen erzeugt meist ein Dokument, das niemand abarbeitet.
Dieser Leitfaden behandelt, was zuerst zu beheben ist, wie Sie es an einem Nachmittag selbst testen, und warum Overlay-Widgets nicht die Abkürzung sind, als die sie verkauft werden.
Die Korrekturen mit der größten Wirkung#
Das sind die Barrieren, die Menschen ganz daran hindern, Aufgaben zu erledigen, statt sie nur etwas zu erschweren. Beheben Sie sie vor allem, was auf einer längeren Liste steht.
- Tastaturzugang. Jedes interaktive Element mit Tab erreichbar und mit Enter oder Leertaste bedienbar, in sinnvoller Reihenfolge, mit sichtbarem Fokusring. Wenn die Website nur mit der Maus nutzbar ist, spielt nichts anderes auf dieser Liste eine Rolle.
- Textalternativen. Sinnvoller Alt-Text bei Bildern, die Information tragen; leeres alt bei dekorativen. Ein fehlendes alt ist nicht dasselbe wie ein leeres.
- Formularbeschriftungen. Ein echtes <label>, das mit jedem Eingabefeld verbunden ist. Platzhaltertext ist keine Beschriftung — er verschwindet beim Tippen und wird nicht zuverlässig vorgelesen.
- Kontrast. Fließtext bei 4,5:1, großer Text und Bedienelemente bei 3:1, geprüft gegen den echten Hintergrund.
- Überschriften. Eine H1, keine übersprungenen Ebenen. Screenreader-Nutzer navigieren mehr über Überschriften als über alles andere.
- Linktexte. Vierzehnmal „Mehr lesen“ gibt einem Screenreader-Nutzer vierzehn identische Ziele. Sagen Sie, wohin es führt.
- Fehlermeldungen. Neben dem Feld, als Text, mit der Beschreibung, was zu tun ist — nicht nur Farbe, nicht nur ein roter Rahmen.
Testen Sie selbst an einem Nachmittag#
Sie brauchen keine Spezialsoftware, um die meisten Probleme zu finden. Diese fünf Durchgänge dauern auf einer mittelgroßen Website ein bis zwei Stunden und finden den Großteil der echten Barrieren.
| Test | Wie | Was er findet |
|---|---|---|
| Nur Tastatur | Maus abziehen, mit Tab durch jede Seite | Fallen, unsichtbarer Fokus, unerreichbare Bedienelemente |
| Zoom auf 200 % | Browser-Textgröße, nicht Seitenzoom | Abgeschnittener Text, horizontales Scrollen, kaputte Layouts |
| Screenreader | VoiceOver oder NVDA auf den Haupt-Templates | Fehlende Beschriftungen, nichtssagende Links, unangekündigte Änderungen |
| Automatischer Scan | axe oder Lighthouse im Browser | Kontrast, fehlendes alt, ARIA-Fehlgebrauch — etwa 30 % der Probleme |
| Graustufen | Browser-Filter oder Systemeinstellung | Alles, was allein über Farbe vermittelt wird |
Automatische Werkzeuge finden ungefähr ein Drittel der Barrierefreiheitsprobleme. Sie sind ein Ausgangspunkt, keine Bestehensnote — eine Website mit 100 in Lighthouse kann per Tastatur trotzdem unbenutzbar sein.
Die Muster, die den meisten Ärger machen#
Eigene Komponenten sind der Ort, an dem Barrierefreiheit meist bricht, denn native Elemente bringen Verhalten mit, das eigene nachbauen müssen.
- Eigene Dropdowns aus divs, ohne Tastaturunterstützung oder Rollen. Ein natives <select> ist gratis und funktioniert überall.
- Modale Dialoge, die den Fokus nicht einfangen, bei Escape nicht schließen und den Hintergrund scrollbar lassen.
- Karussells, die automatisch weiterlaufen ohne Pause-Bedienelement — sie sind nahezu allen gegenüber feindselig, nicht nur behinderten Nutzern.
- Reine Icon-Buttons ohne zugänglichen Namen. Ein X ohne Beschriftung wird als „Schaltfläche“ vorgelesen.
- Infinite Scroll ohne Möglichkeit, den Fußbereich zu erreichen.
- Div-Suppe: klickbare divs statt Buttons und Links, was Tastaturunterstützung und Semantik in einem Zug entfernt.
- Bewegung, die prefers-reduced-motion ignoriert.
Die billigste Barrierefreiheits-Strategie ist, das native HTML-Element für die Aufgabe zu nehmen. Jeder eigene Ersatz ist ein Versprechen, Verhalten nachzubauen, das gratis dabei war.
Warum Overlay-Widgets keine Lösung sind#
Barrierefreiheits-Overlays versprechen Konformität aus einem einzigen Skript. Sie können sie nicht liefern, weil die zugrundeliegenden Probleme strukturell sind: Ein Skript kann nicht wissen, was ein Bild zeigt, kann keine Formularbeschriftung schreiben, die zum Zweck des Feldes passt, und kann keine Tastaturfalle in einer eigenen Komponente reparieren.
Sie stören außerdem die assistive Technik, die Menschen bereits nutzen und konfiguriert haben, weshalb mehrere Behindertenverbände davon abraten. Es lohnt sich vor allem, sie zu kennen, um sie mit einer belastbaren Begründung ablehnen zu können.
- Sie können keinen zutreffenden Alt-Text erzeugen, weil sie nicht wissen, was das Bild im Kontext bedeutet.
- Sie können keine Tastaturfallen in Komponenten beheben, die sie nicht gebaut haben.
- Sie kollidieren häufig mit den eigenen Screenreader-Einstellungen der Nutzer.
- Sie beseitigen kein rechtliches Risiko — die zugrundeliegenden Barrieren bestehen weiter.
- Das Geld ist bei den sieben Korrekturen oben auf dieser Seite besser angelegt.
Häufige Fragen
Ist Barrierefreiheit gesetzlich vorgeschrieben?
In vielen Rechtsordnungen ja, für öffentliche Stellen und zunehmend für private Unternehmen — der European Accessibility Act, der ADA in den Vereinigten Staaten in seiner Anwendung auf Websites und Entsprechungen anderswo. Die Pflichten unterscheiden sich nach Land und Branche, prüfen Sie das also lokal. Praktisch gilt: WCAG 2.2 AA ist der Standard, auf den fast jede Regulierung zeigt.
Wie viel kostet Barrierefreiheit zusätzlich?
Von Anfang an mitgedacht sehr wenig — hauptsächlich Disziplin bei Semantik, Kontrast und Fokuszuständen. Auf eine fertige Individualwebsite nachgerüstet kann es ein erhebliches Projekt sein, weil die Korrekturen strukturell statt kosmetisch sind. Dieser Unterschied ist das ganze Argument dafür, es im Briefing anzusprechen und nicht nach dem Start.
Was ist der Unterschied zwischen WCAG A, AA und AAA?
Das sind Konformitätsstufen. A ist das Minimum und lässt echte Barrieren bestehen; AA ist, was Regulierungen im Allgemeinen verlangen und worauf die meisten Organisationen zielen; AAA enthält Kriterien, die nicht für alle Inhalte erreichbar sind — etwa eine 7:1-Kontrastanforderung, die manche Markenpaletten nicht erfüllen können. Zielen Sie auf AA und behandeln Sie AAA als Verbesserung je Kriterium statt als Ziel.
Hilft Barrierefreiheit dem SEO?
Indirekt und tatsächlich. Saubere Überschriftenstruktur, beschreibende Linktexte, Alt-Attribute, echte Semantik und schnelle, stabile Seiten helfen beidem. Aber die Überschneidung ist teilweise: Eine Website kann gut ranken und per Tastatur unbenutzbar sein. Machen Sie Barrierefreiheitsarbeit, weil Menschen die Website sonst nicht nutzen können, und nehmen Sie den SEO-Nutzen als Nebeneffekt.
website barrierefreiheitwcagbarrierefreies webdesignscreenreadertastaturnavigationbarrierefreiheit testen
