Digitale Barrierefreiheit

WCAG: Prinzipien, Ebenen und Erfolgskriterien

Begriffe vorab

• Erfolgskriterium: eine prüfbare Anforderung der WCAG.
• Konformität: die Erfüllung aller Kriterien einer Stufe.
• Techniken: Hinweise des W3C, wie Kriterien umgesetzt werden können; sie sind informativ, nicht verbindlich.

Die Web Content Accessibility Guidelines (WCAG) sind der internationale Standard für barrierefreie Webinhalte, herausgegeben vom W3C über die Web Accessibility Initiative (WAI). Aktuelle Fassungen sind WCAG 2.1 (2018) und WCAG 2.2 (2023), die WCAG 2.1 vollständig einschließt und um weitere Erfolgskriterien ergänzt.

Vier Prinzipien, ein Akronym

Jedes Erfolgskriterium gehört zu einem der vier POUR-Prinzipien (siehe vorige Lektion): wahrnehmbar, bedienbar, verständlich, robust.

Drei Konformitätsstufen

• A – Mindestanforderung, ohne die manche Nutzergruppen vollständig ausgeschlossen wären.
• AA – der in Gesetzen und Richtlinien übliche Zielstandard (siehe Rechtslektion).
• AAA – die höchste Stufe; das W3C selbst empfiehlt AAA nicht als pauschales Ziel für ganze Websites, da einige Kriterien für bestimmte Inhalte nicht erreichbar sind.

Aufbau eines Erfolgskriteriums

Jedes Kriterium hat eine Nummer nach dem Schema Prinzip.Richtlinie.Kriterium, zum Beispiel 1.4.3 Kontrast (Minimum) unter Prinzip 1 (Wahrnehmbar), Richtlinie 4 (Unterscheidbar).

Wichtige Kriterien zum Kennenlernen

• 1.1.1 Nicht-Text-Inhalte (A): Alternativtext für Bilder.
• 1.4.3 Kontrast Minimum (AA): 4,5:1 für normalen, 3:1 für großen Text.
• 2.1.1 Tastatur (A): Alle Funktionen ohne Maus erreichbar.
• 2.4.7 Fokus sichtbar (AA): Der Tastaturfokus muss erkennbar sein.
• 3.3.2 Beschriftungen/Anweisungen (A): Formularfelder brauchen erkennbare Labels.
• 4.1.2 Name, Rolle, Wert (A): Interaktive Elemente müssen für assistive Technologien identifizierbar sein.

Was ist neu in WCAG 2.2?

WCAG 2.2 ergänzt unter anderem Kriterien zu größeren Klickzielen (2.5.8 Zielgröße, Minimum: mindestens 24 × 24 CSS-Pixel, mit Ausnahmen), zu einem Tastaturfokus, der nicht vollständig von anderen Inhalten verdeckt werden darf (2.4.11 Fokus nicht verdeckt, Minimum, Stufe AA), sowie zu erleichtertem Ausfüllen von Formularen (3.3.7 Redundante Eingaben, 3.3.8 Barrierefreie Authentifizierung). Das zuvor enthaltene Kriterium 4.1.1 (Parsing) wurde als veraltet entfernt, da moderne Browser fehlerhaftes HTML ohnehin robust behandeln.

WCAG-Versionsnummern und einzelne Kriterien ändern sich. Für eine verbindliche Prüfung immer die aktuelle Fassung auf w3.org/WAI/standards-guidelines/wcag/ konsultieren.

Ein Beispiel: ein Kriterium durchgehen

Kriterium 1.1.1 (Nicht-Text-Inhalte) verlangt Textalternativen. Ein Diagramm mit Umsatzzahlen braucht eine Beschreibung, die die Kernaussage wiedergibt, etwa „Umsatz stieg von 2 Mio. € auf 3 Mio. €“. Ein rein dekoratives Bild bekommt einen leeren Alternativtext, damit Screenreader es überspringen. Das Kriterium nennt also nicht einfach „Alt-Text setzen“, sondern verlangt einen zum Zweck passenden Ersatz.

Konformität ist Seitenbezogen

Konformität gilt für vollständige Seiten, nicht für einzelne Elemente; alle Inhalte einer Seite müssen die Stufe erfüllen, auch eingebundene Komponenten. Bei Abläufen wie einer Bestellung müssen alle Schritte konform sein, sonst gilt der Ablauf nicht als konform.

Wie man WCAG im Projekt nutzt

• Zielstufe (meist AA) und Version (z. B. 2.1 oder 2.2) festlegen.
• Kriterien in Designvorgaben und Abnahmekriterien übersetzen.
• Bei Änderungen der Version prüfen, welche neuen Kriterien hinzukommen.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.

Quellen

