Accessibility-Findings im Ticketing priorisieren nach Schweregrad

1. Warum unpriorisierte Findings im Backlog-Friedhof verschwinden

Ein typisches Muster in vielen Teams sieht so aus: Ein umfangreiches Accessibility-Audit wird beauftragt, liefert einen langen PDF-Bericht mit hunderten Einzelbefunden, und diese Befunde werden pauschal als Tickets angelegt, ohne dass zwischen einer Barriere, die den Checkout vollständig blockiert, und einer kosmetischen Abweichung im Fußzeilentext unterschieden wird. Das Ergebnis ist ein Backlog, in dem sich niemand traut, mit der Abarbeitung zu beginnen, weil die schiere Menge überfordert und keine der Priorität erkennbar ist.

Nach wenigen Wochen verlieren diese Tickets an Aktualität, werden von neuen, fachlich dringlicheren Anforderungen verdrängt und verbleiben unbearbeitet über Monate oder Jahre im Backlog, ein Zustand, der in vielen Teams treffend als Accessibility-Backlog-Friedhof bezeichnet wird. Eine konsequente Priorisierung nach Schweregrad direkt bei der Erfassung jedes einzelnen Findings ist der wirksamste Hebel, um genau dieses Schicksal zu vermeiden.

2. Schweregrad-Kategorien: Blocker, Major und Minor

Eine bewährte Einteilung unterscheidet drei Kategorien: Ein Blocker verhindert eine zentrale Funktion vollständig für eine bestimmte Nutzergruppe, etwa ein per Tastatur nicht erreichbarer Bestätigen-Button im Checkout, und wird typischerweise gegen WCAG-Kriterien der Konformitätsstufe A gemessen, deren Nichteinhaltung als grundlegender Ausschluss gilt. Ein Major-Finding erschwert eine Funktion erheblich, ohne sie vollständig unmöglich zu machen, etwa eine verwirrende, aber technisch noch bedienbare Formularvalidierung, und orientiert sich häufig an Stufe AA.

Ein Minor-Finding schließlich betrifft Komfort und Konsistenz, ohne eine Aufgabe grundsätzlich zu verhindern, etwa ein Fokusindikator, der zwar sichtbar, aber optisch wenig auffällig ist. Diese Einteilung orientiert sich bewusst an den WCAG-Konformitätsstufen A, AA und AAA, übernimmt sie aber nicht eins zu eins, weil die tatsächliche Priorität zusätzlich von der betroffenen Nutzergruppe und der Häufigkeit der betroffenen Interaktion abhängt, nicht allein von der formalen Konformitätsstufe des verletzten Kriteriums.

3. Impact-Einschätzung nach betroffener Nutzergruppe

Neben der reinen Schwere eines technischen Verstoßes lohnt sich eine zweite, unabhängige Dimension: wie viele Nutzende welcher Gruppe tatsächlich betroffen sind und wie zentral die betroffene Seite für den gesamten Kaufprozess ist. Ein fehlendes Alt-Attribut auf einer selten besuchten Unterseite hat einen anderen Impact als dasselbe fehlende Alt-Attribut auf dem Hauptprodukt der Startseite, selbst wenn beide technisch identisch als dieselbe WCAG-Regelverletzung eingestuft werden.

Für die Einschätzung hilft eine einfache Matrix, die den technischen Schweregrad auf der einen Achse gegen die geschätzte Reichweite, etwa Seitenaufrufe pro Monat oder Zentralität im Bestellprozess, auf der anderen Achse stellt. Ein Blocker auf einer stark frequentierten Seite wie dem Checkout landet dabei konsequent an oberster Stelle der Priorität, während derselbe Blocker auf einer kaum besuchten Archivseite zwar weiterhin dringend, aber weniger zeitkritisch bleibt.

4. Konkrete Beispiele je Schweregrad-Kategorie

Ein typischer Blocker im Magento-Kontext ist eine Tastaturfalle in einem modal geöffneten Warenkorb-Dialog, aus dem sich per Tastatur nicht mehr herausnavigieren lässt, weil der Fokus fälschlicherweise innerhalb des Dialogs gefangen bleibt, selbst nachdem der Dialog geschlossen werden sollte. Ein Major-Finding ist häufig ein fehlender oder inhaltlich nichtssagender Alt-Text auf zentralen Produktbildern der Produktdetailseite, der Screenreader-Nutzenden eine sinnvolle Kaufentscheidung erheblich erschwert, ohne den Kauf technisch vollständig zu verhindern.

Ein klassisches Minor-Finding ist ein Fokusindikator, der zwar den WCAG-Mindestanforderungen an Kontrast und Dicke genügt, sich aber optisch kaum vom Standard-Zustand eines Elements unterscheidet und dadurch die Orientierung bei der Tastaturnavigation unnötig erschwert, ohne sie unmöglich zu machen. Diese abgestuften Beispiele helfen dem gesamten Team, neue Findings konsistent und nachvollziehbar in dieselbe Kategorie einzuordnen wie bereits bekannte, vergleichbare Fälle.

5. Aufnahme in bestehende Jira- oder Linear-Workflows

Statt Accessibility-Findings als separaten, isolierten Bug-Typ außerhalb des gewohnten Workflows zu führen, empfiehlt sich die Integration als eigenes Label oder benutzerdefiniertes Feld innerhalb des bestehenden Ticketsystems, etwa ein Feld a11y-severity mit den Werten Blocker, Major und Minor, das parallel zur ohnehin vorhandenen Priorität des Tickets gepflegt wird. Diese Integration stellt sicher, dass Accessibility-Findings im selben Sprint-Planning und im selben Backlog-Grooming behandelt werden wie jeder andere fachliche Bug, statt in einem separaten, häufig übersehenen System zu verschwinden.

