Status Quo

Bevor man eine Reise beginnt, muss man sich mindestens über zwei Dinge im Klaren sein: Wo man gerade ist und wohin man will oder muss. Die Definition des Zielorts „Zugänglichkeit“ nimmt einem der Gesetzgeber ab, wenn man z. B. ein Onlineshop betreibt und Menschen aus der Europäischen Union zum Kauf (oder zumindest einem Vertragsabschluss führen will): Barrierefreiheit des eigenen Webauftritts und z. B. durch die Erfüllung der Europäischen Norm 301 549 oder einer vergleichbaren, ausführlichen Norm.

Was aber ist der genaue Startpunkt? Es gibt natürlich immer die Möglichkeit, einen intensiven Audit des eigenen Webprojektes bei einer Barrierefreiheits-Fachkraft zu bestellen. Aber dies ist nicht der einzige Weg und auch wenn man sich den Grenzen der im Folgenden genannten Strategien bewusst ist, so können diese doch immer noch sehr für die eigene „Standortbestimmung“ hilfreich sein.

Da die Web Content Accessibility Guidelines (oder „WCAG“) der Dreh- und Angelpunkt einer Mindest-Barrierefreiheit im Web darstellen, gibt es natürlich einige Instrumente, die automatisch oder halbautomatisch die dortigen „Checkpoints“ (genauer: „Erfolgskriterien“) abfragen.

Und auch wenn die EN 301 549 ein paar Aspekte mehr beinhaltet als die WCAG und auch wenn einige Prüfschritte menschliches Urteilsvermögen und Kontext erfordern, so sind diese Tools dennoch eine Hilfe. Wichtig ist nur, dass man ihre Aussagekraft nicht überschätzt und beispielsweise aus einem hundertprozentigen Google Chrome Lighthouse-Score nicht schließt, dass nun restlos alles in bester Ordnung ist. Im Folgenden werden einige empfehlenswerte Instrumente vorgestellt:

Der Industriestandard (bekannt in einigen verschiedenen „Verpackungen“) ist sicherlich die axe-Bibliothek der Agentur Deque. Diese ist im Kern ein Node.js-Skript und wahrscheinlich am Ehesten als Browsererweiterung bekannt:

Beide Varianten stellen die kostenlose Version eines Produktes dar, was auch deutlich so beworben wird, aber nur in Chromium-basierten Browsern laufen wird. Mehr zu axe Pro im übernächsten Kapitel.

axe ist auch der Kern eines Features, das eventuell aus einem anderen Zusammenhang bekannt ist: Unter dem Namen „Lighthouse“ hat Google einige Analyse-Instrumente zu Performance/Ladezeiten, SEO und eben auch Barrierefreiheit (Zugänglichkeit) zusammengefasst. Der Teil, der die Accessibility automatisch checkt (im Rahmen, in dem es automatisiert möglich ist), ist eine leichte Anpassung der axe-Bibliothek.

Das Praktische an axe-core ist, dass es – wie bereits erwähnt – im Kern ein Node.js-Skript ist und sich somit z. B. in eine bestehende Test-Infrastruktur einhaken lässt: Die axe-core-Bibliothek auf GitHub bietet vertiefende Infos zur API (Schnittstelle), unterstützten Sprachen und Browsern.

Zusammengefasst kann axe, auch in der Nicht-Pro-Version einige Andeutungen zum Stand der Barrierefreiheit geben. Auch wenn es möglich ist, das Skript zu überlisten, so bietet seine Ausführung doch eine erste Indikation dazu an, wie es um die Zugänglichkeit eines Web-Dokuments bestellt ist.

WAVE vom Projekt WebAIM ist ebenfalls ein automatisierter Checker, verfolgt aber im Gegensatz zu axe (und Konsorten) einen visuelleren Ansatz: Fehler bzw. Hinweise werden im Kontext der gefundenen Stellen dargestellt. Im Bereich "Errors" und, wenn vorhanden. "Contrast Errors" werden, wie es der Name schon sagt, Dinge gelistet, die WAVE als problematisch erkennt, wie z. B. Eingabefelder ohne programmatischen Bezeichner und Links ohne text- und damit namengebenden Inhalt. Aber auch z. B. Alternativtexte und verwendete ARIA-Rollen werden ausgegeben, was WAVE zu einer Mischung aus Fehlererkennungs- und Debugging-Instrument macht.

