Die 4 WCAG-Prinzipien: Perceivable, Operable, Understandable, Robust

Die WCAG sind nicht als willkürliche Checkliste konzipiert, sondern folgen einer klaren Logik: Damit ein Mensch ein digitales Angebot nutzen kann, muss er es wahrnehmen, bedienen und verstehen können – und die Technik muss robust genug sein, um mit verschiedenen Geräten und assistiven Technologien zu funktionieren. Diese vier Prinzipien helfen, Barrierefreiheitsanforderungen einzuordnen und Prioritäten zu setzen.

Perceivable – Wahrnehmbar

Inhalte müssen so präsentiert werden, dass alle Nutzer sie wahrnehmen können – unabhängig davon, ob sie sehen, hören oder tasten. Konkret bedeutet das:
• Alt-Texte für Bilder (WCAG 1.1.1): Blinde Nutzer können Bilder nicht sehen – der Alt-Text ist ihre Alternative.
• Untertitel und Transkripte für Audio/Video (WCAG 1.2): Gehörlose Nutzer brauchen Textversionen.
• Kontraste (WCAG 1.4.3): Text muss sich ausreichend vom Hintergrund abheben (mindestens 4,5:1).
• Reflow (WCAG 1.4.10): Inhalte müssen bei 400 % Zoom ohne horizontales Scrollen nutzbar sein.
• Keine Information nur über Farbe (WCAG 1.4.1): Farbenblinde Nutzer brauchen zusätzliche Hinweise.

Operable – Bedienbar

Alle Funktionen müssen mit verschiedenen Eingabemethoden bedienbar sein – nicht nur mit der Maus. Die wichtigsten Anforderungen:
• Tastaturbedienbarkeit (WCAG 2.1.1): Jede Funktion muss per Tastatur erreichbar sein.
• Keine Tastaturfallen (WCAG 2.1.2): Der Fokus darf nicht in einem Element „gefangen" werden.
• Genügend Zeit (WCAG 2.2.1): Zeitlimits müssen verlängerbar sein.
• Keine Anfälle (WCAG 2.3.1): Kein Inhalt darf mehr als dreimal pro Sekunde blitzen.
• Navigation (WCAG 2.4): Skip-Links, aussagekräftige Seitentitel, sichtbarer Fokus.
• Zeigegeräte (WCAG 2.5): Touch-Gesten müssen Alternativen haben, Klickziele groß genug sein.

Understandable – Verständlich

Inhalte und Bedienung müssen verständlich sein – sowohl sprachlich als auch in der Interaktion:
• Sprache des Dokuments (WCAG 3.1.1): Die Sprache muss im HTML-lang-Attribut angegeben sein, damit Screenreader korrekt vorlesen.
• Sprache einzelner Abschnitte (WCAG 3.1.2): Fremdsprachige Passagen mit lang-Attribut kennzeichnen.
• Konsistente Navigation (WCAG 3.2.3): Navigation bleibt auf allen Seiten gleich.
• Konsistente Benennung (WCAG 3.2.4): Gleiche Funktionen tragen überall denselben Namen.
• Fehlererkennung (WCAG 3.3.1): Fehler in Formularen müssen identifiziert und beschrieben werden.
• Fehlervorbeugung (WCAG 3.3.4): Bei rechtlichen/finanziellen Transaktionen: Eingaben prüfbar, korrigierbar, bestätigbar.

Robust

Inhalte müssen robust genug sein, um von verschiedenen Browsern, Geräten und assistiven Technologien interpretiert werden zu können:
• Parsing (WCAG 4.1.1, in WCAG 2.2 als obsolet markiert): Valides HTML ohne doppelte IDs oder fehlende Tags.
• Name, Role, Value (WCAG 4.1.2): Alle UI-Komponenten müssen einen programmatisch erkennbaren Namen und Zustand haben.
• Status Messages (WCAG 4.1.3): Statusmeldungen (z. B. „Artikel in den Warenkorb gelegt") müssen assistiven Technologien mitgeteilt werden, ohne den Fokus zu verschieben (aria-live).
Robustheit ist das technische Fundament: Ohne sauberen, semantischen Code können assistive Technologien die anderen drei Prinzipien nicht umsetzen.

POUR in der Praxis: Priorisierung

Nicht alle POUR-Verstöße wiegen gleich schwer. Ein pragmatischer Ansatz:
1. Perceivable: Alt-Texte und Kontraste sind die häufigsten und am einfachsten zu behebenden Barrieren.
2. Operable: Tastaturbedienbarkeit ist kritisch – ohne sie ist die Seite für viele Nutzer komplett unbenutzbar.
3. Understandable: Sprache und Formulare sind oft schnell zu fixen (lang-Attribut, Labels).
4. Robust: Erfordert saubere Coding-Practices, die langfristig eingeplant werden sollten.
bf-check ordnet jeden gefundenen Verstoß einem POUR-Prinzip zu, damit Sie gezielt priorisieren können.