Barrierefreies Marketing: Warum Web Accessibility deine Conversion-Rate steigert

Barrierefreie Marketing-Assets erreichen mehr Menschen, erzeugen saubereren semantischen Code und kommen auch Nutzern zugute, die keine Beeinträchtigung haben. Das Barrierefreiheitsstärkungsgesetz verpflichtet private Unternehmen in Deutschland seit Juni 2025 zur Einhaltung von WCAG 2.1 Level AA. Wer diese Kriterien konsequent umsetzt, verbessert gleichzeitig technische Qualität, Lesbarkeit und mittelbar die Conversion-Rate seiner Kampagnen.

Das Wichtigste in Kürze

• Alt-Texte bei Bildern, ein Farbkontrast von mindestens 4,5:1 und beschreibende Link-Ankertexte sind die drei wirkungsstärksten Hebel im E-Mail-Marketing
• Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025 für private Unternehmen mit B2C-Digitalangeboten; Kleinstunternehmen mit weniger als 10 Mitarbeitenden und unter 2 Millionen Euro Jahresumsatz sind für Dienstleistungen ausgenommen, nicht aber für Produkte
• WCAG 2.1 Level AA ist der gesetzlich verankerte Mindeststandard; er umfasst 50 testbare Erfolgskriterien in den Kategorien Wahrnehmbar, Bedienbar, Verständlich und Robust
• Accessibility-Optimierungen verbessern SEO, weil Suchmaschinen-Crawler und Screenreader denselben semantischen Code verarbeiten
• E-Mail-Templates und Landing Pages lassen sich mit einem strukturierten Vorgehen Schritt für Schritt auf WCAG-konformen Stand bringen

Was Web Accessibility konkret mit deiner Conversion-Rate zu tun hat

Der Zusammenhang zwischen Barrierefreiheit und Conversion-Rate läuft nicht über eine Einzelmaßnahme, die plötzlich mehr Klicks erzeugt, sondern über mehrere Mechanismen, die zusammenwirken. Wer das versteht, kann gezielter priorisieren statt blind alle Kriterien abzuhaken.

Barrierefreiheit verbessert Lesbarkeit für alle Nutzer

Ein Farbkontrast von 4,5:1 macht Text nicht nur für Menschen mit Sehschwäche lesbar. Er ist bei schlechter Lichtsituation, reflektierenden Bildschirmen oder kleinen Displays für jeden Nutzer besser. Dasselbe gilt für Schriftgrößen: Wer für ein 16px-Minimum auslegt, sorgt dafür, dass der Fließtext auf dem günstigen Android-Einsteigermodell genauso gut ablesbar ist wie auf dem Retina-Display. Accessibility-Maßnahmen, die für betroffene Nutzer notwendig sind, verbessern für alle die Lesbarkeit – ohne zusätzlichen Aufwand.

Ähnlich verhält es sich mit klaren CTA-Texten. Ein Button-Label wie „Jetzt E-Book herunterladen" funktioniert für Screenreader-Nutzer besser als „Hier klicken" – er ist aber auch für alle anderen Nutzer eindeutiger. Eindeutige Ankertexte reduzieren kognitive Last und erhöhen die Klickrate, weil der Nutzer sofort weiß, was ihn erwartet. Das ist kein Accessibility-Trick, sondern gutes Conversion-Design, das nebenbei WCAG-Anforderungen erfüllt.

Semantischer Code hilft Suchmaschinen und Screenreadern gleichermaßen

Suchmaschinen-Crawler und Screenreader verarbeiten denselben semantischen Code. Wer eine korrekte Überschriften-Hierarchie (H1 bis H3) pflegt, Formular-Labels korrekt setzt und Bilder mit aussagekräftigen Alt-Texten versieht, gibt damit gleichzeitig Suchmaschinen bessere Signale. Seiten, die technisch sauber strukturiert sind, werden von Google verlässlicher indexiert und eingeordnet. Das ist kein Nebeneffekt, sondern ein struktureller Vorteil: Eine WCAG-konforme Seite liefert Crawlern genau die Signale, die sie zur Einordnung von Inhalten brauchen.

Eine lückenhafte Formular-Semantik kostet in zwei Richtungen gleichzeitig. Nutzer ohne Hilfstechnologie bemerken fehlendes Label-Text oft nicht bewusst, aber die höhere Fehlerrate beim Ausfüllen und die längere Bearbeitungszeit wirken sich auf den Conversion-Funnel aus. Schlecht strukturierte Formulare erzeugen höhere Abbruchraten, die man oft fälschlicherweise dem Inhalt zuschreibt statt der technischen Gestaltung.