• W3C – Web Content Accessibility Guidelines (WCAG) 2.1 und 2.2, Empfehlungen der W3C Web Accessibility Initiative
• W3C WAI – „Understanding Conformance“ (Erläuterung der Stufen A/AA/AAA) (allgemeine Referenz, nicht Zeile für Zeile geprüft)

Rechtliche Grundlagen: EAA, BFSG, BITV 2.0 und internationale Regeln

Begriffe vorab

• Richtlinie: ein EU-Rechtsakt, der von den Mitgliedstaaten in nationales Recht umgesetzt werden muss.
• Verordnung: gilt in den Mitgliedstaaten unmittelbar.
• Erklärung zur Barrierefreiheit: öffentliche Angabe zu Stand und bekannten Mängeln.

Barrierefreiheit ist in vielen Ländern nicht nur guter Stil, sondern Pflicht. Die folgenden Regelwerke sind im deutschsprachigen Raum und international am relevantesten.

EU: European Accessibility Act (EAA)

Die Richtlinie (EU) 2019/882 verpflichtet private Anbieter bestimmter Produkte und Dienstleistungen (u. a. E-Commerce, Bankdienstleistungen, E-Books, Personenverkehr) zur Barrierefreiheit. Die Mitgliedstaaten mussten sie in nationales Recht umsetzen; die Anwendungspflicht für Unternehmen gilt ab dem 28. Juni 2025. Kleinstunternehmen (weniger als 10 Beschäftigte und höchstens 2 Mio. € Jahresumsatz oder Jahresbilanzsumme) sind bei Dienstleistungen von der Pflicht ausgenommen; für Hersteller und Händler von Produkten gilt diese Ausnahme nicht.

Deutschland: BFSG

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die EAA in Deutschland um und gilt seit dem 28. Juni 2025 für die betroffenen privaten Anbieter. Es ergänzt die bereits bestehende BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung), die öffentliche Stellen des Bundes zur Barrierefreiheit ihrer Websites und Apps verpflichtet, inklusive einer öffentlich zugänglichen Erklärung zur Barrierefreiheit.

Der technische Unterbau: EN 301 549

Die europäische Norm EN 301 549 definiert die technischen Anforderungen an barrierefreie IKT-Produkte und -Dienstleistungen. Für Webinhalte verweist sie inhaltlich auf die WCAG. BITV 2.0 und viele nationale Umsetzungen der EAA/EU-Richtlinien stützen sich auf diese Norm.

International

• USA – Section 508 des Rehabilitation Act verpflichtet Bundesbehörden zu barrierefreier IKT.
• USA – Americans with Disabilities Act (ADA): Gerichte wenden Titel III zunehmend auch auf Websites privater Unternehmen an; das US-Justizministerium hat zudem eine Regel erlassen, die für Webangebote staatlicher und kommunaler Stellen (Titel II) WCAG 2.1 AA als Maßstab festlegt.
• Weltweit: Viele Länder orientieren sich an WCAG, auch außerhalb konkreter Gesetzespflichten, unter anderem weil sich internationale Anbieter ohnehin daran ausrichten.

Gesetze, Fristen und Anwendungsbereiche ändern sich und unterscheiden sich je nach Branche und Unternehmensgröße. Diese Lektion ist eine Orientierung, keine Rechtsberatung – im Zweifel die Originaltexte oder eine Rechtsberatung konsultieren.

Ein Beispiel: Online-Shop

Ein Online-Shop für Verbraucher fällt grundsätzlich in den Anwendungsbereich des BFSG, sofern das Unternehmen nicht als Kleinstunternehmen ausgenommen ist. Die Website samt Bestellprozess, Zahlung und Kundenbereich sollte dann barrierefrei nutzbar sein. Eine rein informative Unternehmensseite ohne Verkauf ist dagegen nicht ohne Weiteres erfasst; hier entscheidet der Einzelfall.

Wer prüft und was droht?

Zuständige Marktüberwachungsbehörden können Nachbesserung verlangen und bei Verstößen Sanktionen verhängen. Zusätzlich können Betroffene und Verbände Ansprüche geltend machen. Wer betroffen sein könnte, sollte frühzeitig den Stand der eigenen Angebote prüfen und Maßnahmen planen.

Unterschied zwischen öffentlichem und privatem Sektor

Für öffentliche Stellen gelten BITV 2.0 und die Web-Accessibility-Richtlinie mit Erklärungspflicht; für private Anbieter bestimmter Produkte und Dienstleistungen gilt das BFSG. Die technische Grundlage ist in beiden Fällen die Norm EN 301 549 bzw. in der Praxis die WCAG.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.

Quellen

