WCAG

Die WCAG sind eine technische Empfehlung des World Wide Web Consortium, kurz W3C, und bilden weltweit einen zentralen Referenzrahmen für digitale Barrierefreiheit.

Die WCAG selbst sind kein Gesetz und keine Zertifizierung des W3C. Sie können aber rechtlich relevant werden, wenn Gesetze, Normen, Verträge oder Ausschreibungen auf WCAG-Kriterien verweisen. Außerdem gibt es externe Audits, Konformitätsbewertungen, Prüfberichte und Zertifikate von Dienstleistern, die sich auf WCAG-Anforderungen beziehen. Solche Nachweise ersetzen jedoch nicht automatisch eine rechtliche Bewertung im konkreten Anwendungsfall.

In der Praxis werden WCAG-Kriterien häufig auch auf digitale Dokumente, mobile Anwendungen, Softwareoberflächen, Intranets, Kundenportale, Dokumentenmanagementsysteme und andere Informationssysteme angewendet. Streng genommen geschieht das oft über ergänzende Standards und Dokumente wie EN 301 549 oder WCAG2ICT, die Anforderungen an Informations- und Kommunikationstechnik auf Web- und Nicht-Web-Kontexte übertragen. Für Unternehmen sind die WCAG deshalb ein zentraler Bezugsrahmen, auch wenn nicht jedes digitale System im engeren Sinn direkt „WCAG“ ist.

Das Ziel der WCAG ist, digitale Inhalte so zu gestalten, dass Menschen sie möglichst unabhängig von körperlichen, sensorischen, kognitiven oder situativen Einschränkungen nutzen können. Davon profitieren nicht nur Menschen mit Behinderungen, sondern auch ältere Nutzerinnen und Nutzer, Personen mit temporären Einschränkungen oder Menschen in schwierigen Nutzungssituationen. Gute Kontraste, klare Sprache, zuverlässige Tastaturbedienung und verständliche Fehlermeldungen verbessern die Nutzbarkeit für sehr viele Menschen.

WCAG kurz erklärt

WCAG in einem Satz: Die Web Content Accessibility Guidelines beschreiben prüfbare Anforderungen, mit denen Webinhalte wahrnehmbar, bedienbar, verständlich und robust gestaltet werden können. Die aktuelle W3C Recommendation ist WCAG 2.2. In vielen rechtlichen und normativen Kontexten ist derzeit jedoch weiterhin die jeweils herangezogene Fassung von EN 301 549 maßgeblich, die je nach Version auf WCAG 2.1 oder künftig stärker auf WCAG 2.2 verweisen kann.

Typische Zielstufe in der Praxis ist WCAG AA. Eine Konformität auf AA bedeutet, dass alle anwendbaren Erfolgskriterien der Stufen A und AA erfüllt werden. Für viele Websites, Portale, Intranets und Informationsmanagementsysteme ist AA ein realistisches und fachlich sinnvolles Zielniveau, während AAA häufig nur für ausgewählte Inhalte oder besonders anspruchsvolle Nutzungskontexte vollständig umsetzbar ist.

Was sind die WCAG?

Die Web Content Accessibility Guidelines werden vom World Wide Web Consortium, kurz W3C, entwickelt. Innerhalb des W3C arbeitet die Web Accessibility Initiative, kurz WAI, an Standards, Erläuterungen und unterstützenden Materialien zur digitalen Barrierefreiheit. Die WCAG sind international anerkannt und bilden die Grundlage vieler gesetzlicher, technischer und organisatorischer Anforderungen.

Die WCAG beschreiben, wie Webinhalte gestaltet und technisch umgesetzt werden sollten, damit sie unter anderem nutzbar sind für Menschen mit Sehbehinderungen oder Blindheit, Hörbehinderungen oder Gehörlosigkeit, motorischen Einschränkungen, kognitiven Einschränkungen oder neurologischen Besonderheiten. Auch temporäre Einschränkungen, etwa ein gebrochener Arm, und situative Barrieren, etwa laute Umgebung oder starke Sonneneinstrahlung auf dem Display, werden durch viele WCAG-Maßnahmen reduziert.

Wichtig ist die Unterscheidung zwischen Barrierefreiheit und barrierearm. Barrierefreiheit ist fachlich und rechtlich immer auf einen definierten Maßstab bezogen, etwa eine WCAG-Version, eine Konformitätsstufe, eine gesetzliche Vorgabe oder einen geprüften Nutzungskontext. „Barrierearm“ ist dagegen kein offizieller WCAG-Konformitätsstatus, sondern ein praxisüblicher Begriff für Angebote, die Barrieren reduzieren, aber keine definierte Konformität beanspruchen.

Wie sind die WCAG aufgebaut?

Die WCAG sind hierarchisch aufgebaut. Sie bestehen aus vier Grundprinzipien, mehreren Richtlinien und konkreten Erfolgskriterien. Für die formale Konformität sind vor allem die Erfolgskriterien entscheidend, weil sie beschreiben, welche Anforderungen erfüllt werden müssen.

Die WCAG gliedern sich in:

• Prinzipien: die vier grundlegenden Anforderungen an barrierefreie Webinhalte
• Richtlinien: thematische Vorgaben innerhalb dieser Prinzipien
• Erfolgskriterien: prüfbare Anforderungen mit den Konformitätsstufen A, AA und AAA
• unterstützende W3C-Dokumente: insbesondere „How to Meet WCAG“, „Understanding WCAG“ und „Techniques for WCAG“

Die unterstützenden Dokumente sind sehr hilfreich, aber nicht selbst der normative Kern der WCAG-Konformität. Verbindlich für die Konformitätsbewertung sind die Erfolgskriterien. Techniken zeigen mögliche Wege zur Umsetzung, schließen aber andere geeignete Lösungen nicht aus.

Einige Anforderungen lassen sich technisch gut vorprüfen, etwa bestimmte Kontrastwerte, fehlende Formularverknüpfungen oder einzelne ARIA-Fehler. Viele entscheidende Aspekte erfordern jedoch manuelle Bewertung, zum Beispiel Tastaturbedienbarkeit, Fokusreihenfolge, sinnvolle Alternativtexte, verständliche Linktexte oder die Nutzbarkeit eines vollständigen Prozesses. Eine seriöse WCAG-Prüfung kombiniert deshalb automatisierte Tests, manuelle Prüfung, redaktionelle Bewertung und realistische Nutzungsszenarien.

Die vier Grundprinzipien der WCAG

Die WCAG beruhen auf vier zentralen Prinzipien. Sie werden häufig mit dem englischen Kürzel POUR zusammengefasst: Perceivable, Operable, Understandable und Robust. Auf Deutsch bedeutet das: wahrnehmbar, bedienbar, verständlich und robust.

Wenn eines dieser Prinzipien nicht erfüllt ist, kann ein digitales Angebot für bestimmte Nutzergruppen teilweise oder vollständig unzugänglich sein. Die Prinzipien helfen Ihnen, Barrierefreiheit nicht nur als technische Checkliste zu verstehen, sondern als Qualitätsmaßstab für Inhalte, Bedienung, Verständlichkeit und technische Kompatibilität.

Wahrnehmbar

Informationen müssen so bereitgestellt werden, dass Nutzerinnen und Nutzer sie wahrnehmen können. Inhalte dürfen nicht ausschließlich über einen einzigen Sinneskanal zugänglich sein. Wer ein Bild nicht sehen, ein Video nicht hören oder Farben nicht unterscheiden kann, benötigt gleichwertige Alternativen.

Typische Maßnahmen sind:

• informative Bilder mit sinnvollen Alternativtexten versehen
• dekorative Bilder mit leerem Alternativtext auszeichnen oder technisch ignorierbar machen
• aufgezeichnete Videos mit Ton mit Untertiteln versehen
• Live-Audio in synchronisierten Medien auf Level AA mit Untertiteln zugänglich machen
• reine Audioinhalte durch Transkripte oder gleichwertige Textalternativen ergänzen
• relevante visuelle Informationen in aufgezeichneten Videos zugänglich machen
• Inhalte nicht ausschließlich über Farbe vermitteln
• ausreichende Kontraste für Text, Bedienelemente und grafische Informationen sicherstellen
• Tabellen, Diagramme und Infografiken strukturiert oder ergänzend textlich erklären

Bei Videos ist die genaue Anforderung von der Konformitätsstufe abhängig. Auf Level A kann für aufgezeichnete Videoinhalte mit relevanten visuellen Informationen eine Audiodeskription oder eine Medienalternative erforderlich sein. Auf Level AA ist für aufgezeichnete Videos eine Audiodeskription erforderlich, sofern relevante visuelle Informationen nicht bereits in der Tonspur enthalten sind.

Ein Beispiel: Wenn ein Formularfeld nur durch eine rote Umrandung als fehlerhaft markiert wird, kann das für Menschen mit Farbsehschwäche problematisch sein. Besser ist eine zusätzliche Fehlermeldung in Textform, etwa „Bitte geben Sie eine gültige E-Mail-Adresse ein.“ Besonders zugänglich ist die Lösung, wenn die Fehlermeldung technisch mit dem betroffenen Feld verbunden ist und von Screenreadern ausgegeben wird.

In Informationsmanagementsystemen betrifft dieses Prinzip beispielsweise Dokumentenvorschauen, Statusanzeigen, Diagramme in Dashboards, Suchergebnislisten, Pflichtfeldmarkierungen und farbcodierte Workflows. Wenn ein Freigabestatus nur durch Grün, Gelb oder Rot dargestellt wird, sollten Sie zusätzlich eine textliche Kennzeichnung wie „freigegeben“, „in Prüfung“ oder „abgelehnt“ verwenden.

Bedienbar

Digitale Inhalte müssen bedienbar sein, auch ohne Maus. Nutzerinnen und Nutzer sollten alle wesentlichen Funktionen mit verschiedenen Eingabemethoden erreichen können, zum Beispiel per Tastatur, Sprachsteuerung, Schaltersteuerung oder alternativen Eingabegeräten. Besonders wichtig ist, dass die Bedienung nicht in Tastaturfallen endet.

Dazu gehören unter anderem:

• vollständige Tastaturbedienbarkeit
• sichtbare Fokusmarkierungen
• logische Fokusreihenfolge
• keine Tastaturfallen
• ausreichend Zeit für Eingaben oder verlängerbare Zeitlimits
• Vermeidung von blinkenden oder flackernden Inhalten
• Skip-Links und andere Möglichkeiten zum Überspringen wiederholter Inhalte
• bedienbare Dialogfenster, Menüs, Akkordeons, Tabs und Filter
• Alternativen zu komplexen Zeigergesten oder Drag-and-drop-Bewegungen

Gerade bei Portalen, Dokumentenmanagementsystemen oder Enterprise-Search-Lösungen ist dieser Punkt zentral. Nutzerinnen und Nutzer müssen Menüs, Suchfunktionen, Tabellen, Filter, Upload-Dialoge und Formulare zuverlässig bedienen können. Wenn eine Filterauswahl nur per Maus geöffnet werden kann, ist sie für viele Menschen nicht nutzbar.

