Barrierefreiheit bei der Modernisierung — WCAG praxisnah

Barrierefreiheit wird oft auf „WCAG-Badge kaufen“ oder einen Accessibility-Overlay-Button reduziert — der Screenreader eher stört als hilft. Bei einer echten Modernisierung ist der Hebel sauberes Markup und getestete Interaktionen: genau das, was Pagebuilder-Altlasten zerstören. Du profitierst doppelt: mehr Menschen erreichen Kontakt und Leistungen; Maschinen verstehen Überschriften, Labels und Wege besser. Dieser Beitrag beschreibt den praxisnahen WCAG-Pfad für Dienstleister-Webseiten nach Stack-Wechsel — mit klarer Grenze zur Rechtsberatung.

Was Barrierefreiheit bei Modernisierung bedeutet

Antwort zuerst: Barrierefrei heißt hier: mit Tastatur, Screenreader und ohne perfektes Sehen unter Zeitdruck zum Ziel kommen — Leistungsinfo lesen, Kontakt finden, Formular absenden.

Konkret im Modern-Stack-Rebuild:

• eine H1 pro Seite, logische H2/H3-Hierarchie
• echte <button> / <a> statt <div onclick>
• sichtbare Focus-Ringe (nicht outline: none ohne Ersatz)
• Kontrast zu --ms-orange und Textfarben
• Alt-Texte mit Inhalt (nicht „Bild1.jpg“)
• Formular-Labels mit for/id, Fehler am Feld
• Skip-Links wo lange Navigation den Fokus blockiert

Rechtliche BFSG-/BITV-Tiefe bleibt bei deiner Beratung; wir liefern technische Umsetzung und dokumentierte Kernflows im Stack — siehe Abschnitt zur Rechtsgrenze unten. Primärquellen: WCAG Overview, Understanding WCAG 2.2.

Warum Pagebuilder-Barrierefreiheit täuscht

Antwort zuerst: Visuell „schön“ ≠ semantisch korrekt — Elementor/Divi produzieren oft falsche Heading-Ebenen, unlabeled Icons und Dialoge ohne Fokus-Management.

Typische Pagebuilder-Fehler:

Deshalb sind Pagebuilder-Ablösung, WordPress-Migration, Elementor-Migration und Divi-Migration auch Accessibility-Projekte — nicht nur Performance. Markup neu bauen schlägt Overlay auf kaputtem DOM.

Praktische WCAG-Checkliste für KMU-Webseiten nach Modernisierung

Antwort zuerst: Unique Evidence dieses Artikels ist eine knappe, umsetzbare Checkliste für typische Dienstleister-Sites — nicht ein Zertifizierungsprogramm.

1) Tastatur (Keyboard)

Tab-Reihenfolge folgt der visuellen Lesereihenfolge. Alle interaktiven Elemente erreichbar: Navigation, CTAs, Formularfelder, Consent, WhatsApp-Link. Escape schließt Dialoge; Fokus kehrt sinnvoll zurück. Kein Keyboard-Trap in Bannern oder Lightboxen.

2) Sichtbarer Fokus

Jeder fokussierte Control zeigt einen klaren Ring oder Kontrastzustand. outline: none nur mit gleichwertigem Ersatz. Mobile: große Touch-Targets, aber Desktop-Tastatur bleibt Erstklass-Bürger.

3) Kontrast und Farbe

Text und UI gegen Hintergrund ausreichend kontrastreich — auch Orange-Akzent und Links. Links nicht nur über Farbe erkennbar (Unterstreichung oder klares Link-Muster). Informative Inhalte nicht allein in Farbe kodieren (Fehler = rot und Text).

4) Formulare

Jedes Feld hat ein sichtbares Label. Pflichtfelder klar. Fehlermeldungen am Feld, nicht nur als Toast. Erfolgszustand ansagbar. Honeypot/Turnstile dürfen den Tastaturweg nicht zerstören. Details: Datenschutz & Formulare.

5) Medien und Alt-Texte

Informative Bilder bekommen beschreibenden Alt-Text. Dekorative Bilder als dekorativ markieren — Screenreader sollen nicht jeden Hintergrundstock hören. Videos: keine Autoplay-Tonspur ohne Kontrolle.

6) Semantik statt DIV-Wüste

Listen als <ul>/<ol>, Tabellen nur für tabellarische Daten, Landmarken (header, main, nav, footer) wo sinnvoll. Das ist dieselbe HTML-Disziplin, die Technical SEO und Extraktion brauchen.

Diese sechs Blöcke sind der Unique Evidence Asset: praxisnahe WCAG für KMU nach Modernisierung — messbar an Kernflows, nicht an Badge-PDFs.

Formulare, Fokus und Conversion