• Richtlinie (EU) 2019/882 (European Accessibility Act)
• Barrierefreiheitsstärkungsgesetz (BFSG), Deutschland
• Barrierefreie-Informationstechnik-Verordnung (BITV 2.0), Deutschland
• ETSI/EN 301 549 – „Accessibility requirements for ICT products and services“
• U.S. Access Board – Section 508 Standards; U.S. Department of Justice – ADA Title II Rule (allgemeine Referenz, nicht Zeile für Zeile geprüft)

Assistive Technologien und Screenreader

Begriffe vorab

• Braillezeile: ein Gerät, das Bildschirmtext in tastbarer Brailleschrift ausgibt.
• Bildschirmlupe: vergrößert Bildschirmbereiche.
• Sprachsteuerung: Bedienung per gesprochenen Befehlen.
• Rotor / Elementliste: Screenreader-Funktion, die Überschriften, Links oder Formularfelder auflistet.

Assistive Technologien sind Hilfsmittel, die Menschen mit Behinderungen die Nutzung digitaler Inhalte ermöglichen. Wer für Barrierefreiheit entwickelt, sollte die wichtigsten Werkzeuge zumindest einmal ausprobiert haben.

Screenreader

Screenreader lesen Bildschirminhalte vor oder geben sie in Braille-Schrift aus. Verbreitete Programme:

• NVDA (NonVisual Desktop Access) – kostenlos, Windows.
• JAWS – kommerziell, Windows, in Unternehmen und Behörden verbreitet.
• VoiceOver – in macOS und iOS integriert.
• TalkBack – in Android integriert.

Der jährliche WebAIM Screen Reader Survey erhebt, welche Programme Nutzerinnen und Nutzer bevorzugen und in Kombination mit welchen Browsern; die Ergebnisse verschieben sich leicht von Jahr zu Jahr, weshalb die aktuelle Erhebung die verlässlichste Quelle ist.

Weitere Hilfsmittel

• Vergrößerungssoftware und Betriebssystem-Zoom für Sehbehinderungen.
• Schalter- und Augensteuerung für Menschen ohne Feinmotorik in Händen.
• Spracheingabe (z. B. Diktierfunktionen) als Alternative zur Tastatur.
• Browser-Erweiterungen für Lesehilfen, etwa angepasste Schriftarten oder Vorlesefunktionen.

Wie Screenreader Webseiten „sehen“

Screenreader nutzen nicht das visuelle Layout, sondern den Accessibility Tree, eine aus dem DOM abgeleitete Struktur mit Rollen, Namen und Zuständen jedes Elements. Fehlt einem Button ein zugänglicher Name, meldet der Screenreader nur „Schaltfläche“ ohne weitere Information.

Der beste erste Test: Maus beiseitelegen, Bildschirm ausschalten oder abdecken, und versuchen, die eigene Website allein mit Tastatur und Screenreader zu bedienen. Vieles fällt dabei sofort auf, was am Bildschirm unsichtbar bleibt.

Wie Screenreader-Nutzende navigieren

Sie lesen nicht Zeile für Zeile, sondern springen gezielt: von Überschrift zu Überschrift, von Link zu Link, zu Formularfeldern oder zu Seitenbereichen (Landmarks). Deshalb sind korrekte Überschriftenhierarchie, aussagekräftige Linktexte und Landmarks entscheidend. Ein Link „hier klicken“ sagt in einer Linkliste nichts; „Preisliste herunterladen“ dagegen schon.

Eine Seite aus Sicht eines Screenreaders

Der Screenreader liest: „Schaltfläche“ – ohne Namen, weil ein Icon-Button kein Textlabel hat. Mit einem zugänglichen Namen wie „Warenkorb öffnen“ wird daraus „Warenkorb öffnen, Schaltfläche“. Kleine Ergänzungen entscheiden, ob ein Element nutzbar ist.

Selbst ausprobieren

• Den eingebauten Screenreader des Betriebssystems aktivieren (VoiceOver, TalkBack) oder NVDA unter Windows.
• Eine eigene Seite mit Tastatur und ausgeschaltetem Bildschirm bedienen.
• Auf Stellen achten, an denen nichts oder Unverständliches angesagt wird.

Zum Selbermachen: ein Screenreader-Kurztest

1. Aktiviere VoiceOver (macOS/iOS) oder TalkBack (Android).
2. Rufe eine eigene Seite auf und navigiere nur über Überschriften.
3. Gehe ein Formular durch und achte darauf, ob jedes Feld verständlich benannt ist.
4. Notiere Stellen, an denen Unverständliches oder nichts angesagt wird.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.

Quellen

• WebAIM – „Screen Reader User Survey“ (jährliche Erhebung) (allgemeine Referenz, nicht Zeile für Zeile geprüft)
• W3C WAI – „Accessible Rich Internet Applications (WAI-ARIA)“, Abschnitt zum Accessibility Tree (allgemeine Referenz, nicht Zeile für Zeile geprüft)
• NV Access – Dokumentation zu NVDA; Apple – VoiceOver-Dokumentation (allgemeine Referenz, nicht Zeile für Zeile geprüft)

