Abschätzung des Aufwands für eine Barrierefreiheitskorrektur

Korrekturen im Bereich der Barrierefreiheit sind keine Fehler. Es handelt sich um Funktionen, die das Team bei der ersten Veröffentlichung nicht integriert hat.

Ein Barrierefreiheitsproblem als Fehler zu behandeln („Beheben Sie das Modal, damit es den Fokus einfangt“) beschränkt sich auf die Behebung dieses einen Problems. Es berücksichtigt jedoch nicht, wovon dieses Problem abhängt: die übrige Tastaturnavigation, die Ansagen des Bildschirmleseprogramms sowie den Farbkontrast, bei dem wahrscheinlich auch im nächsten Modal dasselbe Problem auftritt. Die meisten „kleinen Barrierefreiheitskorrekturen“ sind Einstiegspunkte in eine Problemklasse, die sich durch die gesamte Komponente zieht.

Die realistische Schätzung bezieht sich auf die Klasse, nicht auf die Instanz. Wenn Sie eine Korrektur ausliefern, werden Sie im nächsten Sprint wiederkommen, um sich um das „Geschwisterelement“ zu kümmern, und dann um das „Geschwisterelement des Geschwisterelements“, bis jemand zugibt, dass es sich bei der Aufgabe um die „Überprüfung des Interaktionsmodells für Modalfenster“ handelt, und den Aufwand entsprechend bemisst.

Was in dem Raum gesagt wird

Frontend: „Das Einfügen der Fokusfalle dauert einen halben Tag.“

Frage: „Wird die Schaltfläche ‚Schließen‘ von Bildschirmleseprogrammen angesagt?“

Designer: „Ist der Kontrast bei der sekundären Schaltfläche ausreichend?“

Leitfrage: „Wie viele andere Modalverben haben dieselbe Form?“

PM: „Machen wir alle oder nur die, über die sich die Kunden beschwert haben?“

Fragen, die man sich vor der Stimmabgabe stellen sollte

• Handelt es sich hierbei um eine Instanz oder um eine Klasse? Wie viele ähnliche Komponenten gibt es?
• Umfang der Prüfung: diese Komponente, diese Seite, dieses Produkt?
• WCAG-Zielstufe: A, AA, AAA?
• Tests: Axe, manueller Screenreader, Durchlauf ausschließlich über die Tastatur?
• Regressionsvermeidung: Lint-Regel, Story-Snapshot, CI-Prüfung?
• Wie hoch ist das laufende Budget für die Barrierefreiheitsarbeit, nachdem dieses Projekt umgesetzt wurde?

Wenn es sich um eine Klasse und nicht um eine Instanz handelt, trennen Sie mit split die Komponente, auf die Kunden zugreifen, von der Überprüfung der übrigen Komponenten und vergleichen Sie die jeweiligen Umfänge mit dem, wozu Sie sich tatsächlich verpflichten.

Legen Sie die Größe der Klasse fest, nicht die der Instanz. Eine „Fokusfalle“ ist ein halber Tag; das dahinterstehende Muster ist die Geschichte.

Ähnlich wie bei der Schätzung einer Änderung am Design-System ist die Korrektur im Upstream-Bereich gering, während der eigentliche Arbeitsaufwand im Downstream-Bereich liegt. Sehen Sie sich die anderen Beispiele für durchgeführte Schätzungen an oder starten Sie eine kostenlose Planning-Poker-Sitzung, sobald der Umfang vereinbart ist.