Accessibility in Entwicklungsprozessen

Accessibility im Entwicklungsprozess

0:00 Dieses Modul ist das am wenigsten technische des ganzen Seminars — und es wirkt vermutlich am stärksten. Denn Barrierefreiheit scheitert selten am Können. Nach zwei Tagen wissen Sie genug, um praktisch jeden Fall zu lösen. Sie scheitert an der Zuständigkeit, am Zeitpunkt, an der Priorisierung. Der Leitsatz bringt das auf den Punkt: Ein Sammelticket wird verschoben, ein Kriterium in der Story wird umgesetzt.

0:24 Es geht also darum, das Wissen aus den letzten beiden Tagen so im Prozess zu verankern, dass es nicht von einzelnen engagierten Personen abhängt — sondern einfach passiert.

Accessibility in Entwicklungsprozessen

0:34 Acht Kapitel entlang des Entwicklungsablaufs. Erst die beiden Listen — Definition of Ready und Definition of Done. Dann die Akzeptanzkriterien, die zugleich Testfälle sind. Danach Reviews, Komponentenprüfungen und die Prüfkette in der Pipeline. Zum Schluss zwei organisatorische Kapitel: der Umgang mit dem, was offen bleibt, und die Verteilung der Verantwortung.

0:56 In der Übung entwerfen Sie eine Definition of Done mit höchstens acht Punkten — und diese Obergrenze ist wichtiger, als sie klingt.

Definition of Ready und Definition of Done

1:05 Beginnen wir mit zwei Listen, die es in vielen Teams gibt und in denen Barrierefreiheit meist fehlt. Sie sind Vereinbarungen, keine Werkzeuge — genau deshalb kosten sie nichts und werden trotzdem selten getroffen. Barrierefreiheit gehört in beide Listen, und das aus verschiedenen Gründen. In die Definition of Ready, damit eine Aufgabe erst startet, wenn Tastaturverhalten und Semantik geklärt sind.

1:29 Denn wenn das beim Start unklar ist, wird es im Sprint erfunden — unter Zeitdruck, von jemandem, der gerade daran arbeitet. Und in die Definition of Done, damit die Aufgabe erst fertig ist, wenn das auch geprüft wurde. Beides sind Teamvereinbarungen, keine Werkzeuge. Sie kosten kein Geld, keine Lizenz, keine Einarbeitung — nur eine Entscheidung, die alle mittragen.

1:52 Die Tabelle zeigt für jeden Zeitpunkt eine Frage und ein Beispiel. Bei „Ready" geht es zweimal um Klärung: Ist geklärt, was gilt — etwa das Tastenmuster der Komponente? Und ist das Nötige vorhanden — etwa formulierte Fehlertexte statt nur roter Rahmen? Beides ist die Arbeit, die vor dem Sprint passieren muss, weil sie eine Entscheidung braucht und keine Implementierung.

2:15 Bei „Done" geht es zweimal um Nachweis: Wurde geprüft, und ist es belegt? Achten Sie auf die letzte Zeile — der Befund gehört ins Ticket. Sonst wissen Sie in drei Monaten nicht mehr, ob geprüft wurde. Der erste Stolperstein ist der häufigste bei allen Prozessvereinbarungen: die Listen aufschreiben und im Sprint nicht anwenden.

2:35 Sie hängen dann im Wiki und werden bei der Einarbeitung gezeigt. Der zweite ist eine Gewichtsverschiebung mit Folgen: alles in die Definition of Done packen und nichts in die of Ready. Dann wird am Ende geprüft, was am Anfang hätte geklärt werden müssen — und die Korrektur ist teuer, genau wie bei der Evaluation in Modul zwei.

2:53 Und der dritte ist ein Formulierungsfehler: Punkte formulieren, die niemand prüfen kann. „Ist barrierefrei" ist kein Punkt, das ist eine Hoffnung.

Zugängliche Akzeptanzkriterien in User Stories

3:02 Damit zum wichtigsten praktischen Werkzeug dieses Moduls. Ein gut formuliertes Akzeptanzkriterium leistet dreierlei auf einmal — und das dritte wird in Modul achtzehn richtig interessant. „Barrierefrei umgesetzt" ist kein Kriterium. Es lässt sich nicht prüfen, es lässt sich nicht widerlegen, und es bedeutet für jede Person im Team etwas anderes.

