Barrierefreiheit nach WCAG 2.2: SEO und Inklusion

Etwa 7,8 Millionen Menschen in Deutschland leben mit einer anerkannten schweren Behinderung — dazu kommen Millionen weitere mit temporären oder situativen Einschränkungen: eine gebrochene Hand, eine Augenoperation, Lärm in der U-Bahn beim Lesen auf dem Smartphone. Barrierefreiheit im Web betrifft also nicht eine kleine Nische, sondern einen erheblichen Teil Ihrer potenziellen Patientinnen und Patienten.

Das Barrierefreiheitsstärkungsgesetz (BFSG) verpflichtet seit Juni 2025 viele Unternehmen, ihre digitalen Angebote barrierefrei zu gestalten. Für Arztpraxen und Gesundheitseinrichtungen ist Barrierefreiheit zudem ein Vertrauenssignal — und sie überlappt technisch mit SEO, weil viele WCAG-Anforderungen dieselben Prinzipien adressieren wie suchmaschinenfreundliches Markup.

WCAG 2.2: Die vier Prinzipien

Die Web Content Accessibility Guidelines (WCAG) 2.2 strukturieren Anforderungen in vier Prinzipien: Wahrnehmbar, Bedienbar, Verständlich und Robust. Jedes Prinzip enthält konkrete Erfolgskriterien auf drei Konformitätsstufen: A (Minimum), AA (Standard für die meisten gesetzlichen Anforderungen) und AAA (höchste Stufe, nicht immer erreichbar).

Für Praxiswebsites ist Konformitätsstufe AA der realistische und empfohlene Zielstandard. Stufe A allein reicht für die BFSG-Konformität nicht aus. Stufe AAA ist für komplexe Websites oft nicht vollständig erreichbar, einzelne AAA-Kriterien sind aber wo möglich sinnvoll.

WCAG 2.2 ergänzt WCAG 2.1 um neun neue Erfolgskriterien — darunter Focus Not Obscured (fokussierte Elemente dürfen nicht verdeckt werden), Dragging Movements (Alternativen zu Drag-and-Drop) und Target Size (Mindestgröße für Touch-Targets). Bestehende Websites sollten bei Überarbeitungen die neuen Kriterien mit einbeziehen.

Wahrnehmbar: Inhalte für alle Sinne zugänglich

Alternativtexte für Bilder (1.1.1): Jedes informative Bild braucht einen alt-Text, der den Inhalt beschreibt. Dekorative Bilder erhalten alt=“”. Ein Teamfoto: „Dr. Schmidt und Dr. Weber in der Praxis am Empfang“. Nicht: „Bild1.jpg“ oder „Team“.

Farbkontrast (1.4.3): Text muss ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund haben (3:1 für großen Text ab 18pt). Das betrifft häufig Praxiswebsites mit hellen Grüntönen auf weißem Hintergrund oder graue Texte auf hellgrauen Flächen. Tools wie der WebAIM Contrast Checker validieren Kontraste vor dem Launch.

Textgröße und Skalierbarkeit (1.4.4): Inhalte müssen auf 200 Prozent Zoom ohne Funktionsverlust lesbar sein. Feste Pixelgrößen in CSS vermeiden, relative Einheiten (rem, em, %) nutzen.

Untertitel und Transkripte (1.2): Videos auf der Praxiswebsite — Erklärvideos zu Behandlungen, Praxisführungen — brauchen Untertitel. Audio-Inhalte brauchen Transkripte. Das verbessert nicht nur Barrierefreiheit, sondern auch SEO, weil der Text indexierbar wird.

Bedienbar: Navigation und Interaktion

Tastaturbedienbarkeit (2.1.1): Alle Funktionen müssen per Tastatur erreichbar sein — Navigation, Formulare, Akkordeons, Modals. Kein Element darf in einer Tastaturfalle stecken. Tab-Reihenfolge muss logisch sein.

Fokus sichtbar (2.4.7): Der Tastaturfokus muss deutlich sichtbar sein. outline: none in CSS ohne Ersatz-Fokusindikator ist ein häufiger Fehler in modernen Designs. Ein sichtbarer Fokusrahmen hilft auch sehenden Nutzern, die per Tastatur navigieren.

Touch-Target-Größe (2.5.8, WCAG 2.2): Klickbare Elemente müssen mindestens 24×24 CSS-Pixel groß sein (AA) bzw. 44×44 Pixel empfohlen. Telefonnummern, Termin-Buttons und Navigationslinks auf Mobilgeräten sind häufige Verstöße.

