Barrierefreiheit für Product Owner und Projektleitung

Barrierefreiheit scheitert selten am Können und fast immer an der Steuerung: Sie steht in keiner Akzeptanzbedingung, taucht in keiner Definition of Done auf und wird deshalb als Nacharbeit sichtbar, wenn das Budget schon verplant ist. Die wirksamsten Hebel einer Projektleitung sind keine fachlichen, sondern drei organisatorische – Akzeptanzkriterien, eine erweiterte Definition of Done und ein benannter Umgang mit Fremdsystemen.

Diese Seite sortiert das Wissen dieser Website nach Zuständigkeit. Sie erklärt keine WCAG-Kriterien, sondern zeigt, wo sie in einen Projektablauf gehören – und welche Entscheidungen niemand außer der Steuerungsrolle treffen kann.

Das Wichtigste in Kürze

• Barrierefreiheit gehört in die Definition of Done, nicht in ein eigenes Epic am Ende der Roadmap.
• Zielwert ist WCAG 2.1 AA über die EN 301 549 – nicht „so gut wie möglich“.
• Die Verantwortung verteilt sich auf vier Rollen. Ein einzelnes A11y-Ticket landet sonst immer bei der Entwicklung, obwohl die Hälfte woanders entsteht.
• Fremdsysteme sind der häufigste Blocker: Zahlungsdienstleister, Buchungswidgets, Kartendienste. Dafür braucht es eine Entscheidung, keine Hoffnung.
• Altlasten werden priorisiert, nicht flächendeckend saniert – zuerst die Vorgänge, die Menschen wirklich durchlaufen.
• Die Barrierefreiheitserklärung ist ein Steuerungsinstrument, weil sie bekannte Mängel benennen muss.
• Stand August 2026: Für Neuentwicklungen ist Barrierefreiheit über das BFSG Anforderung, nicht Wunsch. Keine Rechtsberatung.

Die drei Hebel, die nur du hast

1. Akzeptanzkriterien statt Sammelticket. Ein Epic „Barrierefreiheit herstellen“ ist nicht schätzbar, nicht abnehmbar und wandert zuverlässig ans Ende des Backlogs. Wirksam ist das Gegenteil: je Story ein bis zwei konkrete Bedingungen. Für eine Formular-Story etwa „jedes Feld hat ein verknüpftes Label“ und „Fehlermeldungen werden angesagt“. Das ist schätzbar, prüfbar und erzeugt keinen Sonderprozess.

2. Definition of Done erweitern. Drei Zeilen reichen für den größten Teil der Regressionen:

• Die Ansicht ist vollständig mit der Tastatur bedienbar (2.1.1), der Fokus ist sichtbar (2.4.7).
• Ein automatischer Prüflauf (axe, Lighthouse oder der Struktur-Check) meldet keine neuen Fehler.
• Neue Bedienelemente haben Name und Rolle – geprüft mit einem Screenreader oder im Barrierefreiheits-Panel der DevTools.

Der Punkt daran ist nicht Vollständigkeit, sondern Richtung: Es wird nichts Neues kaputt gemacht, während Altes abgebaut wird.

3. Den Zielwert festlegen und aufschreiben. „Barrierefrei“ ist kein Abnahmekriterium, „WCAG 2.1 Stufe AA nach EN 301 549“ schon. Warum genau diese Fassung gilt und nicht 2.2, steht unter EU-Recht: EAA & EN 301 549 und WCAG 2.1 & 2.2.

Wer was verantwortet

Die häufigste Fehlannahme in Projekten ist, Barrierefreiheit sei ein Entwicklungsthema. Tatsächlich verteilt sie sich:

Diese Tabelle beantwortet im Alltag mehr Fragen als jede Kriterienliste – vor allem die, warum ein Kontrastbefund kein Entwicklungsticket ist.

Fremdsysteme: der Blocker, der keiner sein muss

In fast jedem Projekt gibt es mindestens eine Komponente, die nicht dir gehört: Zahlungsdienstleister, Buchungs- oder Terminwidget, Kartendienst, Chat, Bewertungssystem, Consent-Tool. Erfahrungsgemäß ist genau dort der schwerste Befund, und genau dort endet die Handlungsfähigkeit des Teams.

Es gibt trotzdem drei Entscheidungen, die möglich sind – und sie sind Steuerungssache:

1. Beim Anbieter melden und den Vorgang dokumentieren. Das ist keine Formalie: Es verschiebt die Zuständigkeit nachweisbar und ist die Grundlage für die nächsten zwei Punkte.
2. Eine erreichbare Ausweichlösung anbieten – ein bedienbares Kontaktformular oder eine Telefonnummer neben dem unbedienbaren Widget. Das ersetzt die Barrierefreiheit nicht, macht den Vorgang aber durchführbar.
3. Den Mangel in der Barrierefreiheitserklärung benennen. Eine Erklärung, die bekannte Mängel verschweigt, ist selbst ein Mangel.

