WordPress-Website auf Barrierefreiheit prüfen: So fängst du an

Barrierefreiheit ist ein großes Wort. Und wenn man es zu wörtlich nimmt, lähmt es mehr als es hilft.

Eine Website zu 100 % barrierefrei zu machen, das halte ich für unrealistisch. Zu viele Details, zu viele individuelle Bedürfnisse, zu viele Situationen, die kein Tool der Welt vollständig abbilden kann. Was ich stattdessen anstrebe: barriere-arm. Möglichst wenig unnötige Hürden. Und das als Prozess, nicht als einmaliges Projekt.

In diesem Artikel zeige ich dir, wie ich eine WordPress-Website auf Barrierefreiheit prüfe. Du erfährst, welche Tools ich nutze, was ich dabei lerne, und welche Fehler ich immer wieder finde.

Barriere-arm statt barrierefrei: Warum das der ehrlichere Ansatz ist

Perfektion ist kein realistisches Ziel. Das gilt besonders für Barrierefreiheit. Zu viele Kleinigkeiten, zu viele individuelle Einschränkungen, zu viele Situationen, die man nicht alle gleichzeitig berücksichtigen kann.

Was aber realistisch ist: systematisch besser werden. Fehler identifizieren, verstehen, beheben. Und dann den nächsten angehen. Barrierefreiheit ist für mich ein Ideal, dem man sich optimal annähert.

Zukünftig möchte ich noch mehr Betroffene selbst in den Prozess einbinden und von ihnen lernen. Denn das ist der Punkt, den kein Tool ersetzen kann: die Perspektive von Menschen, die täglich mit eingeschränkt zugänglichen Websites umgehen müssen.

Tools für den Einstieg: was sie können (und was nicht)

Ich taste mich mit mehreren Tools an eine Website heran. Kein einzelnes Tool gibt das vollständige Bild. Sie ergänzen sich vielmehr.

WAVE (wave.webaim.org): Der einfachste Einstieg. URL eingeben, sofort sehen, wo Fehler sind. Gut für einen ersten Überblick über fehlende Alt-Texte, Kontrastprobleme und strukturelle Fehler. Kostenlos, keine Installation nötig.

Google Lighthouse: Direkt im Browser über die Entwicklertools (F12) erreichbar. Liefert einen Accessibility-Score und zeigt konkrete Verbesserungspunkte. Auch für Ladezeit und Core Web Vitals nützlich und somit ein Tool für mehrere Aufgaben.

axe DevTools: Browser-Extension, die tief in den Code schaut. Liefert präzisere Fehlerbeschreibungen als WAVE und ist ideal, wenn man verstehen will, warum etwas ein Problem ist.

Silktide: Umfassenderes Audit-Tool, das auch redaktionelle Probleme erkennt. So zum Beispiel schwer lesbare Sprache oder fehlende Seitentitel. Gut für einen tieferen Check über einzelne Seiten hinaus.

Siteimprove / Web Accessibility Crawler: Für größere Websites und systematische Audits. Crawlt die gesamte Website und erstellt eine Übersicht aller gefundenen Probleme.

Wichtig zu wissen: Alle diese Tools zusammen decken schätzungsweise 30-40 % der möglichen Barrierefreiheitsprobleme automatisch auf. Den Rest findet nur ein Mensch. Am besten jemand, der selbst auf Assistenztechnologien angewiesen ist.

Der beste erste Test: VoiceOver auf dem Mac

Bevor ich irgendeins der Tools öffne, mache ich auf dem Mac oft zuerst einen einfachen Test: VoiceOver einschalten, Augen schließen, Tab-Taste drücken. Und dann die eigene Website erkunden.

Das klingt simpel. Aber man lernt dabei unglaublich viel.

Plötzlich merkst du: Der Fokus-Rahmen fehlt. Du weißt also nicht, wo du gerade auf der Seite bist. Die Tab-Reihenfolge springt wild durch die Seite. Ein Button heißt "Klick hier" - aber wofür? Ein Link sagt "mehr erfahren" - aber worüber?

Für sehende Nutzer sind das Kleinigkeiten. Für jemanden, der ausschließlich per Tastatur und Screenreader navigiert, sind es echte Barrieren.

VoiceOver aktivierst du auf dem Mac mit Cmd + F5. Auf Windows gibt es den kostenlosen Screenreader NVDA.

Die häufigsten Fehler - und warum sie auch SEO schaden

Nach vielen Website-Audits sehe ich immer wieder dieselben Probleme. Das Interessante: Fast alle sind gleichzeitig auch SEO-relevante Fehler.

Fehlende oder schlechte Alt-Texte

Für Screenreader-Nutzer ist ein Bild ohne Alt-Text unsichtbar. Oder noch schlimmer, es wird als "image003.jpg" vorgelesen. Für Google ist ein fehlendes Alt-Attribut eine verpasste Chance bei der Bildsuche.

