Website-Barrierefreiheitsaudit: Was nachmessen?

Was sollte ich nach der Beauftragung eines Freelancers für ein Website-Barrierefreiheitsaudit messen?

Ein Audit zur Barrierefreiheit einer Website ist dann nützlich, wenn es Ihrem Team hilft, Barrieren zu erkennen und die nächsten Schritte festzulegen. Ein Bericht mit einer langen Liste von Fehlern mag gründlich wirken, kann Entwickler aber im Unklaren darüber lassen, wo ein Problem auftritt, wen es betrifft und wie sich eine Behebung überprüfen lässt.

Wenn Sie einen Freelancer beauftragen, sollten Sie die Qualität der Nachweise und der darauf gestützten Entscheidungen messen – nicht nur die Anzahl der gefundenen Probleme. Um die Qualität eines WCAG-Audits zu messen, prüfen Sie, ob die vereinbarten Seiten und Aufgaben getestet wurden, ob Ihr Team jeden Befund nachvollziehen kann und welche Probleme noch ungelöst sind. So erhalten Sie eine verlässlichere Antwort auf die Frage „Was sollte ich nach der Beauftragung eines Freelancers für ein Website-Barrierefreiheitsaudit messen?“ als durch einen einzelnen Score oder eine pauschale Aussage zur Konformität.

1. Legen Sie fest, was „barrierefrei“ in diesem Auftrag bedeutet

Ein Barrierefreiheitsaudit hat einen klar abgegrenzten Umfang. Es kann sich auf fünf wichtige Seiten, einen Checkout-Prozess oder eine Auswahl wiederverwendbarer Komponenten beschränken, statt jede Seite und jede Interaktion einer großen Website abzudecken. Halten Sie vor Beginn der Arbeit genau fest, welche Bereiche dazugehören. Prüft der Freelancer die Produktseite und den Checkout, nicht aber den Kontobereich, sollte der Bericht diesen Unterschied klar ausweisen.

Vereinbaren Sie, nach welchen Standards oder Richtlinien der Freelancer vorgeht, und lassen Sie sich erklären, wie diese mit Ihrem konkreten Auftrag zusammenhängen. Der bloße Verweis auf WCAG reicht beispielsweise nicht aus: Im Bericht sollten die relevanten Erfolgskriterien genannt und die durchgeführten Tests erläutert werden. Legen Sie außerdem fest, welche assistiven Technologien und Browserkonfigurationen in das Audit einbezogen werden. Die passende Kombination hängt von Ihrer Zielgruppe und dem Projekt ab. Halten Sie die vereinbarte Testumgebung schriftlich fest, statt davon auszugehen, dass jede denkbare Kombination geprüft wird.

Listen Sie die Aufgaben auf, die im Audit untersucht werden sollen. Dazu kann gehören, eine Lieferbedingung zu finden, ein Kontaktformular abzusenden oder einen Kauf abzuschließen. Die Vorlagen einer Website können auf den ersten Blick barrierefrei wirken und dennoch an einem bestimmten Schritt eine Person ausschließen – etwa wenn eine Validierungsmeldung nach dem Absenden eines Formulars nicht vorgelesen wird.

Formulieren Sie den Umfang kurz und präzise. Darin sollte stehen, was geprüft wurde, was ausgeschlossen war und welche Aussagen das Audit nicht belegt. So wird eine Prüfung ausgewählter Seiten nicht fälschlich als Garantie für die gesamte Website verstanden. Wenn Sie vor der Beauftragung ein bestehendes Angebot oder eine bereits abgeschlossene Prüfung beurteilen, können Sie gezielt die Option „Website Barrierefreiheitsaudit prüfen“ nutzen und dabei insbesondere den Umfang und die Nachweise vergleichen.

2. Sorgen Sie für nachvollziehbare Nachweise

Ein Befund lässt sich viel leichter bearbeiten, wenn eine andere Person ihn reproduzieren kann. Achten Sie bei jedem gemeldeten Problem auf den Namen der Seite oder Komponente, eine genaue Stelle und die Schritte, mit denen sich die Barriere aufrufen lässt. „Das Menü ist nicht barrierefrei“ ist zu ungenau. „Mit der Tabulatortaste vom Logo zum Menübutton wechseln und dann Enter drücken – das Untermenü wird visuell geöffnet, der Fokus bleibt jedoch auf dem Button“ gibt Entwicklern eine konkrete Grundlage für die Untersuchung.

Im Bericht sollten außerdem der verwendete Browser und die assistive Technologie dokumentiert sein. Ist ein Problem in einer bestimmten Kombination aus Screenreader und Browser aufgetreten, braucht Ihr Team diese Angaben, um dasselbe Verhalten zu überprüfen. Als Nachweis kann der Freelancer eine kurze Aufzeichnung, einen Screenshot oder eine Beschreibung des erwarteten und des tatsächlichen Verhaltens beilegen. Ein Screenshot allein erklärt ein Problem mit dem Tastaturfokus nicht; der Nachweis sollte zum jeweiligen Problem passen.