Tastaturbedienung und Fokus-Management

Begriffe vorab

• Fokus: das Element, das gerade per Tastatur bedient werden kann.
• Fokusreihenfolge: die Reihenfolge, in der Elemente per Tab angesprungen werden.
• Fokus-Falle: ein Bereich, aus dem man per Tastatur nicht herauskommt.

Nicht jede Nutzerin bedient eine Website mit der Maus: Menschen mit motorischen Einschränkungen, Screenreader-Nutzende und Power-User arbeiten häufig ausschließlich mit der Tastatur.

Die Grundregel (WCAG 2.1.1)

Jede Funktion muss über die Tastatur erreichbar sein, meist mit Tab (vorwärts), Umschalt+Tab (rückwärts), Enter/Leertaste (aktivieren) und den Pfeiltasten (innerhalb von Komponenten wie Menüs oder Tabs).

Keine Tastatur-Fallen

WCAG 2.1.2 verlangt, dass der Fokus eine Komponente immer wieder verlassen kann. Ein schlecht gebautes Modal, aus dem Tab nicht mehr herausführt, ist eine klassische Tastatur-Falle.

Sichtbarer Fokus (2.4.7 / 2.4.11)

Der Browser zeigt den Fokus standardmäßig mit einem Umriss (outline) an. Ein verbreiteter, aber problematischer Fehler ist *:focus { outline: none; } ohne Ersatz – damit verschwindet jede Orientierung für Tastaturnutzende. Seit WCAG 2.2 verlangt Kriterium 2.4.11 zusätzlich, dass der Fokusindikator nicht durch andere Inhalte verdeckt wird, etwa durch eine fixierte Kopfzeile.

Logische Reihenfolge

Die Tab-Reihenfolge sollte der visuellen und inhaltlichen Reihenfolge entsprechen (WCAG 2.4.3). Positives tabindex (z. B. tabindex="5") erzwingt eine eigene Reihenfolge und sollte vermieden werden; tabindex="0" reiht ein Element sinnvoll in die natürliche Reihenfolge ein, tabindex="-1" macht es nur programmatisch fokussierbar.

Skip-Links

Ein „Zum Inhalt springen“-Link am Anfang der Seite erlaubt es, die Navigation zu überspringen (WCAG 2.4.1 Bypass Blocks). Er ist oft visuell versteckt und erscheint erst beim Fokussieren.

<a class="skip-link" href="#main">Zum Inhalt springen</a>
<main id="main">…</main>

Schneller Praxistest: gesamte Seite nur mit Tab, Umschalt+Tab und Enter durchgehen. Jede Stelle, an der man nicht mehr weiterkommt oder den Fokus nicht mehr sieht, ist ein Fund.

Ein Beispiel: Dialog richtig bauen

Öffnet sich ein Dialog, muss der Fokus hineinwandern, und Tab darf nur innerhalb des Dialogs wechseln, solange er offen ist. Mit Escape lässt er sich schließen, danach kehrt der Fokus zum auslösenden Element zurück. Fehlt das, verliert man als Tastaturnutzer die Orientierung oder bleibt ungewollt hinter dem Dialog hängen.

Eigene Bedienelemente

Baut man statt eines echten Buttons ein anderes Element nach, muss man Fokussierbarkeit, Enter- und Leertastenbedienung, Rolle und Fokusanzeige selbst ergänzen. Natives HTML bringt all das mit – ein Grund mehr, es zu bevorzugen.

Typische Fehler

• Den Fokusrahmen per CSS ohne Ersatz entfernen.
• Elemente mit positivem tabindex in eine eigene Reihenfolge zwingen.
• Menüs, die nur bei Mausberührung aufklappen.
• Fixierte Kopfzeilen, die den fokussierten Inhalt verdecken.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.

Quellen

• WCAG 2.2 – Erfolgskriterien 2.1.1, 2.1.2, 2.4.1, 2.4.3, 2.4.7, 2.4.11
• W3C WAI-ARIA Authoring Practices Guide (APG) – Abschnitt „Keyboard Interface“ (allgemeine Referenz, nicht Zeile für Zeile geprüft)

Farben, Kontraste und Wahrnehmbarkeit

Begriffe vorab

• Kontrastverhältnis: Verhältnis der Helligkeiten von Vorder- und Hintergrundfarbe, von 1:1 (kein Kontrast) bis 21:1.
• Großer Text: nach WCAG ab etwa 18 pt bzw. 14 pt fett.
• Nicht-Text-Kontrast: Mindestkontrast für Bedienelemente und wichtige Grafiken (3:1).