3:24 Prüfbar ist dagegen: Der Dialog erhält beim Öffnen den Fokus, hält ihn, schließt mit Escape und gibt den Fokus an die auslösende Schaltfläche zurück. Das ist der Dreiklang aus Modul zehn, als Satz formuliert. Und jetzt kommt der Teil, den ich besonders schätze: Solche Sätze sind zugleich Testfall und Auftrag an einen Coding Agent.

3:43 Dieselbe Formulierung, die Sie für die Abnahme brauchen, können Sie dem Werkzeug übergeben. Oben steht die Absicht: „Der Umbuchungsdialog ist barrierefrei." Ein Satz, mit dem niemand arbeiten kann. Unten dieselbe Absicht in vier prüfbaren Sätzen. Beim Öffnen liegt der Fokus auf der Überschrift. Der Fokus bleibt im Dialog. Escape schließt. Nach dem Schließen liegt der Fokus wieder auf der auslösenden Schaltfläche.

4:10 Vier Sätze, vier Tests — jeder einzeln prüfbar, jeder eindeutig. Und wie die Fußzeile sagt: Derselbe Text taugt als Auftrag an einen Coding Agent. Das ist ein sehr praktischer Nebeneffekt, auf den wir in Modul achtzehn und neunzehn zurückkommen. Der erste Stolperstein ist der Leitsatz dieses Moduls: Kriterien in ein Querschnittsticket auslagern statt in die Story.

4:34 Das Querschnittsticket heißt dann „Barrierefreiheit verbessern" und wandert von Sprint zu Sprint. Der zweite ist ein Effizienzproblem: wiederkehrende Anforderungen in jeder Story neu formulieren. Was immer gilt — der Fokusindikator, die Tastaturbedienung —, gehört in die Definition of Done, nicht in jede Story. Und der dritte ist eine Zugänglichkeitsfrage in eigener Sache: Kriterien schreiben, die nur mit Spezialwissen prüfbar sind.

5:00 Ihre Kriterien müssen von jemandem prüfbar sein, der dieses Seminar nicht besucht hat.

Design- und Code-Reviews

5:05 Jetzt zwei Momente, in denen Prüfen fast nichts kostet — weil ohnehin jemand hinschaut. Fünf Punkte, eine Minute. Und im Designreview sind Änderungen am billigsten. Zwei Reviews, zwei Zeitpunkte, zwei Prüflisten. Im Designreview lassen sich Kontraste, Fokuszustände, Zielgrößen und Fehlertexte klären — und dort kosten Änderungen am wenigsten, weil noch nichts gebaut ist.

5:30 Ein Fokuszustand, der im Entwurf steht, wird umgesetzt. Einer, der fehlt, wird erfunden oder vergessen. Im Codereview lohnt eine kurze Liste von vier Fragen: die richtigen Elemente, Namen vorhanden, Tastatur bedienbar, kein ARIA ohne Grund. Das ist buchstäblich eine Minute, wenn man weiß, worauf man schaut — und nach zwei Tagen Seminar wissen Sie das.

5:54 Die rechte Spalte sagt, was jedes Review beiträgt. Das Designreview findet, was später teuer zu ändern wäre — Farbentscheidungen, Zielgrößen, Textformulierungen. Das Codereview findet, was im Entwurf gar nicht sichtbar war: welches Element verwendet wurde, ob Namen gesetzt sind, ob die Tastatur funktioniert. Und die dritte Zeile schließt den Bogen zum vorigen Kapitel: Beide prüfen, ob das Kriterium erfüllt ist — also ob die Story fertig ist.

6:20 Wenn Sie Ihre Akzeptanzkriterien gut formuliert haben, ist das Review keine Zusatzarbeit, sondern nur ein Abhaken der Sätze, die schon im Ticket stehen. Der erste Stolperstein ist eine Gewohnheit, die man ändern kann: im Designreview nur über Ästhetik sprechen. Die vier Punkte aus der Tabelle dauern eine Minute und ändern die Qualität der Übergabe erheblich.

6:42 Der zweite ist eine Delegation an die Maschine: im Codereview auf das Werkzeug verweisen statt selbst hinzusehen. Das Werkzeug prüft nicht, ob der Name sinnvoll ist — das haben wir in Modul fünfzehn gesehen. Und der dritte ist die Ursache vieler späterer Reparaturen: Fokuszustände im Entwurf gar nicht darstellen. Was im Entwurf nicht vorkommt, existiert für die Übergabe nicht.

