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 verplant ist. Die wirksamsten Hebel einer Projektleitung sind organisatorisch. Sie heißen Akzeptanzkriterien, eine erweiterte Definition of Done und ein benannter Umgang mit Fremdsystemen.

Diese Seite sortiert das Wissen dieser Website nach Zuständigkeit. Sie zeigt, wo die WCAG-Kriterien in einen Projektablauf gehören und welche Entscheidungen niemand außer der Steuerungsrolle treffen kann. Die Kriterien selbst erklären die verlinkten Seiten.

Das Wichtigste in Kürze

• Barrierefreiheit gehört in die Definition of Done jeder Story. Ein eigenes Epic am Ende der Roadmap wird nie fertig.
• Shift Left spart Geld: Nach einer Fallstudie von Deque lassen sich 67 Prozent der Barrieren bereits in der Designphase vermeiden.
• Stand Oktober 2026: ETSI hat die EN 301 549 V4.1.1 mit WCAG 2.2 am 2. September 2026 veröffentlicht. Bis zur Nennung im EU-Amtsblatt bleibt V3.2.1 mit WCAG 2.1 AA der Bezugspunkt. Neue Akzeptanzkriterien schreibst du am besten gleich gegen WCAG 2.2 AA.
• Die Verantwortung verteilt sich auf fünf Rollen. Ein einzelnes A11y-Ticket landet sonst immer bei der Entwicklung, obwohl die Hälfte der Barrieren woanders entsteht.
• Fremdsysteme bleiben deine Verantwortung. Nach § 14 BFSG haftet der Anbieter der Dienstleistung für das Ganze, also auch für eingebundene Zahlungs- und Buchungswidgets.
• Altlasten werden nach Vorgängen priorisiert. Zuerst kommen Anmeldung, Kauf, Buchung und Kontakt, weil Menschen sie durchlaufen müssen.
• Barrierefreiheit endet nicht mit dem Launch. Ein Feedback-Weg, Nachtests bei großen Releases und Tests mit Menschen mit Behinderung gehören in den Betrieb.
• Das BFSG gilt seit dem 28. Juni 2025 für angebotene Dienstleistungen, auch für den Bestand. Diese Seite ist keine Rechtsberatung.

Shift Left: Warum der Zeitpunkt die Kosten bestimmt

Mit „Shift Left“ ist gemeint, Barrierefreiheit auf der Zeitachse eines Projekts möglichst weit nach links zu schieben. Ein Projekt läuft grob durch Planung, Design, Entwicklung, Test und Release. Je weiter rechts ein Fehler auffällt, desto mehr Arbeit hängt bereits an ihm. Eine Fallstudie von Deque kommt zu dem Ergebnis, dass sich 67 Prozent der Barrieren in der Designphase vermeiden lassen. Das deckt sich mit meiner Erfahrung aus Audits: Die meisten Befunde wurden lange vor der ersten Zeile Code entschieden.

Für die Steuerung folgt daraus eine einfache Regel. Barrierefreiheit wird in der Planung als Zielwert festgelegt, im Design als Zustand spezifiziert, in der Entwicklung je Story abgenommen und im Test gegen den Zielwert geprüft. Ein Audit am Ende ersetzt keinen dieser Schritte. Es bestätigt nur, ob sie funktioniert haben.

Die drei Hebel, die nur du hast

1. Akzeptanzkriterien statt Sammelticket. Ein Epic „Barrierefreiheit herstellen“ ist weder schätzbar noch abnehmbar und wandert zuverlässig ans Ende des Backlogs. Wirksam ist das Gegenteil: je Story ein bis vier konkrete Bedingungen mit Kriteriennummer und, wo möglich, mit Zahlenwert. 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).

Sobald das Team damit sicher ist, bekommt jede Rolle eine eigene Zeile. Für das Design heißt sie etwa „Kontraste gemessen und Fokuszustand für jedes Bedienelement spezifiziert“. Für die Redaktion heißt sie „Überschriften geprüft, Alt-Texte und Linktexte geschrieben“. Die Richtung zählt mehr als die Vollständigkeit. Neues kommt ohne neue Barrieren dazu, während Altes abgebaut wird.

3. Den Zielwert festlegen und aufschreiben. „Barrierefrei“ ist kein Abnahmekriterium. „WCAG 2.2 Stufe AA, mindestens aber EN 301 549 V3.2.1“ ist eines. Die Lage zum Stand Oktober 2026: Im Amtsblatt genannt ist bisher nur V3.2.1 mit WCAG 2.1 AA. Die neue Fassung V4.1.1 verweist auf WCAG 2.2 AA. Wer heute Akzeptanzkriterien schreibt, nimmt die neun neuen Kriterien von 2.2 deshalb gleich mit und muss später nichts nachziehen. Für Apps und Fachanwendungen gelten außerdem die Kapitel 11 und 12 der Norm (Software, Dokumentation und Support), die in der WCAG nicht vorkommen. Die Einordnung steht unter EU-Recht: EAA & EN 301 549 und WCAG 2.1 & 2.2.