Von angeborener Rot-Grün-Sehschwäche sind in Bevölkerungen nordeuropäischer Herkunft bis zu etwa 8 % der Männer und 0,5 % der Frauen betroffen; in anderen Bevölkerungen sind die Anteile geringer. Kontrast und Farbgestaltung betreffen aber auch Sehbehinderungen allgemein und die Nutzung bei grellem Licht.

Kontrastanforderungen nach WCAG 1.4.3 und 1.4.6

• AA, normaler Text: mindestens 4,5:1 Kontrastverhältnis zum Hintergrund.
• AA, großer Text (ab ca. 18pt bzw. 14pt fett): mindestens 3:1.
• AAA, normaler Text: mindestens 7:1; AAA, großer Text: mindestens 4,5:1.

Reiner Dekor-Text und rein dekorative Bilder sind von der Kontrastanforderung ausgenommen.

Farbe niemals als einziges Merkmal (WCAG 1.4.1)

Ein Pflichtfeld nur rot zu umrahmen oder einen Link nur farblich (ohne Unterstreichung oder anderes Merkmal) vom Fließtext abzuheben, schließt Menschen mit Farbfehlsichtigkeit aus. Zusätzliche Merkmale wie Symbole, Text („* Pflichtfeld“) oder Unterstreichung sind nötig.

Kontrast praktisch prüfen

Werkzeuge wie der WebAIM Contrast Checker oder die Kontrastprüfung in Browser-Entwicklertools berechnen aus zwei Farbwerten automatisch das Kontrastverhältnis und zeigen, welche WCAG-Stufe erreicht wird.

Weitere Wahrnehmbarkeits-Kriterien

• 1.4.4 Textgröße ändern: Text muss sich bis 200 % vergrößern lassen, ohne Inhalt oder Funktion zu verlieren.
• 1.4.10 Reflow: Inhalte müssen bis 400 % Zoom ohne horizontales Scrollen lesbar bleiben (mit definierten Ausnahmen wie Tabellen und Karten).
• 1.4.12 Textabstand: Nutzende dürfen Zeilenhöhe und Buchstabenabstand selbst vergrößern können, ohne dass Inhalte abgeschnitten werden.

Farbkontrast wird oft erst spät im Projekt geprüft, wenn das Designsystem schon feststeht. Kontraste gehören in die Farbpalette selbst, nicht nur in eine spätere Korrekturschleife.

Ein Beispiel: Grau auf Weiß

Ein mittleres Grau wie #999999 auf Weiß erreicht nur etwa 2,8:1 und besteht WCAG AA für normalen Text nicht. Ein dunkleres Grau wie #767676 erreicht gerade 4,5:1. Der Unterschied ist für viele Menschen mit normaler Sicht kaum auffällig, für Menschen mit Sehbehinderung oder bei Sonnenlicht aber entscheidend.

Auch Bedienelemente brauchen Kontrast

WCAG 2.1 verlangt zusätzlich mindestens 3:1 für Ränder von Eingabefeldern, Symbole und Zustände wie „ausgewählt“. Ein hellgrauer Feldrand auf weißem Grund kann das Formular unsichtbar machen.

Ein Ablauf für Designsysteme

1. Kontrast bereits beim Festlegen der Farbpalette prüfen.
2. Erlaubte Kombinationen dokumentieren (Text auf Hintergrund).
3. Helle und dunkle Darstellung getrennt prüfen.
4. Zustände wie Hover, Fokus und deaktiviert mitprüfen.

Zum Selbermachen: Kontraste prüfen