Zeitbegrenzungen gehören ebenfalls zum Prinzip Bedienbar. Wenn eine Sitzung automatisch abläuft, ein Formular nach kurzer Zeit gesperrt wird oder ein Sicherheitscode nur sehr kurz gültig ist, sollten Nutzerinnen und Nutzer rechtzeitig informiert werden und die Möglichkeit haben, die Zeit zu verlängern, sofern keine zwingenden Sicherheitsgründe entgegenstehen.

Verständlich

Inhalte und Bedienoberflächen müssen verständlich sein. Nutzerinnen und Nutzer sollten erkennen können, welche Informationen sie vor sich haben, welche Handlung erwartet wird und was nach einer Eingabe passiert. Vorhersehbares Verhalten, konsistente Begriffe und klare Anleitungen sind deshalb ein wichtiger Teil der WCAG.

Das betrifft zum Beispiel:

• klare und konsistente Sprache
• eindeutige Formularbeschriftungen
• nachvollziehbare Navigation
• konsistente Bezeichnungen in Menüs, Buttons und Systemmeldungen
• verständliche Fehlermeldungen
• Korrekturvorschläge bei Eingabefehlern, sofern diese bekannt sind
• Hilfe bei komplexen Eingaben
• vorhersehbares Verhalten von Bedienelementen
• verständliche Anleitungen für mehrstufige Prozesse

Ein schlechtes Beispiel ist eine Fehlermeldung wie „Eingabe ungültig“. Besser ist: „Bitte geben Sie das Datum im Format TT.MM.JJJJ ein.“ Noch hilfreicher ist eine zusätzliche Beispielangabe wie „Beispiel: 24.06.2026.“

Für Unternehmen ist Verständlichkeit besonders wichtig, weil digitale Informationssysteme häufig komplexe Prozesse abbilden. Wenn Nutzerinnen und Nutzer in einem Kundenportal Dokumente hochladen, einen Antrag ausfüllen oder einen Freigabeprozess starten, müssen die einzelnen Schritte klar benannt sein. Unverständliche Systemmeldungen führen nicht nur zu Barrieren, sondern auch zu Supportanfragen, Prozessabbrüchen und Datenfehlern.

Robust

Inhalte müssen technisch so umgesetzt sein, dass sie mit aktuellen und zukünftigen Benutzeragenten einschließlich Assistenztechnologien kompatibel sind. Dazu zählen Browser, Screenreader, Braillezeilen, Sprachsteuerungen, Vergrößerungssoftware, Bildschirmtastaturen und andere assistive Systeme. Robustheit bedeutet, dass Inhalte nicht nur optisch funktionieren, sondern auch semantisch korrekt aufgebaut sind.

Robuste Inhalte entstehen durch sauberes HTML, korrekt ausgezeichnete Überschriften, sinnvolle Formularbeschriftungen, semantische Bedienelemente und eine technisch verlässliche Struktur. Wenn ein Button nur als grafisches Element ohne korrekte Rolle umgesetzt ist, kann ein Screenreader ihn möglicherweise nicht als Schaltfläche erkennen. Wenn ein Formularfeld keine programmatisch erkennbare Beschriftung hat, ist sein Zweck für assistive Technologien unklar.

In modernen Webanwendungen ist Robustheit besonders relevant, weil viele Oberflächen dynamisch geladen werden. Wenn Suchergebnisse, Benachrichtigungen, Fehlermeldungen oder Statusänderungen nachträglich erscheinen, müssen diese Änderungen auch für Assistenztechnologien erkennbar sein. Dafür sind unter anderem semantische HTML-Elemente, korrekt eingesetzte ARIA-Attribute, Live Regions und eine sorgfältige Fokussteuerung wichtig.

Konformitätsstufen: A, AA und AAA

Die WCAG unterscheiden drei Konformitätsstufen: A, AA und AAA. Jede höhere Stufe umfasst zusätzlich die niedrigeren Stufen. Eine Ansicht oder ein definierter Prozess ist also nur dann WCAG AA-konform, wenn alle anwendbaren Erfolgskriterien der Stufen A und AA erfüllt sind.

Konformität bezieht sich formal auf vollständige Webseiten im Sinne einzelner vollständiger Seiten oder Ansichten, nicht nur auf isolierte Fragmente. In dynamischen Anwendungen kann eine „Seite“ auch eine vollständige Ansicht oder ein definierter Zustand einer Anwendung sein. Einzelne Komponenten können selbstverständlich geprüft und bewertet werden, eine formale WCAG-Konformitätsaussage betrifft jedoch vollständige Seiten, Ansichten, Seitengruppen oder definierte Prozesse.

Wenn ein Prozess aus mehreren Schritten besteht, müssen alle Schritte des Prozesses zugänglich sein. Ein barrierefreier Login allein reicht nicht aus, wenn die anschließende Suche, der Download oder die Formularabsendung nicht nutzbar sind. Für Informationsmanagementsysteme ist diese Prozesssicht besonders wichtig, weil viele Barrieren erst im Zusammenspiel von Suche, Filterung, Dokumentvorschau, Berechtigungen und Formularen sichtbar werden.

Die WCAG nennen fünf formale Konformitätsanforderungen:

• Konformitätsstufe: Es muss angegeben werden, ob A, AA oder AAA erreicht wird.
• vollständige Seiten: Ganze Seiten oder Ansichten müssen die Anforderungen erfüllen, nicht nur einzelne Komponenten.
• vollständige Prozesse: Alle Seiten oder Ansichten eines zusammenhängenden Prozesses müssen konform sein.
• barrierefrei unterstützte Technologien: Technologien dürfen zur Erfüllung nur vorausgesetzt werden, wenn sie ausreichend von Benutzeragenten und Assistenztechnologien unterstützt werden.
• keine Störung durch nicht-konforme Inhalte: Nicht-konforme Inhalte dürfen die Nutzung konformer Inhalte nicht beeinträchtigen.

Der Begriff accessibility supported bedeutet, dass eine eingesetzte Technologie in der Praxis von relevanten Browsern, Benutzeragenten und Assistenztechnologien ausreichend unterstützt wird. Eine Funktion darf also nicht nur theoretisch im Code vorhanden sein, sondern muss für Nutzerinnen und Nutzer tatsächlich zugänglich sein. Das ist besonders wichtig bei JavaScript-Komponenten, ARIA-Implementierungen, PDF-Anzeigen im Browser oder komplexen Webanwendungen.

WCAG A

Die Stufe A beschreibt grundlegende Anforderungen. Werden diese nicht erfüllt, können bestimmte Nutzergruppen Inhalte oft gar nicht verwenden. Level A ist die Mindeststufe, reicht in professionellen und rechtlich relevanten Kontexten aber häufig nicht aus.

Typische Level-A-Kriterien sind zum Beispiel:

• 1.1.1 Nicht-Text-Inhalt: Informative Bilder und andere Nicht-Text-Inhalte benötigen eine geeignete Textalternative.
• 1.3.1 Informationen und Beziehungen: Struktur, Beziehungen und Bedeutung müssen programmatisch erkennbar oder im Text verfügbar sein.
• 1.3.2 Sinnvolle Reihenfolge: Inhalte müssen in einer verständlichen Reihenfolge ausgegeben werden können.
• 2.1.1 Tastatur: Funktionen müssen per Tastatur bedienbar sein.
• 2.4.3 Fokusreihenfolge: Die Fokusreihenfolge muss Bedeutung und Bedienbarkeit unterstützen.
• 3.3.1 Fehleridentifikation: Eingabefehler müssen erkannt und beschrieben werden, sofern sie automatisch erkennbar sind.
• 3.3.7 Redundante Eingabe: Informationen, die bereits eingegeben wurden, sollen in einem Prozess nicht unnötig erneut eingegeben werden müssen, sofern keine Ausnahmen greifen.
• 4.1.2 Name, Rolle, Wert: Bedienelemente müssen für Assistenztechnologien korrekt identifizierbar sein.

Ein Beispiel: Ein Formularfeld darf nicht nur optisch neben dem Text „E-Mail“ stehen. Die Beschriftung muss auch technisch mit dem Eingabefeld verbunden sein. Nur dann kann ein Screenreader den Zweck des Feldes zuverlässig ausgeben.

WCAG AA

Die Stufe AA ist in der Praxis besonders wichtig. Sie gilt häufig als Zielniveau für öffentliche Stellen und viele Unternehmen. Viele rechtliche und normative Anforderungen in Europa orientieren sich an EN 301 549 und damit je nach herangezogener Fassung stark an WCAG 2.1 auf Stufe AA. Künftige Fassungen können WCAG 2.2 stärker berücksichtigen.

Typische Level-AA-Kriterien sind zum Beispiel:

• 1.4.3 Kontrast: Normaler Text benötigt in der Regel ein Kontrastverhältnis von mindestens 4,5:1.
• 1.4.5 Bilder von Text: Bilder von Text sind auf Level AA nur unter bestimmten Ausnahmen zulässig, etwa wenn die Darstellung wesentlich ist oder das Bild rein dekorativ ist.
• 1.4.10 Reflow: Inhalte müssen bei 320 CSS-Pixel Breite ohne zweidimensionales Scrollen nutzbar bleiben, sofern keine Ausnahmen greifen.
• 1.4.11 Nicht-Text-Kontrast: Bedienelemente und wichtige grafische Informationen benötigen in der Regel mindestens 3:1 Kontrast.
• 1.4.4 Textgröße ändern: Text muss bis 200 Prozent vergrößert werden können, ohne dass Inhalt oder Funktion verloren gehen.
• 2.4.7 Fokus sichtbar: Der Tastaturfokus muss sichtbar sein.
• 2.4.11 Fokus nicht verdeckt - Minimum: Die fokussierte Benutzeroberflächenkomponente darf in WCAG 2.2 auf AA nicht vollständig durch vom Autor erzeugte Inhalte verdeckt werden.
• 2.5.7 Ziehbewegungen: Funktionen, die Drag-and-drop erfordern, müssen ohne Ziehbewegung bedienbar sein, sofern keine Ausnahmen greifen.
• 2.5.8 Zielgröße - Minimum: Interaktive Ziele müssen in WCAG 2.2 auf AA mindestens 24 mal 24 CSS-Pixel groß sein oder unter definierte Ausnahmen fallen.
• 3.2.3 Konsistente Navigation: Wiederkehrende Navigation muss konsistent bleiben.
• 3.2.6 Konsistente Hilfe: Wenn Hilfefunktionen vorhanden sind, müssen sie in einer konsistenten Reihenfolge erscheinen.
• 3.3.3 Fehlerempfehlung: Korrekturvorschläge müssen bereitgestellt werden, wenn sie bekannt sind und keine Sicherheits- oder Zweckgründe entgegenstehen.
• 3.3.8 Zugängliche Authentifizierung - Minimum: Authentifizierung darf nicht allein von kognitiven Funktionstests abhängen, sofern keine unterstützenden Alternativen bereitstehen.

Für Unternehmenswebsites, Portale, Intranets und Informationsmanagementsysteme ist WCAG AA meist das sinnvollste Zielniveau. Es verbindet ein hohes Maß an Zugänglichkeit mit realistischer Umsetzbarkeit. Entscheidend ist jedoch, dass AA nicht „ein bisschen besser als A“ bedeutet, sondern alle anwendbaren A- und AA-Erfolgskriterien umfasst.