Was in dieser Lage nicht hilft, ist ein zugekauftes Widget: Ein Accessibility-Overlay ändert nichts an den Ursachen und ist kein Nachweis.

Altlasten priorisieren

Eine gewachsene Anwendung lässt sich nicht in einem Quartal sanieren, und der Versuch erzeugt vor allem Frust. Die Reihenfolge, die sich bewährt hat:

1. Die Vorgänge zuerst, die Menschen tatsächlich durchlaufen – Anmeldung, Kauf, Terminbuchung, Kontakt. Ein Vorgang ist erst konform, wenn jeder Schritt es ist.
2. Dann die häufig abgerufenen Seiten. Analytics beantwortet das in fünf Minuten.
3. Dann die mechanisch behebbaren Massenfehler: Kontraste, Alt-Texte, Formularlabels, Dokumentsprache. Reihenfolge und Umfang stehen in der BFSG-Checkliste.
4. Zuletzt der selten genutzte Bestand – oder er wird ersetzt statt saniert.

Budget und Aufwand realistisch einordnen

Zwei Zahlen helfen in Budgetgesprächen mehr als jedes Argument. Erstens: In einer Neuentwicklung ist Barrierefreiheit überwiegend eine Frage der Arbeitsweise, nicht des Zusatzaufwands – die Mehrkosten entstehen fast vollständig durch Nacharbeit. Zweitens: Die Sanierung derselben Anforderung nach dem Launch kostet ein Vielfaches, weil sie Design, Code und Inhalt gleichzeitig berührt. Die Einordnung mit Zahlen steht unter Was kostet Barrierefreiheit? und Zahlen & Business Case.

Für die Abnahme lohnt sich außerdem die Unterscheidung zwischen einem internen Durchlauf und einer externen Prüfung: Der interne Durchlauf gehört in jeden Sprint, die externe Prüfung einmal vor dem Launch – siehe BITV-Test, Audit & VPAT.

Häufiger Fehler in der Praxis

Ein A11y-Epic anlegen. Es wird nie fertig, weil es keine Abnahmebedingung hat – und es entlastet alle anderen Stories davon, das Thema zu berühren.

Die Prüfung an den Schluss legen. Ein Audit zwei Wochen vor dem Launch produziert eine Befundliste, die niemand mehr abarbeiten kann, und verwandelt Barrierefreiheit in ein Launch-Risiko statt in eine Qualitätseigenschaft.

Den automatischen Prüflauf für die Abnahme halten. Werkzeuge finden je nach Quelle etwa ein Drittel der Barrieren. Was sie nicht können, steht unter Prüfwerkzeuge im Vergleich.

Die Redaktion vergessen. Wenn niemand Zeit für Alt-Texte und Untertitel eingeplant hat, entstehen die Barrieren nach dem Launch – zuverlässig und dauerhaft.

Häufige Fragen

Brauchen wir eine eigene Rolle für Barrierefreiheit?

In größeren Organisationen hilft eine benannte Ansprechperson, in kleineren Teams nicht. Wichtiger als die Rolle ist, dass das Thema in der Definition of Done steht – sonst wird die Ansprechperson zum Flaschenhals, an dem alle anderen sich entlasten.

Wie schätzt man Barrierefreiheit im Backlog?

Gar nicht als eigene Position. Sie wird Teil der Schätzung der jeweiligen Story, weil sie Teil der Umsetzung ist. Eigene Positionen entstehen nur für Sanierungsarbeiten am Bestand – und die lassen sich nach dem Muster oben priorisieren.

Reicht es, wenn ein externer Dienstleister prüft?

Für den Nachweis ja, für die Steuerung nein. Ein Audit liefert eine Befundliste zu einem Stichtag; ohne interne Prüfschritte ist der Zustand drei Sprints später wieder ein anderer.

Ab wann ist unser Produkt betroffen?

Das hängt von Angebot, Unternehmensgröße und Zielgruppe ab. Die Einordnung liefert der BFSG-Schnelltest in vier Fragen; die Ausnahmen und Fristen stehen unter Ausnahmen, Fristen & Bußgeld. Dieser Abschnitt erklärt die Rechtslage, ersetzt aber keine Rechtsberatung.

Verwandte Themen

• Barrierefreiheit in Einkauf und Vergabe – wie Anforderungen in Verträge kommen
• Barrierefreiheit im UX- und UI-Design – die Entscheidungen vor der ersten Zeile Code
• BFSG-Checkliste für Websites – die Arbeitsreihenfolge für den Bestand
• Barrierefreiheit selbst testen – der interne Durchlauf, der in jeden Sprint passt

Quellen

• Barrierefreiheitsstärkungsgesetz (BFSG) – Gesetzestext
• EN 301 549 V3.2.1 – die harmonisierte Norm mit dem Zielwert (PDF)
• Planning and Managing Web Accessibility – Vorgehensmodell des W3C WAI