Was ist Barrierefreiheit im Web? WCAG und inklusives Design erklärt

Barrierefreiheit im Web bedeutet, Websites und Apps so zu bauen, dass Menschen mit Behinderungen sie nutzen können – ob sie blind sind und einen Screenreader verwenden, keine Maus bedienen können, eine Sehschwäche oder Farbenblindheit haben, gehörlos sind oder kognitive oder Lernbehinderungen haben. In der Praxis geht es um Dinge wie Textalternativen für Bilder, ausreichenden Farbkontrast, Formulare mit richtigen Beschriftungen und darum, dass alles mit der Tastatur allein funktioniert. Der internationale Standard dafür ist WCAG, die Web Content Accessibility Guidelines des W3C.

Barrierefreiheit wird oft als a11y abgekürzt – „a“, dann 11 Buchstaben, dann „y“.

Warum Barrierefreiheit beim Bauen mit KI wichtig ist

KI-Baukästen sind gut darin, Apps zu erzeugen, die richtig aussehen. Barrierefreiheit betrifft vor allem das, was Sie auf einem Screenshot nicht sehen: ob ein Button wirklich ein Button ist, ob ein Eingabefeld ein Label hat, das ein Screenreader vorlesen kann, und ob Sie das Menü mit der Tab-Taste erreichen.

Deshalb lohnt es sich, nachzufragen:

• Es wird leicht übersehen. Ein individuell gestaltetes Dropdown kann perfekt aussehen und ohne Maus unbenutzbar sein. Das bemerken Sie nur, wenn Sie gezielt testen.
• Früh richtig gemacht kostet weniger. Barrierefreie Komponenten schon im ersten Prompt anzufragen, kostet fast nichts. Eine fertige App nachträglich umzubauen bedeutet, jeden Bildschirm anzufassen.
• Es hilft allen. Untertitel helfen Menschen in lauter Umgebung, guter Kontrast hilft Menschen mit dem Handy in der Sonne, und klare Beschriftungen helfen allen, Formulare schneller auszufüllen.
• Es überschneidet sich mit SEO. Saubere Überschriften, aussagekräftige Links und Alt-Texte helfen auch Suchmaschinen, Ihre Seiten zu verstehen – siehe SEO für mit KI gebaute Websites.
• Es kann gesetzlich verlangt sein. Je nachdem, wo Sie tätig sind und wen Sie bedienen, kann Barrierefreiheit eine gesetzliche Pflicht sein.

Ein Alltagsvergleich

Denken Sie an den Eingang eines Gebäudes.

Treppen funktionieren für viele Menschen. Eine Rampe funktioniert für Rollstuhlfahrer – und auch für Eltern mit Kinderwagen, Lieferanten mit Sackkarren und Reisende mit Koffern. Automatische Türen, klare Schilder, Brailleschrift an Aufzugknöpfen und gute Beleuchtung beseitigen jeweils eine Barriere für jemanden.

Webbarrierefreiheit ist dieselbe Idee für digitale Räume: die Rampen, Schilder und Handläufe Ihrer App. Und wie bei einem Gebäude ist es viel einfacher, eine Rampe in die Pläne aufzunehmen, als sie nachträglich einzubauen, wenn der Beton schon ausgehärtet ist.

WCAG in Kürze

WCAG wird von der Web Accessibility Initiative des W3C veröffentlicht. Die aktuelle Version ist WCAG 2.2, erstmals im Oktober 2023 veröffentlicht. Sie ist abwärtskompatibel: Inhalte, die WCAG 2.2 erfüllen, erfüllen auch 2.1 und 2.0, und das W3C empfiehlt, die neueste Version zu verwenden. WCAG 2.2 ist außerdem als internationaler Standard ISO/IEC 40500:2025 anerkannt. Ein deutlich anderes WCAG 3 befindet sich als früher Entwurf in Arbeit, nicht als fertiger Standard.

WCAG ist um vier Prinzipien herum aufgebaut, die man sich oft als POUR merkt:

Jede Richtlinie hat prüfbare Erfolgskriterien auf drei Stufen:

• Stufe A – das Minimum. Wer hier scheitert, wird für manche Menschen komplett ausgeschlossen.
• Stufe AA – das übliche Ziel und die Stufe, auf die sich die meisten Gesetze und Richtlinien beziehen.
• Stufe AAA – die höchste Stufe. Sie lohnt sich stellenweise als Ziel, aber das W3C empfiehlt nicht, sie für ganze Websites vorzuschreiben, weil manche Inhalte sie nicht erreichen können.

