Tools für Barrierefreiheitstests: Was finden axe, Lighthouse und WAVE?

Kurz gesagt

Ein automatisches Tool für Barrierefreiheit findet, was im Code gegen eine Regel verstößt. Ob etwas für den Nutzer sinnvoll ist, kann es nicht wissen. Wer diesen Unterschied kennt, holt mehr aus dem Tool heraus.

• axe ist eine Open-Source-Test-Engine. Sie läuft als Code in Ihrer eigenen Testumgebung.
• Lighthouse lässt sich aus den Chrome-Entwicklertools starten und gibt der Seite eine Punktzahl für Barrierefreiheit.
• WAVE zeichnet die Probleme mit Icons über die Seite.

Alle drei sind ein Anfang. Wie ich die eigentliche Prüfung mache, beschreibe ich im Ratgeber zur Barrierefreiheitsprüfung. Diese Seite handelt nur von den Tools.

Was ein automatisches Testtool kann und was nicht

Das Tool liest den Code der Seite und die Struktur, die der Browser daraus baut. Dann prüft es jedes Element gegen eine Liste von Regeln. Fehlt einem Bild das alt, ist der Name eines Buttons leer oder ist das Verhältnis zwischen Text und Hintergrund zu gering, meldet es das.

Die Web Accessibility Initiative (WAI) des W3C zieht die Grenze klar. Laut ihrem Leitfaden zur Auswahl von Tools können Tools Barrierefreiheit nicht feststellen, sie können nur dabei helfen. Derselbe Leitfaden schreibt, dass Tools manchmal falsche oder irreführende Ergebnisse liefern.

Die Übersichtsseite der WAI zur Evaluierung sagt dasselbe: Kein Tool kann allein feststellen, ob eine Website die Standards erfüllt. Dafür braucht es die Beurteilung eines Menschen, der sich auskennt.

Die Regeln hängen an Erfolgskriterien der WCAG. Aber nicht jedes Kriterium lässt sich aus dem Code ablesen. Die Antwort auf die Frage „Erfüllt dieser Alternativtext die Aufgabe des Bilds?“ steht nicht im Code.

axe: die Regel-Engine

axe-core ist eine Open-Source-Engine für Barrierefreiheitstests von Webseiten. Laut README wird sie von Deque Systems aktiv betreut. Sie enthält Regeln für WCAG 2.0, 2.1 und 2.2 auf den Stufen A, AA und AAA, dazu Regeln für Best Practices.

Einer der Grundsätze von axe ist, keinen Fehlalarm zu geben. Laut README ist das Ziel null falsch positive Ergebnisse, abgesehen von Softwarefehlern. Elemente, bei denen axe nicht sicher ist, gibt es als „incomplete“ zurück und sagt, dass sie von Hand geprüft werden müssen.

Deshalb schaue ich beim Lesen eines axe-Berichts auf zwei Listen. Die Fehler sind Aufgaben zum Beheben. Die Liste „muss geprüft werden“ ist die Reihenfolge meiner eigenen Prüfungen.

Eine Einstellung, die Sie kennen sollten

Laut der Regelbeschreibung von axe sind die Regeln für WCAG 2.2 Stufe A und AA standardmäßig abgeschaltet. Als Grund steht dort, dass WCAG 2.2 noch nicht breit übernommen und nicht verpflichtend ist. Die Regel target-size, die die Größe von Tippzielen misst, gehört zu dieser Gruppe.

Auch AAA-Regeln und experimentelle Regeln laufen standardmäßig nicht. Zielen Sie auf WCAG 2.2 AA, schalten Sie diese Regeln in Ihrer Testumgebung ausdrücklich ein. Sonst hat ein sauber wirkender Bericht die Kriterien aus 2.2 vielleicht gar nicht angesehen.

Die Lighthouse-Punktzahl für Barrierefreiheit

Lighthouse ist ein automatisches Open-Source-Tool zur Prüfung von Seiten. Es prüft Bereiche wie Performance, Barrierefreiheit und SEO. Es lässt sich aus den Chrome-Entwicklertools, über die Kommandozeile, als Node-Modul oder über die Website PageSpeed Insights starten.

Die Punktzahl für Barrierefreiheit ist der gewichtete Durchschnitt aller Barrierefreiheitsprüfungen. Jede Prüfung ist bestanden oder nicht bestanden, Teilpunkte gibt es nicht. Fehlt einem Teil der Buttons auf der Seite der Name, bekommen Sie für diese Prüfung null.

Die Gewichte reichen von 3 bis 10. Die Seite zur Bewertung in Lighthouse stützt die Gewichte auf die Einschätzung der Nutzerauswirkung durch axe. Der Name von Buttons, das alt-Attribut von Bildern und das Label von Formularelementen gehören zu den Prüfungen mit Gewicht 10.

Was die Punktzahl nicht zählt, steht auf derselben Seite. Prüfungen, die von Hand gemacht werden müssen, sowie Prüfungen mit geringer Auswirkung oder für Best Practices beeinflussen die Punktzahl nicht. 100 Punkte sagen also, dass alles bestanden ist, was das Tool angesehen hat. Über alles andere sagen sie nichts.

Wenn Sie Lighthouse auch für die Performance nutzen: Diese Seite beschreibe ich im Ratgeber zu Core Web Vitals.

WAVE: Probleme direkt auf der Seite sehen

WAVE ist eine Sammlung von Evaluierungstools, die WebAIM auf seiner Website anbietet. Es gibt Erweiterungen für Chrome, Firefox und Edge. Die Ergebnisse legt WAVE mit Icons direkt über die Seite. Für Designer ist das für mich das am leichtesten lesbare Tool.

Laut der Hilfeseite von WAVE sind rote Icons Fehler, die behoben werden müssen. Grüne Icons sind Elemente, die die Barrierefreiheit wahrscheinlich verbessern, aber auch sie sollten geprüft werden. Gelbe Warnungen markieren Stellen, die Sie sich ansehen sollten.

WAVE nennt auch seine eigene Grenze. Es kann Ihnen nicht sagen, ob die Seite barrierefrei ist, das kann nur ein Mensch feststellen. Dass keine Fehler erscheinen, heißt auch nicht, dass die Seite barrierefrei oder konform ist.

Eine Gewohnheit von WAVE mag ich. Weil es nicht weiß, ob ein Alternativtext passt, zeigt es den Text auf dem Screen und überlässt Ihnen die Entscheidung. Steht bei den Fotos in der Produktliste nur „Bild“, sehen Sie das auf einen Blick.

Wie viele Probleme finden automatische Tools?

Eine der Zahlen zu dieser Frage stammt aus der README von axe. Dort steht, dass sich mit axe-core im Schnitt 57 % der WCAG-Probleme automatisch finden lassen. Bevor man diese Zahl nutzt, sollte man schauen, wie sie gemessen wurde.

Die Zahl beruht auf Deques eigenem Bericht zur Abdeckung automatischer Tests. Der Bericht untersucht über 13.000 Seiten und fast 300.000 Probleme aus mehr als 2.000 Audits. Berücksichtigt wurden nur erste Audits. Von insgesamt 294.958 Problemen wurden 169.242 mit automatischen Tests gefunden, das sind 57,38 %.

Wichtig ist: Die Quote ist nach der Zahl der Probleme berechnet, nicht nach der Zahl der Kriterien. Im selben Bericht steht, dass nur bei 16 der 50 Erfolgskriterien von WCAG 2.1 AA automatisch gefundene Probleme auftraten. Laut Bericht kommen manche Problemarten viel häufiger vor als andere. 73.733 der 169.242 automatisch gefundenen Probleme stammen aus einem einzigen Kriterium, 1.4.3 Kontrast.

Der Bericht hat weitere Grenzen. Untersucht wurden nur HTML-Seiten und die Stufen A und AA von WCAG 2.0 und 2.1. Die Daten stammen aus Audits, die Deque mit eigenen Tools und eigener Methode gemacht hat. Wer misst und wer das Tool verkauft, ist also dieselbe Firma.

Ich lese die Zahl so: Das Tool räumt einen großen Teil der häufigen Fehler schnell weg. Aber bei den meisten Kriterien hat der Mensch das letzte Wort.

Ausprobieren: Was findet das Tool?

Die acht Karten unten sind ausgedachte Beispiele für Probleme, die ich in Audits oft sehe. Wählen Sie bei jeder Karte: Findet das ein automatisches Tool, oder muss ein Mensch von Hand hinschauen? Nach Ihrer Wahl öffnen sich Antwort und Begründung unter der Karte.

Was findet das Tool?

• Blassgrauer Hilfetext

  Auf weißem Grund steht ein hellgrauer, kleiner Hinweistext. Das Kontrastverhältnis liegt unter 4,5:1.

  Tool findet es. Das Verhältnis von Text auf einfarbigem Grund misst das Tool. Genau danach sucht die Regel color-contrast von axe. Dieselbe Regel liefert manchmal auch „muss geprüft werden“, dann messen Sie selbst.

• Produktfoto ohne Alternativtext

  Das Hauptfoto auf der Produktseite hat im img-Element gar kein alt-Attribut.

  Tool findet es. Dass das Attribut fehlt, steht im Code. Die Regel image-alt von axe und eine der am stärksten gewichteten Prüfungen von Lighthouse finden das.

• Sinnloser Alternativtext

  Am Bild steht alt="IMG_2041.jpg". Das Attribut ist da, sagt aber nicht, was das Bild zeigt.

  Nur von Hand. Das Tool sieht, dass es einen Alternativtext gibt, und lässt ihn durch. Ob der Text das Bild ersetzt, entscheidet ein Mensch. Deshalb zeigt WAVE den Alternativtext auf dem Screen und überlässt Ihnen die Entscheidung.

• Icon-Button ohne Namen

  Das Mülleimer-Icon im Warenkorb ist ein Button. Darin steckt nur ein SVG, kein Text und kein aria-label.

  Tool findet es. Der zugängliche Name des Buttons ist leer. Die Regel button-name von axe findet das, und Lighthouse zählt dieselbe Prüfung mit dem höchsten Gewicht.

• E-Mail-Feld ohne Label

  Im Formular für den Newsletter gibt es ein E-Mail-Feld. Mit dem Feld ist kein label und kein anderer Name verbunden.

  Tool findet es. Die Verbindung zum Label steht im Code, das Tool liest sie. Die Regel label von axe verlangt für jedes Formularelement ein Label. Ob das Label verständlich ist, prüfen aber wieder Sie.

• Durcheinander in der Fokus-Reihenfolge

  Im Checkout springt die Tab-Taste nach dem Namensfeld zu den Links unten auf der Seite und dann zurück zur Kartennummer.

  Nur von Hand. Weil jedes Element einzeln fokussierbar ist, ist kein Regelverstoß zu sehen. Ob die Reihenfolge logisch ist, merken Sie nur beim Durchgehen mit Tab.

• Tastaturfalle

  Ein Fenster mit einer Aktion öffnet sich. Die Tab-Taste kreist im Fenster, Esc schließt es nicht, und der Button zum Schließen ist nicht erreichbar.

  Nur von Hand. Beim Lesen des Codes versucht der Browser nicht, das Fenster zu öffnen und zu schließen. Die Falle findet jemand, der versucht, mit der Tastatur hinein- und wieder hinauszukommen.

• Fehler nur in Rot

  Der Rahmen des fehlerhaften Felds wird rot. Daneben steht kein Text und kein Icon.

  Nur von Hand. Im Code ist alles da: Feld und Label. Dass der Fehler nur über Farbe vermittelt wird, sieht nur ein Mensch, der auf den Screen schaut.

Die Karten sind ausgedacht. Die Einteilung ist meine: Was ich „Tool findet es“ nenne, hat eine Entsprechung in der Regelliste von axe; was ich „Nur von Hand“ nenne, erscheint im Code nicht als Regelverstoß. Auf einer echten Seite wird das Ergebnis des Tools trotzdem mit eigenen Augen bestätigt.

Die vier Probleme, die man nur von Hand findet, haben eines gemeinsam: Der Code sieht „richtig“ aus. Es gibt ein Label, einen Alternativtext, die Elemente sind fokussierbar. Das Problem liegt darin, was das alles zusammen dem Nutzer sagt.

Prüfungen, die kein Tool ersetzt

Wenn der Toolbericht sauber ist, mache ich diese kurze Runde:

1. Ich lege die Maus weg und versuche, den Hauptablauf nur mit der Tastatur abzuschließen. Der Fokusring muss bei jedem Schritt sichtbar sein, die Reihenfolge der Lesereihenfolge auf dem Screen folgen.
2. In jedes Fenster, das sich öffnet, gehe ich hinein und versuche, mit Esc und Tab wieder herauszukommen. Wenn das Fenster zugeht, muss der Fokus zum Button zurückkehren, der es geöffnet hat.
3. Den Kontrast von Text auf Fotos oder Farbverläufen messe ich von Hand. Geben Sie die Farben in den Kontrastrechner ein, dann sehen Sie das Verhältnis.
4. Ich fülle das Formular absichtlich falsch aus. Der Fehler muss nicht nur über Farbe, sondern auch in Text vermittelt werden. Wie das geht, zeige ich im Muster zum Formulardesign.
5. Ich schalte den Screenreader ein und höre mir die Alternativtexte der Bilder und die Namen der Buttons an.

Diese Runde findet nicht alles, schaut aber auf die meisten Stellen, an denen das Tool blind ist. Die Schritte einer vollständigen Prüfung finden Sie im Ratgeber zur Prüfung.

Die rechtlichen Pflichten in Deutschland beschreibe ich auf dieser Seite nicht. Dafür lesen Sie den Abschnitt zu BFSG und BITV 2.0 im WCAG-Ratgeber.

Meine Notiz

Teams, die mit „Wir haben 100 in Lighthouse, wir sind barrierefrei“ zu mir kommen, bitte ich zuerst, mit der Tastatur zu bezahlen. Meist bleiben wir am ersten Fenster hängen, das sich öffnet. Die Punktzahl ist nicht falsch. Sie hat diese Frage nur nie gestellt.

Zur Wahl des Tools habe ich nur einen Rat: Wichtiger als welches Tool ist, wie oft Sie es laufen lassen. Bauen Sie axe in Ihre Testumgebung ein, kommen dieselben Fehler nicht mit jedem Release zurück. WAVE gebe ich dem Design, Lighthouse nutze ich für einen schnellen ersten Blick.

Befunde aus dem Toolbericht kopiere ich auch nicht einfach. In meinen Bericht schreibe ich nur Probleme, die ich auf dem Screen mit eigenen Augen bestätigt habe. Wenn Sie das für Ihr Produkt machen lassen wollen: Der UX Audit enthält die Kernprüfungen der WCAG 2.2.