In diesem Abschnitt erhalten Sie einen Überblick darüber, was beim Abfassen von Fehlerreports wichtig ist.
Einige Möglichkeiten sind optional und hängen von Ihrer Erfahrung in Technik und Barrierefreiheit ab. Verfügen Sie etwa nicht über das Wissen, wie ein bestimmter Fehler behoben wird, dann lassen Sie diesen Punkt in Ihrem Fehlerreport weg.
Informationen zur Test-Umgebung
Schreiben Sie die Basis-Informationen zum System auf, damit Fehler leichter nachvollzogen werden können. Dazu gehören:
- Betriebssystem und Version, ggf. auch Unterversion
- verwendeter Browser und Version
- ggf. assistive Technologie und Version
- verwendete Prüf-Tools
- ggf. verwendtes Smartphone
Achten Sie beim Test darauf, dass der Browser möglichst „sauber“ ist. Das heißt, es solten keine Cookie-Blocker, Skript-Blocker, Werbeblocker oder ähnliches aktiviert sein. Ggf. macht es Sinn, ein eigenes Browser-Profil nur für das Testen anzulegen. Das ist etwa im Firefox möglich. Es sollten in diesem Profil keine Erweiterungen installiert sein, es sei denn, sie sind für das Testen relevant.
Bei einigen Redaktionssystemen wie WordPress oder Drupal ist es sinnvoll, sich vor dem Testen auszuloggen bzw. einen anonymen Tab für das Testen zu verwenden. Eingeloggte Nutzer sehen Inhalte oft anders. Auch der Browser-Cache sollte ggf. gelleert werden, da Sie ansonsten einige Dinge wie die Cookie-Mitteilungen nicht sehen können.
Schreiben Sie auch das Datum des Tests auf. Manche Seiten werden täglich aktualisiert. Zudem kann es sein, dass die Reports erst Monate nach dem Test gelesen werden.
Schreiben von Bug-Reports
Bug-Reports sollten immer aus der Perspektive derjenigen geschrieben werden, welche den Fehler beheben soll. Diese Person hat eventuell wenig bis keine Ahnung von Barrierefreiheit.
Folgende Punkte sollten in jedem Bug-Report enthalten sein:
- An welcher Stelle tritt der Fehler auf.
- Wann tritt der Fehler auf? Welche Schritte muss die Techniker:In tun, um den Fehler zu reproduzieren.
- Was ist das erwünschte Ergebnis? Was muss anders sein oder passieren, damit der Fehler nicht mehr auftritt.
Bitte beachten Sie: Es gibt Webseiten, die vollständig dynamisch erzeugt werden. Dazu gehören etwa Suchergebnisseiten in Online-Shops oder Meldungen bei falsch ausgefüllten Formularen. Solche Fehler können nur reproduziert werden, wenn die Tester:In weiß, wie Sie vorgegangen sind, um den Fehler bei sich reproduzieren zu können.
Es kann sein, dass die techniker:In keine bis wenig Erfahrung mit Barrierefreiheit hat. Und auch keine Zeit, sich im Detail damit zu beschäftigen. Deshalb sollte immer klar gemacht werden, was genau schief läuft und was das richtige/erwünschte Verhalten wäre.
Ordnen Sie jedes Problem dem passenden WCAG-Kriterium zu. Die WCAG verweist auf für Technikerinnen wichtige Dokumente wie die Techniques (How to Meet) und „Understand…“, die den Verantwortlichen dabei helfen können, das Problem besser zu verstehen und ggf. zu beheben.
Empfehlungen
Geben Sie, wenn möglich, Empfehlungen dazu, wie ein Fehler behoben oder ein Problem gelöst werden kann. Zeigen Sie in jedem Fall auf, welches Verhalten erwünscht ist bzw. der Barrierefreiheit entspricht.
Hinweis auf WCAG-Kriterium oder Best Practice
Verweisen Sie bei Fehlern stets entweder auf das passende WCAG-Kriterium oder auf Best-Practice-Dokumentationen. WCAG-Kriterien wiegen schwerer, da hier ein Fail dazu führt, dass die gesamte WCAG nicht bestanden wurde und die Website damit nicht standardkonform ist.
Best Practices sind vor allem interessant, wenn sie leicht angewendet werden können und belegt ist, dass sie sich positiv auf die User Experience auswirken.
Verantwortlichkeiten
Interessant ist auch, wer für die Behebung eines Fehlers zuständig ist. In der Regel gibt es zwei Personengruppen: Technikerinnen, die sich um die Wartung der Website kümmern und Redakteurinnen, die für die inhaltliche Pflege der Website verantwortlich sind. Als Faustregel kann gelten, dass alle Elemente, die den Rahmen der Website bilden, also Navigation, Fußzeile, Banner und so weiter in die Technik fallen. Nur der eigentliche Content-Bereich wird von den Redakteurinnen betreut. Eingeschränkt gilt das für interaktive Elemente wie Formulare, Player oder andere dynamische Elemente im Inhalts-Bereich. Sie fallen häufig ebenfalls in die Technik-Ecke.
Sie können in dem Fehlerreport eine eigene Spalte anlegen, in der Sie die vermutliche Verantwortlichkeit darstellen. Redakteurinnen können in der Regel Fehler schneller beheben als Technikerinnen.
Priorisierung/Einschätzung des Schweregrades
Wichtig ist außerdem, dass Sie den Schweregrad des Problems spezifizieren.
Der Schweregrad eines Problems hängt davon ab, wie stark sich das Problem auf die Nutzerinnen auswirkt. Ein Problem ist schwerwiegend, wenn es sich
- auf viele Nutzerinnen stark auswirkt
- einer Nutzerinnengruppe den Zugriff komplett verhindert
Ein schwerwiegendes Problem für mehrere Nutzerinnengruppen sind etwa Formulare ohne Beschriftungen. Sie können von Blinden, Sehbehinderten oder motorisch Behinderten nicht oder nicht komfortabel genutzt werden.
Ein schwerwiegendes Problem für eine bestimmte Nutzerinnengruppe sind etwa Informationsgrafiken ohne Bildbeschreibung. Blinde wissen dann nicht, was dort zu sehen ist, wodurch ihnen Informationen entgehen.
Priorisiert werden sollten außerdem schwerwiegende Probleme, die voraussichtlich schwer zu beheben sind. Hier wird mehr Vorlaufzeit bzw. Woman-Power benötigt, um sie zu beheben.
Probleme, die sich nicht schwerwiegend auswirken, aber komplex zu beheben sind können hingegen runterpriorisiert werden.
-Fehler dokumentieren
Probleme mit der Barrierefreiheit sollten auch sauber grafisch dokumentiert werden. Die einfache Möglichkeit sind Screenshots. Dort können Sie zum Beispiel auch Hervorhebungen oder Anmerkungen machen. Wählen Sie die Ausschnitte sorgfältig aus, damit die Technikerinnen genau wissen, an welcher Stelle das Problem auftritt.
Bei komplexeren Webseiten/Interaktionen kann es auch sinnvoll sein, Videos oder mehrere Screenshots eines Verlaufs von der Fehlerkette aufzunehmen. Hierbei sollten Sie ebenfalls darauf achten, dass alle Interaktionen gut zu erkennen sind, zum Beispiel sollte der Maus-Cursor sichtbar sein.
Für diesen Zweck gibt es einige Programme und Browser-Erweiterungen.
Sprache und Ausführlichkeit
Die Sprache von Fehler-Reports sollte eindeutig und unmißverständlich sein. Im Englischen wird häufig zwischen Muss- und Soll-Kriterien unterschieden. Muss heißt dabei, dass eine Anforderung umgesetzt werden muss. Soll heißt, dass es wünschenswert ist, aber nicht sein muss. Kann beschreibt Möglichkeiten, eine Anforderung umzusetzen. Dabei werden diese Worte häufig in Großbuchstaben geschrieben, um sie davon abzuheben, dass sie ohne diese starke Implikation auch im normalen Fließtext eines Reports verwendet werden.
Writing effective Accessibility Bug Reports