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 einfangen kann“) beschränkt sich auf die Behebung dieses einen Problems. Es berücksichtigt nicht, wovon dieses Problem abhängt: den Rest der Tastaturnavigation, die Ansagen des Screenreaders und den Farbkontrast, der wahrscheinlich auch im nächsten Modal dasselbe Problem aufweist. 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 bereitstellen, werden Sie im nächsten Sprint wiederkommen müssen – für das „Geschwisterelement“ und dessen „Geschwisterelement“ –, bis jemand einräumt, 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 durch oder nur die eine, ü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 abgeschlossen ist?

Wenn es sich um eine Klasse und nicht um eine Instanz handelt, trennen Sie die Komponente, auf die Kunden zugreifen, von der Überprüfung der übrigen Komponenten und passen Sie den Umfang jeder Komponente an das an, 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 vorgelagerten Bereich gering, während der eigentliche Arbeitsaufwand in der nachgelagerten Abdeckung liegt. Sehen Sie sich die anderen Beispiele für Schätzungen an oder starten Sie eine kostenlose Planning-Poker-Sitzung, sobald der Umfang vereinbart ist.