Alt-Texte sollten beschreibend sein: nicht "Logo", sondern "Markus Richter, SEO-Berater aus Hamburg". Nicht "Handwerker", sondern "Klempner repariert Wasserleitung in Hamburger Altbauwohnung".

Falsche Überschriftenstruktur

Überschriften sind für Screenreader-Nutzer das Inhaltsverzeichnis einer Seite. Wer mehrere H1 setzt, auf H2 verzichtet und H3 als Gestaltungselement missbraucht, macht die Seite für Screenreader unlesbar und für Google schwerer verständlich.

Die Regel ist einfach: H1 einmal, H2 für Hauptabschnitte, H3 für Unterpunkte. Konsequent, nicht dekorativ.

Schlechte Kontraste und Lesbarkeit

Cremige Pastellfarben sehen im Designentwurf elegant aus. In der Sonne auf dem Smartphone, mit Alterssichtigkeit oder bei einer Sehschwäche sind sie kaum lesbar.

Der WCAG-Standard fordert mindestens 4,5:1 Kontrast für normalen Text. Das lässt sich mit WAVE oder dem WebAIM Contrast Checker in Sekunden prüfen.

Nicht-sprechende Links

Das ist einer der Fehler, der mich am meisten beschäftigt. Weil er so einfach zu beheben wäre und trotzdem überall vorkommt.

Stell dir vor, du hörst (durch den Screenreader) eine Blogübersicht mit zehn Beiträgen. Unter jedem Beitrag steht ein Link. Alle heißen "mehr erfahren". Du hörst zehnmal hintereinander "mehr erfahren", ohne zu wissen, worüber du mehr erfahren wirst.

Sprechende Links lösen das: "Mehr erfahren über Local SEO für Handwerker" statt "mehr erfahren". Eine kleine Änderung, die aber einen großen Unterschied macht.

Fehlende Listen bei aufzählbaren Inhalten

Eine Angebotskachel mit drei Features sieht für sehende Nutzer sofort strukturiert aus. Ein Screenreader liest sie als zusammenhängenden Text. Er weiß nicht, dass es sich um eine Liste handelt.

Wer semantisch korrekte Listen verwendet (<ul> oder <ol>), gibt dem Screenreader wichtige Kontextinformationen: "Liste mit vier Elementen". Der nicht-sehende Nutzer weiß sofort, wie viele gleichartige Dinge noch folgen. Das ist ein echter Mehrwert und gleichzeitig sauberes HTML.

Fehlender Skip-Link

Ein Skip-Link ist ein unsichtbarer Link am Seitenanfang, der Tastaturnutzern ermöglicht, direkt zum Hauptinhalt zu springen, ohne vorher durch die gesamte Navigation tabben zu müssen.

Für sehende Nutzer ist er unsichtbar. Für Tastatur- und Screenreader-Nutzer ist er eine erhebliche Erleichterung. Er taucht oft als erstes auf, wenn man Tab drückt und verschwindet danach wieder. Wenige Zeilen Code, große Wirkung.

Tastaturbedienung nicht funktionsfähig

Kann man alle wichtigen Funktionen der Website per Tastatur erreichen? Kontaktformular, Navigation, Buttons, Links?

Der einfachste Test: Tab-Taste drücken und durch die Seite navigieren. Ist immer klar sichtbar, welches Element gerade fokussiert ist? Viele WordPress-Themes schalten den Fokus-Rahmen aus, weil Designer ihn "unschön" finden. Das Ergebnis: Man navigiert blind durch die Seite.

Häufig gestellte Fragen

Mein Fazit: Barrierefreiheit als Haltung, nicht als Projekt

Barrierefreiheit ist kein Projekt, das man abschließt. Es ist eine Haltung, die man durch Lernen, Testen, Verstehen und Nachjustieren entwickelt.

Fang mit den Basics an: Alt-Texte, Überschriftenstruktur, Kontraste, sprechende Links. Das sind dieselben Dinge, die auch SEO verbessern. Du erledigst also zwei Aufgaben auf einmal.

Dann mach den VoiceOver-Test. Schließ die Augen, drück Tab, erkunde deine eigene Seite. Du wirst Dinge entdecken, die kein Tool findet.

Und irgendwann: Binde Menschen ein, die täglich auf diese Technologien angewiesen sind. Kein Tool und kein Experte ersetzt diese Perspektive.

Barriere-arm statt barrierefrei: das ist ein realistisches, ehrliches Ziel. Und es ist besser als gar nichts anzugehen, weil es perfekt sein müsste.

👉 Warum Barrierefreiheit uns alle betrifft - nicht nur Menschen mit Behinderung: Barrierefreiheit im Web: Warum deine Website mehr Menschen ausschließt als du denkst

👉 Wie sauberes HTML gleichzeitig für besseres SEO sorgt: Was ist E-E-A-T - und warum entscheidet es darüber, ob Google dir vertraut?