Antwort zuerst: Dasselbe Formular, das Screenreader bedienbar macht, reduziert Abbrüche für alle Nutzer.

Conversion & Anfragen und Barrierefreiheit überlappen hart: große Touch-Targets mobil, klare Pflichtfeld-Kennzeichnung, Fehlermeldungen verständlich, WhatsApp als sichtbare Alternative. Branchennuance ohne Sonder-Markup-Wildwuchs:

• Physio: Terminweg kurz, große Buttons, Telefon erreichbar
• Steuerberater: sachliche Labels, kein Druck-Jargon
• Handwerk: Telefon/WhatsApp prominent, Einsatzgebiet klar

Leere „Interessen“-Felder, die du gar nicht erhebst, gehören weder in UI noch in Mails — das ist Conversion- und Vertrauenshygiene zugleich.

Testen — ohne Badge-Theater

Antwort zuerst: Automatisierte Tools (Axe, Lighthouse) plus manuelle Checks: Tab durch Navigation, Formular nur mit Tastatur, Zoom, Screenreader-Stichprobe.

Testplan für Go-Live:

1. Startseite → Leistungsseite → Anfrage (nur Tastatur)
2. Fokus sichtbar auf jedem Schritt
3. Formular absenden inkl. Fehlerfall
4. Consent/Banner öffnen und schließen
5. 200 % Zoom ohne horizontalen Scroll-Bruch der Kerninhalte
6. Stichprobe VoiceOver oder NVDA auf dem Kontaktweg
7. Mobile Viewport: CTAs sofort erreichbar

Core Web Vitals — besonders INP — sind indirekte Accessibility: träge Buttons und späte Hydration fühlen sich wie „geht nicht“ an. Nach Go-Live: Komponenten-Standards in Wartung & Updates, damit „kleine“ Design-Tweaks keine Fokus-Regressionen einschleppen.

Barrierefreiheit und Maschinenlesbarkeit

Antwort zuerst: Semantisches HTML ist die Schnittmenge aus WCAG und Extraktion — Überschriften tragen Bedeutung; das ersetzt weder JSON-LD noch Content-Taktiken.

Census (AI-Readiness-Studie, 6.675 Audits): Agent-Ready Ø 25/100, JSON-LD 41,9 %, llms.txt 15,6 %. Klare Headings/Labels helfen RAG und Menschen; sie sind kein Ersatz für Schema oder Direct Answers. Princeton GEO (Aggarwal et al., arXiv:2311.09735): klare Passagen helfen generativer Sichtbarkeit — auf sauberem HTML. Optional mit Redesign: Kontrast und Typografie im Designsystem verankern, statt nachträglich zu „retten“.

Rechtlicher Kontext — ohne Rechtsberatung und ohne Garantie

Antwort zuerst: Barrierefreiheit rückt für viele Betreiber stärker in den Fokus (u. a. BFSG-Kontext für bestimmte Anbieter) — technische Umsetzung ersetzt keine juristische Einordnung und ist keine Rechtsgarantie.

Modern Stack liefert:

• WCAG-orientierte Komponenten und Kontrastregeln
• dokumentierte Kernflow-Tests (Tastatur, Formular, Fokus)
• nachvollziehbaren Kontakt- und Informationsweg

Modern Stack liefert nicht:

• formelle Konformitätserklärung „WCAG 2.2 AA zertifiziert“ als Produktversprechen
• Rechtsberatung zu BFSG/BITV/Anwendungsbereich
• Accessibility-Overlay als Allheilmittel

Ob dein Betrieb eine formale Erklärung, Audits durch Dritte oder Ausschreibungsnachweise braucht, klärst du mit Beratung. Praxisnah fragen öffentliche Auftraggeber und größere KMU zunehmend nach Tastatur- und Kontrast-Nachweisen — deshalb dokumentieren wir Tests, statt Badges zu verkaufen.

Mobile First und ältere Zielgruppen

Antwort zuerst: Gerade Gesundheits- und Beratungszielgruppen nutzen große Schrift und Telefon — deshalb Typo, Zeilenhöhe und CTAs so bauen, dass Zoom und Tastatur nicht zerbrechen.

Physio- und Steuerberater-Zielgruppen brauchen oft größere Schrift und klare Telefonwege. Text in Bildern ohne Kontrast-Overlay fällt durch. Cookie-/Consent-Banner dürfen auf Mobil nicht die Hälfte des Viewports fressen und gleichzeitig den Fokus stehlen — Bedienbarkeit und Conversion teilen sich denselben Engpass.

Medien, PDFs und Downloads

Antwort zuerst: Alt-Texte gelten für informative Bilder; dekorative Medien bleiben still — PDFs sind ein separates Aufgabenpaket.

