Barrierefreiheit und SEO: eine Arbeit, zwei Gewinne

Ein Suchmaschinen-Crawler ist funktional ein blinder Nutzer mit schneller Leitung: Er sieht das Design nicht, er liest die Dokumentstruktur. Deshalb ist fast alles, was Barrierefreiheit verlangt – Semantik, Hierarchie, Textalternativen, aussagekräftige Linknamen –, zugleich ein SEO-Signal. Und seit Juni 2025 macht der European Accessibility Act (EAA) Barrierefreiheit für die meisten digitalen Verbraucherdienste in der EU zur gesetzlichen Pflicht: Was früher „nice to have" war, kann jetzt Bußgelder nach sich ziehen. In Deutschland setzt das Barrierefreiheitsstärkungsgesetz (BFSG) die Richtlinie um.

Die Schnittmenge: eine Korrektur, zwei Nutznießer

• Überschriftenhierarchie (h1 → h2 → h3, ohne Sprünge, genau ein h1) ist die Gliederung, an der sich Screenreader orientieren – und die Struktur, aus der Crawler und KI-Suchmaschinen Abschnitte herausziehen und zitieren.
• Semantische Landmarken (<nav>, <main>, <article>, <footer>) sagen assistiven Technologien und Parsern, worum es in jedem Bereich geht. Eine Suppe aus <div>-Elementen ist für Parser schwerer zu deuten und fällt bei Audits durch.
• Alt-Texte bedienen mit derselben Zeichenkette Screenreader und die Bildersuche.
• Linknamen: „hier klicken" besteht WCAG nicht (ein Link muss auch ohne Kontext Sinn ergeben) und verschenkt das Ankersignal. Eine einzige Umformulierung behebt beide Probleme.
• lang-Attribute – am <html>-Element und an fremdsprachigen Passagen – steuern die Aussprache der Screenreader und die Spracherkennung für Ihr hreflang.
• CLS ist ein Barrierefreiheitsproblem, bevor es eine Metrik wird: Layoutsprünge treffen Menschen mit motorischen und visuellen Einschränkungen am stärksten. Die Behebung der Core Web Vitals ist Barrierefreiheitsarbeit.

Barrierefreiheit ist kein direkter Rankingfaktor. Manche Umsetzungsdetails, etwa semantische Struktur und beschreibender Text, erleichtern es Suchsystemen aber auch, eine Seite zu interpretieren.

Next.js: im Pipeline erzwingen

// .eslintrc — jsx-a11y fängt fehlende Alt-Texte, falsche Rollen und unbeschriftete Bedienelemente schon im PR ab
{
  "extends": ["next/core-web-vitals", "plugin:jsx-a11y/recommended"]
}

• next/image verlangt alt bereits – drücken Sie sich bei aussagekräftigen Bildern nicht mit einem leeren alt="" davor.
• Setzen Sie <html lang={locale}> im Haupt-Layout aus dem Routenparameter.
• Lassen Sie in der CI Lighthouse Accessibility neben Performance laufen – dasselbe Tooling, das Sie fürs Monitoring ohnehin haben, nur ein Gate mehr.
• Automatisierung findet ~30–40 % der WCAG-Probleme; das Durchgehen der Hauptwege nur mit der Tastatur findet den Großteil des Rests. Wenn Sie ein Element nicht mit Tab erreichen, erreicht ein Crawler es womöglich auch nicht über Links.

EAA: die Frist, die die Diskussion beendet

Seit dem 28. Juni 2025 erfasst der EAA E-Commerce, Bankwesen, Verkehr, E-Books und die meisten digitalen Verbraucherdienste, die in der EU angeboten werden (Kleinstunternehmen mit weniger als 10 Beschäftigten und 2 Mio. € Umsatz sind ausgenommen). Die Durchsetzung ist national und beschwerdebasiert – ein nicht barrierefreier Checkout ist jetzt ein rechtliches Risiko, kein Backlog-Eintrag. Die praktische Messlatte ist WCAG 2.1 AA (über EN 301 549) – genau der Standard, auf den die obigen Korrekturen zielen.

Checkliste:

• Ein h1 pro Seite; Überschriftenebenen ohne Sprünge; semantische Landmarken vorhanden
• Jedes aussagekräftige Bild hat einen echten Alt-Text; jeder Link ergibt auch ohne Kontext Sinn
• lang aus der Locale am <html>-Element und an fremdsprachigen Passagen gesetzt
• jsx-a11y in ESLint + Lighthouse-A11y-Gate in der CI; Hauptwege per Tastatur getestet
• Anwendbarkeit des EAA geprüft; Verbraucherwege erfüllen WCAG 2.1 AA