Versuchen Sie, einige Befunde selbst oder gemeinsam mit einem Entwickler nachzuvollziehen, bevor Sie den Bericht abnehmen. Wählen Sie, sofern im Umfang enthalten, je ein Problem zur Tastaturbedienung, zu einem Formular und zur Seitenstruktur aus. Kann Ihr Team den beschriebenen Schritten nicht folgen, bitten Sie den Freelancer um eine Präzisierung, solange die Einzelheiten des Audits noch präsent sind.

Diese Dokumentation ist auch nach dem Audit wichtig. Ändert ein Entwickler eine gemeinsam genutzte Komponente, helfen die ursprünglichen Schritte dabei festzustellen, ob die Änderung die gemeldete Barriere tatsächlich behoben oder nur ihr Erscheinungsbild verändert hat.

3. Gleichen Sie die Befunde mit echten Nutzungsszenarien ab

Testen Sie die Aufgaben, die Nutzer tatsächlich erledigen müssen, und nicht nur einzelne Oberflächenelemente. Ein Nutzungsszenario kann eine Reihe kleiner Hindernisse sichtbar machen: einen Menübutton mit unklarem Namen, ein Formular, das eingegebene Daten nach einem Fehler verwirft, und eine Bestätigungsmeldung, die nicht vorgelesen wird. Jedes Problem mag für sich genommen geringfügig erscheinen; zusammen können sie jemanden daran hindern, eine Anfrage abzuschließen.

Gehen Sie einige wichtige Nutzungsszenarien ausschließlich mit der Tastatur durch. Verwenden Sie anschließend die passende assistive Technologie, sofern sie zum vereinbarten Umfang gehört. Prüfen Sie bei einem Kontaktformular, ob Sie alle Felder erreichen, erforderliche Angaben verstehen, Fehler erkennen und korrigieren sowie das Absenden bestätigen können. Halten Sie genau fest, an welcher Stelle der Ablauf scheitert und ob es eine Ausweichmöglichkeit gibt. Eine solche Möglichkeit ist ein hilfreicher Nachweis, beseitigt die Barriere aber nicht.

Berücksichtigen Sie bei Ihrer Prüfung auch das Ergebnis der Aufgabe. Konnte die Person die gesuchten Informationen finden? Konnte sie das Formular ohne Hilfe absenden? Konnte sie erkennen, ob der Checkout erfolgreich war? Solche Fragen verknüpfen technische Befunde mit dem Zweck der Seite, ohne vorzugeben, ein kurzes Audit bilde die Erfahrung aller Nutzer ab.

Wenn Sie neben der Arbeit an der Barrierefreiheit weitere Freelance-Projekte auf Ihrer Website vergeben, sollten die Zuständigkeiten klar geregelt sein. Ein Entwickler kann eine Behebung umsetzen, während der Freelancer sie überprüft. Möchten Sie für ein solches Audit externe Unterstützung suchen, können Sie einen Freelancer für Barrierefreiheitsaudit beauftragen. Vereinbaren Sie vor Arbeitsbeginn, wer das Ergebnis dokumentiert. Auf 24freelance.pro können Sie sich zum Einstieg in ein Gespräch über technische Projektanforderungen das Profil von IT IT IT IT IT IT ansehen.

4. Prüfen Sie, ob Ihr Team mit den Befunden arbeiten kann

Jeder Befund sollte die Barriere, die betroffenen Personen oder Interaktionen, den Ort des Problems und die Begründung für die Einstufung des Schweregrads erklären. Diese Erläuterung sollte Ihrem Team helfen, Prioritäten zu setzen, statt vorauszusetzen, dass eine Schweregrad-Kennzeichnung für sich selbst spricht. Eine Tastaturfalle im Checkout hat beispielsweise andere Folgen als eine uneinheitliche Überschriftenebene auf einer selten besuchten Seite.

Achten Sie auch auf eine praktikable Empfehlung. Ein hilfreicher Bericht könnte vorschlagen, die sichtbare Beschriftung als zugänglichen Namen eines Bedienelements bereitzustellen und zugleich erläutern, wie sich das Ergebnis erneut testen lässt. Die Empfehlung sollte konkret genug sein, um die Untersuchung anzuleiten, ohne eine Codeänderung vorzuschreiben, die möglicherweise nicht zum Framework Ihrer Website passt.

Seien Sie vorsichtig, wenn die Ergebnisse eines automatisierten Prüfwerkzeugs als vollständiges Audit ausgegeben werden. Automatisierte Tools können bestimmte Muster erkennen, belegen aber weder, dass eine Aufgabe mit der Tastatur erledigt werden kann, noch, dass Anweisungen im jeweiligen Kontext verständlich sind. Fragen Sie nach, welche Befunde von Menschen geprüft wurden und wie der Freelancer das für Nutzer sichtbare Verhalten getestet hat.

Unklare Befunde führen zu vermeidbarem Hin und Her. Steht in einem Ticket nur „Kontrast korrigieren“, fragen Sie nach, welcher Text oder welche Komponente betroffen ist, was beobachtet wurde und worauf sich die Empfehlung stützt. Ein klarer Befund erspart Entwicklern Rätselraten und gibt Ihrem Team die Möglichkeit, die Änderung später zu überprüfen.