BFSG und WCAG 2.1: Was seit Juni 2025 für private Unternehmen gilt

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die europäische Accessibility-Richtlinie (Richtlinie 2019/882, European Accessibility Act) in deutsches Recht um. Es gilt seit dem 28. Juni 2025. Bis zu diesem Datum hatten Unternehmen Zeit, ihre digitalen Produkte und Dienstleistungen anzupassen. Wer das versäumt hat, sitzt seitdem in einer rechtlichen Lücke, die Wettbewerber, Verbraucherschutzverbände und Marktüberwachungsbehörden aktiv nutzen können.

Wer unter das BFSG fällt

Das Gesetz richtet sich an Unternehmen, die bestimmte Produkte und Dienstleistungen für Verbraucher (B2C) anbieten. Für E-Commerce-Anbieter, die Produkte oder Dienstleistungen online an Endkunden verkaufen, gilt das BFSG explizit. Online-Shops, Buchungsplattformen und digitale Kaufprozesse sind damit eindeutig betroffen.

Die einzige Ausnahme gilt für Kleinstunternehmen, die ausschließlich Dienstleistungen erbringen: Wer weniger als 10 Mitarbeitende hat und einen Jahresumsatz sowie eine Jahresbilanzsumme von unter 2 Millionen Euro aufweist, ist von den Anforderungen an Dienstleistungen ausgenommen. Für Produkte gilt diese Ausnahme nicht. Wer als kleines Unternehmen ein digitales Produkt vertreibt, fällt unabhängig von Größe und Umsatz unter das Gesetz.

Bei Verstößen drohen Bußgelder bis zu 100.000 Euro sowie Abmahnungen durch Wettbewerber und Verbraucherschutzverbände. Die Marktüberwachungsbehörden können Anpassungen anordnen und Produkte vom Markt nehmen lassen. Die Konsequenzen sind damit deutlich konkreter als von vielen Unternehmen noch erwartet.

Welcher technische Standard konkret verlangt wird

Das BFSG verweist auf die europäische Norm EN 301 549, die ihrerseits auf WCAG 2.1 Level AA aufbaut. WCAG steht für Web Content Accessibility Guidelines, herausgegeben vom W3C (World Wide Web Consortium). Level AA ist das mittlere von drei Konformitätsniveaus (A, AA, AAA). Es umfasst 50 testbare Erfolgskriterien, die in vier Prinzipien gruppiert sind:

• Wahrnehmbar: Inhalte müssen in einer Form darstellbar sein, die Menschen wahrnehmen können, also mit Textalternativen, Untertiteln und ausreichendem Farbkontrast
• Bedienbar: Alle Funktionen müssen per Tastatur erreichbar sein; Inhalte dürfen keine Krampfanfälle auslösen können; Nutzer brauchen ausreichend Zeit für Interaktionen
• Verständlich: Text und Benutzeroberfläche müssen verständlich sein; Fehler müssen klar identifiziert werden; die Sprache der Seite muss deklariert sein
• Robust: Inhalte müssen von verschiedenen Nutzeragenten, einschließlich Hilfstechnologien wie Screenreadern, zuverlässig interpretiert werden können

WCAG 2.2, die aktuelle Weiterentwicklung des Standards, fügt neun weitere Kriterien hinzu, darunter konkrete Anforderungen an die Fokus-Sichtbarkeit und an die Mindestgröße von Touch-Targets. Das BFSG verweist formal auf WCAG 2.1, aber WCAG 2.2 ist abwärtskompatibel: Wer alle 2.2-Kriterien erfüllt, erfüllt automatisch auch alle 2.1-Kriterien. Es ist deshalb sinnvoll, direkt auf WCAG 2.2 hin zu optimieren, anstatt später noch einmal nachzuarbeiten.

Zusätzlich zu den technischen Anforderungen verlangt das BFSG eine Erklärung zur digitalen Barrierefreiheit auf der Website. Dieses Dokument muss angeben, welche Standards eingehalten werden, welche Teile noch nicht konform sind und welchen Kontaktweg Nutzer nutzen können, um Barrieren zu melden. Das Fehlen dieser Erklärung ist selbst ein Verstoß, unabhängig davon, wie gut die Website technisch umgesetzt ist.