Keine reine Farbkodierung (1.4.1): Informationen dürfen nicht nur über Farbe vermittelt werden. Formularfehler brauchen Text und Icon, nicht nur rote Umrandung. Statusanzeigen brauchen Textlabels.

Verständlich: Klare Sprache und vorhersagbares Verhalten

Sprache der Seite (3.1.1): Das lang-Attribut im html-Tag muss gesetzt sein (lang=“de”). Bei mehrsprachigen Inhalten innerhalb einer Seite: lang-Attribut auf dem jeweiligen Element.

Konsistente Navigation (3.2.3): Navigation und wiederkehrende Elemente müssen auf allen Seiten gleich positioniert sein. Patienten, die von der Startseite zur Leistungsseite navigieren, erwarten die Menüführung an derselben Stelle.

Formularbeschriftungen (3.3.2): Jedes Formularfeld braucht ein sichtbares label oder aria-label. Platzhaltertext ersetzt kein Label. Fehlermeldungen müssen verständlich sein: „Bitte geben Sie eine gültige E-Mail-Adresse ein“ statt „Fehler“.

Kontaktformulare auf Praxiswebsites sind ein häufiger Barrierefreiheits-Engpass. Pflichtfelder klar markieren, Fehler inline und nicht nur nach Absenden anzeigen, und den Submit-Button nicht deaktivieren, sondern Fehler beim Absenden melden.

Robust: Technisch zukunftssicher

Valides HTML (4.1.1): Korrekte Verschachtelung, eindeutige IDs, geschlossene Tags. Screenreader und assistive Technologien parsen den DOM — fehlerhaftes Markup führt zu falscher Vorlese-Reihenfolge oder fehlenden Inhalten.

ARIA nur wo nötig (4.1.2): ARIA-Attribute (aria-label, aria-expanded, role) dort einsetzen, wo native HTML-Elemente nicht ausreichen. details/summary für Akkordeons ist besser als div mit aria-expanded. Buttons sind besser als div mit role=“button”.

Name, Role, Value: Interaktive Elemente müssen für assistive Technologien einen zugänglichen Namen, eine Rolle und einen Wert haben. Ein Hamburger-Menü-Button braucht aria-label=“Menü öffnen” und aria-expanded=“false”.

Barrierefreiheit und SEO: Gemeinsame Schnittmenge

Viele WCAG-Anforderungen verbessern gleichzeitig SEO: Alternativtexte helfen der Bildersuche. Semantisches HTML (h1–h6, nav, main, article) hilft Google, Inhalte zu verstehen. Strukturierte Überschriften-Hierarchie verbessert Crawlbarkeit. Schnelle Ladezeiten (indirekt WCAG 2.2.2: ausreichend Zeit) verbessern Core Web Vitals.

Barrierefreiheit ist kein SEO-Trick — aber eine barrierefreie Website ist technisch sauberer, und technisch saubere Websites ranken besser.

Checkliste: WCAG 2.2 Konformität (Stufe AA)

• Alternativtexte für alle informativen Bilder
• Farbkontrast mindestens 4,5:1 (Text) bzw. 3:1 (großer Text)
• Tastaturbedienbarkeit aller interaktiven Elemente
• Sichtbarer Fokusindikator bei Tastaturnavigation
• Touch-Targets mindestens 24×24 Pixel
• Formularfelder mit sichtbaren Labels und verständlichen Fehlermeldungen
• lang=“de” im html-Element
• Überschriften-Hierarchie ohne Sprünge (h1 → h2 → h3)
• Videos mit Untertiteln
• Automatisierten Test (axe, Lighthouse Accessibility) und manuellen Test mit Screenreader

Fazit

Barrierefreiheit nach WCAG 2.2 ist ab 2025 für viele Unternehmen gesetzliche Pflicht — und für Praxiswebsites ohnehin eine Frage der Patientenorientierung. Wer WCAG 2.2 Stufe AA als Standard im Webprojekt verankert, schafft eine Website, die mehr Menschen erreicht, Vertrauen signalisiert und technisch sauberer ist. Bei Monoworks berücksichtigen wir Barrierefreiheit von der Konzeption bis zum Launch — nicht als nachträglichen Audit-Bericht, sondern als integralen Bestandteil jeder Praxiswebsite.