5. Messen Sie den Fortschritt anhand bestätigter Behebungen, nicht des Ticketstatus

Ein Ticket mit dem Status „Erledigt“ beweist nicht, dass ein Barrierefreiheitsproblem behoben ist. Halten Sie für jede vereinbarte Änderung fest, ob sie umgesetzt und anhand der ursprünglichen Schritte erneut getestet wurde. Prüfen Sie anschließend, ob sie die ursprüngliche Barriere beseitigt hat, ohne eine neue zu schaffen.

Ein Entwickler könnte beispielsweise dafür sorgen, dass ein benutzerdefiniertes Menü auf Tastatureingaben reagiert, den Fokus nach dem Schließen aber an einer unerwarteten Stelle belassen. Bei einer kurzen Sichtprüfung mag das ursprüngliche Problem behoben erscheinen, während der Ablauf für eine Person, die die Tastatur nutzt, weiterhin scheitert. Wird die gesamte Interaktion erneut getestet – und nicht nur die geänderte Codezeile –, kann dieser Unterschied auffallen.

Verwenden Sie in Ihrem Tracking-System zwei einfache Status: „Behebung verifiziert“ und „Prüfung ausstehend“. Tragen Sie ein, wer die Änderung erneut getestet hat und welche Nachweise oder Schritte dafür verwendet wurden. Ist der Freelancer für die Überprüfung zuständig, halten Sie das ausdrücklich fest. Führt Ihr internes Team den erneuten Test durch, weisen Sie eine verantwortliche Person zu, damit die Prüfung bei der Übergabe nicht untergeht.

Fassen Sie eine Behebung nicht mit einem unabhängigen Redesign zusammen, wenn danach nicht mehr erkennbar ist, was geändert wurde. Werden mehrere Aktualisierungen gleichzeitig veröffentlicht, erleichtert eine kurze Notiz, die jeden Befund der entsprechenden Veröffentlichung oder Komponente zuordnet, spätere Überprüfungen.

6. Dokumentieren Sie Ausnahmen und verbleibende Risiken

Manche Probleme werden möglicherweise zurückgestellt, weil eine Funktion neu entwickelt wird, ein Drittanbieter-Tool beteiligt ist oder dem Team eine geeignete Alternative fehlt. Halten Sie für jede Ausnahme die verantwortliche Person, den Grund, eine vorübergehende Ausweichlösung und einen Prüftermin fest. „Warten auf den Anbieter“ ist keine vollständige Dokumentation, wenn niemand für die Nachverfolgung zuständig ist.

Inhalte von Drittanbietern sollten gesondert dokumentiert werden. Verhindert beispielsweise ein eingebettetes Buchungstool die Tastaturnavigation, halten Sie fest, wo es eingebunden ist und welche Alternative Nutzern gegebenenfalls tatsächlich zur Verfügung steht. Der Freelancer kann den Code des Anbieters vielleicht nicht ändern, doch die Barriere betrifft weiterhin die Besucher Ihrer Website.

Unterscheiden Sie zwischen „nicht getestet“, „nicht behoben“ und „außerhalb dieses Auftrags“. Diese Angaben bedeuten Unterschiedliches. Wurde eine Seite vom Audit ausgeschlossen, sollten Sie sie nicht als geprüft und bestanden ausweisen. Wurde ein Befund zurückgestellt, sollten Sie ihn nicht allein deshalb schließen, weil Ihr Team die Änderung heute nicht umsetzen kann.

Überprüfen Sie Ausnahmen an einem festgelegten Datum oder zu einem definierten Projektmeilenstein. Eine vorübergehende Ausweichlösung kann überholt sein, wenn sich ein Formular, ein Anbieter oder das Seitenlayout ändert. Mit einer verantwortlichen Person und einem Prüftermin wird das Team daran erinnert, zu kontrollieren, ob sich das verbleibende Risiko verändert hat.

7. Fazit: Entscheidend ist, ob das Audit bessere und sicherere Entscheidungen ermöglicht

Ein hilfreiches Barrierefreiheitsaudit liefert Ihrem Team nachvollziehbare Nachweise, umsetzbare Befunde und eine klare Übersicht darüber, was noch nicht getestet oder behoben wurde. Es sollte nicht den Eindruck erwecken, eine begrenzte Prüfung beweise die Barrierefreiheit der gesamten Website. Entscheidend ist, ob das Audit Ihnen dabei hilft, festzulegen, was behoben werden muss, wie Sie die Behebung überprüfen und wer sich um die verbleibenden Probleme kümmert.

Prüfen Sie vor der Abnahme, ob der Umfang der Vereinbarung entspricht, testen Sie stichprobenartig einige Schritte zur Reproduktion und vergewissern Sie sich, dass zurückgestellte Punkte Verantwortliche und Prüftermine haben. Das kostet weniger Zeit, als Monate später einen unklaren Bericht erneut aufzurollen – womöglich dann, wenn sich die Person, die das Audit durchgeführt hat, nicht mehr daran erinnert, wie das Problem aufgetreten ist.