Heute geht es darum, wie man aus Kundensicht auf Prüfberichte blicken und wie man mit ihnen umgehen sollte.
Warum sind Prüfberichte so umfangreich?
Zuerst einmal solltet ihr generell damit rechnen, dass diese Prüfberichte sehr umfangreich sind. Ich weiß zwar nicht, wie kompakt ein klassischer Software-Testbericht aussieht, aber ich vermute, diese sind etwas kürzer.
Dass Berichte zur Barrierefreiheit so lang sind, liegt an den vielen Meta-Informationen. Es gibt eine ausführliche Einleitung, in der die Rahmenbedingungen dokumentiert werden, und jeder einzelne Prüfschritt wird genau aufgeführt. Den meisten Platz nimmt jedoch die Dokumentation der Fehler ein – vor allem durch die Beschreibungen und die Screenshots. Gerade wenn mehrere Screenshots pro Issue (also pro gefundenem Problem) enthalten sind, bläht das den Bericht auf.
Ich habe schon erlebt, dass Unternehmen diese Berichte als PowerPoint-Präsentation bereitstellen. Das halte ich persönlich für absolut überflüssig. Besonders im öffentlichen Dienst gibt es leider immer noch Personen, die solche Berichte ausdrucken – und das oft mehrfach, damit jeder eine Kopie hat. Bei PowerPoint ist das reine Papier- und Ressourcenverschwendung. In einer PDF-Datei ist es in der Regel etwas kompakter, aber oft immer noch umfangreicher als nötig. Wenn ihr die Wahl habt – und das solltet ihr immer so einfordern –, verlangt ein Format, mit dem man direkt weiterarbeiten kann. Das kann Markdown, HTML oder JSON sein. Also ein Format, das sich möglichst automatisiert weiterverarbeiten und direkt in Ticket-Systeme (wie Jira) überspielen lässt. Umfangreich bleibt es wegen der Screenshots und Beschreibungen trotzdem, und es hängt natürlich davon ab, wie viele Barrieren gefunden wurden. Das wird häufig unterschätzt, gehört aber dazu.
Die Herausforderung mit der Fachsprache
Die zweite große Herausforderung ist die Sprache. Wir Barrierefreiheits-Expertinnen versuchen immer, die Problembeschreibungen allgemein verständlich zu formulieren. Unsere Zielgruppe beim Kunden sind ja nicht nur Entwicklerinnen und Entwickler, sondern auch das Management oder die Projektleitung. Wir wissen, dass die Lesenden in der Regel keine Fachleute für Barrierefreiheit sind.
Auf der anderen Seite müssen wir uns kurz fassen. Wenn wir anfangen, tiefere Details wie die genaue ARIA-Semantik im Bericht zu erklären, nimmt das kein Ende. Das wäre zu viel Text, der den Beteiligten vor Ort oft gar nicht weiterhilft. Hier stoßen wir an Zeit- und Ressourcen-Grenzen – und auch die Geduld der Lesenden ist nicht unbegrenzt.
Achtet darauf, ob die Beschreibungen verständlich sind. Lest am besten stichprobenartig rein und prüft, ob die Entwicklungsteams damit arbeiten können. Natürlich wird nicht jeder Begriff sofort klar sein. Wir müssen in den Berichten Fachbegriffe wie ARIA, Maschinenlesbarkeit oder Semantik verwenden. Das tun wir, damit die Entwicklerinnen und Entwickler die Probleme exakt recherchieren können. Wenn wir hier ungenaue Begriffe verwenden, wird die eigene Recherche im Netz extrem schwierig.
Dabei ist es oft sinnvoller, die englischen Fachbegriffe (gerade bei ARIA) zu nutzen. Auf Deutsch ist vieles nicht gut oder uneinheitlich dokumentiert. Von der WCAG gibt es beispielsweise mehrere deutsche Übersetzungen (die offizielle Übersetzung, die Fassung aus der BITV, die Version für den EN-Standard etc.), die sich nicht immer einig sind. Mit den englischen Begriffen findet man beim Recherchieren deutlich mehr und präzisere Informationen.
Deshalb müssen wir voraussetzen, dass die Kundenseite ihren Teil der Arbeit leistet. Wenn Begriffe wie „ARIA“ oder „Live-Regionen“ unklar sind, muss man diese selbst recherchieren. Um dieses Thema kommt man bei der Barrierefreiheit nicht herum.
Beratung sichert den Erfolg
Deshalb empfehle ich euch dringend: Buche nicht nur den reinen Test, sondern hole dir direkt die passende Beratung dazu. Am besten beauftragt man die Beratung bei der Stelle, die auch den Test durchgeführt hat, weil das erfahrungsgemäß viel reibungsloser abläuft.
Das Schlechteste, was man tun kann, ist, einen Test machen zu lassen und den Bericht dann in der Schublade liegenzulassen – frei nach dem Motto: „Wir haben den Test gemacht, damit ist unsere Pflicht erfüllt.“ Das ist völliger Quatsch, dann kann man es auch gleich lassen.
Der zweitgrößte Fehler ist es, den Prüfbericht ohne entsprechendes Fachwissen im eigenen Team umsetzen zu wollen. Es ist toll, wenn man diese Expertise im Haus hat. Wenn nicht, ist es am einfachsten, sich Unterstützung zu holen – entweder von der Prüfstelle oder von einer neutralen Person für das Consulting.
Ich sage das nicht, um mehr Aufträge zu generieren, sondern weil die Praxis zeigt: Ohne Barrierefreiheits-Expertise ist die Umsetzung extrem zäh, schwierig und fehleranfällig. Zudem kann die Prüfstelle natürlich keine Verantwortung für das Endergebnis übernehmen, wenn es vorab keine fachliche Abstimmung gab.
Checkliste: Worauf solltet ihr bei einem Prüfbericht achten?
Wenn ihr einen Prüfbericht erhaltet, sollten die folgenden Kerninformationen (Metadaten) immer enthalten sein:
– Geprüfte Seiten/Ansichten: Welche Teile des Produkts wurden getestet?
– Kriterienkatalog: Welcher Standard wurde zugrunde gelegt? (In der Regel die europäische Norm EN 301 549 oder die WCAG 2.2).
– Konformitätsstufe: Bei der WCAG sollte immer dabei stehen, welche Stufe geprüft wurde (A, AA oder AAA).
– Basisdaten: Das Prüfdatum und der Name der prüfenden Firma. Das Datum ist wichtig, weil sich am Produkt während oder nach dem Test noch Dinge geändert haben könnten.
Die Kernfrage lautet: Ist die Dokumentation der Prüfschritte wirklich vollständig? Ein gut dokumentierter Mangel muss immer folgende Elemente enthalten:
1. Den konkreten WCAG- oder EN-Prüfschritt.
2. Die genaue Problembeschreibung.
3. Einen Lösungsvorschlag oder das erwartete Verhalten (Soll-Zustand).
Es muss also immer klar daraus hervorgehen: Was läuft aktuell falsch und wie sollte es eigentlich aussehen?
Transparenz bei den Prüfwerkzeugen
Ein weiterer wichtiger Aspekt ist die Frage: Welche Prüfwerkzeuge wurden benutzt? Einige Kriterien werden rein visuell geprüft, wie zum Beispiel eine sinnvolle Reihenfolge der Inhalte. Das lässt sich oft nur auf Basis einer menschlichen Einschätzung beurteilen. Viele andere Prüfschritte, wie etwa Kontraste, sind dagegen sehr objektiv. Dafür gibt es spezielle Tools wie Kontrast-Checker. Welches Tool man dafür genau nutzt, ist im Grunde egal, da immer das gleiche Ergebnis herauskommen sollte.
Andererseits gibt es Bereiche wie ARIA, bei denen es extrem wichtig ist zu dokumentieren, welches Tool konkret verwendet wurde. Nur so lassen sich die Fehler später exakt reproduzieren. Das ist für die Behebung entscheidend: Wenn man einen Fehler nicht reproduzieren kann, ist es unglaublich schwer, ihn zu korrigieren. Achtet also darauf, dass die Beschreibungen so gestaltet sind, dass das umsetzende Team die Probleme nachstellen kann und die verwendeten Werkzeuge dokumentiert sind.
Besonders wichtig ist das beim Einsatz von Screenreadern oder beim Prüfschritt 11.7 (Benutzerdefinierte Einstellungen) aus der EN 301 549. In diesem Bereich herrscht oft Uneinigkeit darüber, wie genau geprüft werden soll. Hier müsst ihr wissen, welche Einstellungen die prüfende Person genutzt hat, um benutzerdefinierte Ansichten zu simulieren. Nur so könnt ihr das Verhalten bei euch reproduzieren und im Sinne des Prüfberichts korrigieren.
Welche Aufgaben fallen beim Auftraggeber an?
1. Die Vollständigkeitsprüfung: Wie gerade beschrieben, solltet ihr prüfen, ob alle wichtigen Meta-Daten und verständliche Beschreibungen vorliegen.
2. Die Übersetzung in die eigene Fachsprache: Ihr müsst das gesamte Konvolut an Daten in eure interne Sprache übersetzen. Jedes Unternehmen hat eigene Sprachregelungen und Bezeichnungen für bestimmte Komponenten. Diese Übersetzungsarbeit solltet ihr leisten, bevor ihr die Mängel in ein Ticket-System gießt.
3. Tickets komponentenorientiert erstellen: Die WCAG ist sehr checklistenorientiert und leider nicht komponentenorientiert aufgebaut. Man arbeitet sich von oben nach unten durch die Liste (von Erfolgskriterium 1.1.1 bis zum letzten, meist 4.1.3) und prüft das gesamte Produkt daraufhin ab. Moderne Software-Teams arbeiten heute jedoch fast ausschließlich mit Komponenten.
Das bedeutet für euch: Ihr müsst die einzelnen Prüfschritte den jeweiligen Komponenten eurer Anwendung zuordnen. Ein konkretes Beispiel: Kontrastprobleme werden im Bericht meist alle in einem einzigen Prüfschritt gesammelt. Betroffen sind davon aber oft völlig unterschiedliche Komponenten (z. B. der Header, ein Button und der Footer). Ihr müsst diese Mängel also aufteilen. Das ist etwas mühsam, lässt sich aber kaum vermeiden – es sei denn, ihr bindet eine Beratung so tief ein, dass diese eure internen Komponenten kennt und die Zuordnung direkt übernimmt. Als Außenstehender weiß man das sonst schlichtweg nicht.
4. Tickets zuweisen und User Stories erstellen: Nach der Erstellung müssen die Tickets den passenden Teams zugeordnet werden. Je nach Teamstruktur können sich die Beteiligten die für sie relevanten Punkte auch selbst heraussuchen. Zudem sollten hieraus – meist durch die Entwicklerinnen oder die Product Owner – passende User Stories geschrieben werden, um die Anforderungen für die Praxis greifbar zu machen.
Priorisierung der Aufgaben
Ein umfassender Prüfbericht enthält schnell Dutzende oder Hunderte von Mängeln. Es ist völlig klar, dass man das nicht in einem Rutsch und oft nicht einmal in einem Jahr abarbeiten kann. Deshalb müsst ihr die Aufgaben sinnvoll priorisieren. Hierzu gibt es verschiedene Ansätze:
– Kritische Blocker zuerst: Welche Barrieren hindern Nutzende komplett an der Bedienung und müssen sofort gelöst werden?
– Quick Wins mitnehmen: Das sind Fehler, die sich schnell und mit wenig Aufwand beheben lassen. Das motiviert das Team, weil man schnell Erfolge sieht, bevor man die dicken Bretter bohrt.
– Synergien nutzen: Wenn an einer Komponente ohnehin gerade gearbeitet wird, solltet ihr die Barrierefreiheitsanforderungen dort direkt mit einfließen lassen.
– Veraltete Komponenten aussortieren: Manchmal erledigen sich Tickets von selbst. Wenn eine fehlerhafte Komponente ohnehin bald wegfallen soll, kann man den Austausch eventuell vorziehen und spart sich so die Behebung des Fehlers in der alten Version.
– Aufwendige Tickets zurückstellen: Komplexe Probleme mit hohem Aufwand, die nicht kritisch sind, kann man bewusst für einen späteren Zeitpunkt einplanen.
Wichtiger Hinweis zur Konformität: Fehler vs. Empfehlungen
Es wird auf Kundenseite oft missverstanden, daher betone ich es noch einmal ganz deutlich: Alles, was im Bericht als Fehler markiert ist, muss zwingend behoben werden.
Das Gesetz verlangt Konformität. Eine Anwendung ist rechtlich gesehen erst dann barrierefrei beziehungsweise konform, wenn alle Fehler beseitigt wurden. Prüfstellen priorisieren Fehler zwar oft in „hoch“, „mittel“ oder „gering“, um euch eine Orientierung zu geben. Aber auch ein Fehler mit „geringer Priorität“ bleibt ein Fehler und muss gelöst werden.
Unterscheiden müsst ihr dabei zwischen zwei Kategorien:
– Fehler: Müssen in jedem Fall behoben werden (ob heute oder morgen, ist eine Frage eurer Priorisierung).
– Empfehlungen (Best Practices): Sind genau das – Empfehlungen. Sie optimieren die Usability, sind aber für die rechtliche Konformität nicht zwingend erforderlich.
Nutzt die Nachbesprechung
In der Regel bieten Prüfstellen nach der Übergabe des Berichts eine Sprechstunde oder eine Nachbesprechung an. Wir bei Adesso machen das standardmäßig so, und ich kann euch nur empfehlen: Nutzt diese Gelegenheit!
Lasst euch damit aber nicht zu viel Zeit. Barrierefreiheits-Expertinnen und -Experten testen sehr viel. In meiner Spitzenzeit habe ich 30 bis 40 Websites und Anwendungen pro Monat geprüft. Wir dokumentieren zwar so präzise wie möglich, damit wir uns auch selbst wieder hineindenken können. Aber nach ein paar Monaten weiß niemand mehr aus dem Kopf, was die konkreten Probleme bei einem bestimmten Projekt waren. Nach zwei bis drei Wochen ist die Erinnerung noch frisch, nach einem Jahr ist sie weg.
Schaut euch den Bericht also zügig an und stellt eure Rückfragen zeitnah. Natürlich gibt es dabei Grenzen – eine unendlich lange Beratung ist im reinen Testbudget meist nicht enthalten. Aber Unklarheiten oder ungenaue Beschreibungen im Bericht zu klären, gehört absolut dazu. Es ist vollkommen legitim nachzufragen, wenn etwas nicht präzise genug beschrieben wurde oder ihr eine Einschätzung anders seht.