WCAG AAA

Die Stufe AAA ist die höchste Konformitätsstufe. Sie ist für viele Websites und Anwendungen nicht vollständig realistisch, kann aber für besonders wichtige Inhalte oder besonders schutzbedürftige Zielgruppen sinnvoll sein. Häufig werden einzelne AAA-Kriterien ergänzend umgesetzt, ohne vollständige AAA-Konformität zu beanspruchen.

Typische AAA-Themen sind:

• höhere Kontrastanforderungen für Text
• weitergehende Anforderungen an Untertitel, Audiodeskription oder Medienalternativen
• Unterstützung beim Verständnis ungewöhnlicher Wörter, Abkürzungen oder schwieriger Begriffe
• Anforderungen an ein bestimmtes Leseniveau oder ergänzende Erklärungen
• besonders nutzerfreundliche Navigations- und Orientierungshilfen
• größere Zielgrößen für interaktive Elemente
• strengere Anforderungen an nicht verdeckten Fokus
• spezifischere Anforderungen an die Fokusdarstellung

Wichtig ist: Anforderungen zum Leseniveau oder zu ungewöhnlichen Begriffen sind nicht automatisch gleichzusetzen mit Leichter Sprache. Leichte Sprache folgt eigenen Regeln und Prüfverfahren. WCAG AAA kann jedoch Anregungen geben, wie besonders wichtige Informationen verständlicher gemacht werden können.

WCAG-Versionen: 2.0, 2.1 und 2.2

Die WCAG werden weiterentwickelt, weil sich Technologien, Endgeräte und Nutzungsgewohnheiten verändern. Die aktuelle W3C Recommendation ist WCAG 2.2. Rechtliche Vorgaben können jedoch je nach Land, Normversion und Anwendungsbereich weiterhin auf WCAG 2.1 oder auf eine bestimmte Fassung von EN 301 549 verweisen.

Die Entwicklung der WCAG 2.x lässt sich grob so einordnen:

• WCAG 2.0 - 2008: Grundlage mit den vier POUR-Prinzipien, den Stufen A, AA und AAA sowie zentralen Anforderungen zu Alternativtexten, Tastaturbedienung, Struktur, Kontrast und Kompatibilität.
• WCAG 2.1 - 2018: Erweiterung um Anforderungen für mobile Nutzung, Menschen mit Sehbehinderungen, Touch-Bedienung, flexible Bildschirmausrichtungen, Reflow und kognitive Barrieren.
• WCAG 2.2 - 2023: Ergänzung weiterer Kriterien zu Fokus, Zielgrößen, Drag-and-drop, konsistenter Hilfe, redundanter Eingabe und zugänglicher Authentifizierung.

Zu den wichtigen Neuerungen in WCAG 2.2 gehören 2.4.11 Focus Not Obscured (Minimum) auf AA, 2.5.7 Dragging Movements auf AA, 2.5.8 Target Size (Minimum) auf AA, 3.2.6 Consistent Help auf A, 3.3.7 Redundant Entry auf A und 3.3.8 Accessible Authentication (Minimum) auf AA. Zusätzlich gibt es 3.3.9 Accessible Authentication (Enhanced) auf AAA und 2.4.13 Focus Appearance auf AAA. Das frühere Erfolgskriterium 4.1.1 Parsing wurde in WCAG 2.2 entfernt beziehungsweise als obsolet behandelt.

WCAG, WAI-ARIA, ATAG, UAAG und WCAG2ICT

WCAG wird häufig mit anderen W3C-Standards verwechselt. Die WCAG beschreiben Anforderungen an Webinhalte. Sie beantworten also die Frage, wie Inhalte, Funktionen und Oberflächen gestaltet sein müssen, damit sie zugänglich sind.

WAI-ARIA ist eine technische Spezifikation, mit der Rollen, Zustände und Eigenschaften für assistive Technologien ergänzt werden können. ARIA ist besonders bei komplexen Webanwendungen nützlich, ersetzt aber kein semantisch korrektes HTML. Falsch eingesetztes ARIA kann Barrieren sogar verstärken.

ATAG, die Authoring Tool Accessibility Guidelines, betreffen Werkzeuge zur Erstellung von Inhalten, etwa Content-Management-Systeme, Redaktionssysteme oder Dokumentenwerkzeuge. UAAG, die User Agent Accessibility Guidelines, beziehen sich auf Benutzeragenten wie Browser und Medienplayer. WCAG2ICT erklärt, wie WCAG-Anforderungen auf Nicht-Web-IKT wie Software, mobile Apps, digitale Dokumente oder geschlossene Systeme übertragen werden können.

WCAG, EN 301 549, BITV, BFSG und European Accessibility Act

Die WCAG sind ein technischer Standard beziehungsweise eine W3C-Empfehlung. Rechtliche Pflichten entstehen nicht unmittelbar aus den WCAG selbst, sondern aus Gesetzen, Verordnungen, Normen oder Verträgen, die auf WCAG-Kriterien verweisen oder sie übernehmen. Deshalb ist es wichtig, WCAG von rechtlichen Regelwerken zu unterscheiden.

In Europa und Deutschland sind vor allem folgende Begriffe relevant:

• EN 301 549: Europäische Norm mit Barrierefreiheitsanforderungen an Informations- und Kommunikationstechnik. Sie verweist für Webinhalte stark auf WCAG-Kriterien und wird in vielen rechtlichen Kontexten herangezogen.
• BGG: Das Behindertengleichstellungsgesetz regelt in Deutschland unter anderem Barrierefreiheitspflichten des Bundes.
• BITV 2.0: Die Barrierefreie-Informationstechnik-Verordnung konkretisiert Anforderungen an digitale Angebote öffentlicher Stellen des Bundes.
• Landesrechtliche Regelungen: Für Länder und Kommunen gelten ergänzend die Behindertengleichstellungsgesetze und Verordnungen der Bundesländer.
• European Accessibility Act, kurz EAA: Eine EU-Richtlinie zur Barrierefreiheit bestimmter Produkte und Dienstleistungen.
• BFSG: Das Barrierefreiheitsstärkungsgesetz setzt den EAA in Deutschland für bestimmte Produkte und Dienstleistungen um.
• BFSGV: Die Verordnung zum Barrierefreiheitsstärkungsgesetz konkretisiert Anforderungen für betroffene Produkte und Dienstleistungen.

Das BFSG gilt nicht pauschal für alle Unternehmenswebsites oder alle digitalen Services. Es betrifft bestimmte Produkte und Dienstleistungen, insbesondere im Verbraucherbereich, etwa E-Commerce-Angebote, Bankdienstleistungen, bestimmte Telekommunikationsdienste, E-Books, Hardware und Selbstbedienungsterminals. Es gibt Ausnahmen, Übergangsregelungen und Anforderungen an Marktüberwachung; ein zentraler Stichtag ist der 28.06.2025.

WCAG-Konformität kann rechtliche Risiken reduzieren, ist aber keine automatische Garantie für vollständige Rechtskonformität. Je nach Anwendungsbereich können weitere Pflichten bestehen, etwa eine Erklärung zur Barrierefreiheit, ein Feedbackmechanismus, Fristen, Dokumentationspflichten, Marktüberwachung oder Anforderungen an Support- und Kommunikationswege.

Internationale Einordnung

Auch außerhalb Europas spielen die WCAG eine wichtige Rolle. In den USA verweist Section 508 für digitale Angebote öffentlicher Stellen auf Anforderungen, die stark an WCAG orientiert sind. Zusätzlich kann der Americans with Disabilities Act, kurz ADA, im Zusammenhang mit digitalen Angeboten relevant werden, auch wenn die genaue Anwendung stark vom Einzelfall und der Rechtsprechung abhängt.

In Kanada ist unter anderem der Accessibility for Ontarians with Disabilities Act, kurz AODA, relevant. Auch viele andere Länder nutzen WCAG direkt oder indirekt als Grundlage für nationale Vorgaben, Beschaffungskriterien oder Prüfstandards. Wenn Sie international tätig sind, sollten Sie deshalb nicht nur die WCAG-Stufe, sondern auch die jeweils geltenden nationalen Regelungen prüfen.

Barrierefreiheitserklärung und Feedbackmechanismus

Für viele öffentliche Stellen und bestimmte regulierte Angebote ist nicht nur die technische Barrierefreiheit relevant. Es können auch organisatorische Pflichten bestehen, etwa eine Barrierefreiheitserklärung und ein zugänglicher Feedbackmechanismus. Damit können Nutzerinnen und Nutzer Barrieren melden und Informationen zu nicht barrierefreien Inhalten anfordern.

Eine Barrierefreiheitserklärung beschreibt in der Regel, welchen Stand der Barrierefreiheit ein Angebot hat, welche Bereiche noch nicht vollständig zugänglich sind und wie Nutzerinnen und Nutzer Kontakt aufnehmen können. Sie sollte selbst barrierefrei zugänglich, verständlich formuliert und regelmäßig aktualisiert werden. Für Unternehmen ist eine solche Dokumentation auch dann sinnvoll, wenn sie nicht ausdrücklich vorgeschrieben ist, weil sie Transparenz schafft und Verbesserungen nachvollziehbar macht.

Eine formale WCAG-Konformitätserklärung sollte mindestens die geprüfte WCAG-Version, die angestrebte Konformitätsstufe, das Datum der Bewertung, den geprüften Umfang, die geprüften Seiten, Ansichten oder Prozesse, die vorausgesetzten Technologien und bekannte Einschränkungen enthalten. Sinnvoll sind außerdem Angaben zur Prüfmethode, zu verwendeten Testwerkzeugen, zu getesteten Browser- und Assistenztechnologie-Kombinationen sowie zu geplanten Verbesserungen.

Warum sind die WCAG wichtig?

Die WCAG schaffen einen international anerkannten Rahmen, mit dem digitale Barrierefreiheit planbar, prüfbar und vergleichbar wird. Für Unternehmen bedeutet das: WCAG helfen nicht nur bei der Einhaltung von Vorgaben, sondern verbessern auch digitale Services, interne Prozesse und die Qualität von Informationssystemen. Barrierefreiheit ist damit ein Bestandteil professioneller Informationsqualität.

Viele WCAG-Anforderungen verbessern die allgemeine Benutzerfreundlichkeit. Ein barrierefreies Formular ist meist auch ein besseres Formular: Es hat eindeutige Labels, verständliche Pflichtfeldhinweise, konkrete Fehlermeldungen und eine logische Tab-Reihenfolge. Dadurch sinkt die Fehlerquote, Prozesse werden schneller abgeschlossen und Supportaufwand kann reduziert werden.

Auch wirtschaftlich ist Barrierefreiheit relevant. Zugängliche digitale Prozesse können Abbrüche reduzieren, Supportkosten senken und die Wartbarkeit von Komponenten erhöhen. Manche Maßnahmen können auch Suchmaschinenoptimierung indirekt unterstützen, etwa durch saubere Struktur, aussagekräftige Links und textbasierte Inhalte. Barrierefreiheit und SEO haben jedoch unterschiedliche Ziele, Kriterien und Bewertungssysteme.

WCAG im Informationsmanagement

