POUR in der Barrierefreiheit
POUR steht für wahrnehmbar, bedienbar, verständlich und robust, die vier Prinzipien hinter jedem WCAG-Erfolgskriterium. Mit Beispielen zu jedem Prinzip.
Was ist POUR in der Barrierefreiheit?
POUR steht für Perceivable, Operable, Understandable und Robust (wahrnehmbar, bedienbar, verständlich, robust). Das sind die vier Prinzipien, nach denen die Web Content Accessibility Guidelines gegliedert sind. Jedes WCAG-Erfolgskriterium gehört zu einem davon, deshalb ist POUR ein schneller Weg, um zu fragen, woran es scheitert, wenn jemand eine Seite nicht nutzen kann. Den ganzen Standard erklärt WCAG.
WCAG 2.2 hat vier Prinzipien und 13 Richtlinien. Die Prinzipien sind die oberste Ebene, die Richtlinien sagen, was erreicht werden soll, und die Erfolgskriterien sind die prüfbaren Regeln.
Die vier POUR-Prinzipien
Wahrnehmbar (Perceivable)
Informationen und Bedienelemente müssen so dargestellt werden, dass Nutzer sie wahrnehmen können. Dazu gehören Textalternativen für Bilder, Untertitel für Audio und Video, Inhalte, die bei geänderter Darstellung ihren Sinn behalten, sowie ausreichender Kontrast und unterscheidbare Farben. Richtlinien 1.1 bis 1.4. Siehe barrierefreie Bilder.
Bedienbar (Operable)
Komponenten und Navigation müssen bedienbar sein. Alles muss per Tastatur funktionieren, Nutzer brauchen genug Zeit, nichts darf so blinken, dass es Anfälle auslösen kann, Seiten brauchen klare Navigationswege, und Steuerelemente müssen mehr als einen präzisen Mausklick verkraften. Richtlinien 2.1 bis 2.5.
Verständlich (Understandable)
Inhalte und das Verhalten der Oberfläche müssen verständlich sein. Die Seitensprache ist gesetzt, die Navigation verhält sich vorhersehbar, und Formulare beschriften ihre Felder und erklären Fehler als Text. Richtlinien 3.1 bis 3.3. Siehe barrierefreie Formulare.
Robust
Inhalte müssen robust genug sein, damit Browser und assistive Technologien sie zuverlässig auslegen können. In der Praxis heißt das: Steuerelemente stellen Name, Rolle und Zustand bereit, die ein Screenreader vorlesen kann, zuerst mit nativem HTML und mit ARIA, wo HTML kein Gegenstück hat. Richtlinie 4.1, die einzige unter diesem Prinzip.
Beispiel: ein Login-Formular, vier Fehler
- Wahrnehmbar: Das Logo hat keinen Alternativtext, ein Screenreader liest einen Dateinamen vor.
- Bedienbar: Der Button „Anmelden“ ist ein gestyltes
div, das nur auf Mausklicks reagiert, Tastaturnutzer können nicht absenden. - Verständlich: Ein fehlgeschlagener Login zeigt „Ungültige Eingabe“, ohne zu sagen, welches Feld falsch ist.
- Robust: Ein eigenes Sprachmenü aus unbeschrifteten
div-Elementen gibt assistiver Technologie weder Rolle noch Namen.
So nutzen Sie POUR
- Audit-Befunde sortieren. Ordnen Sie jedes Problem seinem Prinzip zu und sehen Sie, ob sich Probleme häufen, etwa viele Bedienbarkeitsfehler durch eigene Widgets.
- Berichte gliedern. Ein Accessibility Conformance Report folgt denselben Prinzipien, Kriterium für Kriterium.
- Entwürfe früh prüfen. Stellen Sie vor dem Bau die vier Fragen: Lässt es sich wahrnehmen, bedienen, verstehen und von assistiver Technologie auslegen?
Häufige Fehler
- POUR als Checkliste mit vier Punkten behandeln. Es ordnet die Kriterien, ersetzt aber nicht deren Prüfung.
- Einen perfekten Lighthouse-Score für „fertig“ halten. Automatische Prüfungen decken nur einen Teil von WCAG ab und überlassen Dinge wie Tab-Reihenfolge und eingeschlossenen Fokus einem Menschen. Siehe im Blog (auf Englisch) die Übersicht über Tools für Barrierefreiheitstests.
- Robust auf „valides HTML“ verkürzen. Robust meint Namen, Rollen und Zustände, die assistive Technologie nutzen kann. WCAG 2.2 hat das alte Kriterium 4.1.1 Parsing entfernt.
Um den automatischen Teil über die Zeit im Blick zu behalten, führt das LoadFocus Page-Speed-Monitoring geplante Lighthouse-Audits aus und hält die Kategorie Accessibility neben Performance fest, sodass ein Rückgang nach einem Release sichtbar wird. Es ist ein Regressionsalarm, keine Konformitätsprüfung.
Häufige Fragen zu POUR
Wofür steht POUR?
Für Perceivable, Operable, Understandable und Robust, also wahrnehmbar, bedienbar, verständlich und robust.
Wer hat die POUR-Prinzipien definiert?
Es sind die vier Prinzipien der WCAG, herausgegeben von der Web Accessibility Initiative des W3C.
Ist POUR dasselbe wie WCAG?
Nein. POUR ist die oberste Ebene der WCAG-Struktur. Darunter liegen die Richtlinien und die Erfolgskriterien der Stufen A, AA und AAA, gegen die Sie tatsächlich testen.
Heißt ein perfekter automatischer Score, dass eine Website POUR erfüllt?
Nein. Automatische Tools prüfen nur einen Teil der Erfolgskriterien. Tastaturbedienung, Fokusführung und die Verständlichkeit von Fehlermeldungen brauchen manuelle Tests.
Verwandte Begriffe
- Was ist ein Screenreader? Definition, Beispiele, Tests
- Checkliste für Software-Barrierefreiheit (WCAG 2.2)
- Was ist ein VPAT (Voluntary Product Accessibility Template)?
- Web Accessibility Initiative (WAI): Definition und Standards
- WCAG: Web Content Accessibility Guidelines erklärt
- Was sind barrierefreie Formulare?
- Was sind barrierefreie Medienformate?
- Was sind bewegungsausgelöste Störungen in der Software?
Verwandte LoadFocus-Tools
Setze dieses Konzept mit LoadFocus in die Praxis um, derselben Plattform, die alles antreibt, was du gerade gelesen hast.