Linktexte müssen den Zweck nennen („Leistungsübersicht PDF“ statt „hier klicken“). Wenn PDFs barrierearm (Tagged PDF) sein sollen, ist das kein impliziter Bestandteil der Basis-Migration — Scope vorher trennen. Bilder aus der Content-Migration: fehlende Alts gehören in dieselbe Pipeline wie Medien-Rewrites, nicht in den Freitag-Abend vor Go-Live.

Farben und das Modern-Stack-Designsystem

Antwort zuerst: Orange-Akzent (--ms-orange ≈ #ff5500) nur mit ausreichendem Kontrast; Links bleiben als Links erkennbar — nicht nur farbig.

Migration und Redesign verankern Fokus- und Kontrast-Tokens im Designsystem, statt Einzelpages zu „fixen“. Basis-Migration ab 500 € für bis zu 10 Seiten; Redesign ab 1.000 €, wenn Typo/Kontrast/Layout systematisch neu sitzen müssen — Preise & Pakete.

Wann lohnt der Accessibility-Fokus in der Modernisierung — und wann nicht allein?

Antwort zuerst: Sinnvoll immer als Mitnahmeeffekt des Rebuilds; allein zu wenig, wenn Informationsarchitektur und Conversion komplett veraltet sind.

Mitnehmen bei: WordPress-/Pagebuilder-Cutover, Formular-Neubau, Designsystem-Einführung, öffentlichen oder ausschreibungsnahen Kunden.

Zusätzlich brauchen: veraltete IA → Redesign; schwache Anfragen → Conversion; fehlende Maschinen-Schicht → GEO/Schema — Barrierefreiheit ersetzt keines davon.

Consent, Banner und Dialoge — der vergessene Accessibility-Engpass

Antwort zuerst: Cookie-/Consent-Banner und Modals sind häufig der erste Fokus-Trap — besonders auf Mobil, wo sie halb den Viewport fressen.

Nach Modernisierung gelten dieselben Regeln wie für Formulare: Banner per Tastatur erreichbar, Fokus sichtbar, Escape bzw. Ablehnen/Einstellungen ohne Maus, keine unsichtbare Overlay-Schicht über dem gesamten Dokument ohne Fokus-Management. Drei CTAs (Akzeptieren / Ablehnen / Einstellungen) müssen ohne Scroll-Rätsel erreichbar sein; Einstellungen dürfen nach unten scrollbar sein, ohne den Rest der Seite unbedienbar zu machen.

Overlays von Drittanbietern, die „Accessibility“ versprechen und gleichzeitig den DOM umschreiben, sind kein Ersatz für semantische Komponenten. Wenn Consent und Hauptinhalt konkurrieren, verlierst du sowohl Barrierefreiheit als auch Conversion — derselbe Engpass wie bei Local-Pack-Landings auf dem Smartphone.

Komponenten-Standards im Stack (was wir festnageln)

Antwort zuerst: Accessibility überlebt nur, wenn sie in Design-Tokens und React-Komponenten steckt — nicht in einmaligen Lighthouse-Screenshots.

Im Rebuild verankern wir typischerweise:

• Button-/Link-Primitives mit Fokus-Styles und Mindestgrößen
• Form-Field-Primitive (Label, Hint, Error, aria-describedby)
• Heading-Komponenten, die Heading-Level nicht „aus Designgründen“ überspringen
• Dialog/Sheet mit Fokus-Trap, Return-Focus und Esc
• Skip-Link zur #main-Landmark
• Kontrast-Tokens für Text, Orange-Akzent und Surfaces

Pagebuilder-HTML importieren wir nicht 1:1. Content-Migration übernimmt Inhalte und Hierarchie; Markup entsteht neu. So bleibt Barrierefreiheit wartbar unter Wartung & Updates, statt nach jedem Marketing-Slider zu kollabieren.

Was wir bewusst nicht versprechen

Antwort zuerst: Kein Overlay-Produkt, keine AA-Plakette als Marketing-Claim, keine Garantie gegen jede künftige Content-Regression durch Redaktion.

Redaktion kann nach Go-Live wieder unbeschriftete Icons oder Kontrast-Text-auf-Bild einfügen — deshalb bleiben Verantwortlichkeiten sichtbar (wer schreibt Alts, wer prüft PDFs). Automatisierte CI-Checks (wo vorhanden) fangen Regressionen teilweise; manuelle Kernflow-Tests bleiben für Releases mit Formular-/Consent-Änderungen Pflicht.

Sonderfälle außerhalb Basis-Migration: komplexe Apps mit Live-Regions, umfangreiche Datentabellen, barrierearme PDF-Bibliotheken, mehrsprachige Screenreader-Feintuning. Die gehören in den Scope-Workshop — nicht stillschweigend in „Modernisierung inkl. alles“.

Beispiel: Anfrageformular nach Pagebuilder-Ablösung

Antwort zuerst: Das Formular ist der härteste WCAG- und Conversion-Schnitt — Labels, Fehler, Fokus und Tastatur entscheiden, ob die Modernisierung „fertig“ ist.

Vorher (typisch Elementor/Divi): Placeholder als Pseudo-Label, Fehler nur rot ohne Text, Submit als <div>, Pflichtfelder ohne required/aria-required, Erfolgsseite als Popup ohne Fokuswechsel. Nachher im Stack: jedes Feld mit sichtbarem Label, Fehlertext am Feld (aria-invalid + Beschreibung), echter Submit-Button, Erfolgsstatus im Dokumentfluss, Honeypot/Turnstile ohne Fokus-Diebstahl, WhatsApp als paralleler Kanal mit erkennbarem Linktext.

Abnahmekriterium (praxisnah, keine Rechtsgarantie): Eine Person kann den Weg Start → Leistung → Anfrage nur mit Tastatur abschließen, inklusive absichtlichem Fehler und Korrektur. Scheitert dieser Flow, ist die Modernisierung für Barrierefreiheit und Conversion nicht abgenommen — unabhängig vom Lighthouse-Score.

Reihenfolge im Projekt: wann Accessibility greift

Antwort zuerst: Accessibility ist kein End-Sprint nach dem Design-Freeze — sie sitzt in Audit, Komponentenbau, Content-Migration und Staging-Abnahme.

1. Audit — Heading-Chaos, Dialoge, Formulare, Kontrast-Risiken, PDF-Last inventarisieren
2. Designsystem — Fokus-, Kontrast- und Typo-Tokens vor Seitenbau
3. Rebuild — Komponenten statt Pagebuilder-DOM; Inhalte mappen
4. Staging — Tastatur-/Zoom-/Screenreader-Stichprobe auf Kernflows
5. Cutover — keine last-minute Overlay-Plugins „zum Absichern“
6. Wartung — Regression-Regel für Formular-/Consent-Releases

So bleibt Barrierefreiheit Teil der WordPress-Migration und des Redesigns — nicht ein separates „A11y-Workpackage“, das am Freitag unter den Tisch fällt. Preise bleiben transparent: Basis ab 500 €, Redesign ab 1.000 €, Sonderumfänge (Tagged PDF, komplexe Widgets) vorher getrennt.

Kontrast, Orange-Akzent und Typografie — Praxisregeln

Antwort zuerst: Markenfarbe darf auffallen, aber Text und Controls müssen WCAG-taugliche Kontraste halten — sonst scheitert Zoom und Sehschwäche zuerst am Hero.

Praktisch heißt das: Fließtext nie in Hellgrau auf Weiß „fürs Design“; Orange (--ms-orange) vor allem für CTAs und Akzente, nicht als einzige Informationsträger-Farbe; Hover-/Focus-Zustände dunkler oder mit Ring, nicht nur Transparenz. Schriftgrößen und Zeilenhöhe so wählen, dass 200 % Zoom die Kernspalte lesbar hält. Im Redesign verankern wir das in Tokens — in der reinen Content-Migration korrigieren wir zumindest die schlimmsten Kontrast- und Fokus-Brüche auf Kontakt- und Leistungsseiten.

Das ist Absicht, kein Legal-Claim: bessere Lesbarkeit und Bedienbarkeit für KMU-Zielgruppen (Physio, Handwerk, Kanzlei), dokumentiert über Staging-Checks — ohne Zertifikatsversprechen. Wenn Kontrast und Fokus erst nach dem Go-Live „irgendwie“ nachgezogen werden, zahlst du doppelt: einmal Design-Schuld, einmal Regression an Formularen und Consent.

Checkliste vor dem Kick-off

Liste der Kernflows (Kontakt, Leistung, Formular) → bekannte Scanner-Findings (nur als Start, nicht als Ziel) → Pagebuilder-Dialoge/Slider/Consent inventarisieren → Alt-Text-Verantwortung klären → PDF-Scope ja/nein → Consent-Verhalten mobil (Fokus, CTAs, Viewport) → Zoom-/Tastatur-Abnahme im Staging → Komponenten-Standards vs. Einmal-Fixes → dokumentieren, was getestet wurde (ohne Zertifikatsversprechen) → Wartungsregel: keine outline: none ohne Ersatz.

Kurz: Barrierefreiheit bei Modernisierung ist Komponenten-Disziplin — Tastatur, Kontrast, Formulare, Fokus — für Menschen gemacht, maschinenfreundlich als Nebeneffekt, ohne Rechtsgarantie. Einstieg: Webseite-Modernisierung. Anfrage stellen