Für Informationsmanagementsysteme sind die WCAG besonders relevant, weil dort oft komplexe Inhalte und Prozesse abgebildet werden. Es geht nicht nur um öffentliche Webseiten, sondern um digitale Arbeitsumgebungen, in denen Informationen erstellt, gesucht, freigegeben, verteilt, archiviert und genutzt werden. Fachlich können WCAG-Kriterien auch für interne Systeme angewendet werden, selbst wenn die rechtliche Verpflichtung vom jeweiligen Kontext abhängt.

Typische Beispiele sind:

• Dokumentenmanagementsysteme
• Wissensdatenbanken
• Intranets
• Extranets
• Kundenportale
• Serviceportale
• Enterprise-Search-Lösungen
• Redaktionssysteme
• digitale Formulare
• Workflows und Freigabeprozesse
• Archiv- und Records-Management-Systeme
• Helpdesk- und Ticketsysteme
• Lernplattformen und interne Schulungsportale

Gerade bei solchen Systemen reicht es nicht aus, nur die Startseite barrierefrei zu gestalten. Auch Login, Suche, Filterfunktionen, Tabellen, Dokumentenvorschauen, Upload-Dialoge, Berechtigungsdialoge, Benachrichtigungen, Fehlermeldungen und Downloads müssen zugänglich sein. Wenn ein Prozess aus mehreren Schritten besteht, ist der Prozess nur dann barrierefrei nutzbar, wenn alle Schritte zugänglich sind.

Typische Prüfpfade sind zum Beispiel „registrieren und Konto bestätigen“, „einloggen und Passwort zurücksetzen“, „Dokument suchen und herunterladen“, „Formular ausfüllen und absenden“, „Antrag stellen und Status prüfen“, „Produkt in den Warenkorb legen und Checkout abschließen“ oder „Termin suchen und buchen“. Solche Pfade zeigen Barrieren oft besser als isolierte Einzeltests.

Typische WCAG-Anforderungen in der Praxis

Viele Barrieren entstehen nicht durch Sonderfälle, sondern durch alltägliche Elemente wie Links, Formulare, Tabellen, Bilder, Medien, Dialoge und Dokumente. Deshalb lohnt es sich, wiederkehrende Anforderungen systematisch in Design, Entwicklung, Redaktion und Qualitätssicherung zu verankern. Besonders hilfreich sind klare Standards für Komponenten, Inhalte und Prüfprozesse.

Wichtige Praxisanforderungen sind:

• Alternativtexte: Informative Bilder benötigen sinnvolle Alternativtexte. Dekorative Bilder sollten einen leeren Alternativtext haben oder technisch so eingebunden sein, dass sie von Assistenztechnologien ignoriert werden.
• Überschriftenstruktur: Überschriften sollten semantisch sinnvoll und nachvollziehbar eingesetzt werden. Eine übersprungene Überschriftenebene ist nicht automatisch ein WCAG-Verstoß, kann aber Orientierung und Struktur verschlechtern.
• Tastaturbedienbarkeit: Menüs, Modale, Filter, Kalenderauswahlen, Upload-Felder, Tabellenaktionen und Buttons müssen ohne Maus bedienbar sein.
• Kontraste: Text, große Schrift, Icons, Eingabefelder, Diagramme und grafische Bedienelemente benötigen ausreichende Kontraste.
• Formulare: Jedes Eingabefeld braucht eine eindeutige, programmatisch verbundene Beschriftung. Fehlermeldungen sollten konkret, auffindbar und mit dem Feld verknüpft sein.
• Linktexte: Linktexte sollten den Zweck des Links beschreiben. „Hier klicken“ oder „mehr“ ist oft zu ungenau.
• Medienalternativen: Aufgezeichnete Videos mit Ton benötigen Untertitel. Reine Audioinhalte benötigen eine Textalternative, und relevante visuelle Videoinformationen können Audiodeskription oder Medienalternativen erfordern.
• Reflow und Zoom: Inhalte müssen bei Vergrößerung und schmalen Ansichten nutzbar bleiben. WCAG fordert nicht pauschal responsives Design, aber Anforderungen wie Reflow, Zoomfähigkeit und Orientierung unterstützen mobile und flexible Nutzung.
• Statusmeldungen: Hinweise wie „Dokument wurde gespeichert“ oder „Suche abgeschlossen“ sollten auch für Screenreader erfassbar sein.
• Seitentitel: Jede Seite oder Ansicht sollte eindeutig benannt sein, damit Nutzerinnen und Nutzer wissen, wo sie sich befinden.
• Sprache: Die Hauptsprache einer Seite und relevante Sprachwechsel sollten technisch ausgezeichnet sein.

Kontraste, Fokus und Zielgrößen

Kontrast ist mehr als die Lesbarkeit von Fließtext. Die WCAG unterscheiden unter anderem Textkontrast, Kontrast für großen Text, Nicht-Text-Kontrast für Bedienelemente und grafische Informationen sowie Anforderungen an Fokusindikatoren. Auch Diagramme, Statusfarben und Icons sollten so gestaltet sein, dass Informationen nicht allein von Farbe oder schwachen Kontrasten abhängen.

Für normalen Text verlangt WCAG AA in der Regel ein Kontrastverhältnis von mindestens 4,5:1. Für großen Text gilt auf AA in der Regel 3:1. Großer Text bedeutet mindestens 18 Punkt oder 14 Punkt fett, wobei die genaue Bewertung in CSS-Pixel und tatsächlicher Darstellung geprüft werden sollte. Für Nicht-Text-Kontrast verlangt WCAG 2.1 AA bei wesentlichen grafischen Informationen und sichtbaren Grenzen von Bedienelementen in der Regel 3:1.

Bei Fokusindikatoren ist Präzision wichtig. WCAG 2.1 AA verlangt mit 2.4.7 Fokus sichtbar, dass der Tastaturfokus sichtbar ist, schreibt aber nicht für jeden Fokusindikator einen allgemeinen Mindestkontrastwert vor. Kontrastanforderungen können sich je nach Umsetzung aus 1.4.11 Nicht-Text-Kontrast ergeben. WCAG 2.2 ergänzt mit 2.4.11 Fokus nicht verdeckt - Minimum auf AA und 2.4.13 Focus Appearance auf AAA spezifischere Anforderungen.

WCAG 2.2 bringt zusätzliche Aufmerksamkeit für Zielgrößen. Das Erfolgskriterium 2.5.8 Target Size (Minimum) auf Level AA fordert für interaktive Ziele grundsätzlich mindestens 24 mal 24 CSS-Pixel, enthält aber Ausnahmen, etwa für Inline-Links, gleichwertige alternative Ziele oder durch den Benutzeragenten bestimmte Größen. Auf Level AAA gibt es mit 2.5.5 Target Size (Enhanced) strengere Anforderungen von grundsätzlich 44 mal 44 CSS-Pixel.

Alternativtexte richtig einsetzen

Alternativtexte hängen immer vom Kontext ab. Dasselbe Bild kann in einem Kontext informativ und in einem anderen dekorativ sein. Ein Alternativtext sollte nicht beschreiben, dass etwas „ein Bild“ ist, sondern die relevante Information vermitteln, die sehende Nutzerinnen und Nutzer aus dem Bild erhalten.

Ein schlechtes Beispiel für ein Produktfoto wäre „Bild123.jpg“ oder „Foto“. Besser ist je nach Kontext „Roter Aktenordner mit Beschriftungsfeld“ oder „Dashboard mit Dokumentenstatus und Freigabeanzeige“. Wenn dasselbe Bild nur dekorativ neben einem bereits erklärenden Text steht, kann ein leerer Alternativtext sinnvoll sein, damit Screenreader keine redundanten Informationen ausgeben.

Bei Diagrammen reicht ein kurzer Alternativtext oft nicht aus. Dann kann der Alternativtext die Kernaussage nennen, während eine ergänzende Beschreibung Daten, Trends oder Zusammenhänge erklärt. Bei komplexen Infografiken sollten Sie außerdem prüfen, ob eine zugängliche Textversion oder Datentabelle erforderlich ist.

Formulare und Fehlermeldungen

Formulare gehören zu den häufigsten Barrieren in digitalen Angeboten. Jedes Eingabefeld benötigt eine sichtbare und programmatisch verknüpfte Beschriftung. Platzhaltertexte allein sind keine gute Beschriftung, weil sie beim Tippen verschwinden, häufig zu wenig Kontrast haben und nicht immer zuverlässig von Assistenztechnologien ausgegeben werden.

Gute Fehlermeldungen sind konkret, verständlich und handlungsorientiert. Statt „Fehler“ sollte die Meldung erklären, welches Feld betroffen ist und wie der Fehler korrigiert werden kann. Beispiel: „Die Versicherungsnummer muss aus einem Buchstaben und neun Ziffern bestehen. Beispiel: A123456789.“

Bei komplexen Eingaben helfen zusätzliche Hinweise vor dem Absenden. Datumsformate, Passwortregeln, erlaubte Dateitypen oder maximale Dateigrößen sollten frühzeitig genannt werden. Wenn Fehler auftreten, sollten sie am Anfang des Formulars zusammengefasst und zusätzlich direkt am jeweiligen Feld ausgegeben werden.

Sprache der Seite und Sprachwechsel

Die Hauptsprache einer Seite sollte im HTML über das lang-Attribut korrekt angegeben werden, etwa lang="de" für Deutsch. Screenreader nutzen diese Information, um Aussprache, Betonung und Sprachregeln anzupassen. Ohne korrekte Sprachauszeichnung können Inhalte schwer verständlich vorgelesen werden.

Auch Sprachwechsel innerhalb einer Seite sollten ausgezeichnet werden, wenn sie relevant sind. Ein englischer Produktname muss nicht immer gesondert markiert werden, ein längerer englischer Abschnitt oder ein fremdsprachiges Zitat dagegen häufig schon. Besonders in internationalen Portalen, Wissensdatenbanken und Dokumentationssystemen ist eine saubere Sprachauszeichnung wichtig.

Orientierung und Navigation

Nutzerinnen und Nutzer sollten jederzeit verstehen, wo sie sich befinden, welche Möglichkeiten sie haben und wie sie zu wichtigen Bereichen gelangen. Dazu gehören eindeutige Seitentitel, klare Überschriften, konsistente Navigation, sichtbare aktive Zustände und nachvollziehbare Linktexte. In umfangreichen Informationssystemen können Breadcrumbs, Suchfunktionen und Filter zusätzliche Orientierung bieten.

WCAG fordert für bestimmte Kontexte mehrere Wege, um Seiten innerhalb eines Angebots zu finden, sofern keine Ausnahme greift. Das kann über Navigation, Suche, Sitemap, Verlinkungen oder Inhaltsverzeichnisse erfolgen. Besonders hilfreich ist es, wenn wiederkehrende Funktionen wie Hilfe, Kontakt, Suche oder Konto immer an erwartbaren Stellen erscheinen.

Tastaturbedienung konkret prüfen

Eine einfache Tastaturprüfung zeigt viele Barrieren schnell. Navigieren Sie mit der Tabulatortaste durch die Seite und prüfen Sie, ob alle interaktiven Elemente erreichbar sind. Der Fokus sollte jederzeit sichtbar sein und in einer sinnvollen Reihenfolge verlaufen.