Die häufigsten Accessibility-Fehler in E-Mail-Kampagnen

Automatisierte Tests mit Tools wie axe oder Lighthouse erfassen verlässlich strukturelle Probleme, aber die häufigsten Fehler in E-Mail-Templates entstehen an anderen Stellen. Sie sind nicht immer im Code sichtbar, sondern stecken in redaktionellen Gewohnheiten, die sich über Jahre eingeschliffen haben.

Fehlende oder inhaltlich leere Alt-Texte

Alt-Texte werden oft vergessen oder mit inhaltsleerem Platzhaltertext gefüllt. Ein Alt-Text wie „Bild" oder „banner.jpg" erfüllt die Anforderung formal, liefert aber keinen Mehrwert. WCAG-Kriterium 1.1.1 verlangt eine Textalternative, die den Inhalt oder die Funktion des Bildes vermittelt. Für ein Angebots-Banner mit dem Text „30 % Rabatt auf alle Jahrespläne" wäre der korrekte Alt-Text genau dieser Satz, denn das ist, was ein sehender Nutzer aus dem Bild entnimmt.

Dekorative Bilder, die keine Information tragen, bekommen hingegen einen leeren Alt-Text (alt=""). Das ist keine Nachlässigkeit, sondern korrekte Praxis: Screenreader überspringen das Bild dann, statt dem Nutzer einen bedeutungslosen Dateinamen oder ein leeres „Bild" vorzulesen. Der Unterschied zwischen dekorativ und informativ ist die entscheidende Frage, die du für jedes Bild einmalig beantworten musst.

Farbkontraste unter dem WCAG-Schwellenwert

WCAG-Kriterium 1.4.3 verlangt ein Kontrastverhältnis von mindestens 4,5:1 zwischen Textfarbe und Hintergrundfarbe bei normaler Schriftgröße (unter 18pt bzw. 14pt fett). Für große Schrift gilt ein Minimum von 3:1. Diese Werte lassen sich mit dem kostenlosen WebAIM Contrast Checker innerhalb von Sekunden prüfen: Hexadezimalcodes für Vorder- und Hintergrundfarbe eingeben, Ergebnis ablesen.

Das größte Problem in der Praxis ist nicht der Haupttext, sondern der Fließtext in sekundären Modulen. Grauer Text auf hellem Grau-Hintergrund, hellblauer Text auf weißem Button-Hintergrund oder Fußnotentext in kleiner Schrift mit zu wenig Kontrast – diese Kombinationen tauchen in E-Mail-Templates häufig auf, weil Designer auf einem kalibrierten Profi-Monitor arbeiten, wo der Unterschied kleiner wirkt als auf einem durchschnittlichen Laptop-Display bei niedrigerer Helligkeit.

Links ohne aussagekräftigen Ankertext

WCAG-Kriterium 2.4.4 verlangt, dass Linktext den Zweck des Links aus dem Kontext heraus erklärt. „Hier klicken", „Mehr erfahren" oder „Weiter" sind für Screenreader-Nutzer nichtssagend. Wer mit der Tab-Taste durch eine E-Mail oder Landing Page navigiert und Links nacheinander vorlesen lässt, bekommt im schlimmsten Fall eine Liste wie „Mehr erfahren, Mehr erfahren, Mehr erfahren" – ohne jeden Kontext, welcher Link wohin führt.

Beschreibende Ankertexte lösen dieses Problem und sind gleichzeitig besser für SEO, weil sie das verlinkte Ziel präzise beschreiben. Statt „Jetzt anmelden" also „Jetzt zum Webinar über E-Mail-Segmentierung anmelden". Der Mehraufwand pro Button beträgt maximal 30 Sekunden, der Mehrwert ist dauerhaft.

Fehlende Überschriften-Hierarchie in Templates

E-Mail-Templates werden oft nach visuellem Ergebnis gebaut: Wer einen fett gestalteten großen Text sieht, liest ihn visuell als Überschrift – auch wenn im HTML kein Heading-Tag, sondern ein gestyltes Absatz-Element steckt. Screenreader erkennen Überschriften ausschließlich über die Heading-Tags H1 bis H6. Eine E-Mail ohne Überschriften-Struktur ist für Screenreader-Nutzer eine einzige ununterbrochene Textmasse, durch die sie nur linear navigieren können, ohne springen zu können. Die Lösung ist konsequenter Einsatz echter Heading-Tags überall dort, wo ein neuer Abschnitt beginnt.

