Webflow und BFSG: Barrierefreiheit im visuellen Website-Builder

Webflow: Designfreiheit vs. Barrierefreiheit

Webflow ist bei Designern und Agenturen beliebt, weil es maximale gestalterische Freiheit bietet – ohne Code schreiben zu müssen. Aber genau diese Freiheit ist auch ein Risiko: Wenn der Designer keine Barrierefreiheit berücksichtigt, ist die Webseite nicht barrierefrei. Anders als bei Templates gibt es keine Leitplanken.

Du kannst in Webflow eine perfekt barrierefreie Seite bauen – oder eine völlig unzugängliche. Es liegt an dir.

Das Barrierefreiheitsstärkungsgesetz (BFSG), das die EU-Richtlinie über Barrierefreiheitsanforderungen (European Accessibility Act) in deutsches Recht umsetzt, gilt seit Juni 2025. Es verlangt gemäß § 3 Abs. 1 BFSG in Verbindung mit § 4 BFSG, dass digitale Produkte und Dienstleistungen – darunter Webshops, SaaS-Plattformen und B2C-Webseiten – den Anforderungen der EN 301 549 und damit den WCAG 2.1 Level AA entsprechen. Webflow-Seiten sind davon nicht ausgenommen, nur weil sie über einen visuellen Builder entstehen.

Der Unterschied zu anderen Baukästen wie Squarespace oder Wix und Jimdo: Webflow gibt dir die volle Kontrolle über das generierte HTML und CSS. Das bedeutet: Jede Barriere, die in deiner Seite steckt, hast du selbst gebaut – bewusst oder unbewusst. Gleichzeitig hast du die Möglichkeit, ARIA-Attribute gezielt einzusetzen und sauberes semantisches Markup zu erzeugen – etwas, das bei anderen Baukästen oft nur eingeschränkt möglich ist. Weitere Informationen finden Sie im BFSG-Glossar.

Webflows Barrierefreiheits-Features im Designer

Webflow hat in den letzten Jahren massiv nachgerüstet: Ein eingebauter Accessibility Audit prüft grundlegende Probleme direkt im Editor. Alt-Texte können für jedes Bild gesetzt werden. ARIA-Attribute sind über die Element-Einstellungen verfügbar.

Die Tab-Reihenfolge kann manuell gesteuert werden. Und Custom Attributes ermöglichen volle Kontrolle über das HTML-Output. Das macht Webflow technisch zu einem der barrierefreiheits-freundlichsten Baukästen.

Konkret bietet der Webflow Designer folgende a11y-Features:

• Semantische Elemente: Im Navigator lassen sich HTML5-Tags wie <section>, <nav>, <article>, <aside>, <header> und <footer> direkt zuweisen – entscheidend für WCAG SC 1.3.1 (Info and Relationships).
• Alt-Texte im Asset-Manager: Jedes Bild erhält ein Alt-Text-Feld. Bei CMS-Collections kannst du ein eigenes Textfeld für Alt-Texte anlegen und im Template dynamisch einbinden.
• Custom Attributes: Über das Element-Panel > Custom Attributes lassen sich beliebige HTML-Attribute setzen – inklusive role, aria-label, aria-expanded, aria-hidden und alle weiteren ARIA-Attribute.
• Focus-Styles: Der ":focus"-State ist für jedes Element über den Interactions-Panel zugänglich. Wichtig: Setze sichtbare Focus-Indikatoren gemäß WCAG SC 2.4.7 (Focus Visible).
• Tab-Index-Steuerung: Du kannst die Tab-Reihenfolge manuell über das Attribut tabindex steuern – allerdings solltest du das sparsam einsetzen und primär auf eine logische DOM-Reihenfolge achten (WCAG SC 2.4.3, Focus Order).
• Heading-Hierarchie: Im Navigator siehst du die Heading-Ebenen (H1–H6) auf einen Blick. Achte darauf, keine Ebenen zu überspringen – also kein H1 direkt gefolgt von H4. Das verletzt WCAG SC 1.3.1 und erschwert die Navigation für Screenreader-Nutzer erheblich.
• Visibility-Einstellungen: Über das Style-Panel kannst du Elemente per display: none oder visibility: hidden ausblenden. Wichtig: Beide Methoden verbergen Inhalte auch vor Screenreadern. Wenn du Inhalte nur visuell verstecken, aber für assistive Technologien verfügbar lassen willst, nutze stattdessen ein „sr-only“-Pattern über eine Custom-CSS-Klasse.

