Die vier Prinzipien der WCAG (POUR)

Die vier Prinzipien der WCAG heißen wahrnehmbar, bedienbar, verständlich und robust – im Englischen Perceivable, Operable, Understandable, Robust, kurz POUR. Sie fordern: Inhalte müssen mit mindestens einem Sinn wahrnehmbar sein, mit jeder Eingabemethode bedienbar, in Sprache und Verhalten verständlich – und technisch so robust, dass auch Hilfstechnologien wie Screenreader sie zuverlässig interpretieren können.

Unter diesen vier Prinzipien ist die gesamte WCAG aufgehängt: 13 Richtlinien konkretisieren sie, 86 testbare Erfolgskriterien (Stand WCAG 2.2) machen sie messbar. Ich finde diese Vierteilung enorm hilfreich, weil sie aus einer unübersichtlichen Liste ein Denkraster macht. Wenn ich eine Komponente prüfe, gehe ich sie der Reihe nach durch: Kann man es wahrnehmen, bedienen, verstehen – und ist es technisch robust? Vier Fragen, die erstaunlich weit tragen, beim Bauen genauso wie beim Prüfen.

Das Wichtigste in Kürze

• POUR steht für Perceivable, Operable, Understandable, Robust – auf Deutsch wahrnehmbar, bedienbar, verständlich, robust.
• Die vier Prinzipien sind die oberste Ebene der WCAG. Darunter hängen 13 Richtlinien und 86 Erfolgskriterien (Stand WCAG 2.2, Oktober 2023).
• Die Reihenfolge ist eine Kette von Voraussetzungen: Was nicht wahrnehmbar ist, kann niemand bedienen; was niemand versteht, nützt auch bedienbar nichts.
• Prinzipien und Richtlinien sind nicht prüfbar. Testbar sind nur die Erfolgskriterien – und nur sie entscheiden über Konformität nach A, AA oder AAA.
• Die Prinzipien haben alle Versionssprünge unverändert überstanden: WCAG 2.0 (2008), 2.1 (2018) und 2.2 (2023) hängen jedes neue Kriterium in dieselbe Struktur.
• Als Prüf-Raster im Alltag: vier Fragen an jedes Bauteil – wahrnehmbar? bedienbar? verständlich? robust? Ein Icon-Button ohne Namen fällt schon bei Frage eins durch.
• Eine grobe Zuordnung zu Nutzergruppen (wahrnehmbar → Sehen und Hören, bedienbar → Motorik, verständlich → Kognition, robust → Hilfstechnik) hilft beim Einstieg, greift aber zu kurz: Jedes Prinzip wirkt quer durch alle Gruppen.

Warum genau diese vier?

Die Vierteilung ist kein Zufall, sondern eine bewusste Kurskorrektur. Die erste Fassung der Richtlinien, WCAG 1.0 von 1999, war im Kern eine Sammlung von HTML-Techniken – brauchbar, aber eng an die Webtechnik ihrer Zeit gebunden. Mit WCAG 2.0 (2008) hat das W3C die Perspektive gedreht: Statt zu fragen „Welche Technik ist einzusetzen?“, fragt der Standard seitdem „Was muss ein Mensch mit dem Inhalt tun können?“ Die Antwort sind die vier Prinzipien, und sie haben alle Versionssprünge unverändert überstanden – auch WCAG 2.1 (2018) und WCAG 2.2 (2023) hängen jedes neue Kriterium in dieselbe Struktur.

Die Logik dahinter ist eine Kette von Voraussetzungen. Damit jemand eine Website nutzen kann, muss der Inhalt erstens seine Sinne erreichen (wahrnehmbar), zweitens muss er alle Funktionen auslösen können (bedienbar), drittens muss er Inhalt und Bedienung begreifen (verständlich) – und viertens muss seine Technik, vom alten Browser bis zur Braillezeile, das alles korrekt transportieren (robust). Reißt ein Glied, reißt die Kette: Eine Seite mit perfekten Kontrasten, die sich nicht per Tastatur bedienen lässt, ist genauso unzugänglich wie eine tastaturfreundliche Seite ohne Alt-Texte. Das W3C beschreibt diese Grundidee in seinen Accessibility Principles.

