Zum Inhalt springen

Arbeitsweise · Haltung und Methode

Erst der Mensch, dann die Technik.

Barrierefreiheit gehört in den Prozess – nicht ans Ende. Ich arbeite in eurem Team, nicht als externer Auditor davor oder danach.

Hier erfahrt ihr, was mich dabei leitet, wie das 5-Linsen-Modell funktioniert und wo es in eurem Sprint andockt.

Haltung

Fünf Grundsätze, nach denen ich arbeite.

Kein Leitbild für die Wand. Eher das, was in einer guten CONTRIBUTING.md steht: wie wir zusammenarbeiten, damit das Ergebnis trägt.

  1. Erst der Mensch, dann die Technik.

    Der Mensch mit seinen Herausforderungen, Bedürfnissen und Erfahrungen besucht eure Seite – nicht das WCAG-Kriterium. Deshalb denken wir zuerst in Menschen und ihren Situationen. Die Kriterien folgen daraus.

  2. In den Prozess, nicht ans Ende.

    Barrierefreiheit gehört ins Ticket, nicht ins Abnahmeprotokoll. Was im Refinement eine Frage kostet, kostet nach dem Release einen Umbau.

  3. Teil des Teams – nicht der Auditor davor oder danach.

    Ich sitze mit im Refinement, schaue in eure Designs und spreche eure Sprache: Story, Definition of Done, Pull Request. Ich schicke keinen Bericht von außen, sondern arbeite mit euch an euren echten Tickets.

  4. Barrierefreiheit gehört zu guter Software-Qualität.

    Genau wie sauberer Code, Tests oder eine stabile Pipeline. Wer sie aufschiebt, baut technische Schulden auf – und zahlt später mit Zinsen.

    „Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.“

    “Continuous attention to technical excellence and good design enhances agility.”

    Agiles Manifest, Prinzip 9

  5. Barrierefreiheit wird ein selbstverständlicher Teil eurer Prozesse.

    Nicht als Projekt daneben, sondern als Gewohnheit: im Refinement, im Design, im Review. Ich ziehe mich zurück, sobald es ohne mich läuft.

Das 5-Linsen-Modell

Fünf Linsen, damit niemand vergessen wird.

Jede Linse steht für Menschen und die Art, wie sie digitale Produkte nutzen. Und fast jede:r schaut irgendwann selbst durch eine davon – dauerhaft, vorübergehend oder in einer bestimmten Situation.

Im Ticket

So sieht das im Ticket aus.

Aus jeder Linse wird ein prüfbares Akzeptanzkriterium – mit klarer Zuständigkeit.

  1. Linse anlegen

    Im Refinement fragt ihr: Wer könnte an dieser Story scheitern?

  2. Kriterium formulieren

    Aus der Antwort wird ein Satz, den man prüfen kann – kein „sollte barrierefrei sein“.

  3. Zuständigkeit klären

    Design, Dev, Redaktion oder Product: Jedes Kriterium hat eine Rolle, die es einlöst.

Beispielticket
SHOP-482 · Story Refinement

Als Kund:in möchte ich meine Lieferadresse ändern.

Akzeptanzkriterien Barrierefreiheit

  • Alle Felder per Tastatur erreichbar, sichtbarer Fokus Motorik Dev
  • Kontrast der Fehlermeldung mind. 4,5:1 Sehen Design
  • Fehlermeldung nennt Feld und Lösung Kognition Redaktion
  • Fehler werden per Screenreader angekündigt Sehen Dev

Jede Linse wird zu einem prüfbaren Kriterium – mit klarer Zuständigkeit.

Im Sprint

Wo die Linsen in eurem Sprint andocken.

Keine Extra-Meetings, kein Paralleluniversum. Barrierefreiheit läuft in den Terminen mit, die ihr ohnehin habt – und die Definition of Done hält alles zusammen.

Definition of Done · inklusive Barrierefreiheit

  1. Schritt 01

    Refinement

    Team
    Ihr wendet die Linsen auf die Story an und leitet daraus Akzeptanzkriterien ab.
    Ich
    Ich stelle die Fragen – bis ihr sie selbst stellt.

  2. Schritt 02

    Design

    Team
    Ihr annotiert eure Absicht: Überschriften, Fokusreihenfolge, Alternativtexte, Landmarks. Und prüft Touch-Targets, Kontraste und Zustände wie Fokus, Fehler und Disabled.
    Ich
    Ich gehe die Annotationen mit euch durch.

  3. Schritt 03

    Entwicklung

    Team
    Ihr prüft nebenbei mit Tastatur, Zoom auf 200 % und Screenreader – nicht erst am Ende.
    Ich
    Ich bin für Pairing ansprechbar.

  4. Schritt 04

    Code Review

    Team
    Barrierefreiheit steht im PR-Template. Ihr reviewt euch gegenseitig.
    Ich
    Auf Wunsch schaue ich stichprobenartig in PRs – nicht in jeden.

  5. Schritt 05

    Sprint Review

    Team
    Ihr führt die Demo einmal mit Tastatur oder Screenreader vor.
    Ich
    Ich zeige, was Nutzer:innen dabei erleben.

  6. Schritt 06

    Retro

    Team
    Ihr fragt: Was ist durchgerutscht – und warum?
    Ich
    Ich helfe, den Prozess anzupassen.

Und im nächsten Sprint wieder von vorn – jedes Mal ein bisschen selbstverständlicher.

Ihr arbeitet mit Kanban? Funktioniert genauso – Hauptsache, es gibt Tickets.

gemeinsam
weiter

Ein 38-seitiger Audit-Bericht mit Befunden, darauf ein Zettel: Und jetzt?

Nach dem Audit

Ich lasse euch mit dem Bericht nicht allein.

Ein Audit ist ein Anfang, kein Ergebnis.

Wir gehen die Befunde gemeinsam durch, klären Fragen direkt im Code, und ich prüfe nach, ob eure Lösungen tragen. Wenn ihr wollt, begleite ich euch dabei, dass dieselben Fehler gar nicht erst wieder entstehen.

  • 60 Minuten Ergebnis-Call

  • Offene Fragen direkt im Code klären

  • Re-Test der Kernprobleme, ohne Frist

  • Auf Wunsch: Begleitung im Sprint

Zum Accessibility Audit Zur Begleitung im Sprint

Einstieg

Klingt nach eurem Team? So könnt ihr anfangen.

Einsteig

Flow-Check

Ihr wollt sehen, wie das an eurem Produkt aussieht? Ich gehe einen eurer Flows mit euch durch.

Mehr zum Flow-Check

Wissen

Workshops

Euer Team lernt die Linsen kennen – an Beispielen, die zu eurem Alltag passen.

Alle Workshops ansehen

Verankerung

Begleitung im Sprint

Ich arbeite in euren Sprints mit, bis Barrierefreiheit selbstverständlich ist.

Mehr zur Begleitung

Barrierefreiheit lässt sich integrieren wenn ihr wisst, wo ihr ansetzt. Ich unterstütze euch dabei.

Gemeinsam schauen wir uns an, wie das in eurem Team konkret aussehen kann – und wo ich am meisten unterstützen kann.

Kostenloses Erstgespräch vereinbaren