Prüfen Sie außerdem, ob Schaltflächen mit Enter oder Leertaste ausgelöst werden können, ob Menüs und Auswahllisten erwartbar bedienbar sind und ob Dialoge mit Escape geschlossen werden können, sofern dies vorgesehen ist. Bei modalen Dialogen sollte der Fokus in den Dialog wechseln, dort bleiben und nach dem Schließen sinnvoll zur auslösenden Stelle zurückkehren. Eine Tastaturfalle liegt vor, wenn Nutzerinnen und Nutzer nicht mehr weiter oder zurück navigieren können.

Medien: Untertitel, Transkripte und Audiodeskription

Medieninhalte benötigen je nach Art unterschiedliche Alternativen. Für aufgezeichnete Videos mit Ton sind Untertitel erforderlich. Reine Audioinhalte benötigen eine Textalternative, etwa ein Transkript. Relevante visuelle Informationen in Videos müssen über Audiodeskription oder Medienalternativen zugänglich gemacht werden, wobei die konkrete Anforderung von der Konformitätsstufe abhängt.

Für Live-Audio in synchronisierten Medien fordert WCAG AA Untertitel. Gebärdensprache kann eine wertvolle Ergänzung sein und ist in bestimmten Kontexten besonders hilfreich, gehört aber nicht pauschal zu den AA-Anforderungen für alle Inhalte. Wichtig ist, Medien nicht erst nachträglich zu betrachten, sondern Untertitel, Transkripte und Beschreibungen bereits in Planung und Produktion mitzudenken.

Untertitel sollten nicht nur gesprochene Sprache enthalten, sondern auch relevante Geräusche, Sprecherwechsel und nichtsprachliche Informationen, wenn sie für das Verständnis wichtig sind. Automatisch erzeugte Untertitel können ein guter Ausgangspunkt sein, müssen aber in der Regel geprüft und korrigiert werden.

ARIA richtig einsetzen

ARIA kann Barrierefreiheit verbessern, wenn native HTML-Elemente nicht ausreichen. Gleichzeitig ist ARIA kein Ersatz für falsches oder unvollständiges HTML. Die wichtigste Regel lautet: Verwenden Sie native HTML-Elemente, wenn diese die benötigte Funktion bereits korrekt abbilden.

Ein echter <button> ist in der Regel besser als ein <div> mit nachträglich ergänzter Button-Rolle. Native Elemente bringen Tastaturverhalten, Rollen, Zustände und Interaktion häufig bereits korrekt mit. Wenn ARIA eingesetzt wird, müssen Name, Rolle und Wert stimmen, und dynamische Zustände wie „geöffnet“, „ausgewählt“ oder „deaktiviert“ müssen zuverlässig aktualisiert werden.

Falsch eingesetztes ARIA kann Barrieren verschärfen. Ein Bedienelement kann optisch funktionieren, aber für Screenreader falsche Informationen ausgeben. Deshalb sollten ARIA-Komponenten immer mit Tastatur und geeigneten Screenreader-Testumgebungen geprüft werden.

Dynamische Inhalte und Single-Page-Anwendungen

Viele moderne Webanwendungen laden Inhalte dynamisch nach. Suchergebnisse, Filter, Statusmeldungen, Validierungsfehler, Dialogfenster oder Benachrichtigungen erscheinen, ohne dass eine klassische neue Seite geladen wird. Für sehende Mausnutzerinnen und -nutzer ist das oft selbstverständlich, für assistive Technologien aber nur dann erkennbar, wenn die Änderungen korrekt umgesetzt sind.

Wichtige Maßnahmen sind:

• Statusmeldungen mit geeigneten Live Regions ausgeben
• Fokus nach dem Öffnen modaler Dialoge sinnvoll setzen
• Fokus innerhalb modaler Dialoge halten und Rücksprung ermöglichen
• Fehlermeldungen technisch mit den betroffenen Feldern verbinden
• Seiten- oder Ansichtswechsel in Single-Page-Anwendungen erkennbar machen
• dynamische Inhalte nicht nur visuell hervorheben
• Tastaturbedienung bei Menüs, Tabs, Akkordeons und Autocomplete-Feldern sicherstellen

Ein Beispiel: Wenn nach einer Suche die Meldung „37 Treffer gefunden“ erscheint, sollte diese Information nicht nur sichtbar eingeblendet werden. Sie sollte auch so ausgezeichnet sein, dass Screenreader sie wahrnehmen können. Andernfalls wissen Nutzerinnen und Nutzer möglicherweise nicht, ob die Suche abgeschlossen wurde oder ob sich der Inhalt verändert hat.

Mobile Accessibility

Mobile Barrierefreiheit ist ein wesentlicher Bestandteil moderner WCAG-Umsetzung. Inhalte werden auf Smartphones, Tablets, Touchscreens, kleinen Bildschirmen, mit Bildschirmtastatur oder in wechselnder Ausrichtung genutzt. WCAG 2.1 und WCAG 2.2 enthalten deshalb mehrere Anforderungen, die für mobile Nutzung besonders relevant sind.

Achten Sie insbesondere auf:

• Nutzbarkeit im Hoch- und Querformat, sofern keine zwingende Ausrichtung erforderlich ist
• Reflow bei schmalen Ansichten und starker Vergrößerung
• ausreichend große Touch-Ziele
• Alternativen zu komplexen Gesten
• keine Funktionen, die ausschließlich durch Schütteln oder Gerätesensoren bedienbar sind
• sichtbaren Fokus bei angeschlossenen Tastaturen
• Formulare, die mit Bildschirmtastatur gut nutzbar bleiben
• Inhalte, die bei Zoom nicht abgeschnitten oder überlagert werden

Responsives Design ist eine häufige Methode, um diese Anforderungen umzusetzen, aber nicht automatisch gleichbedeutend mit WCAG-Konformität. Entscheidend ist, ob Inhalte und Funktionen bei unterschiedlichen Darstellungen tatsächlich zugänglich bleiben. Ein responsives Layout kann trotzdem Barrieren enthalten, wenn Menüs nicht per Tastatur bedienbar sind oder Inhalte bei Zoom verdeckt werden.

Kognitive Barrierefreiheit

Kognitive Barrierefreiheit betrifft Menschen mit Lernschwierigkeiten, Konzentrationsproblemen, Gedächtnisbeeinträchtigungen, neurodivergenten Wahrnehmungsweisen oder geringer digitaler Erfahrung. Viele Maßnahmen verbessern zugleich die allgemeine Verständlichkeit. Gerade komplexe Informationssysteme profitieren von klaren Abläufen, konsistenten Interaktionen und reduzierter Komplexität.

Hilfreich sind:

• klare Sprache und kurze, gut strukturierte Abschnitte
• konsistente Begriffe für dieselbe Funktion
• vorhersehbares Verhalten von Navigation und Bedienelementen
• sichtbare Orientierung in mehrstufigen Prozessen
• Hilfen bei komplexen Eingaben
• Vermeidung unnötiger Wiederholungseingaben
• verständliche Fehlermeldungen und Korrekturvorschläge
• keine unnötigen Ablenkungen durch Bewegung oder automatische Änderungen

WCAG 2.2 stärkt diesen Bereich unter anderem durch Kriterien wie Consistent Help, Redundant Entry und Accessible Authentication. Viele weitergehende Anforderungen zu Leseniveau, ungewöhnlichen Wörtern oder Abkürzungen liegen jedoch auf AAA. Komplexe Sprache ist daher nicht automatisch ein WCAG-A- oder WCAG-AA-Verstoß, kann aber die tatsächliche Nutzbarkeit erheblich beeinträchtigen.

Leichte Sprache und Einfache Sprache

Leichte Sprache und Einfache Sprache sind wichtige Ansätze, um Informationen verständlicher zu machen. Sie sind jedoch nicht dasselbe wie WCAG-Konformität. Leichte Sprache folgt eigenen Regeln, Zielgruppenanforderungen und Prüfverfahren, häufig einschließlich Prüfung durch Menschen aus der Zielgruppe.

Einfache Sprache ist weniger streng geregelt und richtet sich an eine breitere Zielgruppe. Sie nutzt klare Satzstrukturen, bekannte Begriffe und übersichtliche Abschnitte. WCAG kann Verständlichkeit unterstützen, ersetzt aber keine fachgerechte Erstellung von Leichter Sprache oder Einfacher Sprache, wenn diese für bestimmte Inhalte erforderlich oder sinnvoll ist.

Authentifizierung, Passwörter und CAPTCHAs

Login-Prozesse sind oft der erste kritische Zugangspunkt zu digitalen Angeboten. Wenn Authentifizierung nicht zugänglich ist, spielt die Barrierefreiheit des eigentlichen Inhalts kaum noch eine Rolle. WCAG 2.2 enthält mit 3.3.8 Accessible Authentication (Minimum) auf AA und 3.3.9 Accessible Authentication (Enhanced) auf AAA zwei Kriterien, die kognitive Funktionstests als alleinige Zugangshürde problematisch machen.

Achten Sie bei Authentifizierungsprozessen darauf, dass Nutzerinnen und Nutzer Passwortmanager verwenden, Passwörter einfügen und Zugangsdaten kopieren können. Mehr-Faktor-Authentifizierung sollte mit zugänglichen Verfahren möglich sein, etwa über gut bedienbare Apps, Codes, Sicherheitsschlüssel oder biometrische Verfahren, sofern diese als Option und nicht als unüberwindbare Hürde gestaltet sind. Zeitlimits sollten angemessen sein und verständlich kommuniziert werden.

CAPTCHAs sind besonders kritisch, weil sie häufig Sehvermögen, Hörvermögen, Mustererkennung oder kognitive Leistungen voraussetzen. WCAG verlangt unter anderem Textalternativen zur Identifikation und alternative CAPTCHA-Formen für unterschiedliche Sinnesmodalitäten. In der Praxis bleiben CAPTCHAs trotz Alternativen oft problematisch, weil sie Nutzergruppen weiterhin ausschließen können. Besser ist häufig ein weniger störender Missbrauchsschutz, etwa serverseitige Prüfungen, Risikoanalysen oder Honeypot-Felder, sofern diese datenschutz- und sicherheitskonform gestaltet sind.

Datenschutz und Barrierefreiheit

Barrierefreiheit und Datenschutz müssen gemeinsam gedacht werden. Cookie-Dialoge, Einwilligungsbanner, Tracking-Einstellungen, Sicherheitsabfragen und Konto-Verifikationen sind oft zentrale Zugangspunkte. Wenn diese Elemente nicht per Tastatur bedienbar sind oder von Screenreadern nicht verstanden werden, können Nutzerinnen und Nutzer ihre Datenschutzrechte nicht gleichwertig ausüben.

Auch biometrische Verfahren, CAPTCHAs, Verhaltensanalysen oder risikobasierte Authentifizierung sollten barrierefrei und datenschutzkonform gestaltet werden. Eine Sicherheitsmaßnahme darf nicht dazu führen, dass bestimmte Nutzergruppen ausgeschlossen werden. Umgekehrt sollten barrierefreie Alternativen nicht unnötig personenbezogene Daten erheben oder Nutzerinnen und Nutzer zu weniger datenschutzfreundlichen Verfahren zwingen.

Barrierefreie Tabellen

