NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Vier grüne Säulen tragen eine Plattform mit dem Schriftzug POUR, rechts Rakete

Was sind die vier POUR Prinzipien der digitalen Barrierefreiheit?

POUR steht für Perceivable, Operable, Understandable und Robust. Auf Deutsch: wahrnehmbar, bedienbar, verständlich und robust. Diese vier Prinzipien bilden das Fundament der Web Content Accessibility Guidelines. Jedes einzelne Erfolgskriterium der WCAG ordnet sich einem dieser vier Prinzipien unter.
Die Reihenfolge ist kein Zufall. Sie beschreibt den Weg durch eine Nutzung. Erst muss ich einen Inhalt überhaupt wahrnehmen. Dann muss ich ihn bedienen. Dann muss ich ihn verstehen. Und am Ende muss der Code so sauber sein, dass Screenreader, Braillezeile und Spracheingabe damit arbeiten können. Fällt eine Stufe aus, endet die Nutzung.
POUR ist damit die Klammer über allem, was das Barrierefreiheitsstärkungsgesetz und der European Accessibility Act fordern. Wer die vier Prinzipien versteht, ordnet jede Anforderung selbst ein, statt eine Checkliste abzuhaken.
Inhalt
NCA Cypress Workshop mit Cypress Ambassador Roland Golla

E2E Tests, die euer Team selbst schreibt

Ein Tag inhouse mit Roland Golla, offizieller Cypress Ambassador und seit über 20 Jahren in Testing und Refactoring zu Hause. Auf unserem YouTube Kanal zeigt er in über 70 Live Coding Tutorials, wie Cypress in echten Projekten läuft. Dazu kommt unser Open Source Plugin NCA TESTIFY: Basistests für jede Website, mit einer Zeile im CI/CD Setup. Im Workshop lernt euer Team Setup, stabile Selektoren, Custom Commands und Tests in der Pipeline.

  1. 1
    Kostenloses Vorgespräch
    Projekt, Stack und Teststand klären
  2. 2
    Workshoptag bei euch
    Setup, Patterns und erste Tests im Team
  3. 3
    Praxistag optional
    Tests im eigenen Projekt und in CI
Roland Golla
Roland Golla
Fullstack Developer
Zum Cypress Workshop arrow_forward

Wir verankern POUR direkt in euren Komponenten und Tests

Never Code Alone kommt aus Duisburg und arbeitet seit über 20 Jahren an Softwarequalität. Barrierefreiheit behandeln wir wie jedes andere Qualitätsthema: messbar, automatisiert und im Build verankert. axe-core, Pa11y und Lighthouse laufen bei uns in der Pipeline, Cypress prüft die Tastaturbedienung am echten DOM. Roland Golla ist Cypress Ambassador und bringt Teams genau diese Arbeitsweise bei.
Passend dazu unterstützen wir bei Accessibility Webdesign, im Frontend Development und bei jedem Accessibility Audit. Wir richten die passenden Accessibility Testing Tools ein, verbinden axe DevTools mit Cypress und bauen den Google Lighthouse Accessibility Audit in die CI ein.

Wahrnehmbar heißt, Information hängt nie an nur einem Sinn

Ein Bild ohne Textalternative ist für einen Screenreader eine leere Stelle. Ein Video ohne Untertitel ist für gehörlose Nutzer stumm. Grauer Text auf hellgrauem Grund verschwindet, sobald jemand in der Sonne auf das Handy schaut. Wahrnehmbar heißt: Jede Information muss über mehr als einen Kanal ankommen.
  • Textalternativen für jedes Bild, das Information transportiert. Dekoration bleibt leer.
  • Untertitel und Audiodeskription für zeitbasierte Medien.
  • Kontrast von mindestens 4,5 zu 1 bei normalem Text auf Stufe AA.
  • Struktur im Code, nicht nur im Layout. Eine Überschrift ist ein h Element, keine fette Zeile.
Farbe allein darf nie das Signal sein. Ein rot markiertes Pflichtfeld braucht zusätzlich Text. Tiefer geht es in den Beiträgen zu Alternativtext, Nicht Text Inhalten, Untertiteln, Audiodeskription, Farbkontrast und Color Accessibility.

Bedienbar ist eine Seite, die auch ohne Maus funktioniert