1. Wähle fünf Farbkombinationen deiner Website (Fließtext, Links, Buttons, Platzhalter, Fehlermeldung).
2. Prüfe sie mit einem Kontrastrechner.
3. Notiere, welche unter 4,5:1 (Text) bzw. 3:1 (Bedienelemente) liegen.
4. Passe die Palette an und teste in hellem und dunklem Modus erneut.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind. Die Kontrastwerte der Beispiele (#999999 ≈ 2,85:1, #767676 ≈ 4,54:1 auf Weiß) habe ich nachgerechnet.

Quellen

• WCAG 2.2 – Erfolgskriterien 1.4.1, 1.4.3, 1.4.4, 1.4.6, 1.4.10, 1.4.12
• WebAIM – „Contrast Checker“ und „Visual Disabilities: Color Blindness“ (allgemeine Referenz, nicht Zeile für Zeile geprüft)

Semantisches HTML und WAI-ARIA

Begriffe vorab

• Semantik: Bedeutung von Elementen, nicht nur ihr Aussehen.
• Rolle: Art des Elements (Button, Link, Tab).
• Zustand: veränderliche Eigenschaft wie „aufgeklappt“.
• Zugänglicher Name: der Name, den assistive Technik für ein Element ausgibt.

Die wirkungsvollste Barrierefreiheits-Maßnahme ist oft die unspektakulärste: korrektes, semantisches HTML.

Die erste ARIA-Regel

Der WAI-ARIA Authoring Practices Guide formuliert es als „No ARIA is better than Bad ARIA“ und als erste Regel: Wenn ein natives HTML-Element oder -Attribut mit der benötigten Semantik existiert, sollte es verwendet werden, statt ein generisches Element mit ARIA nachzubauen.

<!-- Gut -->
<button>Absenden</button>

<!-- Unnötig aufwendig und fehleranfällig -->
<div role="button" tabindex="0" onclick="..." onkeydown="...">Absenden</div>

Ein natives <button> ist automatisch per Tastatur fokussierbar und auslösbar und wird von Screenreadern korrekt als Schaltfläche angesagt. Der div muss all das händisch nachbilden und vergisst dabei leicht Details wie Leertaste als Auslöser.

Landmark-Rollen und Strukturelemente

HTML5-Elemente wie <header>, <nav>, <main>, <aside> und <footer> erzeugen automatisch ARIA-Landmarks, über die Screenreader-Nutzende direkt zwischen Seitenbereichen springen können. Überschriften (<h1> bis <h6>) müssen eine sinnvolle, nicht rein optisch motivierte Hierarchie bilden – sie sind die wichtigste Navigationshilfe für Screenreader-Nutzende.

Wann ARIA sinnvoll ergänzt

Für Komponenten, die HTML nicht nativ abdeckt (Tabs, Akkordeons, komplexe Comboboxen), definiert WAI-ARIA Rollen, Zustände und Eigenschaften:

• role – z. B. role="tablist", role="dialog".
• aria-expanded – zeigt an, ob ein Element auf- oder zugeklappt ist.
• aria-label / aria-labelledby – liefert einen zugänglichen Namen, wenn kein sichtbarer Text ausreicht.
• aria-live – meldet dynamische Inhaltsänderungen (z. B. eine Statusmeldung), ohne dass der Fokus wechseln muss.

Der WAI-ARIA Authoring Practices Guide (APG) liefert für Standardmuster wie Tabs, Akkordeons und Dialoge fertige Referenzimplementierungen inklusive Tastaturverhalten.

ARIA-Attribute ändern nur, was assistive Technologien ansagen – sie ändern nichts am tatsächlichen Verhalten. aria-hidden="true" auf einem fokussierbaren Element versteckt es zwar vor Screenreadern, per Tastatur bleibt es aber trotzdem erreichbar. Beides muss zusammenpassen.

Ein Beispiel: Akkordeon

Ein Akkordeon besteht aus einer Schaltfläche, die einen Bereich auf- und zuklappt. Mit einem echten <button>, dem Attribut aria-expanded (wahr/falsch) und aria-controls, das auf den Bereich verweist, erfährt ein Screenreader-Nutzer: „Versand, Schaltfläche, eingeklappt“. Das Zustandsattribut muss beim Klick mit dem tatsächlichen Zustand aktualisiert werden, sonst sagt die Seite etwas Falsches an.

Der Namensbaustein

Ein zugänglicher Name entsteht in dieser Reihenfolge aus sichtbarem Text, aria-labelledby, aria-label oder dem Label. Sichtbarer Text ist der beste Name, weil er mit dem übereinstimmt, was alle sehen; Sprachsteuerungsnutzer sprechen, was sie sehen.

Heading- und Landmark-Gerüst

• Genau eine h1 je Seite, darunter logisch gestaffelte Überschriften.
• Jeder Hauptbereich in ein passendes Landmark (main, nav, footer).
• Mehrere Navigationen durch Namen unterscheiden.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.

Quellen

• W3C – WAI-ARIA 1.2 Spezifikation und „WAI-ARIA Authoring Practices Guide (APG)“ (allgemeine Referenz, nicht Zeile für Zeile geprüft)
• WCAG 2.2 – Erfolgskriterium 4.1.2 „Name, Rolle, Wert“
• MDN Web Docs – „ARIA“ und „HTML-Elemente nach Kategorie“ (Referenz zu semantischem HTML) (allgemeine Referenz, nicht Zeile für Zeile geprüft)

Barrierefreie Formulare und Fehlermeldungen

Begriffe vorab

• Label: die sichtbare Beschriftung eines Formularfelds.
• Fehlermeldung: Hinweis, was falsch ist und wie es behoben wird.
• Autovervollständigung: Vorschläge des Browsers anhand gespeicherter Daten.

Formulare sind eine der fehleranfälligsten Stellen für Barrierefreiheit, weil hier Eingabe, Beschriftung, Fehlerprüfung und Fokus zusammenspielen müssen.

Jedes Feld braucht ein echtes Label

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" required>

Ein <label> mit passendem for/id-Paar verknüpft Beschriftung und Feld fest. Ein bloßer Platzhaltertext (placeholder) ist kein Ersatz: Er verschwindet bei der Eingabe, hat oft zu wenig Kontrast und wird von manchen Screenreadern nicht zuverlässig vorgelesen (WCAG 3.3.2, 1.3.1).

Fehler klar benennen

WCAG 3.3.1 verlangt, dass Fehler in Text identifiziert und beschrieben werden, nicht nur farblich markiert. Eine gute Fehlermeldung nennt das betroffene Feld und erklärt, was zu tun ist:

<p id="email-error" role="alert">E-Mail-Adresse: Bitte ein gültiges Format wie name@beispiel.de eingeben.</p>
<input type="email" id="email" aria-describedby="email-error" aria-invalid="true">

aria-describedby verknüpft die Fehlermeldung mit dem Feld, aria-invalid="true" signalisiert den fehlerhaften Zustand, und role="alert" (bzw. eine aria-live-Region) sorgt dafür, dass Screenreader die neue Meldung automatisch ansagen.

Gruppierung und Pflichtfelder

<fieldset> mit <legend> gruppiert zusammengehörige Felder, etwa eine Reihe von Radiobuttons, und gibt der Gruppe eine gemeinsame Beschriftung. Pflichtfelder sollten nicht nur farblich, sondern auch textlich oder mit einem Symbol plus Erläuterung gekennzeichnet sein (siehe Lektion zu Farben).

Ausfüllhilfen (WCAG 2.2, Kriterium 1.3.5 und 3.3.7/3.3.8)

WCAG empfiehlt, den Zweck von Eingabefeldern zusätzlich maschinenlesbar zu machen, etwa über autocomplete-Attribute (autocomplete="email", autocomplete="tel"), damit Browser und Hilfsmittel beim Ausfüllen unterstützen können. Neuere WCAG-2.2-Kriterien verlangen außerdem, dass bereits bekannte Informationen nicht erneut abgefragt werden müssen und dass Authentifizierung nicht allein auf einem Gedächtnis- oder Rechentest beruht, wenn es zugänglichere Alternativen gibt.

Praxistest: das komplette Formular nur mit der Tastatur ausfüllen und bewusst einen Fehler erzeugen (z. B. ungültige E-Mail). Wird die Fehlermeldung vom Screenreader angesagt, und ist danach klar, welches Feld korrigiert werden muss?

Ein Beispiel für eine gute Fehlerbehandlung

Nach dem Absenden erscheint oben eine Zusammenfassung: „2 Fehler: E-Mail-Adresse fehlt, Postleitzahl ungültig.“ Die Einträge sind Links zu den Feldern. Direkt am Feld steht eine verständliche Meldung („Bitte eine fünfstellige Postleitzahl eingeben“). Der Fokus springt zur Zusammenfassung, die Screenreader automatisch ansagen. So erfährt jede Person, was los ist und wo.

Verständlich statt technisch

Meldungen wie „Fehler 27“ oder „Ungültige Eingabe“ helfen nicht. Besser: sagen, was erwartet wird, möglichst mit Beispiel. Die Anweisung vor dem Feld zu nennen („Format: TT.MM.JJJJ“) ist hilfreicher, als erst danach zu beanstanden.

Weitere Stolpersteine

• Automatisches Weiterspringen zwischen Feldern.
• Zeitlimits ohne Verlängerungsmöglichkeit.
• CAPTCHAs ohne zugängliche Alternative.
• Pflichtangaben nur farblich gekennzeichnet.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.

Quellen

• WCAG 2.2 – Erfolgskriterien 1.3.1, 1.3.5, 3.3.1, 3.3.2, 3.3.7, 3.3.8
• W3C WAI-ARIA APG – Muster „Form“ und „Alert“ (allgemeine Referenz, nicht Zeile für Zeile geprüft)
• WHATWG HTML Living Standard – Abschnitt zu autocomplete

Testen: automatisiert, manuell und mit echten Nutzenden

Begriffe vorab

• Audit: eine strukturierte Prüfung gegen festgelegte Kriterien.
• Regressionstest: wiederholte Prüfung, ob Änderungen alte Probleme zurückbringen.
• Nutzertest: Test mit echten Nutzenden, hier auch mit Menschen mit Behinderungen.

Barrierefreiheit lässt sich nicht allein durch ein Tool „grün“ testen. Verlässliche Prüfungen kombinieren drei Ebenen.

1. Automatisierte Tests

Werkzeuge wie axe DevTools (Deque Systems), WAVE (WebAIM) und die Accessibility-Prüfung in Lighthouse (Google) finden automatisch einen Teil der WCAG-Verstöße, etwa fehlende Alternativtexte, fehlende Formular-Labels oder zu geringen Kontrast.

Automatisierte Tools finden nur einen Teil der Probleme. Belegt sind zwei Messungen: In einem Test des britischen Government Digital Service fand das beste von 13 Werkzeugen 40 % der 142 bekannten Barrieren einer Testseite; Deque ermittelte in über 2.000 Audits, dass automatisierte Tests etwa 57 % der gefundenen Probleme nach Anzahl erfassten (nach Anzahl, weil sich häufige Fehler wie fehlende Alternativtexte oder zu geringer Kontrast leicht automatisch finden lassen). Sinnvolle Lesereihenfolge, ob ein Alternativtext inhaltlich passt oder ob eine Tastaturbedienung sich wirklich sinnvoll anfühlt, kann kein automatisches Werkzeug abschließend beurteilen.

2. Manuelle Expertenprüfung

Dazu gehören die Praxistests aus den vorigen Lektionen: reine Tastaturbedienung, Test mit einem echten Screenreader (NVDA oder VoiceOver reichen für den Einstieg), Kontrastprüfung und Zoom-Test bis 400 %. Eine strukturierte Grundlage bietet die WCAG-EM (Website Accessibility Conformance Evaluation Methodology) des W3C, die beschreibt, wie eine repräsentative Stichprobe von Seiten systematisch bewertet wird.

3. Tests mit Menschen mit Behinderungen

Die verlässlichste, aber aufwendigste Ebene: echte Nutzende mit unterschiedlichen Behinderungen und ihren gewohnten Hilfsmitteln testen lassen. Nur so zeigen sich Probleme, die weder automatisierte Tools noch Experten-Heuristiken zuverlässig aufdecken.

Der WebAIM Million

WebAIM analysiert jährlich automatisiert die Startseiten der eine Million meistbesuchten Websites („WebAIM Million“). Im Bericht 2025 hatten 94,8 % der untersuchten Startseiten automatisiert erkennbare WCAG-2-Verstöße (2024: 95,9 %), im Durchschnitt 51 Fehler je Seite. Am häufigsten waren zu geringer Textkontrast (79,1 %), fehlende Alternativtexte (55,5 %), fehlende Formularbeschriftungen (48,2 %), leere Links (45,4 %), leere Buttons (29,5 %) und fehlende Sprachangabe (15,8 %). Die Zahlen ändern sich jährlich; maßgeblich ist der jeweils aktuelle Bericht.

Barrierefreiheitserklärung

Öffentliche Stellen in der EU müssen nach der Web-Accessibility-Richtlinie (EU) 2016/2102 (in Deutschland über BITV 2.0 umgesetzt) eine öffentlich zugängliche Erklärung zur Barrierefreiheit veröffentlichen, die den Grad der Konformität, bekannte Ausnahmen und einen Kontaktweg für Feedback nennt.

Ein praktikabler Einstieg in ein bestehendes Projekt: automatisierte Prüfung als Basis, danach die wichtigsten Nutzerwege (Login, Bestellung, Kontaktformular) manuell mit Tastatur und Screenreader durchgehen, priorisiert nach Schweregrad und Häufigkeit der Nutzung beheben.

Ein Prüfplan für ein kleines Projekt

1. Automatische Prüfung der wichtigsten Vorlagen (Start, Formular, Übersicht).
2. Tastaturtest der zentralen Abläufe.
3. Screenreader-Kurztest mit einem Bildschirmleseprogramm.
4. Zoom- und Kontrasttest bis 400 % und in hellem wie dunklem Modus.
5. Dokumentation: Befunde mit Schweregrad, betroffener Seite und Lösungsvorschlag.

Barrierefreiheit im Entwicklungsablauf

Automatische Prüfungen lassen sich in die laufende Entwicklung einbinden und verhindern, dass bekannte Fehler wiederkehren. Sie ersetzen manuelle Tests nicht, fangen aber viele einfache Fehler früh ab.

Befunde priorisieren

• Kritisch: Ein Ablauf lässt sich für eine Gruppe gar nicht durchführen.
• Hoch: erhebliche Erschwernis in wichtigen Abläufen.
• Mittel/Gering: Komfort- und Randprobleme.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.

Quellen

• W3C WAI – „Website Accessibility Conformance Evaluation Methodology (WCAG-EM)“ (allgemeine Referenz, nicht Zeile für Zeile geprüft)
• WebAIM – „The WebAIM Million“ (jährlicher Bericht)
• UK Government Digital Service – Vergleichstest von 13 automatisierten Prüfwerkzeugen; Deque – „The Automated Accessibility Coverage Report“
• Deque Systems – axe-core-Dokumentation; WebAIM – WAVE-Dokumentation; Google – Lighthouse-Dokumentation (allgemeine Referenz, nicht Zeile für Zeile geprüft)
• Richtlinie (EU) 2016/2102 über den barrierefreien Zugang zu Websites öffentlicher Stellen