Tabellen sind in Informationsmanagementsystemen besonders häufig, etwa für Suchergebnisse, Dokumentlisten, Metadaten, Berechtigungen, Versionen oder Prozessstatus. Eine einfache Datentabelle sollte klare Spalten- und Zeilenüberschriften enthalten. Überschriftenzellen müssen technisch korrekt ausgezeichnet sein, damit Screenreader Beziehungen zwischen Daten und Überschriften herstellen können.

Bei komplexen Tabellen können zusätzliche Auszeichnungen wie scope, headers und id erforderlich sein. Außerdem sollten Tabellen eine sinnvolle Lesereihenfolge, verständliche Spaltennamen und klare Aktionsbezeichnungen haben. Wenn in jeder Zeile mehrere Icons stehen, müssen deren Funktionen eindeutig benannt sein, zum Beispiel „Dokument öffnen“, „Version herunterladen“ oder „Freigabe starten“.

Layout-Tabellen sollten vermieden werden. Sie erschweren die semantische Interpretation und können bei Screenreadern zu verwirrenden Ausgaben führen. Für Layouts sind CSS und semantische HTML-Strukturen die bessere Wahl.

WCAG und barrierefreie Dokumente

Die WCAG beziehen sich primär auf Webinhalte. Digitale Dokumente wie PDFs, Word-Dateien oder Präsentationen werden jedoch häufig über Websites, Portale und Informationssysteme bereitgestellt. Deshalb sollten sie ebenfalls barrierefrei sein, auch wenn ihre vollständige Bewertung zusätzlich dokumentenspezifische Standards und Werkzeuge erfordert.

Zu relevanten Dokumenttypen gehören:

• PDF-Dateien
• Word-Dokumente
• Präsentationen
• Berichte
• Formulare
• Anleitungen
• Vertragsunterlagen
• Produktinformationen
• Richtlinien und interne Arbeitsanweisungen
• Schulungsunterlagen

Wichtig sind unter anderem korrekte Überschriften, Alternativtexte für Grafiken, logische Lesereihenfolge, ausreichend Kontrast, aussagekräftige Links, korrekt ausgezeichnete Listen und Tabellen, definierte Dokumentsprache, zugängliche Formularfelder und maschinenlesbarer Text statt reiner Bildscans. Gerade bei PDFs ist außerdem eine getaggte Struktur entscheidend. Für PDF-Barrierefreiheit ist neben WCAG häufig PDF/UA als spezifischer Standard relevant.

Eine PDF-Prüfung sollte unter anderem Tags, Leserichtung, Dokumenttitel, Sprache, Lesezeichen, Alternativtexte, Artefakte, Tabellenstruktur, Formularfelder, Links und Sicherheitseinstellungen berücksichtigen. Automatische PDF-Prüfwerkzeuge können viele technische Probleme erkennen, aber nicht zuverlässig bewerten, ob Lesereihenfolge, Alternativtexte oder Formularhinweise fachlich sinnvoll sind.

In Unternehmen entstehen viele Barrieren nicht im Webdesign, sondern in hochgeladenen Dokumenten. Deshalb sollten Vorlagen für Word, PowerPoint und PDF bereits barrierearm oder barrierefrei aufgebaut sein. In Dokumentenmanagementsystemen verbessern aussagekräftige Titel, klare Dateinamen und gepflegte Metadaten zusätzlich Suche, Archivierung und Wiederauffindbarkeit.

KI-generierte Inhalte und Barrierefreiheit

KI kann bei Barrierefreiheit unterstützen, etwa durch automatische Transkripte, Untertitelentwürfe, Alternativtextvorschläge oder Zusammenfassungen. Diese Ergebnisse sollten jedoch nicht ungeprüft veröffentlicht werden. Automatische Alternativtexte können relevante Informationen auslassen, falsche Details ergänzen oder den Kontext eines Bildes missverstehen.

Auch automatisch erzeugte Untertitel und Transkripte benötigen Qualitätssicherung. Fachbegriffe, Namen, Zahlen und Sprecherwechsel werden häufig falsch erkannt. Wenn KI in Redaktions- oder Dokumentationsprozessen eingesetzt wird, sollten klare Prüfregeln gelten: menschliche Kontrolle, Datenschutzprüfung, Korrekturprozesse und Verantwortlichkeit für veröffentlichte Inhalte.

Accessibility Overlays

Accessibility Overlays sind Werkzeuge, die per Skript zusätzliche Bedienhilfen über eine Website legen, etwa Kontrastschalter, Schriftgrößenoptionen oder automatische ARIA-Anpassungen. Solche Funktionen können einzelne Komfortoptionen bieten, stellen WCAG-Konformität aber in der Regel nicht zuverlässig her. Grundlegende Barrieren im Code, in Formularen, Prozessen, Dokumenten oder Inhalten bleiben oft bestehen.

Besonders problematisch ist, wenn Overlays automatische Korrekturen versprechen, ohne die eigentliche Website zu verbessern. Sie können Assistenztechnologien stören, Fokusführung verschlechtern oder falsche Rollen und Beschriftungen erzeugen. Barrierefreiheit sollte deshalb möglichst an der Quelle umgesetzt werden: in Design, Inhalt, Komponenten, Code und Qualitätssicherung.

Grenzen automatisierter WCAG-Tests

Automatisierte Tests sind hilfreich, aber sie erkennen nur einen Teil der Barrieren zuverlässig. Tools können zum Beispiel viele Kontrastprobleme, fehlende Formularverknüpfungen, bestimmte ARIA-Fehler oder strukturelle Auffälligkeiten finden. Sie können aber nicht verlässlich beurteilen, ob ein Alternativtext sinnvoll ist, ob ein Linktext im Kontext verständlich ist oder ob ein komplexer Prozess tatsächlich nutzbar bleibt.

Auch bei Alternativtexten ist Vorsicht nötig. Ein leeres alt-Attribut ist nicht automatisch ein Fehler, wenn ein Bild dekorativ ist. Umgekehrt kann ein vorhandener Alternativtext unbrauchbar sein, wenn er nur „Bild“ oder „Grafik“ lautet. Automatische Werkzeuge liefern daher Hinweise, ersetzen aber keine fachliche Prüfung.

Sinnvolle Prüfkategorien sind:

• Kontrastprüfer für Text, Bedienelemente und grafische Informationen
• Browser-Extensions für schnelle WCAG-Hinweise
• HTML-Prüfwerkzeuge für strukturelle Auffälligkeiten
• Tastaturtests für Fokus, Reihenfolge und Bedienbarkeit
• Screenreader-Tests mit geeigneten Kombinationen aus Browser, Betriebssystem und Assistenztechnologie
• PDF-Prüfwerkzeuge für Tags, Lesereihenfolge und Dokumentstruktur
• manuelle Prozessprüfungen für reale Nutzungsszenarien

HTML-Validierung bleibt wichtig, sollte aber richtig eingeordnet werden. Das frühere WCAG-Erfolgskriterium 4.1.1 Parsing ist in WCAG 2.2 entfallen. Nicht jeder Validierungsfehler ist deshalb automatisch ein WCAG-2.2-Verstoß. Sauberer, robuster Code hilft aber weiterhin, Kompatibilitätsprobleme zu vermeiden.

Screenreader-Tests können beispielsweise mit NVDA und Firefox, JAWS und Chrome oder VoiceOver und Safari durchgeführt werden. Diese Kombinationen sind jedoch keine abschließende Liste. Je nach Zielgruppe, Plattform, Endgerät und Nutzungskontext können andere Kombinationen relevant sein.

WCAG-Prüfung mit WCAG-EM

Für eine strukturierte Evaluation von Websites stellt das W3C die Methodik WCAG-EM bereit. WCAG-EM steht für Website Accessibility Conformance Evaluation Methodology. Die Methodik beschreibt, wie Sie Prüfumfang, repräsentative Seiten, Nutzungsszenarien, Technologien und Bewertungsschritte systematisch festlegen können.

WCAG-EM ist besonders hilfreich bei größeren Websites, Portalen und Informationsmanagementsystemen. Statt zufällig einzelne Seiten zu testen, bestimmen Sie repräsentative Seitentypen, zentrale Prozesse und Zustände. Dadurch wird die Bewertung nachvollziehbarer, vergleichbarer und besser dokumentierbar.

WCAG-Prüfung: So gehen Sie strukturiert vor

Damit WCAG nicht abstrakt bleibt, sollten Sie digitale Angebote schrittweise prüfen. Besonders bei größeren Informationssystemen ist eine priorisierte Vorgehensweise sinnvoll. Prüfen Sie nicht nur einzelne Seiten, sondern vollständige Aufgaben und Prozesse.

Ein möglicher Ablauf ist:

1. Relevante Bereiche identifizieren
   Erfassen Sie zentrale Seiten, Ansichten, Prozesse und Dokumenttypen. Dazu gehören Login, Navigation, Suche, Filter, Formulare, Uploads, Downloads, Fehlermeldungen und häufig genutzte Workflows.
2. Nutzungsszenarien definieren
   Beschreiben Sie typische Aufgaben, zum Beispiel „Dokument suchen und herunterladen“, „Formular ausfüllen“, „Antrag einreichen“, „Termin buchen“ oder „Datensatz freigeben“.
3. Automatisierte Analyse durchführen
   Nutzen Sie Prüfwerkzeuge, um offensichtliche technische Probleme zu finden. Diese Prüfung ist ein guter Einstieg, ersetzt aber keine vollständige Bewertung.
4. Tastaturtest durchführen
   Prüfen Sie, ob alle Funktionen ohne Maus erreichbar, sichtbar fokussierbar und logisch bedienbar sind.
5. Screenreader-Test ergänzen
   Testen Sie zentrale Prozesse, um Beschriftungen, Reihenfolgen, Statusmeldungen und dynamische Inhalte zu überprüfen.
6. Redaktionelle Qualität prüfen
   Bewerten Sie Linktexte, Überschriften, Alternativtexte, Fehlermeldungen, Hilfetexte und Dokumentstrukturen.
7. Ergebnisse priorisieren
   Beheben Sie zuerst Barrieren, die zentrale Prozesse verhindern oder viele Nutzerinnen und Nutzer betreffen.
8. Regelmäßige Nachprüfungen etablieren
   Barrierefreiheit kann durch neue Inhalte, Designänderungen, Komponenten oder Softwareupdates wieder beeinträchtigt werden. Regelmäßige Tests sichern die Qualität langfristig.

Nutzerinnentests und Nutzertests mit Menschen mit Behinderungen

Technische WCAG-Prüfungen sind notwendig, aber sie zeigen nicht immer, wie gut ein Angebot im Alltag funktioniert. Tests mit Menschen mit Behinderungen können aufdecken, welche Barrieren in realen Nutzungssituationen auftreten. Dazu gehören beispielsweise Tests mit Screenreader-Nutzung, Tastaturnavigation, Vergrößerung, Sprachsteuerung oder kognitiver Assistenz.

Solche Tests ersetzen keine WCAG-Prüfung, sondern ergänzen sie. Ein Angebot kann einzelne Erfolgskriterien formal erfüllen und trotzdem schwer verständlich oder ineffizient nutzbar sein. Umgekehrt können Nutzerinnentests Hinweise liefern, die über WCAG hinausgehen und die Qualität eines digitalen Angebots deutlich verbessern.