WCAG 2.2 hat neun Erfolgskriterien zu 2.1 hinzugefügt, darunter Zielgröße (Minimum) auf Stufe AA – anklickbare Ziele sollten grundsätzlich mindestens 24 × 24 CSS-Pixel groß sein, mit Ausnahmen – und Barrierefreie Authentifizierung (Minimum), die Anmeldeschritte begrenzt, die auf Gedächtnis oder Rätsel setzen, etwa wenn man ein Passwort abtippen muss, ohne es einfügen zu dürfen. Außerdem wurde das alte Kriterium „Parsing“ als veraltet gestrichen.

Ein Beispiel: ein Anmeldeformular

Hier ist ein Anmeldeformular, wie eine KI es erzeugen könnte, und was eine Barrierefreiheitsprüfung findet:

Keine dieser Korrekturen verändert das Aussehen des Formulars spürbar. Alle verändern aber, ob manche Menschen es überhaupt benutzen können.

Wichtige Begriffe

Häufige Missverständnisse

• „Barrierefreiheit betrifft nur blinde Nutzer.“ Sie umfasst Seh-, Bewegungs-, Hör-, Sprech- und kognitive Behinderungen, dazu auch vorübergehende Situationen wie einen gebrochenen Arm.
• „Barrierefreie Seiten sehen langweilig aus.“ Barrierefreiheit schränkt ein paar Dinge ein – Kontrast, Fokusstile, Textgröße –, aber gut aussehende barrierefreie Seiten sind die Regel, nicht die Ausnahme.
• „Ein automatischer Checker zeigt 100 Punkte, also sind wir fertig.“ Automatische Tools erkennen nur einen Teil der Probleme. Ob Alt-Texte wirklich aussagekräftig sind oder ein Ablauf mit dem Screenreader Sinn ergibt, muss ein Mensch prüfen.
• „Ein Overlay-Widget macht uns konform.“ Aufgesetzte Werkzeugleisten können fehlende Beschriftungen oder kaputten Tastaturzugang in Ihrem Code nicht beheben. Korrigieren Sie die Quelle.
• „Wir haben keine Nutzer mit Behinderungen.“ Vielleicht wissen Sie es nur nicht. Viele Behinderungen sind nicht sichtbar, und Menschen, die auf eine Barriere stoßen, gehen meist einfach.

Was Sie Ihren KI-Baukasten fragen sollten

• „Baue das so, dass es WCAG 2.2 Stufe AA erfüllt.“
• „Verwende semantisches HTML: echte Buttons, Links, Überschriften in der richtigen Reihenfolge und Beschriftungen für jedes Formularfeld.“
• „Stelle sicher, dass jedes interaktive Element allein mit der Tastatur funktioniert und einen sichtbaren Fokusstil hat.“
• „Prüfe den Kontrast aller Text- und Symbolfarben – 4,5:1 für normalen Text, 3:1 für große Schrift und Symbole.“
• „Füge aussagekräftige Alt-Texte für informative Bilder und leere Alt-Texte für dekorative hinzu.“
• „Zeige Formularfehler als Text, verknüpft mit dem Feld, nicht nur farblich.“
• „Berücksichtige die Einstellung für reduzierte Bewegung des Nutzers bei Animationen.“
• „Führe eine automatische Barrierefreiheitsprüfung aus und liste auf, was sie nicht testen kann, damit ich das von Hand prüfen kann.“

Danach testen Sie selbst: Legen Sie die Maus beiseite und versuchen Sie, Ihren wichtigsten Ablauf nur mit Tab, Umschalt+Tab, Enter und Leertaste abzuschließen. Testen Sie die Hauptseite mit dem eingebauten Screenreader Ihres Handys. Zoomen Sie den Browser auf 200 % und schauen Sie, ob etwas kaputtgeht.

Barrierefreiheit in Mythex

Mythex enthält keinen eigenen Barrierefreiheits-Checker, deshalb behandeln Sie Barrierefreiheit als Teil Ihrer Prompts und Ihrer Tests. Fragen Sie ab dem ersten Prompt nach WCAG 2.2 AA, prüfen Sie das Ergebnis in der Vorschau mit der Tastatur und nutzen Sie /test, damit der Agent Ihre wichtigsten Abläufe durchklickt, bevor Sie veröffentlichen – siehe App-Tests. Das SEO-Rezept verlangt ebenfalls semantische Überschriften und aussagekräftige Alt-Texte, was beiden Zielen dient.

Eine praktische Checkliste finden Sie unter wie Sie Ihre Website barrierefrei machen. Zum Design lesen Sie wie Sie mit KI eine gut aussehende App gestalten, und vor dem Start wie Sie Ihre App vor dem Launch testen. Die maßgebliche Quelle ist die WCAG-Übersicht des W3C.

Fragen