Komponentenprüfungen in Storybook und ähnlichen Umgebungen

7:04 Jetzt die Stelle mit dem größten Hebel im ganzen Prozess. Eine Komponente isoliert zu prüfen ist billiger, als sie später in zwanzig Anwendungsfällen zu suchen. Der Gedanke ist einfach: Prüfen Sie die Komponente dort, wo sie allein steht. Jede Variante bekommt einen eigenen Eintrag, jede Zustandsvariante eine eigene Ansicht — auch Fehler, auch Ladend, auch Deaktiviert, also genau die Zustände aus Modul sechs, die sonst niemand entwirft.

7:31 Und die automatische Prüfung läuft über alle Einträge. Der Gewinn ist doppelt: Sie finden Fehler, bevor sie irgendwo verwendet werden, und Sie können Zustände herstellen, die in der laufenden Anwendung schwer zu erzeugen sind. Dafür brauchen Sie keine Anmeldung, keine Testdaten, kein Netzwerk. Vier Gründe, und der erste ist der wirtschaftliche: Ein Fehler dort wird einmal behoben statt an zwanzig Stellen.

7:55 Bei einem Fokusproblem in der Schaltfläche des Design Systems ist das der Unterschied zwischen einer Stunde und einer Woche. Zweitens lassen sich Zustände einzeln herstellen, was in der Anwendung oft nicht geht. Drittens läuft die Prüfung ohne Anmeldung, Testdaten und Netzwerk — sie ist also schnell und stabil, was für automatische Läufe entscheidend ist.

8:15 Und viertens: Die Vier-Zeilen-Regel aus Modul sechs — Rolle, Name, Tasten, Zustände — ist hier direkt die Testgrundlage. Sie haben die Spezifikation schon. Der erste Stolperstein macht die halbe Wirkung zunichte: nur den Normalzustand als Eintrag anlegen. Genau die Zustände, die im Entwurf fehlen, fehlen dann auch in der Prüfung — und das sind die problematischen.

8:37 Der zweite ist eine Verwechslung von Ebenen: die Prüfung auf die Komponentenwerkstatt beschränken und die Anwendung auslassen. Eine korrekte Komponente kann in einer falschen Struktur landen; Landmarks und Überschriftenhierarchie prüfen Sie nur in der Anwendung. Und der dritte ist Wartungslast ohne Nutzen: Einträge pflegen, die es in der Anwendung so nie gibt.

Die Prüfkette in CI/CD

8:58 Jetzt die Automatisierung. Vier Stufen, die zusammen eine Kette bilden — und eine Aussage über Tore, die ich für die wichtigste dieses Kapitels halte. Vier Stufen, jede mit einem eigenen Zeitpunkt. Linting meldet schon beim Schreiben, was im Code offensichtlich falsch ist — ein Bild ohne Alternativtext, ein Klickhandler auf einem Container.

9:20 Eine Prüfengine in den End-to-End-Tests prüft einzelne Zustände, also das, was Interaktion braucht. Bildvergleiche fangen ein, was beide übersehen — etwa einen verschwundenen Fokusrahmen. Und das Quality Gate entscheidet, was den Build stoppt. Und da kommt der Satz, den ich Ihnen mitgeben möchte: Ein Tor, das nur warnt, wird nach zwei Wochen ignoriert. Das ist keine Vermutung, das ist gelebte Erfahrung in jedem Team.

9:46 Die rechte Spalte zeigt, wie sich die Stufen ergänzen. Linting findet die statischen Fehler beim Schreiben — sofortiges Feedback, kostenlos. Die Prüfengine im Test findet Zustände nach Interaktion, also die dynamischen Fälle aus Modul fünfzehn. Der Bildvergleich findet den verschwundenen Fokusrahmen — ein Beispiel, das ich mag, weil es zeigt, dass manche Regressionen nur visuell erkennbar sind.

10:09 Und das Quality Gate verhindert den Rückfall unter eine einmal erreichte Schwelle. Diese vier zusammen kosten in der Einrichtung ein paar Tage und laufen danach ohne Zutun. Der erste Stolperstein ist der eben genannte: das Tor als Warnung einführen und nie scharf schalten. Die Absicht ist gut — man will das Team nicht überfahren — und das Ergebnis ist Rauschen, das ignoriert wird.