Priorisierung von Barrieren

Nicht jede Barriere hat dieselbe Auswirkung. Priorisieren Sie zuerst blockierende Barrieren, die den Zugang zu zentralen Funktionen verhindern. Dazu gehören nicht bedienbare Logins, unzugängliche Formulare, Tastaturfallen, nicht lesbare Fehlermeldungen, unbedienbare Cookie-Dialoge oder Downloads, die für den Prozess zwingend erforderlich sind.

Danach sollten Sie rechtlich besonders relevante Bereiche, häufig genutzte Prozesse und Barrieren mit großer Reichweite behandeln. Quick Wins wie fehlende Formularlabels, unklare Linktexte oder geringe Kontraste können oft schnell behoben werden. Gleichzeitig sollten strukturelle Ursachen wie fehlerhafte Komponenten, unzugängliche Designsysteme oder ungeprüfte Dokumentvorlagen nachhaltig korrigiert werden.

Beschaffung, Ausschreibungen und Anbieterbewertung

Wenn Sie Software, Portale oder Informationsmanagementsysteme beschaffen, sollten Barrierefreiheitsanforderungen früh festgelegt werden. WCAG- oder EN-301-549-Anforderungen gehören in Lastenhefte, Ausschreibungen, Bewertungsmatrizen und Abnahmekriterien. Nur so wird Barrierefreiheit nicht erst nach der Einführung zum nachträglichen Korrekturprojekt.

Hilfreich sind konkrete Anforderungen an Konformitätsniveau, Prüfverfahren, Dokumentation und Nachweise. Im Unternehmens- und Softwarebeschaffungskontext werden häufig Accessibility Conformance Reports oder VPATs genutzt. Sie beschreiben, in welchem Umfang ein Produkt bestimmte Barrierefreiheitsanforderungen erfüllt, ersetzen aber keine eigene Prüfung der für Sie relevanten Nutzungsszenarien.

Vor der Abnahme sollten zentrale Prozesse praktisch getestet werden. Dazu gehören etwa Login, Suche, Formularbearbeitung, Dokumentenupload, Ergebnislisten, Exporte, Benachrichtigungen und administrative Funktionen. Besonders bei Standardsoftware ist wichtig, auch konfigurierte Oberflächen, Customizing, eingebundene Dokumente und Schnittstellen zu prüfen.

Governance und Verantwortlichkeiten

WCAG-konforme digitale Angebote entstehen nicht allein durch Entwicklung oder Redaktion. Barrierefreiheit ist eine Querschnittsaufgabe, an der mehrere Rollen beteiligt sind. Je klarer Verantwortlichkeiten verteilt sind, desto leichter lässt sich Zugänglichkeit dauerhaft sichern.

Typische Verantwortlichkeiten nach Projektphase sind:

• Konzeption: Anforderungen, Zielgruppen, Nutzungsszenarien, rechtliche Rahmenbedingungen und Prüfumfang festlegen.
• Design: Farben, Kontraste, Fokuszustände, Fehlerzustände, Layouts, Touch-Ziele und Interaktionsmuster zugänglich definieren.
• Entwicklung: semantischen Code, Tastaturbedienung, ARIA, Fokusmanagement, Statusmeldungen und robuste Komponenten umsetzen.
• Redaktion: Überschriften, Linktexte, Alternativtexte, Sprache, Medienalternativen und Dokumente zugänglich erstellen.
• Qualitätssicherung: automatisierte und manuelle Tests durchführen, Prozesse prüfen und Ergebnisse dokumentieren.
• Betrieb: Barrierefreiheit bei Updates, neuen Inhalten, Supportfällen, Feedback und Weiterentwicklungen sichern.

Barrierefreiheit sollte in die Definition of Done, in Designsysteme, Redaktionsleitfäden, Code Reviews, Testpläne und Release-Prozesse aufgenommen werden. Neue Inhalte, Komponenten und Releases können bestehende Konformität verschlechtern. Deshalb ist kontinuierliche Qualitätssicherung wichtiger als eine einmalige Prüfung.

Checklisten für Design, Redaktion und Entwicklung

Eine kompakte redaktionelle Checkliste hilft Ihnen, häufige Inhaltsbarrieren zu vermeiden. Prüfen Sie, ob Überschriften logisch aufgebaut sind, Linktexte den Zweck des Links beschreiben, Alternativtexte sinnvoll sind, Tabellen korrekt strukturiert werden und Dokumente barrierefrei erstellt wurden. Achten Sie außerdem auf klare Sprache, verständliche Fehlermeldungen, konsistente Begriffe und zugängliche Medienalternativen.

Für Design sollten Sie insbesondere Kontraste, Fokuszustände, Fehlerzustände, Layout bei Zoom, Touch-Ziele, Formularzustände und konsistente Komponenten prüfen. Wichtige Informationen sollten nicht nur über Farbe oder Position vermittelt werden. Interaktive Elemente müssen erkennbar sein, und Zustände wie aktiv, deaktiviert, fehlerhaft oder fokussiert sollten eindeutig unterscheidbar sein.

Für Entwicklung stehen semantisches HTML, Tastaturbedienbarkeit, Fokusmanagement, korrekte Formularverknüpfungen, sinnvolles ARIA, Statusmeldungen, robuste Komponenten und Tests im Vordergrund. Prüfen Sie Menüs, Dialoge, Tabs, Akkordeons, Tabellen, Autocomplete-Felder und dynamische Inhalte mit Tastatur und assistiven Technologien. Automatisierte Tests sollten in Entwicklungs- und Release-Prozesse integriert, aber immer durch manuelle Prüfungen ergänzt werden.

Erste 10 WCAG-Prüfungen für den Einstieg

Wenn Sie schnell erste Barrieren finden möchten, beginnen Sie mit grundlegenden Prüfungen. Diese ersetzen kein vollständiges Audit, liefern aber oft wichtige Hinweise. Besonders bei bestehenden Systemen helfen sie, Risiken sichtbar zu machen und Verbesserungen zu priorisieren.

Prüfen Sie zunächst:

1. ob Seitentitel und Hauptüberschriften eindeutig sind
2. ob Inhalte mit der Tastatur erreichbar und bedienbar sind
3. ob der Tastaturfokus sichtbar bleibt
4. ob Formulare sichtbare und technisch verbundene Labels haben
5. ob Fehlermeldungen konkret und mit den Feldern verknüpft sind
6. ob Textkontraste die Mindestwerte erfüllen
7. ob Informationen nicht nur über Farbe vermittelt werden
8. ob Bilder sinnvolle oder leere Alternativtexte haben
9. ob Links ihren Zweck verständlich machen
10. ob zentrale Prozesse wie Login, Suche, Download und Absenden vollständig nutzbar sind

Häufige Fehler bei der Umsetzung

Ein typisches Missverständnis ist, Barrierefreiheit erst am Ende eines Projekts zu prüfen. Das führt oft zu hohem Korrekturaufwand, weil grundlegende Entscheidungen zu Design, Komponenten, Informationsarchitektur und technischer Umsetzung bereits getroffen wurden. Besser ist es, WCAG-Anforderungen von Anfang an in Konzeption, Design, Entwicklung, Redaktion und Qualitätssicherung einzubeziehen.

Häufige Fehler sind:

• fehlende oder unpassende Alternativtexte
• dekorative Bilder, die unnötig vorgelesen werden
• zu geringe Farbkontraste
• Bedienung nur per Maus
• unklare Linktexte
• Formulare ohne korrekte Labels
• Pflichtfelder, die nur farblich markiert sind
• Überschriften, die nur optisch statt strukturell verwendet werden
• PDF-Dokumente ohne barrierefreie Struktur
• dynamische Inhalte, die Screenreader nicht korrekt erfassen
• Fehlermeldungen, die nicht verständlich oder nicht auffindbar sind
• Tabellen ohne korrekte Kopfzeilen
• nicht sichtbarer Tastaturfokus
• Modale oder Pop-ups, die nicht korrekt fokussiert oder geschlossen werden können
• CAPTCHAs ohne tragfähige zugängliche Alternative
• Icons ohne zugängliche Beschriftung
• zu kleine Klick- und Touch-Flächen
• unnötig komplexe Sprache ohne erklärende Unterstützung
• Download-Dokumente, die nicht denselben Barrierefreiheitsanspruch erfüllen wie das Webangebot

Besonders kritisch sind Fehler, die zentrale Prozesse blockieren. Wenn Nutzerinnen und Nutzer zwar Informationen lesen, aber keinen Antrag absenden, kein Dokument herunterladen oder keine Suchergebnisse bedienen können, ist die Barriere nicht nur ein Komfortproblem. Sie verhindert die eigentliche Nutzung des digitalen Angebots.

Häufige Missverständnisse zu WCAG

Ein verbreitetes Missverständnis lautet: „Responsiv bedeutet barrierefrei.“ Ein responsives Layout kann mobile Nutzung erleichtern, sagt aber noch nichts über Tastaturbedienbarkeit, Screenreader-Kompatibilität, Kontraste, Fehlermeldungen oder semantische Struktur aus. Barrierefreiheit muss zusätzlich geprüft werden.

Ein weiteres Missverständnis lautet: „Jedes Bild braucht einen sichtbaren Alternativtext.“ Informative Bilder brauchen eine Textalternative, dekorative Bilder dagegen sollten häufig mit leerem Alternativtext versehen oder technisch ignorierbar gemacht werden. Entscheidend ist die Funktion des Bildes im jeweiligen Kontext.

Auch „Ein automatisches Tool hat keine Fehler gefunden“ bedeutet nicht, dass ein Angebot WCAG-konform ist. Automatisierte Tools erkennen nur einen Teil der Barrieren. Besonders Tastaturführung, Prozesslogik, Verständlichkeit, Alternativtextqualität und dynamische Inhalte müssen manuell geprüft werden.

Best Practices für WCAG-konforme Inhalte

Wenn Sie digitale Inhalte nach WCAG verbessern möchten, hilft ein systematisches Vorgehen. Barrierefreiheit sollte nicht als einmaliges Prüfprojekt verstanden werden, sondern als Bestandteil Ihrer digitalen Qualitätsstrategie. Besonders wirksam ist es, Anforderungen früh zu definieren und in wiederkehrende Arbeitsabläufe zu integrieren.

Bewährte Maßnahmen sind:

1. Barrierefreiheit früh einplanen
   Berücksichtigen Sie WCAG- und EN-301-549-Anforderungen bereits bei Konzeption, Design, Systemauswahl und Beschaffung.
2. Redaktionelle Standards definieren
   Legen Sie fest, wie Überschriften, Linktexte, Alternativtexte, Tabellen, Medieninhalte und Dokumente erstellt werden sollen.
3. Designsysteme barrierefrei aufbauen
   Farben, Typografie, Buttons, Formularfelder, Fehlermeldungen, Fokuszustände und Navigationsmuster sollten zugänglich definiert sein.
4. Komponenten robust entwickeln
   Buttons, Menüs, Dialogfenster, Tabellen, Akkordeons, Tabs und Formulare sollten einmal sauber entwickelt und wiederverwendet werden.