Bedienbar heißt: Jede Funktion lässt sich per Tastatur erreichen, auslösen und wieder verlassen. Das klingt banal, scheitert aber täglich an Modals ohne Escape, an Dropdowns aus reinen div Elementen und an unsichtbaren Fokusrahmen.
  • Tastaturbedienung ohne Fallen. Wer hineinkommt, muss auch wieder heraus.
  • Sichtbarer Fokus, der nicht von Sticky Headern verdeckt wird.
  • Genug Zeit. Sessions und Timeouts müssen verlängerbar sein.
  • Keine blitzenden Effekte, die Anfälle auslösen können.
  • Zielgrößen ab 24 mal 24 CSS Pixel, ein Kriterium aus WCAG 2.2.
Der Tab Weg ist der ehrlichste Test einer Seite. Mehr dazu in den Artikeln zu Keyboard Navigation, Operabilität, taba11y für die Tab Reihenfolge, alternativen Eingabegeräten und der logischen Reihenfolge.

Verständlich wird es mit klarer Sprache und klaren Fehlermeldungen

Verständlich betrifft Inhalt und Verhalten. Der Text muss lesbar sein, die Oberfläche vorhersehbar. Und wenn etwas schiefgeht, muss der Nutzer erfahren, was genau fehlt und wie er es repariert.
  • Sprache im Markup auszeichnen, damit Screenreader richtig aussprechen.
  • Keine Überraschungen. Fokus auf einem Feld startet keinen Seitenwechsel.
  • Fehlermeldungen mit Lösung. Nicht nur Feld ungültig, sondern was erwartet wird.
  • Hilfe an der gleichen Stelle auf allen Seiten.
  • Login ohne Gedächtnisrätsel. Passwortmanager dürfen nicht blockiert werden.
Formulare sind hier der Prüfstein. Weiter geht es bei barrierefreien Formularen, Accessible Forms, Leichter Sprache, barrierefreien Headlines und beim Thema CAPTCHA.

Robuster Code lässt assistive Technik zuverlässig arbeiten

Robust heißt: Der Code hält auch dann, wenn ihn nicht ein Browserfenster darstellt, sondern ein Screenreader, eine Braillezeile oder eine Spracheingabe. Diese Werkzeuge lesen den Accessibility Tree. Der entsteht aus dem Markup.
  • Semantisches HTML zuerst. Ein button ist ein button.
  • ARIA nur, wenn HTML nicht reicht. Falsches ARIA ist schlechter als keines.
  • Name, Rolle und Zustand für jedes Bedienelement.
  • Statusmeldungen, die ohne Fokuswechsel angesagt werden.
Das alte Kriterium zum Parsing ist in WCAG 2.2 entfallen. Sauberes Markup bleibt trotzdem Pflicht, weil doppelte IDs und offene Tags den Accessibility Tree zerlegen. Details in den Beiträgen zu Semantic HTML, ARIA, Name, Rolle, Zustand, Robustheit und zum DOM.

Die vier POUR Prinzipien im Überblick

Prinzip Kernfrage Typische Prüfung
Wahrnehmbar Kommt die Information über mehr als einen Sinn an? Alternativtexte, Untertitel, Kontrastmessung
Bedienbar Funktioniert alles ohne Maus? Tab Durchlauf, sichtbarer Fokus, Zielgrößen
Verständlich Sind Inhalt und Verhalten vorhersehbar? Sprachauszeichnung, Fehlermeldungen, Formularhilfen
Robust Arbeitet assistive Technik zuverlässig damit? Semantik, Name Rolle Zustand, Screenreader Test

Im Entwicklungsalltag sichern Quality Gates POUR schon vor dem Release

Barrierefreiheit scheitert selten am Wissen. Sie scheitert daran, dass niemand prüft, bevor der Code im Main landet. Deshalb behandeln wir die vier Prinzipien wie Tests: automatisiert, im Build, mit einem klaren Ergebnis. Erst das Quality Gate, dann das Aufräumen.
Code: 
          
npm install --save-dev cypress cypress-axe axe-core
Danach prüft jeder E2E Test die Seite gleich mit. Der Scan läuft gegen das echte DOM, also gegen den Zustand, den ein Screenreader auch bekommt.
Code: 
          