Grob lassen sich die Prinzipien auch Nutzergruppen zuordnen: Wahrnehmbarkeit betrifft vor allem Menschen mit Seh- oder Hörbeeinträchtigung, Bedienbarkeit Menschen mit motorischen Einschränkungen, Verständlichkeit Menschen mit kognitiven Einschränkungen, Robustheit alle, die Hilfstechnik einsetzen. Aber Vorsicht mit dieser Schablone – die Prinzipien wirken quer durch alle Gruppen: Untertitel (wahrnehmbar) helfen Gehörlosen ebenso wie Pendlern ohne Kopfhörer, und klare Fehlermeldungen (verständlich) helfen schlicht allen.

Randnotiz – POUR ist wörtlich ein Merkwort. Die Anfangsbuchstaben der vier englischen Prinzipien ergeben bewusst das Wort „pour“ (gießen) – eine Eselsbrücke, die sich durchgesetzt hat. Im deutschen Sprachraum kursiert gelegentlich „WBVR“, aber gemerkt hat sich das niemand.

Prinzip 1: Wahrnehmbar

Informationen und Bedienelemente müssen so dargeboten werden, dass Nutzer sie mit mindestens einem Sinn wahrnehmen können – wer nicht sehen kann, braucht eine hörbare oder ertastbare Alternative, wer nicht hören kann, eine sichtbare. Vier Richtlinien füllen das Prinzip aus:

• 1.1 Textalternativen: Jeder Nicht-Text-Inhalt braucht eine Textentsprechung, denn nur Text lässt sich vorlesen, vergrößern oder in Brailleschrift übersetzen – siehe Alt-Texte schreiben.
• 1.2 Zeitbasierte Medien: Video und Audio brauchen Untertitel, Transkripte und Audiodeskription, je nach Medientyp und Konformitätsstufe.
• 1.3 Anpassbar: Struktur und Beziehungen – Überschriften, Listen, Tabellen, Label – müssen im Code stecken, nicht nur im Aussehen. Dann bleibt der Inhalt auch bei Zoom, eigenem Stylesheet oder Screenreader-Ausgabe erhalten.
• 1.4 Unterscheidbar: Ausreichende Farbkontraste, Farbe nie als alleiniges Signal, Text bis 200 % vergrößerbar, Inhalte reflow-fähig bei 320 Pixel Breite.

So scheitert es in der Praxis: Ein Online-Shop markiert fehlerhafte Pflichtfelder ausschließlich mit rotem Rahmen und bettet die Umsatzgrafik als Bild ohne Alt-Text ein. Für farbenblinde Nutzer sind die Fehler unsichtbar, für blinde Nutzer ist die Grafik ein stummes Objekt – dieselbe Information existiert, aber sie erreicht ihre Sinne nicht.

Ein typischer Verstoß gegen 1.3 sieht harmlos aus:

<!-- Falsch: sieht aus wie eine Überschrift, ist aber keine -->
<p><strong>Lieferung und Versand</strong></p>

<!-- Richtig: echte Überschrift, die Screenreader anspringen können -->
<h2>Lieferung und Versand</h2>

Optisch identisch – aber nur die zweite Variante taucht in der Überschriften-Hierarchie auf, über die sich Screenreader-Nutzer eine Seite erschließen.

Prinzip 2: Bedienbar

Bedienoberfläche und Navigation müssen benutzbar sein – mit jeder Eingabeart, nicht nur mit der Maus. Fünf Richtlinien gehören dazu:

• 2.1 Per Tastatur zugänglich: Alles muss per Tastatur erreichbar und bedienbar sein, ohne Fokusfallen, aus denen man nicht mehr herauskommt.
• 2.2 Ausreichend Zeit: Zeitlimits sind verlängerbar oder abschaltbar; bewegte Inhalte lassen sich pausieren. Sonst verlieren langsam tippende Nutzer Formulareingaben oder ganze Warenkörbe.
• 2.3 Anfälle und physische Reaktionen: Kein Inhalt darf öfter als dreimal pro Sekunde blitzen – schnelles Flackern kann bei fotosensibler Epilepsie Anfälle auslösen.
• 2.4 Navigierbar: Skip-Links, aussagekräftige Seitentitel, sichtbarer Fokus, eine logische Fokusreihenfolge und Linktexte, die ihr Ziel verraten.
• 2.5 Eingabemodalitäten: Auch Touch, Stift und Sprachsteuerung zählen – mit ausreichender Zielgröße (24 × 24 CSS-Pixel als AA-Minimum) und Alternativen zu Drag-Gesten, beides Neuerungen aus WCAG 2.2.

So scheitert es in der Praxis: Eine Hauptnavigation öffnet ihre Unterpunkte nur bei Mouse-Hover. Wer per Tastatur, Switch oder Sprachsteuerung unterwegs ist, erreicht die Unterseiten schlicht nie – die Seiten existieren, sind aber unbedienbar. Die zweite Klassikerin: ein Cookie-Banner, das den Fokus einfängt und per Tastatur nicht schließbar ist. Damit ist die gesamte Website hinter einer Fokusfalle verriegelt.

Prinzip 3: Verständlich

Informationen und Bedienung müssen verständlich sein – die Inhalte ebenso wie das Verhalten der Oberfläche. Drei Richtlinien konkretisieren das:

• 3.1 Lesbar: Die Sprache der Seite ist per lang ausgezeichnet (fremdsprachige Passagen ebenfalls), ungewöhnliche Begriffe und Abkürzungen werden erklärt, die Sprache bleibt so klar wie möglich – wichtig gerade für Menschen mit kognitiven Einschränkungen.
• 3.2 Vorhersehbar: Konsistente Navigation über alle Seiten, keine überraschenden Kontextwechsel: Fokus oder Eingabe allein dürfen keine neue Seite laden.
• 3.3 Hilfestellung bei der Eingabe: Verknüpfte Labels, verständliche Fehlermeldungen, faire Validierung – und seit WCAG 2.2 auch: keine Rätsel beim Login und keine doppelte Abfrage bereits gemachter Angaben.

So scheitert es in der Praxis: Eine Länderauswahl lädt beim Ändern sofort die Länderseite neu. Screenreader- und Tastaturnutzer, die die Liste mit den Pfeiltasten erkunden, werden beim ersten Tastendruck auf eine andere Seite geworfen – ein klassischer Verstoß gegen 3.2. Und wenn das Formular danach nur „Fehler 422“ meldet, statt zu sagen, welches Feld warum betroffen ist, scheitert auch 3.3.

<!-- Falsch: Sprache fehlt – Screenreader raten die Aussprache -->
<html>

<!-- Richtig: deutsche Aussprache, englisches Zitat ausgezeichnet -->
<html lang="de">
  …
  <blockquote lang="en">Content is king.</blockquote>
</html>

Prinzip 4: Robust

Inhalte müssen robust genug sein, um von unterschiedlicher Software – heutigen wie künftigen Browsern und Hilfsmitteln – zuverlässig interpretiert zu werden. Hier steht nur eine einzige Richtlinie:

• 4.1 Kompatibel: Alle Bedienelemente liefern Name, Rolle und Wert an die Zugänglichkeits-Schnittstellen des Browsers – natives semantisches HTML zuerst, ARIA nur wo nötig, siehe die erste Regel von ARIA. Statusmeldungen (etwa „3 Artikel im Warenkorb“) werden so ausgezeichnet, dass Screenreader sie mitbekommen, ohne dass der Fokus dorthin springt.

Dass unter „Robust“ nur eine Richtlinie hängt, täuscht übrigens über ihr Gewicht hinweg: Das alte Kriterium 4.1.1 (Syntaxanalyse) wurde in WCAG 2.2 gestrichen, weil moderne Browser Parsing-Fehler selbst reparieren – geblieben ist der Kern „Name, Rolle, Wert“, und an dem scheitern selbstgebaute Komponenten reihenweise.