Das Webflow Audit Panel: Was es kann und was nicht

Seit 2023 bietet Webflow ein eingebautes Audit Panel, das dein Projekt auf häufige Barrierefreiheitsfehler prüft. Es erkennt:

• Fehlende Alt-Texte bei Bildern
• Leere Links und Buttons ohne zugänglichen Namen
• Fehlende Landmark-Regionen
• Heading-Hierarchie-Probleme (z. B. Überspringen von H2 zu H4)

Was das Audit Panel nicht prüft: Farbkontraste (WCAG SC 1.4.3), Tastatur-Bedienbarkeit von Custom-Interaktionen (SC 2.1.1), korrekte Formular-Labels (SC 1.3.1), Zoom-Verhalten bis 200 % (SC 1.4.4) oder die Funktionsfähigkeit von ARIA-Attributen. Für eine vollständige BFSG-Prüfung brauchst du deshalb einen externen Scanner wie bf-check.de und manuelle Tests.

Custom Code für ARIA: Wo der Designer nicht reicht

Der visuelle Designer deckt die Grundlagen ab, aber für dynamisches ARIA-Verhalten brauchst du Custom Code. Typische Fälle:

Modale Dialoge: Webflow bietet zwar Popups über Interactions, aber das erzeugte Markup enthält kein role="dialog", kein aria-modal="true" und kein automatisches Fokus-Trapping. Du musst per Custom Code (in den Page Settings oder als Embed-Element) JavaScript ergänzen, das beim Öffnen den Fokus in den Dialog verschiebt, die Tab-Navigation auf den Dialog beschränkt und beim Schließen den Fokus zurück zum Auslöser-Element setzt – verlangt von WCAG SC 2.4.3 (Focus Order).

Dropdown-Menüs und Akkordeons: Nutze aria-expanded="true/false" auf dem Toggle-Button und aktualisiere den Wert per JavaScript bei jeder Interaktion. Webflows eingebaute Dropdowns setzen das nicht automatisch.

Live-Regionen: Wenn Inhalte dynamisch nachgeladen werden (z. B. Suchvorschläge, Warenkorbzahlen), muss der Container mit aria-live="polite" oder aria-live="assertive" ausgezeichnet werden. Sonst bemerken Screenreader die Änderung nicht – ein Verstoß gegen WCAG SC 4.1.3 (Status Messages).

CMS-Collections und Alt-Texte

Webflows CMS ist mächtig, hat aber eine Tücke bei der Barrierefreiheit: Das Bildfeld einer Collection hat standardmäßig kein separates Alt-Text-Feld. Du musst ein zusätzliches Textfeld (z. B. „Bild-Alt-Text“) in der Collection-Struktur anlegen und es im Template als alt-Attribut des <img>-Elements binden.

Ohne diesen Schritt erhalten alle CMS-generierten Bilder entweder keinen Alt-Text oder einen generischen – ein klarer Verstoß gegen WCAG SC 1.1.1 (Non-text Content). Besonders bei Blogs, Portfolio-Seiten und Produktlisten mit vielen CMS-Einträgen summieren sich fehlende Alt-Texte schnell zu Dutzenden Verstößen.

Tipp: Erstelle eine Content-Guideline für dein Team, die vorschreibt, dass kein CMS-Eintrag ohne ausgefülltes Alt-Text-Feld veröffentlicht werden darf. Webflow bietet leider keine Pflichtfeld-Validierung für Custom Fields, deshalb ist Disziplin gefragt.

Interactions und Animations: prefers-reduced-motion

Webflows Interactions 2.0 ermöglichen beeindruckende Scroll-Animationen, Parallax-Effekte und Hover-Transitions. Aber: Bewegungsintensive Animationen können bei Menschen mit vestibulären Störungen Übelkeit, Schwindel oder Migräne auslösen.

WCAG SC 2.3.3 (Animation from Interactions) verlangt, dass nicht-essentielle Animationen deaktiviert werden können. Die Lösung ist die CSS-Media-Query prefers-reduced-motion: reduce. Webflow setzt diese nicht automatisch um – du musst sie per Custom Code einbauen:

Füge in den Project Settings unter Custom Code (Head) folgendes CSS ein:

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Damit werden alle CSS-Animationen und Transitions für Nutzer deaktiviert, die in ihren Betriebssystem-Einstellungen reduzierte Bewegung aktiviert haben. Webflow-Interactions, die über JavaScript gesteuert werden (z. B. Scroll-triggered Animations), musst du zusätzlich per JavaScript abfangen:

const motionQuery = window.matchMedia('(prefers-reduced-motion: reduce)');
if (motionQuery.matches) {
  // Interactions deaktivieren oder auf statische Zustände setzen
}

Typische Fehler in Webflow-Projekten

Designer, die Webflow nutzen, machen häufig folgende Fehler: Animationen und Interaktionen, die per Tastatur nicht steuerbar sind – ein Verstoß gegen WCAG SC 2.1.1 (Keyboard). Div-basierte Layouts statt semantischem HTML (Section, Article, Nav) – problematisch für SC 1.3.1 (Info and Relationships). Bild-Text ohne Alt-Text, weil der visuelle Fokus dominiert.

Scroll-Animationen, die bei reduced-motion-Präferenz nicht deaktiviert werden. Modale Fenster und Popups ohne Fokus-Management. Dazu kommen weitere häufige Probleme:

• Fehlende Skip-Links: Webflow erzeugt keinen automatischen „Zum Inhalt springen“-Link. Ohne ihn müssen Tastatur-Nutzer bei jeder Seite durch die gesamte Navigation tabben (SC 2.4.1, Bypass Blocks).
• Unzureichende Farbkontraste: Der Designer zeigt keine Kontrastverhältnisse an. Helle Grautöne auf weißem Hintergrund fallen im visuellen Editor nicht auf, versagen aber bei SC 1.4.3 (Contrast Minimum, 4,5:1 für Normaltext).
• Formulare ohne Labels: Webflows Form-Block bietet zwar Label-Elemente an, aber Designer entfernen sie häufig zugunsten von Placeholder-Text – der kein Ersatz für ein programmatisch zugeordnetes Label ist (SC 1.3.1).
• Auto-Play-Videos: Hintergrund-Videos, die automatisch abspielen, können SC 1.4.2 (Audio Control) verletzen, wenn sie Ton enthalten, und SC 2.3.1 (Three Flashes), wenn schnelle Schnitte vorkommen.

Webflow E-Commerce und Barrierefreiheit

Webflow E-Commerce bringt eigene Herausforderungen mit: Der Checkout-Prozess wird von Webflow gehostet und lässt sich nur begrenzt anpassen. Das bedeutet, du hast keinen Einfluss auf die Barrierefreiheit des Checkouts selbst.

Was du kontrollieren kannst:

• Produktseiten: Alt-Texte für alle Produktbilder (inklusive Galerie-Bilder), aussagekräftige Button-Beschriftungen („In den Warenkorb“ statt nur ein Icon), korrekte Heading-Hierarchie.
• Warenkorb-Interaktionen: Das Mini-Cart-Overlay muss als Dialog behandelt werden – mit Fokus-Trapping und aria-live-Ankündigung, wenn ein Produkt hinzugefügt wurde (SC 4.1.3).
• Produktfilter: Custom-Filter müssen per Tastatur bedienbar sein. Filterergebnisse sollten über aria-live angekündigt werden.

Wichtig gemäß § 3 BFSG: Als Anbieter bist du für die gesamte Customer Journey verantwortlich – auch für Teile, die ein Drittanbieter (hier Webflow) hostet. Teste den Checkout-Prozess mit Tastatur und Screenreader und dokumentiere etwaige Einschränkungen. Falls der Checkout gravierende Barrieren aufweist, die du nicht beheben kannst, solltest du das in deiner Barrierefreiheitserklärung gemäß § 5 BFSG transparent dokumentieren und alternative Bestellwege anbieten (z. B. telefonische Bestellung).

Zusätzlich gilt: Alt-Texte für Produktbilder sind bei E-Commerce besonders kritisch. Jedes Produktbild in der Galerie braucht einen beschreibenden Alt-Text – nicht nur das Hauptbild. Screenreader-Nutzer müssen verstehen können, was die verschiedenen Ansichten zeigen (z. B. „Rote Ledertasche, Rückseite mit Reißverschlussfach“).

Code-Export vs. Webflow-Hosting: Auswirkung auf Barrierefreiheit