cy.visit('/')
cy.injectAxe()
cy.checkA11y()
Automatische Prüfungen finden nur einen Teil der Probleme. Kontrastfehler, fehlende Alternativtexte und falsche Rollen fallen zuverlässig auf. Ob ein Alternativtext den Inhalt wirklich beschreibt, entscheidet weiterhin ein Mensch.
Deshalb gehört zu jedem Projekt der manuelle Teil: einmal komplett per Tastatur durch, einmal mit Screenreader über die Hauptpfade, dazu eine repräsentative Stichprobentestung. Wie das zusammenspielt, steht im Beitrag zu Accessibility Testing sowie bei den Firefox Accessibility Tools und dem Silktide Accessibility Checker.

Was bei POUR, WCAG 2.2 und WCAG 3.0 heute zählt

Die vier Prinzipien stehen seit WCAG 2.0 unverändert. Neue Versionen ergänzen Erfolgskriterien, sie werfen die Struktur nicht um. WCAG 2.2 ist die aktuelle Empfehlung des W3C und inzwischen auch als internationale Norm ISO/IEC 40500 bestätigt.
In Europa übersetzt die harmonisierte Norm EN 301 549 diese Anforderungen in die Beschaffungs und Rechtspraxis. Darauf beziehen sich der European Accessibility Act und das Barrierefreiheitsstärkungsgesetz. Wer wissen will, was das für den eigenen Shop bedeutet, findet Antworten bei Compliance, Konformität und den Übergangsfristen.
WCAG 3.0 liegt als Working Draft vor. Aus Web Content Accessibility Guidelines werden W3C Accessibility Guidelines, das Konformitätsmodell soll von den Stufen A, AA und AAA auf eine abgestufte Bewertung wechseln. Bis daraus eine verabschiedete Empfehlung wird, vergehen noch Jahre. Wer heute plant, plant gegen WCAG 2.2 auf Stufe AA.
Das Gute daran: Arbeit an POUR verfällt nicht. Saubere Semantik, sichtbarer Fokus und verständliche Fehlermeldungen zahlen in jede kommende Version ein. Der Aufwand entsteht einmal, der Nutzen bleibt.

Access by everyone regardless of disability is an essential aspect.

Tim Berners-Lee, Erfinder des World Wide Web und Direktor des W3C – via W3C Pressemitteilung zum Start der Web Accessibility Initiative

Woran POUR in NCA Projekten praktisch hängt

In Code Reviews sehen wir fast immer dieselben Muster. Bilder, deren Alternativtext der Dateiname ist. Modals, aus denen die Tastatur nicht mehr herauskommt. Fehlermeldungen, die nur rot sind. Und Bedienelemente, die ein div mit Klick Handler statt eines Buttons sind. Vier Fehler, vier Prinzipien.
Unsere Reihenfolge ist dabei immer gleich: erst messen, dann aufräumen. Statische Analyse und Engine Scan zeigen die Masse, danach gehen Tastatur und Screenreader über die kritischen Pfade. Wer ohne diese Basis refactored, tauscht alte Fehler gegen neue.
Wenn ein Team einsteigt, gehen wir die Prinzipien an konkreten Komponenten durch. Buttons, Formulare, Navigation, Tabellen. Danach kann das Team die Prüfung selbst fahren, und wir sind nur noch für die harten Fälle im Boot.
Weitere Bausteine aus dem Glossar und der Praxis:
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Erreichen Sie unsere Spezialisten zu barrierefreien Webdesign

Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.

Kostenlose Demo Jetzt anrufen

Häufige Fragen zu den POUR Prinzipien

Die Fragen, die uns in Workshops und Reviews am häufigsten gestellt werden.
Was bedeutet POUR in der Barrierefreiheit 2026?

POUR steht für wahrnehmbar, bedienbar, verständlich und robust. Die vier Begriffe sind die oberste Ebene der WCAG. Jedes Erfolgskriterium gehört zu genau einem dieser Prinzipien. Wer POUR verstanden hat, kann jede einzelne Anforderung einordnen, statt eine lange Liste ohne roten Faden abzuarbeiten.

Welche WCAG Version gilt 2026 als Maßstab?

WCAG 2.2 ist die aktuelle Empfehlung des W3C und inzwischen auch als internationale Norm ISO/IEC 40500 bestätigt. In Europa greift zusätzlich die harmonisierte Norm EN 301 549, auf die sich der European Accessibility Act und das Barrierefreiheitsstärkungsgesetz beziehen. Der übliche Zielwert für Projekte ist Stufe AA.

Reichen automatische Tests für POUR 2026 aus?

