Kundinnen sind oft erschlagen von den Prüf-Berichten, die BTW auch oft schlecht aufbereitet sind. Wegen knapper Ressourcen ist oft die erste Frage, wie man die Finsings aus solchen Prüfberichten priorisieren kann. Es gibt dabei verschiedene Ansätze, die ich hier vorstellen möchte. Diese Ansätze sind teilweise auch verwendbar für projekt-begleitende Umsetzung von Barrierefreiheit, Schwerpunkt ist aber wie gesagt die Umsetzung von Findings bei Barrierefreiheits-Prüfungen.
Am Ende entscheidet die Kundin
Generell muss man sagen, dass der Consultant zwar die Priorisierung vornehmen kann, zumindest bei den meisten hier vorgestellten Methoden. In der Regel muss aber auch die Kundin sich daran beteiligen. Der Consultant kann die internen Abläufe beim Kunden nicht im Detail kennen, ebenso wie die Ressourcen-Planung. Eventuell lohnt es sich, die Vorstellung der Prüf-Ergebnisse so auszugestalten, dass alle relevanten Parteien involviert sind und zumindest die großen Probleme direkt in die Projekt-Planung integriert werden können. Bei einer guten Moderation kann so etwas durchaus in 1,5 bis 2 Stunden durchgeführt werden. Wichtig wäre dabei eine Vorsortierung, es macht keinen Sinn, alle Findings zu besprechen und zu priorisieren.
Wenn Sie eine Priorisierung durch den Consultant wünschen, sollten Sie das direkt in die Beauftragung mit aufnehmen. Ich hatte das immer direkt integriert, aber ich kann nicht für alle Consultants sprechen. Lassen Sie sich auch gerne einen exemplarischen Prüf-bericht vorlegen, um festzustellen, wie gut man damit arbeiten kann. PowerPoint zum Beispiel mag zwar für Demonstrations-Zwecke gut sein, ist aber schlecht für die Übersichtlichkeit, das Filtern und Sortieren oder die Übernahme in Ticket-Systeme.
Priorisierung heißt, dass Sie die Probleme so gewichten, dass Sie sie nach und nach lösen können. Das bedeutet nicht, dass Sie herunter-priorisierte Probleme einfach hinten runterfallen lassen. Die Entscheidung und Verantwortung hat immer die Kundin, nicht der Consultant, er kann nur Vorschläge machen.
Priorisierung nach WCAG-Kriterien
Die Priorisierung nach den WCAG-Kriterien ist die einfachste Form. Sie kann direkt von der Kundin durchgeführt werden, da in den Prüfberichten meistens steht, welcher Konformitätsstufe das Problem zugeordnet ist.
Da A-Kriterien als absolutes Muss für eine barrierefreie Applikation gelten, können sie priorisiert werden gegenüber AA-Kriterien, die zwar in den meisten Staaten verpflichtend sind, aber eben weniger Gewicht haben als A-Kriterien.
Der Vorteil ist dabei, dass man eine objektive Einschätzung hat, während alle anderen vorgestellten Methoden zwar auf Expertinnen-Einschätzungen basieren, aber doch in gewissem Maße subjektiv sind.
Priorisierung nach Schweregrad
Die Priorisierung nach Schweregrad erfordert in der Regel, dass man sich gut mit digitaler Barrierefreiheit auskennt. Das kann aber die Dienstleisterin übernehmen, da es für sie ein geringer Mehr-Aufwand ist.
Wie wird der Impact geschätzt? Dafür gibt es mehrere Anhaltspunkte:
- Es betrifft wichtige Komponenten der Website, zum Beispiel Komponenten, die auf jeder Unterseite vorkommen wie die Haupt-Navigation. Oder es betrifft eine wichtige Komponente wie das Kontaktformular.
- Es ist ein Problem, dass bestimmte Gruppen vollständig ausschließt. Ein Beispiel ist eine Tastaturfalle in einer wichtigen Komponente. Die Fußzeile zum Beispiel ist in der Regel keine wichtige Komponente, die Suchmaske allerdings schon.
- Es ist ein Problem, dass mehrere Komponenten oder Zielgruppen betrifft, zum Beispiel eingeschränkte Bedienbarkeit per Tastatur.
Die Aufteilung nach Rollen
Eine Aufteilung nach Rollen kann ebenfalls sinnvoll sein. Ich unterscheide zwischen Design, Entwicklung und Redaktion. In der Regel ist es zum Beispiel einfacher, redaktionelle als Design- oder Entwicklungs-Probleme zu beheben. Auch das kann die Dienstleisterin übernehmen, in der Regel hat aber die Projekt-Verantwortliche den tieferen Einblick in die internen Abläufe, die Dienstleisterin kann nur eine Einschätzung treffen.
Eine saubere Trennung ist nicht immer möglich. Manchmal kommmt es vor, dass an sich redaktionelle Texte hart rein-gecodet wurden, eine Redakteurin also nicht herankommt. Das Design kann theoretisch leicht geändert werden, erfordert aber oft langwierige Absprachen und muss am Ende von der Entwicklung umgesetzt werden.
Priorisierung nach Einfachheit
Aus der Perspektive der Betroffenen nicht unbedingt die beste Variante, aber manchmal sinnvoll: Es wird danach priorisiert, was am einfachsten behoben werden kann. Der Vorteil sind Quick Winz für die Kundin, was sie eventuell dazu motiviert, mit den schwereren Dingen weiterzumachen. Ein Problem sollte allerdings nicht deshalb vernachlässigt werden, weil es schwer zu beheben ist.
Übrigens gibt es nach meiner Erfahrung keinen Zusammenhang zwischen dem Schweregrad eines Problems und dem Aufwand zu dessen Behebung. Dass einige Entwicklerinnen Probleme dabeihaben, die Tastatur-Bedienbarkeit zu verbessern liebt nicht daran, dass Tastatur-Bedienbarkeit schwer zu implementieren ist. Es liegt eventuell daran, dass sie noch keine Erfahrung mit dem Thema haben, es sich also aneignen müssen oder daran, dass sie es nicht von Anfang an implementiert haben. Es gibt unzählige Patterns für diese und andere Herausforderungen.
Das Priorisierungs-Viereck
Ein kombinierter Ansatz ist das Priorisierungs-Viereck, wie ich es mangels anderer Begriffe nennen möchte. Stellen Sie sich ein Quadrat vor, dass in vier Abschnitte aufgeteilt ist.
- Oben links stehen die Probleme, die leicht behebar sind und einen großen Impact haben.
- Oben rechts stehen die Probleme, die leicht behebbar sind und einen geringen Impact haben.
- Unten links stehen die Probleme, die schwer behebbar sind, aber einen großen Impact haben.
- Unten rechts stehen die Probleme, die schwer behebbar sind und einen geringen Impact haben.
Dabei geht die Priorisierung von links nach rechts und von oben nach unten.