Webflow bietet zwei Wege, eine Seite live zu schalten: Über Webflows eigenes Hosting oder über Code-Export (nur im Workspace-Plan verfügbar).

Webflow-Hosting: Du profitierst von automatischen Updates, CDN und SSL. Allerdings bist du auf die generierten Scripts und Styles angewiesen – Webflows Runtime-JavaScript kann zusätzliche Barrierefreiheitsprobleme verursachen, die du nicht kontrollierst.

Code-Export: Der exportierte HTML/CSS/JS-Code enthält alle ARIA-Attribute und semantischen Strukturen, die du im Designer gesetzt hast. Webflow-spezifische Interactions müssen allerdings manuell durch barrierefreies JavaScript ersetzt werden. Der Vorteil: Du hast volle Kontrolle und kannst Accessibility-Libraries wie focus-trap oder a11y-dialog einbinden.

Für BFSG-kritische Projekte ist der Code-Export oft der sicherere Weg, weil du jede Zeile Code kontrollierst und mit spezialisierten Tools auditieren kannst.

Achtung beim Export: Webflow generiert Klassen wie w-dropdown-toggle, die nach dem Export im Code bleiben. Stelle sicher, dass alle interaktiven Elemente auch ohne Webflows Runtime-JavaScript funktionieren – WCAG SC 2.1.1 (Keyboard) verlangt, dass jede Funktion per Tastatur erreichbar ist, und SC 4.1.2 (Name, Role, Value) fordert, dass interaktive Elemente ihren Zustand programmatisch kommunizieren.

Best Practices für barrierefreies Webflow-Design

Nutze semantische HTML-Elemente (Section statt Div, wo möglich). Setze Alt-Texte konsequent für alle Bilder. Teste jede Interaktion per Tastatur.

Nutze den eingebauten Accessibility Auditor, bevor du publishst. Setze ARIA-Labels für interaktive Elemente. Respektiere prefers-reduced-motion für Animationen.

Hier eine zusammenfassende Checkliste für BFSG-konforme Webflow-Seiten:

1. Vor dem Design: Semantische Seitenstruktur planen (Header, Nav, Main, Footer als Landmarks).
2. Im Designer: Jedes Bild mit Alt-Text versehen. CMS-Collections mit Alt-Text-Feldern einrichten. Focus-Styles für alle interaktiven Elemente definieren.
3. Custom Code: Skip-Link am Seitenanfang einfügen. prefers-reduced-motion respektieren. Fokus-Trapping für Dialoge implementieren. aria-expanded für Dropdowns und Akkordeons setzen.
4. Vor dem Publish: Webflow Audit Panel durchlaufen. Tastatur-Test der gesamten Seite. bf-check.de BFSG-Scan durchführen.
5. Nach dem Launch: Bei jedem Content-Update Alt-Texte und Heading-Struktur prüfen. Regelmäßige Re-Scans einplanen.

Webflow-Formulare barrierefrei gestalten

Webflows Form Block ist ein häufiger Stolperstein. Viele Designer entfernen Label-Elemente aus ästhetischen Gründen und verlassen sich auf Placeholder-Text – ein Verstoß gegen WCAG SC 1.3.1 (Info and Relationships) und SC 3.3.2 (Labels or Instructions).

So machst du Webflow-Formulare BFSG-konform:

• Sichtbare Labels: Behalte das Label-Element bei. Placeholder-Text ist kein Ersatz, da er beim Eintippen verschwindet.
• Fehlermeldungen: Webflows native Fehlermeldung ist englisch und nicht anpassbar. Nutze Custom Code mit aria-live="polite" für deutschsprachige Fehlertexte (SC 3.3.1, Error Identification).
• Pflichtfelder: Markiere mit aria-required="true" und kennzeichne sie visuell – nicht nur mit Farbe (SC 1.4.1).
• Autocomplete: Setze autocomplete für persönliche Datenfelder gemäß WCAG SC 1.3.5 (Identify Input Purpose).

Hinweis: Dieser Artikel bietet allgemeine Informationen zur Barrierefreiheit in Webflow und ersetzt keine Rechtsberatung. Für eine verbindliche Einschätzung deiner BFSG-Pflichten konsultiere eine auf IT-Recht spezialisierte Kanzlei. Die genannten WCAG-Kriterien beziehen sich auf WCAG 2.1 Level AA, die als technische Grundlage des BFSG gilt.

Häufig gestellte Fragen