So bringst du dein ActiveCampaign-Template auf WCAG 2.1 Level AA

ActiveCampaign bietet im E-Mail-Designer die Möglichkeit, auf HTML-Ebene zu arbeiten. Der folgende Prozess ist auf Templates ausgelegt, die mit dem Drag-and-Drop-Builder erstellt wurden. Er lässt sich für jedes Template einmalig durchführen und dann als konforme Vorlage speichern, die alle Beteiligten künftig verwenden.

1. Template im Editor öffnen: Kampagnen → Erstellen → E-Mail gestalten → gewünschtes Template auswählen; im Editor oben rechts auf die HTML-Ansicht wechseln, um den Quelltext zu sehen und zu bearbeiten
2. Alt-Texte prüfen und ergänzen: Suche im Quelltext nach img-Tags; jedes Bild mit einem fehlenden Alt-Attribut auffüllen; Angebots-Banner, Produktbilder und Fotos brauchen inhaltsbeschreibenden Text; rein dekorative Bilder erhalten alt="" (leer, nicht weggelassen)
3. Farbkontraste messen: Öffne den WebAIM Contrast Checker; gib Schriftfarbe und Hintergrundfarbe des Templates ein; korrigiere alle Kombinationen, die unter 4,5:1 liegen für Haupttext und unter 3:1 für große Schrift; notiere die geprüften Farbcodes für alle künftigen Templates
4. Heading-Struktur setzen: Der Betreff der E-Mail entspricht konzeptionell der H1; im Body starten Hauptabschnitte mit H2, Unterabschnitte mit H3; ersetze gestylte Absatz-Elemente, die optisch als Überschriften wirken, durch echte Heading-Tags
5. CTAs überarbeiten: Ersetze alle Buttons und Textlinks mit generischen Labels durch beschreibende Texte; der Ankertext soll das konkrete Ziel oder die konkrete Aktion benennen, nicht nur „Weiter" oder „Klicken"
6. Sprach-Attribut setzen: Im html-Tag des Templates das Attribut lang="de" eintragen; viele Standard-Templates fehlt diese Angabe; Screenreader wählen die Aussprache-Engine anhand dieses Attributs – ohne es liest ein deutschsprachiger Text in falscher Phonetik vor
7. Schriftgröße prüfen: Kein Fließtext unter 14px; Haupttext idealerweise 16px; Disclaimer und Fußnoten dürfen kleiner sein, sollten dann aber ein höheres Kontrastverhältnis aufweisen, da kleinere Schrift schlechter lesbar ist
8. Template als konforme Vorlage speichern: Im Designer unter Vorlagen das bearbeitete Template mit einem Hinweis auf WCAG 2.1 AA im Namen speichern, damit es für alle Beteiligten als geprüfte Basis erkennbar ist und beim nächsten Kampagnen-Start direkt genutzt werden kann

Mit diesem Prozess bringst du ein bestehendes Template in zwei bis drei Stunden auf Level AA. Der größte Zeitaufwand entsteht beim erstmaligen Messen aller Farbkontraste. Danach hast du eine geprüfte Farbpalette, die du als Standard verwendest und nicht mehr jedes Mal von Grund auf prüfen musst.

Landing Pages und Formulare barrierefrei gestalten

Landing Pages haben gegenüber E-Mail-Templates den Vorteil, dass Accessibility-Fehler mit Browser-basierten Tools direkt getestet werden können, ohne HTML exportieren zu müssen. Die häufigsten Schwachstellen stecken dennoch in denselben Bereichen: Formular-Gestaltung, Fehlerkommunikation und Tastaturnavigation.

Formular-Labels richtig einsetzen

Das häufigste Problem bei Lead-Formularen ist das Fehlen echter Label-Elemente. Viele Templates arbeiten ausschließlich mit Placeholder-Text, der im Feld erscheint und verschwindet, sobald der Nutzer zu tippen beginnt. Für Menschen, die langsam tippen oder ein Feld mehrfach durchgehen, ist der Feldname damit verloren, sobald sie den Cursor setzen.

WCAG-Kriterien 1.3.1 und 3.3.2 verlangen sichtbare Labels für alle Eingabefelder. Das Label muss mit dem Feld über das for-Attribut verknüpft sein, damit Screenreader beim Fokussieren des Feldes den Label-Text vorliest. ActiveCampaign-Formulare, die über den nativen Formular-Builder erstellt werden, bringen Labels mit, wenn du die entsprechende Option im Builder aktivierst. Formulare, die über externe Landing-Page-Builder eingebunden werden, musst du manuell prüfen. Wie barrierefreie Formulare die Conversion-Rate konkret beeinflussen, zeigt ein eigener Beitrag mit Umsetzungsbeispielen.