Nein. Automatische Scans finden Kontrastfehler, fehlende Alternativtexte und falsche Rollen zuverlässig. Ob ein Alternativtext den Inhalt sinnvoll beschreibt oder eine Fehlermeldung wirklich weiterhilft, entscheidet ein Mensch. Die Kombination aus Scan in der Pipeline und manueller Prüfung der Hauptpfade ist der Standard, der trägt.

Gilt POUR 2026 auch für Apps, PDF und Dokumente?

Ja. Die vier Prinzipien sind technikneutral formuliert. Sie greifen für Webseiten genauso wie für mobile Apps, PDF Dokumente, Kiosksysteme und Software. Die konkreten Prüfschritte unterscheiden sich, das Ziel bleibt gleich: wahrnehmbar, bedienbar, verständlich und robust für alle Nutzer.

Was ändert WCAG 3.0 2026 an den POUR Prinzipien?

WCAG 3.0 liegt als Working Draft vor und ist noch keine verabschiedete Empfehlung. Geplant sind ein neuer Name, eine andere Gliederung und ein abgestuftes Bewertungsmodell statt der Stufen A, AA und AAA. Die inhaltliche Substanz von POUR bleibt erhalten. Arbeit an Semantik und Bedienbarkeit verfällt also nicht.

Warum ist die Reihenfolge der vier Prinzipien wichtig?

Weil sie den Weg durch eine Nutzung beschreibt. Erst wahrnehmen, dann bedienen, dann verstehen, und darunter muss der Code robust genug sein. Fällt eine Stufe aus, helfen die anderen nicht mehr. Ein perfekt formuliertes Fehlerfeld nützt nichts, wenn niemand mit der Tastatur dorthin kommt.

Was passiert, wenn ein Prinzip nicht erfüllt ist?

Dann bricht die Nutzung für eine Gruppe komplett ab, nicht nur ein bisschen. Ein Video ohne Untertitel schließt gehörlose Nutzer aus. Ein Formular ohne Tastaturbedienung schließt alle aus, die keine Maus benutzen. Dazu kommt das rechtliche Risiko, wenn ein Angebot unter das Barrierefreiheitsstärkungsgesetz fällt.

Wie hängen POUR und die Stufen A, AA und AAA zusammen?

Die vier Prinzipien sind die oberste Ebene. Darunter liegen Richtlinien, darunter die einzelnen Erfolgskriterien. Jedes Erfolgskriterium trägt eine Stufe: A, AA oder AAA. Die Prinzipien sagen also, worum es geht, die Stufen sagen, wie streng geprüft wird. Üblicher Zielwert in Projekten ist AA.

Welches Prinzip wird am häufigsten verletzt?

In unseren Reviews sind Wahrnehmbarkeit und Bedienbarkeit die Dauerbrenner. Zu geringe Kontraste, Alternativtexte mit Dateinamen, unsichtbare Fokusrahmen und selbstgebaute Dropdowns ohne Tastaturunterstützung. Das sind gleichzeitig die Fehler, die sich am schnellsten beheben lassen, weil sie meist in wenigen zentralen Komponenten sitzen.

Wie prüfe ich Bedienbarkeit ohne teure Werkzeuge?

Legen Sie die Maus weg und gehen Sie mit der Tabulatortaste durch die Seite. Achten Sie darauf, ob der Fokus immer sichtbar ist, ob die Reihenfolge Sinn ergibt und ob Sie aus jedem Overlay wieder herauskommen. Dieser Durchlauf kostet nichts und findet einen großen Teil der Probleme.

Wie viel Aufwand steckt in einer POUR Umsetzung?

Das hängt vom Zustand des Codes ab. Eine saubere Komponentenbibliothek braucht wenige Tage, ein gewachsenes Frontend deutlich mehr. Wir starten mit einem kostenlosen Kennenlernen, schätzen den Aufwand am echten Projekt und rechnen transparent minutengenau ab. Ohne Pakete und ohne Mindestlaufzeit.

Wie fange ich in einem bestehenden Projekt an?

Erst messen, dann aufräumen. Statische Analyse und ein Engine Scan zeigen die Masse der Fehler, danach kommen Tastatur und Screenreader auf die wichtigsten Nutzerpfade. Anschließend werden die zentralen Komponenten repariert, nicht einzelne Seiten. So wirkt jede Korrektur an vielen Stellen gleichzeitig.