Ratgeber · Wix & BFSG

Wix barrierefrei machen: Was Baukästen können – und wo die Grenzen liegen

Wix barrierefrei machen – dieses Ziel treibt seit dem Anwendungsbeginn des Barrierefreiheitsstärkungsgesetzes (BFSG) am 28.06.2025 viele Shop-Betreiber um, die ihren Onlineshop mit einem Baukasten wie Wix, Jimdo oder Squarespace gebaut haben. Die gute Nachricht zuerst: Wix bringt eigene Werkzeuge mit, mit denen sich ein relevanter Teil der WCAG-2.1-AA-Anforderungen tatsächlich verbessern lässt. Die ehrliche Nachricht: Wix selbst sagt in der eigenen Dokumentation ausdrücklich nicht zu, dass eine Website nach dem Einsatz dieser Tools rechtssicher barrierefrei ist – und einige Bereiche eines Onlineshops, allen voran Warenkorb und Checkout, werden von den eingebauten Prüfwerkzeugen gar nicht erst erfasst.

Die allgemeinen BFSG-Grundlagen – wer betroffen ist, welche Fristen gelten, was die Kleinstunternehmen-Ausnahme bedeutet und was bei Verstößen droht – haben wir bereits ausführlich im Ratgeber Onlineshop barrierefrei machen erklärt. Dieser Beitrag konzentriert sich gezielt auf die Baukasten-Situation: Was Wix (und im Vergleich Jimdo und Squarespace) an Bord haben, wo der Code-Zugriff endet und wann ein Wechsel auf ein offenes System der ehrlichere Weg sein kann. Hinweis vorab: Dieser Artikel ist keine Rechtsberatung, sondern eine praktische Einordnung auf Basis der öffentlich verfügbaren Wix-Dokumentation und unabhängiger Quellen.

Dieser Ratgeber vertieft die Umsetzung. Die allgemeinen BFSG-Grundlagen – wer betroffen ist, welche Ausnahme gilt, was es kostet – finden Sie im Leitfaden „Onlineshop barrierefrei machen".

Ist Wix barrierefrei? Die kurze Antwort

Kurz gesagt: teilweise, und nicht automatisch. Wix stellt Funktionen bereit, die in Standard-Widgets tatsächlich für ein solides technisches Grundgerüst sorgen – etwa Basis-Tastaturnavigation, semantisches HTML, eine sinnvolle DOM-Reihenfolge und einen Teil der ARIA-Struktur. Dinge wie Alt-Texte, Farbkontraste, eine korrekte Überschriftenhierarchie, beschreibende Linktexte und Formularlabels bleiben aber Aufgabe des Website-Betreibers und werden nicht automatisch erzeugt.

Wer prüfen will, ob genau sein Wix-Shop betroffen ist, findet die rechtlichen Grundlagen – Geltungsbereich, Fristen, Kleinstunternehmen-Ausnahme, mögliche Bußgelder – im Pillar-Artikel Onlineshop barrierefrei machen. An dieser Stelle nur so viel: Die BFSG-Pflicht hängt an der Größe und Tätigkeit des Unternehmens, nicht an der gewählten Plattform. Ein Wix-Shop ist rechtlich genauso betroffen wie ein Shop auf einem offenen System.

Was macht der Wix Accessibility Wizard – und was nicht?

Wix bietet im Editor einen sogenannten Accessibility Wizard, der die Website scannt. Laut Wix-Support orientiert sich der Wizard an WCAG 2.2 und unterscheidet zwischen Problemen, die automatisch erkannt und teils behoben werden, und Aufgaben, die manuell erledigt werden müssen – etwa Alt-Texte oder Formularlabels selbst zu ergänzen.

Entscheidend ist aber, was der Wizard nicht abdeckt. Wix schreibt selbst wörtlich: 'we cannot guarantee that your site will be compliant with your region's accessibility laws and regulations after using the Wizard' – und empfiehlt zusätzlich, einen Accessibility-Experten hinzuzuziehen. Folgende Bereiche werden vom Wizard explizit nicht gescannt:

Wix Code bearbeiten: Wie weit reicht der Zugriff auf HTML und ARIA?

Im normalen Wix-Editor lässt sich der zugrundeliegende HTML-Code nicht direkt einsehen oder bearbeiten – anders als bei einem offenen CMS. Wer ARIA-Attribute oder Tabindex gezielt auf einzelne Elemente anwenden will, kann das nur über Velo, den Entwicklermodus von Wix, per JavaScript nachrüsten. Das setzt Programmierkenntnisse voraus und deckt laut Wix-eigener Dokumentation nicht jedes Element ab – bestimmte App-Seiten bleiben außen vor.

Etwas mehr Spielraum bietet Wix Studio, das agenturorientierte Wix-Produkt: Hier lässt sich eingebetteter HTML-/CSS-/JS-Custom-Code einbinden, was mehr technische Nachbesserung erlaubt als der klassische Editor. Vollen Zugriff auf das von der Wix-Engine gerenderte Basis-Markup ersetzt das aber nicht – der Unterschied zu einem offenen System wie WordPress bleibt strukturell bestehen.

Wichtig zudem: Barrierefreiheit entsteht nicht automatisch durch KI. Auch der frühere Wix-ADI-Generator (seit 10. November 2024 nicht mehr unterstützt, ersetzt durch den neuen Wix AI Website Builder) und vergleichbare KI-Baukästen anderer Anbieter erzeugen keinen von sich aus barrierefreien Code – fehlende Formularlabels, unbeschriftete Icon-Buttons, übersprungene Überschriftenebenen oder zu geringer Kontrast sind typische Folgen, weil Accessibility schlicht kein Trainingsziel dieser Systeme war.

Wix Onlineshop barrierefrei machen: Warum Warenkorb und Checkout kritisch bleiben

Für Onlineshops auf Wix Stores ist ein Punkt besonders relevant: Ausgerechnet der Bestellprozess – der konversionskritischste Teil jedes Shops – wird vom Accessibility Wizard nicht automatisch geprüft. Wer hier Barrieren hat, etwa nicht erreichbare Formularfelder, fehlende Fehlermeldungen für Screenreader oder Tastaturfallen in Zahlungs-Widgets, muss das manuell oder durch eine externe Prüfung feststellen.

Immerhin bringt Wix native Zusatzwerkzeuge mit: einen Smart Focus Ring für sichtbare Fokus-Indikatoren, einen 'Skip to Main Content'-Link und einen Contrast Checker, der gegen AA- und AAA-Werte prüft. Zusätzlich lässt sich per Drittanbieter-Code eine Accessibility-Toolbar einbinden – funktional ist das allerdings ein Overlay-Widget. Und Overlays ändern, wie generell im Ratgeber zum Thema beschrieben, den Quellcode nicht: Fehlende Alt-Texte, mangelhafte Formularlabels oder Tastaturprobleme bleiben im HTML bestehen, unabhängig davon, ob oben rechts ein Accessibility-Icon eingeblendet wird.

Checkliste: Wix barrierefrei machen in 3 Schritten

Für die Praxis hat sich ein dreistufiges Vorgehen bewährt, das sich auch ohne Programmierkenntnisse zu großen Teilen umsetzen lässt:

Wix vs. Jimdo vs. Squarespace: Welcher Baukasten ist barrierefreier?

Auch andere Baukästen kommunizieren offen, dass sie keine vollständige Barrierefreiheit zusagen. Jimdo schreibt in seinem Accessibility Statement: 'Zum jetzigen Zeitpunkt können nicht alle Jimdo Websites barrierefrei gestaltet werden, aber wir arbeiten aktiv daran.' Für Jimdo Creator ergänzt Jimdo, der Fokus liege auf Flexibilität und Kreativität, weshalb damit gebaute Websites 'mitunter nicht für jeden vollständig zugänglich' seien. Hinzu kommt: Jimdo betreibt mit Dolphin und Creator zwei technisch getrennte Systeme mit jeweils eigenen Grenzen – es gibt keine einheitliche Lösung über beide hinweg.

Squarespace formuliert es ähnlich vorsichtig: In seiner Accessibility-Erklärung leistet Squarespace nach eigenen Angaben keine Rechtsberatung zur Barrierefreiheit und verweist auf die ADA-Standards bzw. die Web Accessibility Initiative (WAI); eine pauschale WCAG-Konformitätszusage für alle Templates und Plugins macht Squarespace nicht. Betreiber müssen ihr gewähltes Template also individuell prüfen. Erschwerend kommt hinzu, dass viele Squarespace-Templates keine Drittanbieter-Plugins zulassen, was die nachträgliche Behebung struktureller Probleme einschränkt. Typische Lücken sind auch hier fehlerhafte Überschriftenhierarchien, fehlende Untertitel oder Transkripte, Farbe als alleiniges Unterscheidungsmerkmal, Tastaturprobleme und unzureichender Kontrast.

Ein oft zitierter Vergleich (Search Engine Journal, auf Basis von HTTP-Archive-Daten) nennt automatisiert gemessene Accessibility-Scores von 94 % für Wix, 92 % für Squarespace, 87 % für Duda und 85 % für WordPress. Diese Zahl sollte man mit Vorsicht lesen: Es handelt sich vermutlich um automatisierte Scans, deren Methodik nicht vollständig offengelegt ist – und automatisierte Scanner finden nach etabliertem Fachkonsens generell nur rund 30–40 % der tatsächlichen Barrieren. Ein hoher Score ist also kein Nachweis für WCAG-Konformität. Unabhängig vom Ranking gilt zudem: Die rechtliche BFSG-Verantwortung liegt immer beim Website-Betreiber selbst, unabhängig davon, ob Wix, Jimdo, Squarespace oder WordPress im Hintergrund läuft.

Wann ein Wechsel auf ein offenes System der ehrlichere Weg ist

Bei geschlossenen Baukästen ist der Code-Zugriff – bewusst oder aus Plattformarchitektur-Gründen – begrenzt. Das ist per se nicht dramatisch: Ein relevanter Teil der WCAG-2.1-AA-Kriterien lässt sich bei Wix, Jimdo und Squarespace mit Bordmitteln durchaus verbessern, wie oben beschrieben. Die ehrliche Grenze liegt bei Barrieren, die tief im gerenderten Code verankert sind – etwa im Markup bestimmter Apps, in Checkout-Flows, in komplexen interaktiven Widgets oder im Fokus-Management von Modal-Dialogen. Solche Probleme lassen sich ohne echten Codezugriff oft nicht vollständig lösen, selbst mit Velo oder Wix Studio nicht.

Für kleinere Shops mit überschaubarem Katalog kann Nachbessern mit Bordmitteln trotzdem der richtige Weg sein, insbesondere wenn die kritischen Stellen begrenzt sind. Für Shops, die stark auf Drittanbieter-Apps, individuelle Checkout-Logik oder komplexe Produktkonfiguratoren setzen, ist ein Neuaufbau auf einem offenen System wie WordPress/WooCommerce häufig wirtschaftlicher als der Versuch, jede Baukasten-Grenze einzeln zu umgehen. Das ist keine pauschale Empfehlung, sondern eine Einzelfallentscheidung – ein guter erster Schritt dafür ist ein kostenloser Kurzcheck, der zeigt, wie groß der tatsächliche Handlungsbedarf bei Ihrem konkreten Wix-Shop ist. Je nach Ergebnis reicht das Angebot von einem klassischen Audit über eine gezielte Sanierung bis zu einer neuen barrierefreien Website – die Entscheidung liegt am Ende immer bei Ihnen.

Dieser Ratgeber ist allgemeine Information zum Stand Juli 2026 und ersetzt keine Rechtsberatung. Im Zweifel wenden Sie sich an eine auf IT-Recht spezialisierte Kanzlei.