Fehlermeldungen klar formulieren und zugänglich machen

Wenn ein Formular-Fehler auftritt, muss klar kommuniziert werden, welches Feld betroffen ist und was korrekt einzugeben wäre. „Fehler" oder ein rotes Ausrufezeichen neben einem Feld reicht nicht. WCAG-Kriterium 3.3.1 verlangt, dass Fehler in Textform identifiziert werden; Kriterium 3.3.3 fordert einen Verbesserungsvorschlag, soweit möglich.

In der Praxis bedeutet das: Statt „Ungültige E-Mail-Adresse" besser „Bitte gib eine vollständige E-Mail-Adresse ein, zum Beispiel name@beispiel.de". Die Fehlermeldung muss außerdem programmatisch mit dem Feld verknüpft sein, damit Screenreader sie vorliest. Das geschieht über das aria-describedby-Attribut im Eingabefeld, das auf das Element mit der Fehlermeldung verweist.

Tastaturnavigation und Fokus-Sichtbarkeit

Alle interaktiven Elemente einer Landing Page müssen per Tastatur erreichbar und bedienbar sein. Dazu gehören Buttons, Links, Akkordeon-Elemente, Tabs und modale Dialoge. Der Fokus-Indikator, also das visuelle Signal, welches Element gerade ausgewählt ist, darf durch CSS nicht entfernt werden. WCAG-Kriterium 2.4.7 verlangt, dass der Tastaturfokus immer sichtbar ist; WCAG 2.4.11 in Version 2.2 geht weiter und verlangt, dass der Fokus nicht vollständig verdeckt wird, wenn andere Elemente darüber liegen.

Der Tab-Test ist die schnellste Prüfmethode: Öffne die Landing Page, entferne die Hand von der Maus und navigiere ausschließlich mit der Tab-Taste durch alle interaktiven Elemente. Wenn du irgendwo nicht weißt, wo du dich gerade befindest, oder wenn ein Element nicht per Tastatur bedienbar ist, liegt ein WCAG-Verstoß vor, den du direkt im Quelltext beheben kannst.

Typische Fehler bei der Umsetzung – und wie du sie erkennst

Die häufigste Fehlerquelle bei Accessibility-Projekten ist falsches Vertrauen in automatisierte Tests. Tools wie axe oder Lighthouse helfen dabei, strukturelle Fehler zu finden, decken nach Angaben des W3C aber nur etwa 30 bis 40 Prozent aller WCAG-Fehler automatisch auf. Der Rest erfordert manuelle Prüfung oder Nutzertests.

• Nur automatisierte Tests durchführen und als abgeschlossen markieren: Automatisierte Tests erkennen fehlende Alt-Texte, schlechte Kontraste und fehlende Labels verlässlich. Aber sie prüfen nicht, ob ein Alt-Text inhaltlich sinnvoll ist, ob die Überschriften-Hierarchie logisch aufgebaut ist oder ob Fehlermeldungen dem Nutzer wirklich helfen. Ergänze jeden automatisierten Test mit einem Tab-Durchlauf und einem kurzen Screenreader-Test – VoiceOver auf Mac und iOS, NVDA unter Windows kostenlos verfügbar.
• Accessibility als einmaligen Sprint behandeln: Neue Inhalte, Template-Updates und A/B-Tests können Accessibility-Fehler wieder einführen. Wer Barrierefreiheit als Einmalprojekt behandelt, sitzt nach dem nächsten Redesign wieder bei null. Nachhaltiger ist ein kurzer Accessibility-Check als fester Bestandteil des Freigabeprozesses für neue Templates und Landing Pages.
• Die Accessibility-Erklärung vergessen: Das BFSG verlangt eine Erklärung zur digitalen Barrierefreiheit auf der Website. Das Fehlen dieses Dokuments ist selbst ein Verstoß, unabhängig davon, wie gut die Website technisch umgesetzt ist. Die Erklärung muss angeben, welche Standards eingehalten werden, welche Teile noch nicht konform sind und wie Nutzer Barrieren melden können.
• Barrierefreiheit auf technische Kriterien reduzieren: WCAG ist ein technisches Minimum, keine vollständige UX-Anleitung. Eine Seite kann alle 50 AA-Kriterien erfüllen und trotzdem für Screenreader-Nutzer schwer bedienbar sein, wenn die Navigation unlogisch aufgebaut ist oder Inhalte unnötig komplex formuliert sind. Das Ziel ist eine benutzbare Website, nicht nur eine, die automatisierte Tests besteht.

