Eine Tür, die nicht aufgeht
Stellen Sie sich vor, Sie kommen vor ein Geschäft. Die Auslage gefällt. Sie wollen rein. Die Tür hat keinen Griff, nur ein Sensorfeld, das auf eine Geste reagiert, die Sie nicht ausführen können. Sie stehen davor. Die Schaufensterpuppe hinter dem Glas schaut Sie an. Sie gehen weiter.
So fühlt sich eine nicht barrierefreie Website an. Jeden Tag. Für Millionen Menschen.
Accessibility, auf Deutsch digitale Barrierefreiheit, ist die Disziplin, Websites und Anwendungen so zu bauen, dass alle Menschen sie wahrnehmen, bedienen, verstehen und mit der jeweiligen Technik zuverlässig nutzen können. Auch jene, die nicht sehen. Auch jene, die nicht klicken können wie der Durchschnitt. Auch jene, die mit einer Hand bedienen, weil sie das andere Kind tragen. Und auch jene, die in einem Jahrzehnt mit einer Technologie hier ankommen, die heute noch nicht existiert.
Der internationale Referenzrahmen sind die Web Content Accessibility Guidelines (WCAG) des W3C. Sie sortieren ihre Anforderungen entlang vier Grundprinzipien: wahrnehmbar, bedienbar, verständlich, robust. Im Englischen POUR: Perceivable, Operable, Understandable, Robust. Vier Wörter, in denen das ganze Fach steckt.
Barrierefreies Webdesign schafft Zugang für alle Menschen und berücksichtigt Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit.
Warum das mehr ist als ein Häkchen
Es gibt eine billige Sicht auf Barrierefreiheit. Sie lautet: zusätzlicher Aufwand. Pflichtprogramm. Ein Häkchen am Ende des Projekts.
Diese Sicht ist falsch.
Eine zugängliche Website ist eine bessere Website. Für alle. Die Codebasis ist sauberer. Die Semantik trägt. Die Inhalte sind klarer strukturiert. Die Wartung wird einfacher. Suchmaschinen lesen besser. Supporttickets nehmen ab. Die Reichweite wächst.
Wer Barrierefreiheit als Kostenstelle führt, hat den Punkt nicht verstanden. Sie ist eingebaute Qualität, nicht aufgeklebte Tugend.
Das W3C hat eine Sammlung an Szenarien veröffentlicht, in denen sichtbar wird, wie Menschen mit unterschiedlichen Behinderungen das Web tatsächlich nutzen. Wer ein digitales Produkt verantwortet und diese Seiten nie gelesen hat: holen Sie das nach. Eine Stunde, gut investiert. Sie kommen mit anderen Augen zurück an Ihr Backlog.
WCAG 2.2: was neu ist, und warum es wehtut
Die aktuelle Fassung ist WCAG 2.2. Seit Oktober 2023 als Empfehlung des W3C verabschiedet, ergänzt sie neun zusätzliche Erfolgskriterien. Sie zielen auf jene Stellen, an denen Websites bislang am häufigsten gescheitert sind.
Fokus sichtbar und frei. Ein Tastatur-Nutzer kommt mit Tab durch die Seite. Doch das Sticky-Banner verdeckt gerade das Element, auf dem er steht. Er sieht nichts mehr. WCAG 2.2 sagt klar: das geht nicht (SC 2.4.11 / 2.4.12).
Zielgröße Minimum. Ein interaktives Ziel – Button, Link, Schalter – soll mindestens 24 × 24 CSS-Pixel groß sein. Oder ausreichend Abstand zum Nachbarn haben. Das klingt banal. Probieren Sie eine Bestellseite mit zitternden Fingern. Oder mit einer Sehnenscheidenentzündung. Plötzlich klingt es nicht mehr banal.
Drag-Alternativen. Wenn Ihre Anwendung verlangt, dass etwas mit der Maus gezogen wird, muss dieselbe Funktion auch ohne Ziehgeste erreichbar sein. Sortieren per Drag-and-drop? Schön. Aber auch über Tastatur oder Klick.
Barrierearme Authentifizierung. Logins ohne Gedächtnisrätsel, ohne reine Transkriptionsaufgaben, ohne CAPTCHA-Folter. Passwortmanager-Kompatibilität, Kopieren-und-Einfügen erlauben, passwortlose Verfahren: das gehört in den Werkzeugkasten eines modernen Logins (SC 3.3.8 / 3.3.9).
Die WAI-Übersicht „What’s new in 2.2″ verlinkt zu allen neuen Kriterien mit Beispielen und Abgrenzungen.
Eine besondere Erwähnung verdient der Kontrast. Für Fließtext gilt mindestens 4,5 : 1, für großen Text 3 : 1, für UI-Elemente und ihre Zustände ebenfalls 3 : 1. Das sind Mindestwerte. Planen Sie Reserve ein, denn Schriftwahl, Hintergründe und Anti-Aliasing fressen Lesbarkeit, die das Datenblatt nicht zeigt.
Der Rechtsrahmen, kurz und klar
Drei Erlässe, drei Adressaten.
Öffentliche Stellen in der EU. Die Web Accessibility Directive – Richtlinie (EU) 2016/2102 – verpflichtet Behörden und öffentliche Einrichtungen, ihre Websites und mobilen Anwendungen barrierefrei anzubieten. Inklusive einer öffentlich abrufbaren Erklärung zur Barrierefreiheit, deren Mustertext der Durchführungsbeschluss (EU) 2018/1523 festlegt.
Privatwirtschaft in der EU. Der European Accessibility Act – Richtlinie (EU) 2019/882 – ist seit dem 28. Juni 2025 anzuwenden. Er greift bei Dienstleistungen im elektronischen Geschäftsverkehr, bei Banken, im Personenverkehr, bei Telekommunikation, bei E-Books und mehr. Die Durchsetzung läuft seitdem. Erste Beanstandungen gegen Online-Händler liegen bereits vor. Wer noch nicht angefangen hat, sollte heute anfangen.
In Deutschland setzt das Barrierefreiheitsstärkungsgesetz (BFSG) mit der zugehörigen Verordnung (BFSGV) den EAA um. Die Bundesfachstelle Barrierefreiheit ordnet die Anwendungsbereiche praxisnah ein. Auch für Online-Shops, die in der Aufsichtspraxis besonders im Fokus stehen.
Eine fachliche Einordnung speziell für E-Commerce-Dienste zeigt, wie der EAA Benutzerschnittstellen, Inhalte, Identifikation, Bezahlung, Signatur und Kundensupport adressiert. Durchgängig entlang der POUR-Prinzipien.
Die harmonisierte Norm: EN 301 549
Was im juristischen Text steht und was im Code passieren muss, übersetzt eine eigene Norm: die europäische EN 301 549. Sie ist der technische Brückenkopf zwischen Gesetz und Implementierung. Aktuell harmonisiert, also im Amtsblatt der EU benannt, ist die Version 3.2.1 (2021-03). Sie integriert WCAG 2.1 vollständig. Eine überarbeitete Fassung (v4.x), die WCAG 2.2 abbildet, befindet sich in Vorbereitung. Solange sie nicht harmonisiert ist, gilt für den Compliance-Nachweis weiterhin die 3.2.1.
Daraus folgt die Doppelorientierung, die jedes verantwortliche Team braucht:
- Strategisch an WCAG 2.2 ausrichten. Das ist der Qualitäts- und UX-Maßstab.
- Operativ für Compliance-Nachweise an der harmonisierten EN 301 549 orientieren, solange keine aktualisierte Fassung benannt ist.
POUR in der Praxis: die vier Säulen
Wahrnehmbar
Alles, was Bedeutung trägt, muss in mehr als einer sensorischen Form verfügbar sein. Bilder bekommen präzise Alt-Texte, reine Dekoration ein leeres Alt-Attribut. Videos brauchen Untertitel, reine Audio-Inhalte ein Transkript. Wesentliche Bildinformationen, die der Sprechertext nicht trägt, erhalten eine Audiodeskription. Farbe darf eine Information nie allein tragen. Ein zusätzliches Symbol, ein Muster oder ein Text gehört daneben.
Die Struktur ist dabei kein Kosmetikum. Korrekte Überschriftenhierarchien, sinnvolle Landmarks (Header, Main, Nav, Footer), semantische Tabellen und Listen geben dem Screenreader das Skelett, an dem er entlanghangelt. Wer Überschriften per CSS dimensioniert statt per Markup auszeichnet, baut eine Treppe, die nur Sehende sehen.
Bedienbar
Die Tastaturbedienbarkeit ist der Lakmustest. Stecken Sie die Maus weg und navigieren Sie eine Stunde durch Ihre eigene Anwendung. Wo bleiben Sie hängen? Wo verschwindet der Fokus? Wo öffnet sich ein Modal, aus dem Sie nicht mehr herauskommen?
Der Fokus muss sichtbar bleiben und darf nicht unter Sticky-Headern oder Off-Canvas-Layern verschwinden. Drag-Gesten dürfen nicht alternativlos sein. Klick- und Tap-Ziele bekommen Raum. Skip-Links führen am Seitenkopf direkt zum Hauptinhalt. Linktexte sagen, wohin sie führen. Niemals „hier klicken“.
Verständlich
Klare Sprache. Konsistente Terminologie. Wiederkehrende Ikonografie immer an derselben Stelle. Fehlermeldungen, die nicht beschämen, sondern helfen: freundlich, konkret, programmatisch mit dem Eingabefeld verknüpft.
Formulare sind hier oft die Bruchstelle. Labels werden gerne weggespart. Ein Platzhalter wirkt minimalistisch, doch er verschwindet beim Tippen und ist kein vollwertiges Label. Echte Bindungen sind Pflicht. Redundante Eingaben, also dieselben Daten in zwei aufeinanderfolgenden Schritten, vermeidet WCAG 2.2 explizit (SC 3.3.7).
Und der Login. Bitte: keine Rätselaufgaben mehr, keine verzerrten Buchstaben, keine Logiktests. Wer einen Passwortmanager benutzt, muss ihn benutzen dürfen.
Robust
Hier steht ein Satz aus den WAI Authoring Practices, der über jedem Schreibtisch hängen sollte:
„No ARIA is better than Bad ARIA.“
Falsch eingesetztes ARIA verschlechtert die Zugänglichkeit, statt sie zu verbessern. Die erste Wahl ist immer das passende native HTML-Element. Ein echter Button, kein mit Klick-Handler. Ein echtes Label, keine schwebende Beschriftung. Ein echtes Formularelement, kein nachgebauter Schalter. ARIA ergänzt, wo HTML nichts mehr hergibt. Nicht dort, wo HTML reichen würde.
Wie geprüft wird
Tools finden vielleicht ein Drittel der Probleme. Den Rest finden Menschen mit Zeit, Erfahrung und einem Screenreader.
Sinnvoll ist ein Mehrschicht-Modell.
Automatisiert in der CI. Linters, axe-Checks, regelbasierte Prüfer, die sich an den ACT-Rules orientieren. Sie fangen die rauen Schnitzer ab.
Manuell vor jedem Release. Stichproben mit Tastatur und Screenreader. NVDA ist für Windows kostenlos, VoiceOver auf macOS und iOS ohnehin vorinstalliert. Die Easy Checks des W3C geben Redaktionen eine niederschwellige Erstprüfung an die Hand.
Extern für die Tiefe. Der BIK BITV-/WCAG-Test ist in Deutschland das verlässlichste Verfahren mit transparenten Prüfschritten und veröffentlichbarem Bericht. Jährlich, ergänzend zu internen Audits.
Welche Stelle Ihrer Anwendung würde ein Screenreader-Nutzer als erstes verlassen, wenn er einen Hilfslink sucht?
Was schiefgeht – immer wieder dieselben Dinge
Die häufigsten Fehler sind seit Jahren dieselben. Sie tauchen in jedem zweiten Audit auf.
Der Fokus verschwindet, weil das Sticky-Banner ihn frisst. Das Modal hat keine Fokusrückführung. Nach dem Schließen landet der Cursor irgendwo am Anfang der Seite. Kontraste liegen knapp unter der Schwelle, weil das Designsystem die UI-States stiefmütterlich behandelt. Platzhalter ersetzen Labels. Die Hauptnavigation lässt sich per Maus aufklappen, per Tastatur nicht. ARIA-Rollen werden geschickt verteilt, ohne dass sie semantisch tragen. Untertitel fehlen, weil das Video „eh nur Stimmung“ transportiert. Und damit auch die Stimmung niemanden erreicht, der nicht hört.
Nichts davon ist Pech. Alles davon ist Verfahren.
Die Erklärung zur Barrierefreiheit
Öffentliche Stellen veröffentlichen sie verpflichtend, nach dem EU-Muster (Durchführungsbeschluss 2018/1523). Sie nennt den Normbezug, den Konformitätsstand, nicht zugängliche Inhalte mit Begründung, einen Feedback-Kanal und Durchsetzungswege.
Private Anbieter sind dazu rechtlich nicht im selben Maße verpflichtet. Eine freiwillige, transparente Erklärung zahlt sich trotzdem aus. Sie schafft Vertrauen, erleichtert Feedback aus der Nutzerschaft und zwingt das eigene Haus zu einer ehrlichen Bestandsaufnahme. Wer schreibt, was er liefert, weiß irgendwann, was er nicht liefert.
Der hartnäckigste SEO-Mythos
Macht Barrierefreiheit besseres Ranking? Nein, jedenfalls nicht direkt. Googles John Mueller hat das selbst klargestellt. Accessibility ist kein expliziter Ranking-Faktor.
Aber.
Saubere Semantik. Klare Überschriften. Sinnvolle Alt-Texte. Schnelle Ladezeiten durch schlanken Code. Niedrige Absprungraten, weil Nutzer finden, was sie suchen. All das sind Effekte einer zugänglichen Seite. Und genau diese Effekte zählt der Algorithmus sehr wohl.
Gute Accessibility und gute Findbarkeit sind Geschwister, keine Konkurrenten. Wer das eine ernst nimmt, bekommt das andere geschenkt.
E-Commerce: ein Sonderfall mit Tempo
Wenn Sie einen Online-Shop betreiben, sind Sie mit hoher Wahrscheinlichkeit vom EAA erfasst. Die Bundesfachstelle beschreibt die Anwendung auf Online-Shops ausführlich, mit Übergangsbestimmungen für bestimmte Konstellationen.
Drei Bruchstellen treten in Audits besonders häufig auf.
Erstens der Checkout. Mehrstufige Formulare, in denen der Fokus durch jeden Schritt mitgeführt werden muss. Fehlermeldungen, die nicht nur erscheinen, sondern programmatisch angekündigt werden. Statusmeldungen, die für Screenreader auslesbar sind.
Zweitens die Produktdetails. Varianten, Preise, Verfügbarkeiten, technische Datenblätter. Jede Information muss auch ohne Maus zugänglich sein, ohne Mausgesten erfassbar bleiben, ohne Bildvorschau verständlich bleiben.
Drittens der Kundensupport. Chats, Hotlines, FAQs müssen konsistent auffindbar sein (SC 3.2.6). Ein Chat-Widget, das beim Tab-Sprung gleich zwei Sekunden später aufploppt und den Fokus verschluckt, ist keine Hilfe. Es ist eine Barriere.
Ein letztes Bild
Eine Website ist kein Schaufenster. Sie ist ein Eingang.
Wer einen Eingang baut, muss wissen, wer hindurchgehen wird. Nicht nur die Zielgruppe der Marketingstrategie. Auch die Frau mit Tremor, die das Adressfeld nicht trifft. Auch der Mann, der nicht sieht und mit JAWS arbeitet. Auch das Kind, das gerade lesen lernt. Auch Sie selbst in zwanzig Jahren, mit zittrigeren Händen und müderen Augen.
Eine zugängliche Website ist kein Akt der Gnade gegenüber Minderheiten. Sie ist die Anerkennung, dass „Nutzer“ ein vielfältiges Wort ist. Und dass jeder, der ausgesperrt wird, ein Verlust ist. Für ihn. Und für Sie.
Welche Tür haben Sie gerade gebaut?