Beispiel: eine Story mit Akzeptanzkriterien je Rolle

Die Story lautet: „Als Kundin möchte ich das Kontaktformular ausfüllen, um eine Frage zu meiner Bestellung zu stellen.“ So verteilen sich die Akzeptanzkriterien:

Jede Zeile lässt sich in einer Minute prüfen. Die Story ist abgenommen, wenn alle Zeilen erfüllt sind. Einen eigenen Barrierefreiheitstermin gibt es dabei nicht.

Wer was verantwortet

Die häufigste Fehlannahme in Projekten ist, Barrierefreiheit sei ein Entwicklungsthema. Die Verantwortung verteilt sich so:

Diese Tabelle beantwortet im Alltag mehr Fragen als jede Kriterienliste. Vor allem klärt sie, warum ein Kontrastbefund in das Design gehört und kein Entwicklungsticket ist.

Menschen mit Behinderung beteiligen

Eine Kriterienliste beschreibt die Mindestanforderung. Ob ein Vorgang für Menschen funktioniert, zeigt erst der Test mit ihnen. Das W3C warnt ausdrücklich davor, Barrierefreiheit nur als Checkliste abzuarbeiten. Für die Steuerung heißt das, drei Dinge fest einzuplanen:

1. Anforderungen aus der Nutzung ableiten. Die EN 301 549 nennt in Abschnitt 4.2 zehn Nutzungsarten, darunter Nutzung ohne Sehvermögen, ohne Farbwahrnehmung, ohne Hörvermögen, mit eingeschränkter Feinmotorik und mit eingeschränkten kognitiven Fähigkeiten. Diese Liste eignet sich als Grundlage für Personas.
2. Tests mit Betroffenen vor großen Releases. Eine Person, die täglich mit Screenreader oder Bildschirmlupe arbeitet, findet in einer Stunde Probleme, die keine Prüfliste enthält. Wie unterschiedlich Menschen das Netz bedienen, zeigt Wie Screenreader-Nutzer surfen.
3. Rückmeldungen aus dem Betrieb auswerten. Die Meldungen über den Feedback-Weg sind die billigste Nutzerforschung, die ein Produkt bekommen kann.

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.

Rechtlich ändert das wenig. Nach § 14 BFSG muss der Dienstleistungserbringer gewährleisten, dass seine Dienstleistung die Anforderungen erfüllt. Das schließt eingebundene Fremdsysteme ein. Eine Meldung beim Anbieter dokumentiert den Vorgang, die Pflicht bleibt bei dir. Vier Entscheidungen sind trotzdem möglich, und sie sind Steuerungssache:

1. Beim Anbieter melden und den Vorgang dokumentieren. Die Dokumentation zeigt, dass du an der Korrektur arbeitest. Sie ist die Grundlage für die nächsten Punkte.
2. Eine erreichbare Ausweichlösung anbieten. Dafür eignen sich ein bedienbares Kontaktformular oder eine Telefonnummer neben dem unbedienbaren Widget. Die Lösung macht den Vorgang durchführbar und bekommt ein festes Enddatum. Eine Dauerlösung ist sie nicht.
3. Den Anbieter wechseln oder vertraglich binden. Bei der nächsten Verlängerung gehören Anforderungen und Nachweise in den Vertrag. Formulierungen dafür stehen unter Ausschreibung & Lastenheft.
4. Die Lage offen benennen. Für öffentliche Stellen verlangt die BITV 2.0, bekannte Mängel in der Barrierefreiheitserklärung aufzuführen. Für Unternehmen unter dem BFSG gilt etwas anderes: Ein genannter Mangel bleibt ein Verstoß. Ausnahmen gibt es nur über § 16 und § 17 BFSG, mit Dokumentation und Meldung.

Ein zugekauftes Accessibility-Overlay hilft in dieser Lage nicht. Es ändert nichts an den Ursachen und ist kein Nachweis.

Was das BFSG von der Steuerungsrolle verlangt

Das Gesetz spricht vom Dienstleistungserbringer. Im Projekt landen seine Pflichten fast immer bei Produkt und Projektleitung. Stand Oktober 2026 sind das vor allem diese:

Zuständig ist die Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF) in Magdeburg. Der Bußgeldrahmen reicht nach § 37 BFSG je nach Verstoß bis 100.000 Euro. Das Gesetz gilt seit dem 28. Juni 2025 für alle angebotenen Dienstleistungen, auch für bestehende Websites. Die Übergangsregel in § 38 betrifft nur Produkte, die vorher bereits zur Erbringung eingesetzt wurden, und Verträge, die vor dem Stichtag geschlossen wurden. Beide Fälle enden spätestens am 27. Juni 2030. Einzelheiten stehen unter Ausnahmen, Fristen & Bußgeld, der laufende Stand unter Aktuelles zum BFSG. Dieser Abschnitt ist keine Rechtsberatung.

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. Den Bestand messen. Ein vollständiger Prüfdurchlauf gegen den Zielwert ist die Ausgangslage. Ohne ihn lässt sich weder priorisieren noch ein Fortschritt zeigen. Wie ein interner Durchlauf aussieht, steht unter Barrierefreiheit selbst testen.
2. Die Vorgänge zuerst, die Menschen durchlaufen müssen (Anmeldung, Kauf, Terminbuchung, Kontakt). Ein Vorgang ist erst konform, wenn jeder Schritt es ist.
3. Dann die häufig abgerufenen Seiten. Analytics beantwortet das in fünf Minuten.
4. Dann die mechanisch behebbaren Massenfehler: Kontraste, Alt-Texte, Formularlabels, Dokumentsprache. Reihenfolge und Umfang stehen in der BFSG-Checkliste.
5. Zuletzt der selten genutzte Bestand. Oft ist es günstiger, ihn zu ersetzen als zu sanieren. Bei sehr alten Systemen gilt das für das Ganze.

Eine Regel hilft zusätzlich: Wer ein Element für einen Bugfix anfasst, macht es dabei barrierefrei. So schrumpft der Bestand ohne eigenes Budget.

Nach dem Launch: Barrierefreiheit im Betrieb

Ein Produkt verliert seine Barrierefreiheit schleichend. Neue Inhalte, neue Komponenten und Updates von Fremdsystemen bringen neue Befunde. Drei Dinge halten den Stand:

• Ein erreichbarer Feedback-Weg. Nutzende müssen Barrieren melden können, und jemand muss die Meldungen bearbeiten. Wie das organisiert wird, steht unter Feedback & Schlichtung.
• Nachtests bei großen Releases. Der interne Durchlauf gehört in jeden Sprint, die externe Prüfung einmal vor dem Launch und erneut nach großen Umbauten. Mehr dazu unter BITV-Test, Audit & VPAT.
• Nachweise aufbewahren. Zielwert im Projektplan, Definition of Done, Lastenheft, Prüfberichte, Nachtests und die Bearbeitung von Rückmeldungen zeigen gegenüber der Marktüberwachung, dass Barrierefreiheit gesteuert wird. Eine Vorlage für den Bericht liefert der Muster-Prüfbericht.

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. 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.

Häufiger Fehler in der Praxis

Ein A11y-Epic anlegen. Es wird nie fertig, weil es keine Abnahmebedingung hat. Und alle anderen Stories müssen sich um das Thema nicht mehr kümmern.

Die Prüfung an den Schluss legen. Ein Audit zwei Wochen vor dem Launch produziert eine Befundliste, die niemand mehr abarbeiten kann. Barrierefreiheit wird so zum Launch-Risiko. Früh eingeplant bleibt sie eine Qualitätseigenschaft.

Den automatischen Prüflauf für die Abnahme halten. Werkzeuge finden je nach Quelle und Zählweise etwa ein Drittel bis gut die Hälfte der Barrieren. Was sie übersehen, steht unter Prüfwerkzeuge im Vergleich.

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

Häufige Fragen

Brauchen wir eine eigene Rolle für Barrierefreiheit?

In größeren Organisationen hilft eine benannte Ansprechperson, oft als Accessibility Champion im Team. Sie berät, schult und hält den Zielwert im Blick. Die Umsetzung bleibt bei den Rollen. 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?

Als Teil der jeweiligen Story. Die Akzeptanzkriterien sind Teil der Umsetzung und fließen deshalb in deren Schätzung ein. 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.

Gilt das BFSG auch für unsere bestehende Website?

Ja, wenn sie unter das Gesetz fällt. Seit dem 28. Juni 2025 gilt es für angebotene Dienstleistungen ohne Rücksicht auf ihr Alter. Ob dein Angebot betroffen ist, klärt der BFSG-Schnelltest in vier Fragen. Dieser Abschnitt erklärt die Rechtslage und ersetzt 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, insbesondere § 14, § 17 und § 38
• EN 301 549 V4.1.1: die neue Fassung mit WCAG 2.2 vom 2. September 2026 (PDF)
• EN 301 549 V3.2.1: die im Amtsblatt genannte Fassung (PDF)
• Planning and Managing Web Accessibility: Vorgehensmodell des W3C WAI
• Involving Users in Web Projects for Better, Easier Accessibility (W3C WAI)