5. Automatisierte Tests nutzen
   Tools können viele technische Hinweise liefern, etwa zu Kontrasten, Formularlabels oder ARIA-Problemen.
6. Manuell prüfen
   Prüfen Sie Tastaturbedienung, Screenreader-Ausgabe, Fokusreihenfolge, Verständlichkeit und tatsächliche Nutzbarkeit komplexer Prozesse.
7. Nutzerfeedback einbeziehen
   Rückmeldungen von Menschen mit unterschiedlichen Einschränkungen zeigen, welche Barrieren in realen Nutzungssituationen auftreten.
8. Barrierefreiheit in Workflows integrieren
   Neue Inhalte, Updates, Dokumente und Systemerweiterungen sollten regelmäßig geprüft werden.
9. Schulungen anbieten
   Designerinnen, Entwickler, Redakteurinnen, Projektverantwortliche und Fachabteilungen benötigen ein gemeinsames Verständnis.
10. Barrierefreiheit dokumentieren
    Halten Sie Standards, Prüfergebnisse, bekannte Einschränkungen und geplante Verbesserungen fest.

Seriöse Quellen und Orientierungshilfen

Für die Arbeit mit WCAG sollten Sie möglichst auf Primärquellen und etablierte Prüfmaterialien zurückgreifen. Die wichtigsten Quellen sind die W3C-Dokumente zu WCAG 2.2, „Understanding WCAG“, „Techniques for WCAG“ und „How to Meet WCAG“. Sie erklären Anforderungen, Absichten, typische Fehler und mögliche Umsetzungstechniken.

Für Europa und Deutschland sind außerdem EN 301 549, BITV 2.0, landesrechtliche Vorgaben, der BITV-Test und Informationen zuständiger Überwachungsstellen relevant. Praxisnahe Orientierung bieten außerdem die WAI Tutorials des W3C und Fachressourcen wie WebAIM. Achten Sie darauf, Versionen, Veröffentlichungsdatum und rechtlichen Kontext einer Quelle zu prüfen.

Häufige Fragen zu WCAG

Was bedeutet WCAG?

WCAG steht für Web Content Accessibility Guidelines. Es handelt sich um internationale Richtlinien des W3C für barrierefreie Webinhalte. Sie beschreiben, wie Websites, Webanwendungen und andere webbasierte Inhalte für Menschen mit unterschiedlichen Einschränkungen zugänglich gestaltet werden können.

Sind die WCAG ein Gesetz?

Nein. Die WCAG sind selbst kein Gesetz, sondern eine technische W3C-Empfehlung. Rechtliche Bedeutung erhalten sie, wenn Gesetze, Verordnungen, Normen oder Verträge auf WCAG-Kriterien verweisen, etwa über EN 301 549, BITV 2.0 oder Anforderungen aus dem BFSG.

Sind die WCAG eine Zertifizierung?

Nein, das W3C vergibt keine offizielle WCAG-Zertifizierung. Es gibt jedoch externe Audits, Konformitätsbewertungen, Prüfberichte und Zertifikate von Dienstleistern. Solche Nachweise können hilfreich sein, sollten aber immer mit Blick auf Prüfumfang, Methode, WCAG-Version und geprüfte Prozesse bewertet werden.

Wer entwickelt die WCAG?

Die WCAG werden vom World Wide Web Consortium, kurz W3C, entwickelt. Innerhalb des W3C arbeitet die Web Accessibility Initiative an Standards, Erläuterungen und unterstützenden Materialien zur digitalen Barrierefreiheit.

Welche WCAG-Version ist aktuell relevant?

Fachlich ist WCAG 2.2 die aktuelle W3C Recommendation. Rechtliche Anforderungen können je nach Land, Branche und Normversion aber weiterhin auf WCAG 2.1 oder EN 301 549 verweisen. Deshalb sollten Sie fachliche Aktualität und rechtliche Referenz getrennt prüfen.

Was bedeutet WCAG AA?

WCAG AA ist die zweite Konformitätsstufe. Eine Seite, Ansicht oder ein vollständiger Prozess ist nur dann Level AA-konform, wenn alle anwendbaren Erfolgskriterien der Stufen A und AA erfüllt sind. AA ist in der Praxis häufig das wichtigste Zielniveau.

Ist WCAG AAA Pflicht?

In der Regel ist vollständige WCAG-AAA-Konformität nicht verpflichtend und für viele Angebote schwer vollständig umzusetzen. Häufig wird WCAG AA angestrebt. Einzelne AAA-Kriterien können aber sinnvoll sein, wenn besonders wichtige, sensible oder erklärungsbedürftige Informationen bereitgestellt werden.

Reichen automatische WCAG-Tests aus?

Nein. Automatische Tools sind hilfreich, erkennen aber nur einen Teil der Barrieren zuverlässig. Verständlichkeit, sinnvolle Alternativtexte, Tastaturführung, Fokusmanagement, Screenreader-Nutzung und vollständige Prozesse sollten zusätzlich manuell geprüft werden.

Betrifft WCAG auch PDFs?

WCAG bezieht sich primär auf Webinhalte, aber PDFs und andere digitale Dokumente werden häufig über Webangebote bereitgestellt und sollten ebenfalls barrierefrei sein. Für PDFs sind neben WCAG auch dokumentenspezifische Anforderungen wie PDF/UA relevant. Wichtig sind Tags, Lesereihenfolge, Alternativtexte, Kontraste, Links, Sprache, Formularfelder und maschinenlesbarer Text.

Was ist der Unterschied zwischen WCAG und EN 301 549?

WCAG ist eine internationale Empfehlung für barrierefreie Webinhalte. EN 301 549 ist eine europäische Norm für Barrierefreiheitsanforderungen an Informations- und Kommunikationstechnik. Sie verweist für Webinhalte stark auf WCAG-Kriterien, umfasst aber einen breiteren Anwendungsbereich.

Was ist der Unterschied zwischen BITV, BFSG und European Accessibility Act?

Die BITV 2.0 konkretisiert in Deutschland Anforderungen an digitale Barrierefreiheit für öffentliche Stellen des Bundes. Für Länder und Kommunen gelten zusätzlich landesrechtliche Regelungen. Der European Accessibility Act ist eine EU-Richtlinie für bestimmte Produkte und Dienstleistungen. Das BFSG setzt diese Richtlinie in Deutschland insbesondere für bestimmte privatwirtschaftliche Angebote im Verbraucherbereich um.

Gilt das BFSG für jede Unternehmenswebsite?

Nein. Das BFSG gilt nicht pauschal für alle Unternehmenswebsites oder alle digitalen Services. Es betrifft bestimmte Produkte und Dienstleistungen, insbesondere im Verbraucherbereich, und enthält Ausnahmen sowie Übergangsregelungen. Ob Ihr Angebot betroffen ist, hängt vom konkreten Produkt, der Dienstleistung und dem Nutzungskontext ab.

Warum ist WCAG für Unternehmen wichtig?

WCAG hilft Unternehmen, digitale Angebote nutzerfreundlicher, zugänglicher und besser prüfbar zu machen. Außerdem können WCAG-orientierte Prozesse rechtliche Risiken reduzieren, Supportaufwand senken und die Qualität digitaler Informationsprozesse verbessern. Eine Garantie für vollständige Rechtskonformität ist WCAG-Konformität allein jedoch nicht.

Was ist der Unterschied zwischen Barrierefreiheit und Usability?

Barrierefreiheit sorgt dafür, dass Menschen mit unterschiedlichen Einschränkungen digitale Inhalte nutzen können. Usability beschreibt die allgemeine Benutzerfreundlichkeit. Beide Bereiche überschneiden sich stark, weil klare Strukturen, verständliche Texte und zuverlässige Bedienung allen Nutzerinnen und Nutzern helfen.

Was ist der Unterschied zwischen barrierefrei und barrierearm?

Barrierefrei bedeutet, dass ein Angebot bezogen auf definierte Anforderungen zugänglich ist, etwa auf eine bestimmte WCAG-Version und Konformitätsstufe. Barrierearm ist kein offizieller WCAG-Status, sondern beschreibt eine Verbesserung der Zugänglichkeit ohne formale Konformitätsaussage. Der Begriff sollte deshalb vorsichtig verwendet werden.

Was ist der Unterschied zwischen WCAG A, AA und AAA?

A beschreibt grundlegende Mindestanforderungen. AA umfasst zusätzlich alle A-Kriterien und enthält viele praxisrelevante Anforderungen, etwa zu Kontrasten, Reflow, konsistenter Navigation und Fokus. AAA umfasst zusätzlich alle A- und AA-Kriterien und stellt die höchsten Anforderungen.

Gilt WCAG auch für Intranets und interne Systeme?

Fachlich können WCAG-Kriterien auch auf Intranets, interne Portale, Dokumentenmanagementsysteme und andere interne Anwendungen angewendet werden. Ob eine gesetzliche Pflicht besteht, hängt vom Kontext, der Organisation und dem jeweiligen Regelwerk ab. Unabhängig davon verbessert Barrierefreiheit die Nutzbarkeit für Mitarbeitende.

Was ist WCAG2ICT?

WCAG2ICT ist ein W3C-Dokument, das erklärt, wie WCAG-Anforderungen auf Nicht-Web-Informations- und Kommunikationstechnik übertragen werden können. Dazu gehören etwa Software, mobile Anwendungen, digitale Dokumente und geschlossene Systeme. Es ist besonders hilfreich, wenn WCAG-Kriterien außerhalb klassischer Webseiten angewendet werden sollen.

Was ist WCAG-EM?

WCAG-EM ist die Website Accessibility Conformance Evaluation Methodology des W3C. Sie beschreibt eine strukturierte Methode zur Bewertung von Websites nach WCAG. Dazu gehören unter anderem die Festlegung des Prüfumfangs, die Auswahl repräsentativer Seiten und die Dokumentation der Ergebnisse.

Wie beginnt man mit der WCAG-Umsetzung?

Starten Sie mit einer Analyse Ihrer wichtigsten digitalen Angebote und Prozesse. Prüfen Sie anschließend Kontraste, Tastaturbedienung, Formulare, Überschriftenstruktur, Alternativtexte, Suchfunktionen, Dokumente und dynamische Inhalte. Danach sollten Sie verbindliche Standards für Design, Entwicklung, Redaktion und Qualitätssicherung festlegen.

Wer sollte im Unternehmen für WCAG verantwortlich sein?

WCAG sollte nicht nur einer einzelnen Person zugeordnet werden. Sinnvoll ist ein gemeinsames Modell mit klaren Verantwortlichkeiten für Management, Design, Entwicklung, Redaktion, Qualitätssicherung, IT, Support und Fachabteilungen. Ein Accessibility Owner kann Standards, Prüfprozesse und Wissen koordinieren.

Wie oft sollte Barrierefreiheit geprüft werden?

Barrierefreiheit sollte regelmäßig geprüft werden, insbesondere nach Relaunches, Systemupdates, Designänderungen, neuen Funktionen oder größeren Inhaltsaktualisierungen. Bei dynamischen Portalen und Informationsmanagementsystemen sind kontinuierliche Prüfprozesse besonders sinnvoll, weil neue Inhalte und Releases bestehende Konformität wieder verschlechtern können.