Ein einheitliches Ticket-Template mit festen Pflichtfeldern, etwa betroffene URL, verletztes WCAG-Kriterium, verwendete Testmethode und Schweregrad-Kategorie, beschleunigt sowohl die Erfassung neuer Findings als auch deren spätere Bearbeitung erheblich, weil Entwicklerinnen und Entwickler nicht erst in einem separaten Audit-Dokument nach dem fachlichen Kontext suchen müssen.

# Beispiel-Ticket-Template für Accessibility-Findings (Jira Custom Fields)
title: "[A11Y][Blocker] Fokus in Warenkorb-Dialog gefangen"
labels: [accessibility, a11y-severity-blocker]
custom_fields:
  wcag_criterion: "2.1.2 Kein Tastaturfokus-Trap (Stufe A)"
  test_method: "Manuelle Tastaturnavigation, NVDA"
  affected_url: "/checkout/cart"
  affected_group: "Tastaturnutzende, Screenreader-Nutzende"
  sla_days: 5

6. Verknüpfung mit WCAG-Kriterium und Testmethode

Jedes Ticket sollte explizit angeben, welches konkrete WCAG-Erfolgskriterium verletzt wird und mit welcher Methode der Befund festgestellt wurde, etwa automatisiert per axe-core, manuell per Tastaturnavigation oder im Rahmen eines Nutzertests mit einer Person mit Behinderung. Diese Verknüpfung erlaubt es, später gezielt nach allen offenen Verstößen gegen ein bestimmtes Kriterium zu filtern, etwa um vor einer erneuten externen Zertifizierung gezielt alle noch offenen Stufe-A-Verstöße zu identifizieren.

Zusätzlich hilft die Angabe der Testmethode bei der Priorisierung selbst, weil ein Befund aus echtem Nutzertesting, wie im entsprechenden Artikel dieser Reihe beschrieben, typischerweise eine höhere Priorität verdient als ein rein automatisiert gefundener Verstoß, da er nachweislich zu einer echten Schwierigkeit bei einer echten Person geführt hat.

7. Bearbeitungszeiten und SLA je Schweregrad definieren

Ohne eine verbindliche Bearbeitungsfrist bleibt selbst ein korrekt als Blocker eingestuftes Finding folgenlos, wenn es im Sprint-Planning wiederholt zugunsten neuer Features verschoben wird. Ein klar definiertes Service-Level, etwa Blocker innerhalb von fünf Werktagen, Major innerhalb von vier Wochen und Minor innerhalb des nächsten regulären Quartalsplanungszyklus, gibt dem Team eine verbindliche, überprüfbare Grundlage, an der sich die tatsächliche Bearbeitung messen lässt.

Diese Fristen sollten regelmäßig, etwa monatlich, gegen die tatsächlich noch offenen Tickets ausgewertet werden, damit ein überschrittener Blocker sofort sichtbar wird und eskaliert werden kann, statt erst beim nächsten großen Audit erneut aufzufallen.

8. Vermeidung des Backlog-Friedhofs durch regelmäßige Reviews

Selbst mit sauberer Kategorisierung droht ein Backlog erneut zu einem Friedhof zu werden, wenn niemand regelmäßig aktiv hineinschaut. Ein monatliches Accessibility-Review-Meeting, bei dem gezielt alle offenen Findings nach Schweregrad und Alter durchgegangen werden, verhindert, dass ein einzelnes Ticket über Monate unbemerkt liegen bleibt, und schafft gleichzeitig einen festen Anlass, um überfällige Blocker gegenüber dem Management sichtbar zu eskalieren.

Ein einfaches, aber wirkungsvolles Dashboard, das die Anzahl offener Findings je Schweregrad-Kategorie über die Zeit darstellt, macht Fortschritt oder Stillstand auf einen Blick sichtbar und eignet sich zusätzlich als Reporting-Grundlage gegenüber der Geschäftsleitung, etwa im Kontext des European Accessibility Act, bei dem eine dokumentierte, nachvollziehbare Bearbeitung von Findings zunehmend an Bedeutung gewinnt.

9. Verantwortlichkeiten und Eskalationswege festlegen

Jedes Ticket braucht eine eindeutig verantwortliche Person oder ein eindeutig verantwortliches Team, nicht nur eine allgemeine Zuordnung an das Frontend-Team als Ganzes, weil diffuse Verantwortung in der Praxis dazu führt, dass sich niemand konkret zuständig fühlt. Für Blocker-Findings sollte zusätzlich ein klarer Eskalationsweg definiert sein, etwa eine direkte Benachrichtigung an die Teamleitung, sobald ein Blocker die definierte Bearbeitungsfrist überschreitet, statt auf das nächste reguläre Review-Meeting zu warten.

Diese klare Verantwortlichkeit sollte bereits bei der Ticketerstellung festgelegt werden, nicht erst nachträglich im Sprint-Planning, damit ein Blocker-Finding nicht zunächst tagelang unzugeordnet im Backlog liegt, bevor überhaupt jemand mit der Bearbeitung beginnen kann.

10. Zusammenfassung

11. FAQ: Accessibility-Ticketing: Das Wichtigste auf einen Blick