Häufige Fragen

Gilt das BFSG auch für E-Mail-Newsletter?

Das BFSG gilt primär für digitale Produkte und B2C-Dienstleistungen. Klassische Marketing-Newsletter fallen nicht direkt unter die Pflichten des BFSG, weil sie keine interaktive Dienst-Funktion erfüllen. Die Landing Pages, auf die Newsletter verlinken, und der Online-Shop, der dahintersteht, sind hingegen eindeutig betroffen. Barrierefreie E-Mails sind trotzdem empfehlenswert: Sie erreichen mehr Empfänger, erzielen bessere Interaktionsraten und bereiten auf den Fall vor, dass Regulierung sich weiter ausdehnt.

Was bedeutet WCAG 2.1 Level AA konkret für meine Website?

Level AA ist das mittlere von drei WCAG-Konformitätsniveaus. Es umfasst alle 30 Level-A-Kriterien plus 20 zusätzliche Level-AA-Kriterien. Konkret verlangt Level AA unter anderem: Farbkontrast von mindestens 4,5:1 für normalen Text, skalierbare Seiten bis 200 Prozent ohne Informationsverlust, Untertitel für vorab produzierte audiovisuelle Inhalte, Tastaturzugang für alle Funktionen und sichtbare Fokus-Indikatoren. Die vollständige Auflistung bietet die W3C-WCAG-2.1-Spezifikation unter w3.org/TR/WCAG21/.

Wie prüfe ich, ob meine Website die BFSG-Anforderungen erfüllt?

Der Einstieg gelingt mit der kostenlosen axe DevTools Browser-Extension für Chrome und Firefox: Seite öffnen, Extension starten, Ergebnisse lesen. Lighthouse, in Chrome DevTools unter dem Tab Lighthouse verfügbar, liefert einen Accessibility-Score und gegliederte Fundstellen. Für eine gründliche manuelle Prüfung navigiere ausschließlich per Tab-Taste und nutze den systemeigenen Screenreader. Für eine BFSG-konforme Prüfdokumentation empfiehlt sich die WCAG-EM-Report-Methode des W3C, die einen strukturierten Testprozess vorgibt.

Verbessert Accessibility automatisch mein SEO-Ranking?

Nicht automatisch, aber strukturell. Suchmaschinen-Crawler verarbeiten Seiten ähnlich wie Screenreader: Sie lesen semantischen Code, kein visuelles Layout. Korrekte Heading-Hierarchien, beschreibende Alt-Texte, verknüpfte Formular-Labels und klare Linktext-Beschreibungen sind Signale, die Crawler direkt auswerten. Der Effekt ist kein Accessibility-Bonus im Algorithmus, sondern eine Konsequenz aus besserer technischer Qualität. Seiten mit sauberem semantischen Code bieten Suchmaschinen bessere Voraussetzungen für eine genaue Einordnung.

Was ist der Unterschied zwischen BITV 2.0 und BFSG?

Die BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung) gilt ausschließlich für öffentliche Stellen und öffentlich-rechtliche Institutionen. Sie ist seit 2019 in Kraft und basiert ebenfalls auf WCAG 2.1. Das BFSG erweitert die Pflicht auf private Unternehmen und gilt für digitale Produkte und B2C-Dienstleistungen. Beide Standards verwenden WCAG 2.1 Level AA als technische Grundlage, richten sich aber an unterschiedliche Zielgruppen: BITV 2.0 für den öffentlichen Sektor, BFSG für die private Wirtschaft.

Accessibility ist kein separates Optimierungsprojekt, das neben dem laufenden Betrieb läuft, sondern ein Qualitätsmerkmal, das sich mit einem strukturierten Vorgehen in die reguläre Arbeit integrieren lässt. WCAG 2.1 Level AA liefert dafür 50 konkrete, testbare Kriterien. Wer sie einmalig für seine Templates und Landing Pages abarbeitet, hat damit nicht nur eine sicherere rechtliche Basis nach BFSG, sondern auch sauberere technische Assets, die für alle Nutzer besser funktionieren.