In diesem Beitrag geht es um die Vorgehensweise bei der Durchführung eines Barrierefreiheitstests. Prüferinnen wissen natürlich, wie sieh vorgehen müssen. Aber auch für den Auftraggeber kann es sinnvoll sein, den Ablauf zu kennen, um sich besser darauf einstellen zu können.
Tipps für den Auftraggeber
Als Auftraggeber ist es sinnvoll, bereits selbst zu überlegen, welche Komponenten und Views getestet werden sollten. Wir lieben solche Kunden. Da wir von extern kommen, kennen wir die Logik des Systems nicht, wir können nur mit dem Außenblick urteilen.
Bitte planen Sie ausreichend Vorlaufzeit ein. Die meisten Kunden unterschätzen den Prüfaufwand, die Zahl der Probleme und die Zeit zu deren Behebung. Als Faustregel: Wenn Sie 1. noch nie einen Barrierefreiheits-Test gemacht haben und 2. Sie viele Systeme haben oder diese Systeme komplex sind, sollten Sie mit vielen Problemen und viel Zeit zu deren Behebung rechnen. Leider werden auch die Barrierefreiheits-Skills der eigenen Projekt-Beteiligten überschätzt bzw. schätzen viele Leute ihre Fähigkeiten falsch ein.
Mein Geheimtipp: Lassen Sie zuerst die Komponentenbibliothek prüfen. Viele grundlegende Probleme müssen einmal in der Komponente behoben werden und sind dann in allen Anwendungen behoben, die diese Komponente verwenden. Der Test ist dann nicht überflüssig, aber er kann erheblich schneller durchgeführt werden, was die Kosten insgesamt reduziert.
WCAG EM als Leitfaden
Wer einen Barrierefreiheitstest durchführen möchte, kann sich an der WCAG-EM (Web Content Accessibility Guidelines Evaluation Methodology) orientieren. Diese Evaluationsmethodik ist eine Anleitung des World Wide Web Consortium, konkret der Web Accessibility Initiative, um Barrierefreiheit systematisch und methodisch zu prüfen.
Die Methodik ist öffentlich zugänglich. Es gibt derzeit eine veröffentlichte Version sowie einen Entwurf für Version 2.0. Die aktuelle Version bezieht sich hauptsächlich auf Websites. Die Version 2.0 wird zusätzlich andere Formate wie Apps und PDFs einbeziehen. Die grundlegende Vorgehensweise bleibt jedoch weitgehend gleich.
Für Personen, die nicht tief mit den WCAG vertraut sind, ist wichtig: Die WCAG sind normativ. Das bedeutet, dass sie verbindlich sind, wenn man sich auf sie beruft. Die meisten Dokumente der WAI sind dagegen informativ. Sie dienen als Anleitung, sind aber nicht verpflichtend.
Übersicht verschaffen
Der erste Schritt einer Prüfung ist eine initiale Sichtung des Prüfgegenstands. Bei einer Website oder App bedeutet das, dass man alle relevanten Seiten oder Screens einmal durchgeht und sich einen Gesamteindruck verschafft.
Diese Sichtung ist besonders sinnvoll, um früh zu erkennen, ob eine Prüfung überhaupt sinnvoll ist. Bei PDFs lässt sich zum Beispiel schnell feststellen, ob sie strukturierten Text enthalten. Wenn keine Tags vorhanden sind, keine Überschriften, keine Absätze und keine Tabellen korrekt ausgezeichnet sind, ist das Dokument nicht barrierefrei. In solchen Fällen kann die Prüfung frühzeitig abgebrochen werden.
Ein solcher Schnellcheck ist auch bei Entwürfen sinnvoll. Bei Websites existieren oft verschiedene Versionen, zum Beispiel in Staging-Umgebungen. Es kommt vor, dass veraltete oder unvollständige Versionen geprüft werden. In solchen Fällen sollte man frühzeitig darauf hinweisen, dass grundlegende Anforderungen nicht erfüllt sind und eine vollständige Prüfung keinen Mehrwert bietet.
Dieses Vorgehen spart Zeit und Kosten und ist gegenüber dem Kunden transparenter, als eine vollständige Prüfung trotz offensichtlicher Mängel durchzuführen.
Während der Sichtung sollte man außerdem analysieren, welche Komponenten und Zustände vorhanden sind. Dazu gehört zum Beispiel, ob Elemente aufklappbar sind oder verschiedene Zustände haben. Dies hilft, den Umfang und die Komplexität der Prüfung besser einzuschätzen.
Da Websites und Apps oft sehr viele Seiten enthalten, ist eine vollständige manuelle Prüfung in der Regel nicht möglich. Deshalb wählt man exemplarische Seiten oder Komponenten aus. Ziel ist es, die wichtigsten und repräsentativen Teile zu identifizieren und zu dokumentieren.
Die Methodik sieht außerdem vor, ein Konformitätslevel festzulegen (A, AA oder AAA). In der Praxis ist dieser Schritt oft weniger relevant, da in den meisten Fällen Level AA angestrebt wird.
Ein weiterer Schritt ist die Festlegung des anzuwendenden Standards. Auch dieser Schritt ist häufig bereits durch gesetzliche Vorgaben definiert, zum Beispiel durch die BITV oder das BFSG.
Prüf-Gegenstand festlegen
Ein zentraler Punkt ist die Definition des Prüfgegenstands. Dabei ist es wichtig, nicht nur festzulegen, was geprüft wird, sondern auch, was ausdrücklich ausgeschlossen wird.
Diese Abgrenzung sollte in Abstimmung mit dem Kunden erfolgen. Ein Beispiel sind Webviews in Apps, die externe Inhalte anzeigen. Wenn diese Inhalte nicht in der Verantwortung des Betreibers liegen, können sie vom Test ausgeschlossen werden.
Auch sogenannte Legacy-Systeme spielen eine Rolle. Viele Websites bestehen aus mehreren Systemen, etwa einem neuen und einem alten Bereich. In solchen Fällen muss klar definiert werden, welche Teile Bestandteil der Prüfung sind.
Die Auswahl des Prüfgegenstands erfolgt typischerweise gemeinsam: Die prüfende Person schlägt relevante Seiten oder Komponenten vor, und der Kunde bestätigt oder ergänzt diese Auswahl.
Bei klassischen Websites sollten mindestens folgende Seitentypen berücksichtigt werden:
* die Startseite,
* eine einfache Inhaltsseite,
* eine komplexe Inhaltsseite (z. B. mit Tabellen oder interaktiven Elementen),
* eine Formularseite (z. B. Kontaktformular).
Die Startseite ist besonders wichtig, da sie häufig eine eigene Struktur und spezielle Komponenten enthält.
Bei Anwendungen mit klar definierten Prozessen, zum Beispiel in Online-Shops, müssen vollständige Abläufe geprüft werden. Ein typischer Prozess umfasst die Produktsuche, das Hinzufügen zum Warenkorb, die Anmeldung, die Eingabe von Adress- und Zahlungsdaten sowie den Abschluss der Bestellung.
Gemäß WCAG gilt ein Prozess nur dann als konform, wenn alle Schritte des Prozesses konform sind. Deshalb muss der gesamte Ablauf geprüft werden.
Dies erhöht den Prüfaufwand erheblich, ist aber notwendig, um eine valide Aussage zur Barrierefreiheit treffen zu können.
Hier ist dein Text sprachlich optimiert, strukturiert und so formuliert, dass er sich gut ins Englische übersetzen lässt:
Durchführung der Prüfung
Nachdem der Prüfgegenstand festgelegt wurde und der Kunde eingebunden ist, beginnt die eigentliche Prüfung.
Dieser Schritt ist komplex und stark abhängig von der individuellen Vorgehensweise. Einige Prüferinnen und Prüfer arbeiten jede Seite systematisch entlang aller Kriterien der WCAG durch. Andere gruppieren Prüfschritte und prüfen mehrere Seiten parallel, zum Beispiel in verschiedenen Browser-Tabs.
Unabhängig von der Methode ist eine klare und konsistente Struktur entscheidend. Die Prüfung sollte immer nach einem festen Schema erfolgen.
Für jedes Kriterium wird zunächst geprüft, ob es überhaupt anwendbar ist. Es gibt Kriterien, die in vielen Fällen nicht relevant sind, zum Beispiel Anforderungen zu Blinken oder Flackern. Andere Kriterien sind nahezu immer relevant, sobald Inhalte vorhanden sind. Dazu gehören unter anderem:
* korrekte Verwendung von Überschriften,
* strukturierte Textauszeichnung,
* Tastaturbedienbarkeit.
Anschließend werden die anwendbaren Kriterien systematisch für alle ausgewählten Seiten oder Komponenten geprüft.
Ein wesentlicher Grund für die Dauer solcher Prüfungen ist der geringe Automatisierungsgrad. Automatisierte Tests erzeugen häufig Fehlinterpretationen (False Positives und False Negatives). Daher müssen automatisierte Ergebnisse immer manuell überprüft werden.
Alle identifizierten Probleme müssen dokumentiert werden. Eine gute Dokumentation enthält:
* eine präzise Beschreibung des Problems,
* einen Screenshot oder einen relevanten Codeausschnitt,
* eine Zuordnung zu einem konkreten Kriterium (z. B. WCAG bzw. EN 301 549),
* eine Empfehlung zur Behebung.
Die Fehlerbeschreibung muss konkret sein. Zu allgemeine Beschreibungen sind für Entwicklerinnen und Entwickler nicht umsetzbar.
Die Zuordnung zu einem EN-Kriteriumist wichtig. Sie stellt sicher, dass es sich um ein tatsächliches Barrierefreiheitsproblem handelt und nicht um eine subjektive Einschätzung.
Empfehlungen zur Behebung sollten vorhanden sein, müssen aber nicht vollständig sein. Es reicht, eine mögliche Lösung zu beschreiben. Die konkrete Umsetzung liegt in der Verantwortung des Entwicklungsteams.
Wichtig ist außerdem, das gewünschte Verhalten zu beschreiben. Also: Wie sollte die Funktion korrekt arbeiten? Diese Information ist oft hilfreicher als eine technische Lösung, insbesondere wenn unterschiedliche Technologien oder Frameworks eingesetzt werden.
Da Prüferinnen in der Regel keine Spezialistinnen für alle Frameworks sind, ist es nicht ihre Aufgabe, konkrete Implementierungen für jedes System zu liefern. Ihre Aufgabe ist es, Barrierefreiheitsanforderungen verständlich zu formulieren.
Ein weiterer wichtiger Aspekt ist die Dokumentation der Testumgebung. Dazu gehören:
* verwendete Tools (z. B. Browser-Tools, Bookmarklets, Accessibility-Toolbars),
* Browser und Version,
* ggf. Screenreader (z. B. TalkBack) inklusive Version,
* in bestimmten Fällen auch das Betriebssystem.
Diese Informationen sind notwendig, damit Testergebnisse reproduzierbar sind. Browser und Screenreader können unterschiedliche Verhaltensweisen oder Fehler aufweisen.
Ein guter Prüfbericht muss für den Kunden verständlich sein. Er sollte klar beantworten:
* Was wurde geprüft?
* Was ist das konkrete Problem?
* Was ist das erwartete Verhalten?
Nach Abschluss der Prüfung sollten die Ergebnisse mit dem Kunden besprochen werden. Aufgrund des Umfangs ist es sinnvoll, sich auf die wichtigsten Ergebnisse zu konzentrieren.
Zusätzlich kann es hilfreich sein, den Kunden bei der Erstellung von Tickets zu unterstützen oder direkt in deren Ticketsystem zu arbeiten. Ein direkter Austausch mit dem Entwicklungsteam ist empfehlenswert, da während der Umsetzung häufig Rückfragen entstehen.
Der Prüfbericht sollte in einem gut weiterverarbeitbaren Format bereitgestellt werden, zum Beispiel als CSV-Datei oder in einem Tool, das sich direkt in Ticketsysteme integrieren lässt. Der direkte Zugriff auf das Ticketsystem des Kunden kann den Prozess erheblich vereinfachen.
Zusätzliche Leistungen wie die Erstellung von User Stories können angeboten werden, gehören aber nicht zwingend zum Standardumfang eines Prüfberichts.
In der Praxis sind meist mehrere Prüfzyklen erforderlich. In der Regel werden mindestens zwei Durchläufe benötigt, um die wichtigsten Probleme zu identifizieren und zu beheben.
Der Aufwand hängt stark von der Komplexität des Systems ab. Systeme mit langer Historie und vielen Altkomponenten sind deutlich schwieriger barrierefrei zu gestalten als moderne Anwendungen.