Barrierefreiheit für agile Teams
Barrierefreiheit gehört in den Prozess – nicht ans Ende.
Viele Teams wollen Barrierefreiheit – sie wissen nur nicht, wo sie im Prozess anfangen soll.
Nicht als Zusatzaufgabe. Als Teil technischer Qualität — genauso wie Tests, sauberer Code und CI/CD.
Die Realität in vielen Teams
-
Zu spät gedacht
Barrierefreiheit wird oft erst kurz vor Release geprüft. Dann ist sie teuer, aufwendig und schwer umzusetzen.
-
Unklare Zuständigkeiten
UX, Frontend, Product – alle sind beteiligt, aber niemand wirklich verantwortlich.
-
Fokus auf Compliance
Reine Checklisten ersetzen keine echte Nutzbarkeit. Wer nur abhakt, hat am Ende weder ein gutes Produkt noch echten Schutz.
-
Gewachsene Systeme
Komplexe Codebasen sind selten Zufall. Sie sind das Ergebnis von Entscheidungen — und die kann man ändern.
Das ist kein individuelles Problem. Es ist ein strukturelles.
Strukturelles Problem
„Das Problem ist selten fehlendes Wissen.
Es ist fehlende Struktur.“
setze ich an.
So arbeite ich
Ich arbeite nicht neben dem Team – ich arbeite im System des Teams.
Ich führe Barrierefreiheit nicht ein. Ich integriere sie in das, was bereits funktioniert – in Discovery, Refinement, Umsetzung und Review.
-
Analyse
Ich verstehe, wo Barrierefreiheit in eurem Prozess gerade hängt – und warum.
-
Struktur schaffen
Klare Verantwortlichkeiten und Standards, die zu eurem Alltag passen – nicht zu einem Lehrbuch.
-
Training
Kein Frontalunterricht – sondern gemeinsames Arbeiten an euren echten Themen mit UX, Frontend und Product.
-
Verankern
Begleitete Umsetzung im Sprint. Ziel ist, dass das Team langfristig eigenständig arbeitet.
Über teil:kraft digital
Warum ich teil:kraft gegründet habe.
Ich arbeite seit vielen Jahren in der Frontend- und Produktentwicklung und habe immer wieder gesehen, wie Barrierefreiheit zu spät kommt – oder gar nicht.
Nicht aus Absicht. Sondern weil Struktur fehlt.
Ich stottere — und ich weiß, wie es sich anfühlt, wenn Interaktion nicht so funktioniert, wie sie sollte. Seit über sieben Jahren engagiere ich mich in der Stotter-Selbsthilfe Berlin — nicht als Betroffener, der darüber redet, sondern als Teil des Orga-Teams, das aktiv Strukturen schafft. Digitale Barrieren sind für mich kein abstraktes Problem.
Deshalb ist teil:kraft keine Beratung von außen – sondern Begleitung von innen. Mit dem Ziel, dass Barrierefreiheit im Team bleibt, wenn ich nicht mehr da bin.
Zertifizierungen & Mitgliedschaften
-
IAAP Member
-
IAAP DACH
Barrierefrei Lehren -
Scrum Master (PSM 1)
-
Stottern & Selbsthilfe
Landesverband Ost e.V.
Warum teil:kraft
Barrierefreiheit, die in eurem Alltag funktioniert
-
Im Prozess, nicht daneben
Ich integriere mich in laufende Sprints – nicht als separate Aufgabe daneben.
-
Technisch fundiert
Ich kenne den Code, das Design und die Produktentscheidungen – und weiß, wo Barrierefreiheit in welcher Schicht entsteht.
-
Praxis statt Theorie
Keine abstrakten Richtlinien – sondern konkrete Umsetzung.
-
Persönliche Perspektive
Ich stottere. Das prägt, wie ich arbeite und begleite — nicht aus der Theorie, sondern aus dem, was Barrieren im Alltag wirklich bedeuten.
Angebot
Barrierefreiheit als Teil eurer Arbeitsweise
Barrierefreiheit ist keine Zusatzdisziplin. Sie ist Teil technischer Qualität — wie Testabdeckung, saubere Architektur oder CI/CD. Wer sie früh einbaut, arbeitet schneller. Wer sie ignoriert, schafft technische Schulden.
Pilotprojekt
Training
Sensibilisierungsworkshop
Barrierefreiheit im Team verankern fängt nicht mit Code an. Der Sensibilisierungs-Workshop schafft ein gemeinsames Verständnis — für alle Rollen, ohne Vorwissen.
-
Für alle Disziplinen - Dev, Design, Product, QA
-
Kein Vorwissen nötig
-
4 Stunden | bis 8 Personen
-
Remote oder vor Ort
Pilotpreis: 760,- € (zzgl. 19% MwSt.)
Weitere Angebote in Planung
Beratung
Integration in agile Prozesse
In Planung
Beratung
Integration in agile Prozesse
In Planung
Monatliche Begleitung, integriert in euren Prozess — nicht daneben.
-
Integration in Scrum und Produktprozesse
-
Definition of Done & Qualitätskriterien
-
Priorisierung und Roadmap
-
Unterstützung bei strukturellen Entscheidungen
Prüfung
Barrierefreiheits-Audits
In Planung
Prüfung
Barrierefreiheits-Audits
In Planung
Strukturierte Analyse eurer Anwendung mit klarer Priorisierung und konkreten Handlungsschritten.
-
Tests mit Screenreader und Tastatur
-
WCAG Bewertung
-
Einschätzung von Risiken und Auswirkungen
-
Konkrete, umsetzbare Empfehlungen
-
Re-Tests und Validierung
Barrierefreiheit lässt sich integrieren
wenn ihr wisst, wo ihr ansetzt. Ich unterstütze euch dabei.
FAQ
Fragen, die oft kommen
Barrierefreiheit wirft viele Fragen auf – vor allem in bestehenden Teams und Prozessen.
Hier sind die häufigsten.
Ist Barrierefreiheit aufwendig?
Ist Barrierefreiheit aufwendig?
Wenn Barrierefreiheit spät kommt: ja.
Wenn sie Teil des Prozesses ist: nicht mehr als andere Qualitätsanforderungen.
Brauchen wir zuerst ein Audit?
Brauchen wir zuerst ein Audit?
Nicht unbedingt.
Oft ist es sinnvoller, erst den Prozess zu verstehen und dann gezielt zu prüfen.
Müssen wir alles sofort umsetzen?
Müssen wir alles sofort umsetzen?
Nein. Es geht um Priorisierung und sinnvolle Schritte – nicht um Perfektion.
Wie schnell sehe ich Wirkung?
Wie schnell sehe ich Wirkung?
Erste Verbesserungen zeigen sich oft schon nach wenigen Sprints – zum Beispiel klarere Fokus-Reihenfolgen, bessere Formularbeschriftungen oder barrierefreiere Komponenten. Was sich länger braucht: strukturelle Verankerung im Team. Das ist das eigentliche Ziel.
Wer ist verantwortlich im Team?
Wer ist verantwortlich im Team?
Das ist einer der häufigsten Gründe, warum Barrierefreiheit liegen bleibt – nicht fehlendes Wollen, sondern fehlende Zuständigkeit. Ich helfe dabei, klare Verantwortlichkeiten zu definieren, die zu eurer Teamstruktur passen – ohne neue Rollen erfinden zu müssen.
Kann Barrierefreiheit auch Kosten sparen?
Kann Barrierefreiheit auch Kosten sparen?
Ja – deutlich sogar. Fehler, die erst im QA oder kurz vor Release entdeckt werden, sind aufwendig zu beheben. Barrierefreiheit früh einzubeziehen reduziert Nacharbeit, verkürzt Review-Zyklen und verhindert kostspielige Ausnahme-Lösungen. Und: ein klarer Prozess spart Abstimmungsaufwand.
Unser Team hat gerade keine Kapazitäten dafür
Unser Team hat gerade keine Kapazitäten dafür
Das ist der häufigste Einwand – und oft ein Zeichen, dass Barrierefreiheit bislang als Extra-Aufwand wahrgenommen wird. Genau das ist das Problem, das ich löse. Ich integriere mich in bestehende Sprints und Abläufe, anstatt neue dazuzulegen. Das Ziel ist, dass eure Kapazität für Barrierefreiheit langfristig sinkt – nicht steigt.
Kann eine Einzelperson das leisten?
Kann eine Einzelperson das leisten?
Die kurze Antwort: Ja – und oft besser als ein größeres Team.
Barrierefreiheit in Prozesse zu integrieren ist keine Frage von Kapazität, sondern von Kontinuität. Was Teams wirklich hilft, ist eine Person, die über Sprints hinweg dabei ist, Kontext aufbaut und dort anspricht, wo Entscheidungen entstehen.
Genau das kann ich als Einzelperson leisten – direkt, ohne Umwege, mit vollem Fokus auf euer Team.
Gilt das BFSG überhaupt für uns?
Gilt das BFSG überhaupt für uns?
Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt ab Juni 2025 für viele digitale Produkte und Dienstleistungen, die an Verbraucher:innen gerichtet sind – unabhängig von der Unternehmensgröße. Ob und in welchem Umfang euer Produkt betroffen ist, kläre ich gerne im Erstgespräch. Und selbst wenn keine direkte Pflicht besteht: die rechtlichen Anforderungen nehmen zu, und wer früh anfängt, hat den Vorteil.
Können wir das nicht intern lösen?
Können wir das nicht intern lösen?
Ja – und das ist das Ziel. Ich bin kein Dauerdienstleister. Mein Ansatz ist darauf ausgelegt, dass euer Team am Ende eigenständig arbeitet: mit klaren Standards, Verantwortlichkeiten und dem nötigen Know-how. Was ich mitbringe, ist die Außenperspektive, die Struktur und das Fachwissen, das intern oft (noch) fehlt. Danach läuft es ohne mich.
Barrierefreiheit in euren Prozess holen?
In einem kostenlosen 30-minütigen Erstgespräch schauen wir gemeinsam, wo euer Team aktuell steht – und was der nächste realistische Schritt ist.