Beide genannten Tools verfolgen einen Ansatz, der automatisiertes Testen (dieser Abschnitt) und manuelles Testen (nächster Abschnitt) verbindet: Das so genannte halbautomatisierte Testen. In diesem Ansatz wird das maschinell getestet, was sich von einem Skript gut und eindeutig testen lässt. Bei den Aspekten, die menschliches Urteilsvermögen und einen Menschen mit Kenntnis der Zusammenhänge erfordern (Alternativtexte gut und passend? Tastaturnutzungsreihenfolge sinnvoll? Etc.) wird dieser in vergleichsweise konkreter Sprache angeleitet. Axe Pro und Microsoft Accessibility Insights for Web sind in ihrem Ansatz grob vergleichbar, das Letztgenannte aber kostenlos. Meine Empfehlung lautet deshalb, Accessibility Insights zunächst einmal „probezufahren“ dieser Ansatz zufriedenstellend ist, man auf den Geschmack gekommen ist, kann es sich lohnen, bei Deque um eine axe-Pro-Demo zu bitten.

Bevor man sich der Unternehmung „manuelles Testen“ widmet, muss man sich einem klar sein: Damit Erfolgskriterien – oder vereinfacht: Punkte, die man überprüft – für möglichst viele Seiten und unterschiedliche Situationen gelten, sind sie allgemein und abstrakt formuliert. Das macht zentrale Dokumente wie die WCAG kompatibel zu Gesetzgebungen zur Barrierefreiheit (wie z. B. dem Barrierefreiheitsstärkungsgesetz), auf viele Webauftritte aller Art anwendbar – aber auch häufig recht schwer zu verstehen und - ironischerweise - eher wenig zugänglich.

Im letzten Abschnitt hat beispielsweise eine Erweiterung wie Microsofts Accessibility Insights gezeigt, wie man diese Prüfpunkte im Kontext recht gut ziemlich konkret einordnen kann – aber da die Barrierefreiheitsvorgaben eben Dokumente und Formulierungen, aber keine interaktiven Browsererweiterungen sind, fällt dieser hilfreiche Kontext in einer Überprüfung weg. Stattdessen wurde ein Ansatz gewählt, um mehr Praxis in abstrakte Vorgaben zu bringen: Beispielhafte Fachmethoden und Verständnisdokumente.

Die Fachmethoden werden im Original „Techniques“, also Techniken oder Methoden genannt und in drei Arten aufgeteilt:

Auch wenn nicht alle dieser Techniques aktuell, relevant, allumfassend oder juristisch so schlagkräftig – „normativ“ wie die Erfolgskriterien selbst sind – so bieten ihre Lektüre gegebenenfalls Aha-Momente im Verständnis der Web Content Accessibility Guidelines.

Neben den Techniken gibt es pro WCAG-Erfolgskriterium auch ein Verständnisdokument, beispielsweise Understanding Success Criterion 3.3.7: Redundant Entry. In ihm haben sich die Schöpferinnen und Schöpfer der WCAG verschrieben, jeweils die Absicht, das Ziel und die Vorteile der Erfüllung des Erfolgskriteriums aufzulisten. Es bietet außerdem noch einen Satz an Beispielen und Querverweise auf relevante Fachmethoden zur Mindestkonformität. Zu beachten ist auch hier, dass es trotz allem die Erfolgskriterien sind, die juristisch zählen – Techniques und Understanding-Dokumente sind höchstens informativ.

Sowohl Understanding-Dokumente als auch Fachmethoden sind allerdings nach WCAG-Nummer und damit recht speziell, definitiv nicht nach Schlagworten geordnet. Diese (und andere) Lücke(n) versucht die Web Content Accessibility Guidelines-Schnellreferenz zu füllen: Sie ist auch unter dem Namen „How to meet WCAG“ bekannt.

Während sie auf den ersten Blick nur als Sammlung von bekannten Erfolgskriterien, aber in anderer Verpackung, erscheinen, liegt die Magie meiner Ansicht nach hinter dem Registerreiter „Filter“ und weiter in „Tags“: Diese Schlagworte (wie Animation, Kontrast und Tabellen) versuchen die Erfolgskriterien samt ihrer Verständnisdokumente und Techniques nach Fachlichkeit und praktischen Begriffen zu ordnen. Wie so häufig gilt: Auch wenn dieses Instrument nicht perfekt ist, so lohnt es sich möglicherweise einen Blick in die Schnellreferenz zu werfen, um das zu suchen, was man finden möchte.

Der BIK-Prüfverbund ist ein Netzwerk von Sachverständigen in der Web-Barrierefreiheit in Deutschland (und, Offenlegung, ich bin qualifizierter Prüfer im Verbund). Am bekanntesten ist sicherlich der „BIK BITV-Test“, der Webauftritte auf die (auch für das Barrierefreiheitsstärkungsgesetz relevante) Europäische Norm (EN) 301 549 prüft.

Im Rahmen des Projektes sind drei Ressourcen eventuell hilfreich für eine „Standortbestimmung“, bei dem es in diesem Modul ja geht: