Seit dem 12. November gibt es die Version 21.0 von Screaming Frog. Neben einer direkten API-Anbindung für OpenAI, Gemini und Ollama (Chris Long hat dazu auf LinkedIn eine Anleitung und kurzen Test gepostet) und anderen neuen Features gibt es jetzt auch Accessibility Checks. Das musste ich natürlich direkt austesten.
Vorab: Damit Dir Dein Crawl Ergebnisse im neuen Tab Accessibility anzeigt, musst Du Javascript Rendering auswählen und in den Extraction Settings “Accessibility” anhaken:
Das Ergebnis sieht dann so aus:
Der Tab “Accessibility” zeigt eine Übersicht, auf wie vielen Seiten es Probleme gibt und welche. Die Ergebnisse werden nach Versionen und Levels der Web Content Accessibility Guidelines (2.0 bis 2.2.) sortiert:
“WCAG compliance levels build upon each other and start from WCAG 2.0 A to 2.0 AA, then 2.0 AAA before moving onto 2.1 AA and 2.2 AA. To reach the highest level of compliance (2.2 AA), all violations in previous versions must also be achieved.”
Wird ein Problem unter “WCAG 2.0 AA Violation” erfasst, steht es nicht mehr unter “WCAG 2.1 AA Violation” oder “WCAG 2.2 AA Violation”. Das ist sinnvoll, weil sonst alles doppelt stehen würde.
Andersherum hätte ich es aber besser gefunden. Sprich, wenn alles zuerst unter der aktuellen Version (WCAG 2.2) gelistet wird. Denn die neuesten WCAG sind immer rückwärtskompatibel. Alles, was unter WCAG 2.2 ein Problem ist, ist es auch unter WCAG 2.0.
Andersherum trifft das aber nicht immer zu. Zum Beispiel ist es unter den WCAG 2.2 kein Problem mehr, wenn Elemente keine vollständigen Start- und End-Tags haben. Unter WCAG 2.0 und 2.1 galt das hingegen noch als Nicht-Erfüllen von 4.1.1 Parsing.
Wer sich den Update-Artikel zu Version 21.0 nicht durch- oder “all violations in previous versions must also be achieved” überliest, könnte das Ergebnis missverstehen (à la: Ich hab kein Issue in der aktuellen Version also hab ich generell kein Problem).
Was ich auch etwas umständlich finde ist, dass leider nicht angegeben wird, welche WCAG-Kriterien betroffen sind, sondern “nur” eine Problembeschreibung (zum Beispiel “Text Requires Higher Color Contrast to Background” WCAG 2.0 AA).
Das macht es schwerer direkt in den WCAG passende Informationen dazu zu suchen. Welches WCAG-Kriterium nicht erfüllt ist, erfährt man nur über den Link, der im Details-Tab neben “Help” angezeigt wird:
Wählt man eine URL aus, sieht man im unteren Details-Tab, welche Probleme es auf dieser URL gibt. Mit Klick auf eine der “Issues” erfährt man, an welcher Stelle (Location on Page) das Problem auftritt.
Über den grünen Help-Link oben links (hier geht es zum Beispiel aus dem Screenshot) findet man dann zusätzliche Informationen, die das Problem und dessen -Lösung genauer beschreiben und wie oben schon erwähnt, die dazu gehörigen WCAG-Kriterien.
Mein Fazit zum Accessibility-Check in Screaming Frog 21.0:
- Für Accessibility-Neulinge ggf. etwas überfordernd, da sehr umfangreich.
- Für Leute, die sich mit digitaler Barrierefreiheit schon auseinandergesetzt haben, ist der Check eine gute Unterstützung.
- Er ersetzt aber keine manuelle Prüfung. Denn auch, wenn hier sehr viele Probleme überprüft werden, sind das trotzdem noch nicht alle.
- Ob es zum Beispiel einen sichtbaren Fokus (WCAG 2.4.7 Focus Visible - Level AA) gibt, wird nicht geprüft. Das Erfolgskriterium muss Deine Website aber bestehen, um den Vorgaben des Barrierefreiheitsstärkungsgesetzes zu entsprechen.
Falls Du Dich tiefer mit Barrierefreiheit befassen möchtest, komm doch heute Abend zum SEO Meet up in den Code Working Space. Da spreche ich nämlich darüber, wie SEO die Barrierefreiheit verbessert.
