BFSG für Wix, Jimdo und Website-Baukästen: Was Nutzer wissen müssen

Baukasten-Webseiten und BFSG: Wer ist verantwortlich?

Auch wenn du einen Baukasten nutzt: Du bist für die Barrierefreiheit deiner Webseite verantwortlich, nicht der Baukasten-Anbieter. Wix, Jimdo und Co. stellen die Plattform bereit, aber deine Inhalte, Bilder, Texte und Konfiguration bestimmen die Barrierefreiheit.

Das BFSG unterscheidet nicht zwischen selbst programmiert und per Baukasten erstellt. Nach § 1 BFSG gilt: Wer Dienstleistungen an Verbraucher erbringt, muss die Anforderungen der EN 301 549 erfüllen — unabhängig von der technischen Umsetzung.

In der Praxis bedeutet das eine geteilte Verantwortung:

• Plattform-Anbieter verantworten die Grundstruktur: semantisches HTML, ARIA-Grundgerüst, Tastaturnavigation der UI-Komponenten
• Du als Betreiber verantwortest alles, was du selbst steuerst: Alt-Texte, Überschriften, Kontraste, Formularbeschriftungen, Inhalte

Bei Verstößen haftest du. Der Baukasten-Anbieter ist nicht dein Rechtsschutz. Weitere Informationen finden Sie im BFSG-Glossar.

Wix Editor vs. Wix Studio: Welche Version ist barrierefreier?

Wix bietet zwei grundlegend verschiedene Editoren, die sich stark in ihren Barrierefreiheits-Möglichkeiten unterscheiden:

Wix Editor (klassisch): Der Drag-and-Drop-Editor gibt maximale gestalterische Freiheit — genau das wird zum Problem. Elemente werden absolut positioniert, was die DOM-Reihenfolge zerstört. Screenreader lesen Inhalte dann in falscher Reihenfolge (Verstoß gegen WCAG SC 1.3.2 — Bedeutungsvolle Reihenfolge). Du hast keinen Zugriff auf den generierten HTML-Code.

Wix Studio (ehemals Editor X): Arbeitet mit CSS-Grid und Flexbox, also responsiven Layouts. Die DOM-Reihenfolge bleibt erhalten. Über den Dev Mode kannst du ARIA-Attribute setzen und semantische HTML-Elemente erzwingen. Deutlich bessere Basis für Barrierefreiheit.

Wenn du mit Wix arbeitest und BFSG-Konformität anstrebst: Wix Studio ist die bessere Wahl.

Jimdo Creator vs. Jimdo Dolphin

Jimdo Creator war der ursprüngliche Editor mit Template-Anpassung und begrenztem Code-Zugang. Er wird seit 2020 nicht mehr für Neukunden angeboten, ist aber bei Bestandskunden noch aktiv. Die Barrierefreiheit hängt stark vom gewählten Template ab.

Jimdo Dolphin (jetzt einfach "Jimdo") ist der KI-gestützte Baukasten. Er erstellt Webseiten automatisch auf Basis von Fragen. Die generierten Seiten sind grundlegend strukturiert, aber du hast kaum Kontrolle über:

• Überschriften-Hierarchie (wird automatisch vergeben)
• ARIA-Attribute (nicht editierbar)
• Fokus-Reihenfolge bei Navigation
• Semantische HTML-Elemente

Vorteil: Jimdo erzeugt in der Regel saubere Grundstrukturen. Nachteil: Du kannst Barrierefreiheits-Probleme oft nicht selbst beheben.

Barrierefreiheits-Vergleich der Baukästen

Weitere Details zu einzelnen Plattformen findest du in unseren Spezial-Artikeln: IONOS Homepage-Baukasten und BFSG sowie Squarespace und BFSG-Barrierefreiheit.

Typische Baukasten-Limitierungen bei Barrierefreiheit

Es gibt Barrieren, die du als Baukasten-Nutzer nicht selbst beheben kannst, weil sie in der Plattform verankert sind:

• Fehlende Skip-Links: Viele Baukästen generieren keinen "Zum Inhalt springen"-Link (WCAG SC 2.4.1 — Blöcke umgehen). Du kannst ihn nicht selbst hinzufügen.
• Automatisch generierte DOM-Reihenfolge: Besonders bei Drag-and-Drop-Editoren stimmt die visuelle Reihenfolge nicht mit der Code-Reihenfolge überein (SC 1.3.2).
• Nicht anpassbare Fokus-Styles: Der sichtbare Fokus-Indikator (SC 2.4.7) wird von der Plattform gesteuert. Ist er zu schwach, kannst du wenig tun.
• Eingebettete Widgets: Slider, Lightboxen und Karussells von Baukästen sind oft nicht tastaturzugänglich (SC 2.1.1).
• Automatische Bildkomprimierung: Manche Baukästen komprimieren Text-in-Bild so stark, dass er unleserlich wird.

In diesen Fällen bleiben dir zwei Optionen: Ein Support-Ticket beim Anbieter eröffnen oder die betreffende Funktion durch eine barrierefreie Alternative ersetzen.

Was du bei jedem Baukasten selbst tun kannst

Unabhängig von der Plattform hast du bei folgenden Punkten die volle Kontrolle:

Alt-Texte für alle Bilder

Jeder Baukasten bietet die Möglichkeit, Alt-Texte zu setzen. Nutze sie konsequent. Ein guter Alt-Text beschreibt, was auf dem Bild zu sehen ist — nicht "Bild1.jpg" oder "Foto". Dekorative Bilder bekommen einen leeren Alt-Text (alt=""). Das erfüllt WCAG SC 1.1.1.

Überschriften-Hierarchie einhalten

Nutze die Überschriften-Optionen deines Baukastens korrekt: H1 für den Seitentitel (nur einmal pro Seite), H2 für Hauptabschnitte, H3 für Unterabschnitte. Formatiere Überschriften niemals nur über Schriftgröße und Fettung — das zerstört die semantische Struktur (SC 1.3.1).

Kontrastreiche Farben wählen

WCAG SC 1.4.3 verlangt ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text. Prüfe deine Farbkombinationen mit einem Kontrast-Checker. Besonders kritisch: Helle Schrift auf hellem Hintergrund und farbige Buttons mit weißem Text.

Formulare korrekt beschriften

Egal ob Kontaktformular, Newsletter-Anmeldung oder Bestellformular: Jedes Eingabefeld braucht eine sichtbare Beschriftung. Platzhalter-Text allein reicht nicht (SC 3.3.2). Pflichtfelder müssen als solche gekennzeichnet sein. Mehr dazu: Barrierefreiheit testen — Tools im Überblick.

Deine Seite regelmäßig prüfen

Baukästen aktualisieren ihre Templates regelmäßig. Was gestern barrierefrei war, kann nach einem Plattform-Update Probleme haben. Prüfe deine Seite regelmäßig mit dem kostenlosen BFSG-Scanner von bf-check.de.

Overlay-Widgets sind keine Lösung

Manche Baukasten-Nutzer installieren sogenannte Accessibility-Overlay-Widgets (z. B. AccessiBe, UserWay oder EqualWeb). Diese versprechen "sofortige BFSG-Konformität" per JavaScript. Das ist irreführend.

Overlay-Widgets können keine strukturellen Probleme beheben: fehlende Alt-Texte, kaputte Überschriften-Hierarchie, nicht-tastaturzugängliche Elemente. Sie legen nur eine Schicht über den bestehenden Code, die oft selbst Barrierefreiheits-Probleme erzeugt.

Das BFSG verlangt native Konformität — nicht ein nachträgliches Widget.

Wann ein Wechsel zu WordPress sinnvoll ist

Ein Wechsel lohnt sich, wenn:

• Dein Baukasten strukturelle Barrierefreiheits-Probleme hat, die du nicht beheben kannst
• Du einen Online-Shop betreibst und volle Kontrolle über den Checkout brauchst
• Du ARIA-Attribute und Custom-HTML benötigst
• Deine Seite unter das BFSG fällt und du das Haftungsrisiko minimieren willst

WordPress bietet mit barrierefreien Themes und Plugins wie WP Accessibility deutlich mehr Kontrolle. Aber auch WordPress macht deine Seite nicht automatisch barrierefrei — du musst dort ebenfalls Alt-Texte, Überschriften und Kontraste richtig umsetzen.

Grenzen der Baukästen

Manche Barrierefreiheits-Fixes sind bei Baukästen nicht möglich, weil du keinen Zugriff auf den HTML-Quellcode hast. In solchen Fällen: Beim Anbieter ein Support-Ticket eröffnen, die Funktion durch eine barrierefreie Alternative ersetzen, oder über einen Wechsel zu WordPress nachdenken.

Dokumentiere deine Bemühungen. Wenn du nachweisen kannst, dass du alles in deiner Macht Stehende getan hast und die verbleibenden Probleme plattformbedingt sind, kann das bei Prüfungen und Beschwerden helfen.

Hinweis: Dieser Artikel dient der allgemeinen Information und ersetzt keine Rechtsberatung. Die Barrierefreiheits-Funktionen der genannten Plattformen können sich durch Updates jederzeit ändern. Prüfe den aktuellen Stand direkt beim Anbieter.

Häufig gestellte Fragen