Tools für Barrierefreiheit & SEO

Werkzeuge nehmen einem die stumpfe Arbeit ab: fehlende Alt-Attribute, zu schwache Kontraste, kaputte Strukturen finden sie in Sekunden. Was sie nicht können, ist beurteilen, ob ein Alt-Text sinnvoll ist oder eine Bedienung Sinn ergibt – das bleibt menschliche Arbeit. Ich verstehe Tools deshalb als Verstärker, nicht als Ersatz für das eigene Prüfen.

Die folgende Auswahl ist bewusst kurz gehalten: Es sind die Werkzeuge, die ich tatsächlich nutze, nicht jedes, das es gibt. Wie sie im Prüf-Ablauf zusammenspielen, steht unter Barrierefreiheit selbst testen. Die Links führen jeweils zur offiziellen Seite des Tools.

Tools sehen nur einen Teil. Automatische Prüfer decken je nach Schätzung nur etwa ein Drittel der WCAG-Kriterien ab. Ein grüner Wert ist ein gutes Zeichen, aber kein Konformitätsnachweis – die manuellen Schritte bleiben Pflicht.

Automatische Barrierefreiheits-Prüfer

• axe DevTools – Browser-Erweiterung mit sehr verlässlichen Befunden und wenig Fehlalarmen. Das nutze ich am häufigsten.
• WAVE – zeigt Probleme direkt visuell auf der Seite an, gut zum Erklären.
• Lighthouse – in Chrome eingebaut, praktisch für den schnellen Wert und die Verlaufskontrolle.
• IBM Equal Access und Pa11y – wenn ich Prüfungen automatisieren oder in eine Pipeline hängen will.

Wie ich sie einsetze: Barrierefreiheit selbst testen.

Kontrast & Farbe

• WebAIM Contrast Checker – schnell, eindeutig, mein Standard fürs Nachmessen.
• TPGi Colour Contrast Analyser (CCA) – Desktop-Pipette für Farben außerhalb des Browsers.
• Farbenblindheits-Simulationen – etwa die Render-Emulation in den Chrome DevTools, um zu prüfen, ob eine Information allein über Farbe transportiert wird.

Welche Werte gelten und wie man sie erreicht: Farbkontraste.

Tastatur & Fokus

Hier ist das beste Werkzeug die eigene Hand: Maus weglegen und mit Tab, Shift+Tab, Enter und Leertaste durch die Seite gehen. Kein Tool ersetzt diesen Durchlauf – Details unter Tastatur & Fokus.

Screenreader

• NVDA (Windows, kostenlos) – mein Tipp für den Einstieg.
• VoiceOver (macOS / iOS) – ab Werk dabei.
• JAWS (Windows) – im professionellen Umfeld weit verbreitet.
• TalkBack (Android) und Orca (Linux) – für Tests auf der jeweiligen Plattform.

Erste Schritte und Bedienung: Screenreader-Grundlagen.

Struktur & Validierung

• W3C Nu Html Checker – findet ungültiges Markup, das Browser still schlucken, Hilfsmittel aber stolpern lässt.
• HeadingsMap – zeigt die Überschriften-Struktur und Outline einer Seite auf einen Blick.
• Landmark-Navigation (in axe oder über Browser-Erweiterungen) – prüft die Landmarks.

Performance & Core Web Vitals

• Lighthouse und PageSpeed Insights – Laborwerte plus echte Felddaten.
• WebPageTest – wenn ich genauer hinschauen will, wo die Zeit verloren geht.
• Chrome DevTools (Tab „Performance“) – fürs Detail-Profiling.

Was die Werte bedeuten: Core Web Vitals.

SEO & strukturierte Daten

• Google Rich Results Test und Schema.org Validator – prüfen, ob strukturierte Daten korrekt erkannt werden.
• Google Search Console – zeigt, wie Google die Seite tatsächlich sieht und indexiert.

Meine Grundausstattung

Wenn ich mich auf drei Dinge beschränken müsste, wären es axe DevTools, der WebAIM Contrast Checker und NVDA. Damit deckt man die häufigsten Probleme ab, ohne sich in Werkzeugen zu verlieren.

Von Overlay-Tools halte ich wenig. Skripte, die Barrierefreiheit per Klick „nachrüsten“, kaschieren Symptome, beheben die Ursachen im Markup nicht und ersetzen weder echtes Testen noch echte Umsetzung. Mehr dazu in den häufigen Fragen unter selbst testen.

Fazit

Eine kleine, gut verstandene Werkzeugkiste schlägt eine große, in der man sich verliert. Tools finden etwa ein Drittel der Probleme zuverlässig – die anderen zwei Drittel findest du mit den Checklisten, ein paar Handgriffen und gesundem Menschenverstand. Den passenden Code zum Umsetzen gibt es in der Snippet-Bibliothek.