10:33 Der zweite ist die Gegenreaktion und ebenso problematisch: die Schwelle so setzen, dass der Bestand sie sofort reißt. Dann steht die Entwicklung still, und das Tor wird abgeschaltet. Setzen Sie die Schwelle auf den Ist-Zustand und ziehen Sie sie nach. Und der dritte ist ein Praxisproblem: Bildvergleiche über ganze Seiten fahren. Die schlagen bei jeder Textänderung an — nehmen Sie gezielte Zustände.

Umgang mit Findings und technischen Schulden

10:57 Damit zu dem, was bleibt. Denn nicht alles lässt sich sofort beheben — und der ehrliche Umgang damit ist wertvoller als das Versprechen, alles zu schaffen. Nicht alles lässt sich sofort beheben, und das ist in Ordnung. Nicht in Ordnung ist, wenn es verschwindet. Was bleibt, gehört in ein sichtbares Register — mit vier Angaben: Auswirkung, betroffene Nutzergruppe, Behelfslösung und Termin.

11:21 Und jetzt kommt der Bogen zurück zu Modul sieben: Diese Liste ist zugleich der Kern einer ehrlichen Barrierefreiheitserklärung. Sie erinnern sich — die Erklärung soll das Bekannte und Offene benennen. Wenn Sie das Register führen, haben Sie diesen Teil der Erklärung praktisch fertig. Zwei Pflichten, ein Dokument. Das ist eine der wenigen Stellen, an denen Bürokratie sich selbst spart.

11:45 Die rechte Spalte erklärt, warum jedes Feld nötig ist. Ohne Auswirkung wird nicht priorisiert — das ist derselbe Punkt wie beim Befund in Modul fünfzehn. Ohne die betroffene Gruppe wirkt es wie ein Schönheitsfehler, und Schönheitsfehler wandern ans Ende. Ohne Behelfslösung stehen Betroffene ohne Weg da — und dieser Punkt ist mir besonders wichtig: Ein Behelf kann eine Telefonnummer sein, eine E-Mail-Adresse, ein alternativer Weg.

12:11 Er ist nicht die Lösung, aber er ist besser als nichts. Und ohne Termin altert der Eintrag still vor sich hin, bis ihn jemand in zwei Jahren wiederfindet. Der erste Stolperstein ist ein Sichtbarkeitsproblem: offene Punkte im Ticketsystem verstreuen statt sie zu bündeln. Einzeln sind sie fünfzig kleine Tickets, gebündelt sind sie eine Aussage über den Zustand des Produkts.

12:33 Der zweite verschenkt den Doppelnutzen: das Register führen, aber nie in die Erklärung übernehmen. Dann machen Sie die Arbeit zweimal. Und der dritte ist ein Verfallsproblem: Behelfslösungen dauerhaft stehen lassen und den Termin nicht nachziehen. Ein Behelf ist eine Brücke. Wenn er drei Jahre steht, war er in Wahrheit die Lösung — und dann sollte er auch ordentlich gebaut sein.

Verantwortlichkeiten im Team klären

12:56 Das letzte inhaltliche Kapitel benennt die eigentliche Ursache. Barrierefreiheit scheitert selten am Können, meist an der Zuständigkeit — und angenommene Zuständigkeit ist keine. Nach zwei Tagen Seminar wissen Sie genug. Was fehlt, ist meist die Klarheit darüber, wer was macht. Hilfreich ist eine schlichte Aufteilung: Design verantwortet Kontrast, Fokusdarstellung, Zielgrößen und Texte. Entwicklung verantwortet Semantik, Tastatur und Zustände.

13:24 Die Qualitätssicherung verantwortet die Prüfung. Und der Product Owner verantwortet Priorität und Termin. Das Wichtigste steht am Ende: aufgeschrieben, nicht angenommen. Denn angenommene Zuständigkeit ist keine — jeder denkt, jemand anderes macht es, und alle sind überrascht, wenn es fehlt. Ein Absatz im Team-Wiki löst das.

13:46 Die rechte Spalte nennt je Rolle die typische Lücke, und die haben wir alle in diesem Seminar schon gesehen. Design: Der Fokuszustand wurde nie entworfen. Entwicklung: ARIA statt passender Elemente. Qualitätssicherung: nur automatisch geprüft. Und Product Owner: Befunde ohne Einplanung — der Bericht ist da, und es passiert nichts.

14:07 Vier Rollen, vier Lücken, und jede ist mit dem Wissen aus diesem Seminar zu schließen. Meine Empfehlung: Nehmen Sie diese Tabelle mit ins Team und lesen Sie die rechte Spalte gemeinsam. Meist erkennt jeder seine Zeile sofort wieder. Der erste Stolperstein ist gut gemeint und hochwirksam im negativen Sinn: eine Person zur Beauftragten machen und alle anderen damit entlasten.

14:31 Genau das passiert — alle anderen fühlen sich entlastet, und die eine Person wird zum Flaschenhals und zur Spielverderberin. Der zweite kennen Sie aus Modul eins: Zuständigkeit an Rollen hängen statt an konkrete Fragen. Rollen wechseln, Fragen bleiben. Und der dritte ist der klassische Product-Owner-Fehler: die Priorität dem Team überlassen, ohne sie einzuplanen. „Macht das, wenn Zeit ist" heißt in der Praxis: nie.

Übung — Prüfliste und Quality Gate entwerfen

14:57 In der Übung entwerfen Sie Ihre eigene Definition of Done. Mit einer harten Obergrenze von acht Punkten — und diese Grenze ist der eigentliche Lerninhalt. Sie entwerfen eine Definition of Done für Fahrtwind. Geübt wird das Formulieren von Anforderungen, die im Sprint prüfbar und im Tor durchsetzbar sind — beides zusammen, das ist die Schwierigkeit.

15:17 Erfolgreich sind Sie mit höchstens acht prüfbaren Punkten, einer Festlegung je Punkt, ob automatisch oder manuell geprüft wird, und einer Beschreibung des Tors mit Schwelle und Konsequenz. Die acht sind eine harte Grenze, kein Richtwert. Längere Listen werden nicht angewandt — und eine nicht angewandte Liste ist schlechter als eine kurze, weil sie ein Gefühl von Absicherung erzeugt, das nicht trägt.

15:40 Fünf Schritte. Erst sammeln, ohne zu bewerten — Sie werden vermutlich bei zwanzig Kandidaten landen. Dann auf acht kürzen und jeden Punkt prüfbar formulieren; das Kürzen ist die eigentliche Arbeit, weil es Entscheidungen erzwingt. Dann je Punkt festlegen, ob automatisch oder manuell geprüft wird. Dann Schwelle und Konsequenz für das Tor benennen.

16:01 Und Schritt fünf ist der praktische Realitätstest: die Liste gegen eine echte Story halten und streichen, was dort nicht anwendbar war. Die Fußzeile sagt, was dabei passiert — die Liste halbiert sich meist. Und genau das macht sie wirksam. Der erste Stolperstein ist Vollständigkeitsdenken: Punkte aufnehmen, die im eigenen Projekt gar nicht vorkommen.

16:23 Wenn Sie keine Videos haben, brauchen Sie keinen Untertitel-Punkt — er verbraucht nur einen der acht Plätze. Der zweite macht die ganze Übung folgenlos: das Tor ohne Konsequenz beschreiben. Ein Tor ohne Konsequenz ist eine Anzeige. Und der dritte ist ein organisatorischer, der über die Wirksamkeit entscheidet: die Liste ohne die betroffenen Rollen beschließen.

16:44 Eine Definition of Done, die das Entwicklungsteam nicht mitgetragen hat, wird umgangen — und das zu Recht. Vier Punkte. Ein Sammelticket wird verschoben, ein Kriterium in der Story wird umgesetzt — das ist der wichtigste Satz dieses Moduls. Die Komponentenebene hat den größten Hebel: ein Fehler, einmal behoben, statt zwanzigmal gesucht.

17:05 Ein Quality Gate ohne Konsequenz wird nach zwei Wochen ignoriert; schalten Sie es scharf oder lassen Sie es weg. Und offene Punkte gehören in ein Register mit Auswirkung, Behelf und Termin — das ist zugleich der Kern der Barrierefreiheitserklärung aus Modul sieben. Damit ist der handwerkliche Teil des Seminars abgeschlossen. Ab jetzt geht es um KI und Coding Agents.