So scheitert es in der Praxis: Ein Custom-Dropdown aus verschachtelten <div>-Elementen sieht aus wie ein Auswahlfeld, meldet dem Screenreader aber weder Rolle („Auswahlfeld“) noch Wert („Deutschland ausgewählt“) – und liegt für die Tastatur gar nicht erst im Fokuspfad.

<!-- Falsch: keine Rolle, kein Name, nicht fokussierbar -->
<div class="btn" onclick="submitForm()">
  <img src="/img/senden.svg">
</div>

<!-- Richtig: Rolle, Name, Fokus und Tastatur gratis -->
<button type="submit">Absenden</button>

Robustheit ist das Prinzip, das am stärksten mit semantischem Markup zusammenhängt – und für mich der schönste Beleg dafür, dass sauberer Code und Barrierefreiheit dieselbe Sache sind.

Prinzip, Richtlinie, Erfolgskriterium, Stufe – wer ist wer?

Die WCAG ist streng hierarchisch aufgebaut, und die Nummern verraten die Position: Im Kriterium 1.4.3 Kontrast (Minimum) steht die 1 für das Prinzip (wahrnehmbar), die 4 für die Richtlinie (unterscheidbar), die 3 für das Kriterium selbst.

Konformität wird ausschließlich auf Kriterien-Ebene gemessen: 31 Kriterien haben Stufe A, 24 weitere Stufe AA – zusammen die 55 Kriterien, auf die es rechtlich ankommt, denn Gesetze wie BFSG und BITV verlangen über die EN 301 549 die Stufen A und AA. Was die Stufen genau bedeuten, erklärt die Seite Konformitätsstufen; alle A/AA-Kriterien stehen, nach den vier Prinzipien geordnet, in der Kriterien-Referenz.

Unterhalb der Kriterien listet das W3C noch Techniken – konkrete Umsetzungsrezepte, unterteilt in ausreichende Techniken, empfohlene Techniken und dokumentierte Fehler. Sie sind hilfreich, aber nicht normativ: Verbindlich ist allein das Erfolgskriterium.

POUR als Prüf-Raster: zwei Beispiele durchgespielt

Der eigentliche Wert von POUR liegt für mich im Prüfen: Statt 55 Kriterien abzuhaken, stelle ich an jede Komponente vier Fragen. Fällt eine Antwort negativ aus, weiß ich sofort, in welchem Kapitel der WCAG ich nachschlagen muss.

Beispiel 1: Ein Icon-Button

<button type="submit" class="icon-button">
  <svg aria-hidden="true" viewBox="0 0 24 24">…</svg>
  <span class="visually-hidden">Suchen</span>
</button>

Das SVG ist per aria-hidden versteckt, der sichtbare Text übernimmt den Namen – vier Fragen, vier Häkchen.

Beispiel 2: Ein E-Mail-Feld im Formular

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email"
       autocomplete="email" aria-describedby="email-error">
<p id="email-error">Bitte im Format name@beispiel.de eingeben.</p>

Randnotiz – Konformität ist nicht Benutzbarkeit. WebAIM weist zu Recht darauf hin, dass eine Seite technisch alle Kriterien erfüllen und trotzdem mühsam zu benutzen sein kann – etwa mit korrekten, aber nichtssagenden Alt-Texten. POUR hilft auch hier: Die vier Fragen zielen auf Menschen, nicht auf Häkchen.

Häufige Fehler

• Farbe als einziges Signal. Fehlerfelder nur rot umranden, Links nur farblich absetzen – verstößt gegen 1.4.1 und schließt farbenblinde Nutzer aus. Immer ein zweites Merkmal ergänzen: Icon, Text, Unterstreichung.
• Placeholder statt Label. Der Platzhalter verschwindet beim Tippen und hat meist zu wenig Kontrast – ein Verstoß gegen mehrere Prinzipien gleichzeitig (wahrnehmbar, verständlich, robust).
• Hover-only-Bedienung. Menüs, Tooltips oder Lösch-Buttons, die nur bei Mauskontakt erscheinen, sind für Tastatur- und Touch-Nutzer unsichtbar und unbedienbar.
• Divs mit Klick-Handler statt Buttons. Sieht gleich aus, verliert aber Rolle, Name, Fokus und Tastaturbedienung – der häufigste Robustheits-Fehler überhaupt.
• Automatische Kontextwechsel. Ein <select>, das beim Ändern sofort navigiert, oder ein Fokus, der ungefragt Overlays öffnet, verletzt die Vorhersehbarkeit (3.2).
• Prinzipien mit Kriterien verwechseln. „Unsere Seite ist wahrnehmbar“ ist keine prüfbare Aussage – gemessen wird immer an den Erfolgskriterien samt Stufe.
• Nur das Lieblingsprinzip prüfen. Perfekte Kontraste nützen nichts, wenn die Tastaturbedienung fehlt. POUR heißt: alle vier Fragen stellen, jedes Mal.

Häufige Fragen

Wofür steht POUR?

Für die englischen Namen der vier Prinzipien: Perceivable, Operable, Understandable, Robust – wahrnehmbar, bedienbar, verständlich, robust. Das Akronym ergibt bewusst das englische Wort „pour“ und dient als Merkhilfe.

Sind die vier Prinzipien gleich wichtig?

Im Prinzip ja – eine Seite kann an jedem von ihnen scheitern, und ein einziges gerissenes Kettenglied macht den Inhalt unzugänglich. In der Praxis fallen die meisten Probleme bei „wahrnehmbar“ (Kontraste, Alt-Texte) und „bedienbar“ (Tastatur) auf. Dort schaue ich zuerst.

Wie viele Richtlinien und Kriterien hängen an den Prinzipien?

In WCAG 2.2 sind es 13 Richtlinien und 86 Erfolgskriterien: vier Richtlinien unter „wahrnehmbar“, fünf unter „bedienbar“, drei unter „verständlich“ und eine unter „robust“. Von den Kriterien haben 31 die Stufe A und 24 die Stufe AA – diese 55 sind der übliche Prüfumfang.

Wo finde ich die konkreten Anforderungen?

In den Erfolgskriterien unter den Prinzipien – alle A/AA-Kriterien stehen, nach den vier Prinzipien geordnet, in der Kriterien-Referenz. Welche Stufe (A/AA/AAA) jeweils gilt, erklärt die Seite Konformitätsstufen.

Gilt POUR nur für Websites?

Die WCAG ist für Webinhalte geschrieben, aber die Prinzipien sind bewusst technikneutral formuliert. Die EN 301 549 überträgt die Anforderungen auf Software, Apps und Dokumente, und das W3C beschreibt mit WCAG2ICT, wie sich die Kriterien auf Nicht-Web-Technik anwenden lassen. Die vier Fragen kannst du also genauso an eine native App oder ein PDF stellen.

Hilft POUR auch ohne tiefe WCAG-Kenntnis?

Gerade dann. Die vier Fragen sind ein guter Einstieg, lange bevor man jedes Kriterium kennt – sie schärfen den Blick für das Wesentliche. Und wer später tiefer einsteigt, hat mit den Prinzipien bereits die Landkarte im Kopf, in die sich jedes Kriterium einsortiert.

Fazit

POUR – wahrnehmbar, bedienbar, verständlich, robust – ist das Fundament der WCAG und ein Denkraster, das jede Prüfung vereinfacht: Vier Fragen an jede Komponente decken erstaunlich viel ab, und die Nummern der Kriterien zeigen immer zurück auf ihr Prinzip. Wer die Logik der Kette verstanden hat – wahrnehmen, bedienen, verstehen, transportieren –, liest die WCAG nicht mehr als Liste, sondern als System. Und das vierte Prinzip, Robustheit, führt direkt zurück zum Ausgangspunkt dieser ganzen Website: gutes, semantisches HTML.

Quellen

• Accessibility Principles (POUR) – W3C/WAI
• WCAG 2.2 – Prinzipien, Richtlinien, Erfolgskriterien
• Constructing a POUR Website – WebAIM
• EN 301 549 V3.2.1 (Norm, PDF)