Squarespace und BFSG: Barrierefreiheit im US-Baukasten für deutsche Webseiten

Squarespace in Deutschland: Schön, aber barrierefrei?

Squarespace ist bekannt für elegante Templates und einfache Bedienung. In den USA hat Squarespace bereits auf ADA-Compliance reagiert und einige Barrierefreiheits-Features eingebaut. Für deutsche Nutzer unter dem BFSG (Barrierefreiheitsstärkungsgesetz) stellt sich die Frage: Reichen diese Maßnahmen für die europäischen WCAG-Anforderungen?

Die kurze Antwort: Teilweise ja, aber mit Lücken. Wer eine Squarespace-Seite betreibt, die unter § 1 BFSG fällt – also Produkte oder Dienstleistungen im elektronischen Geschäftsverkehr anbietet –, muss aktiv nachbessern. Dieser Artikel zeigt dir, was Squarespace kann, wo die Grenzen liegen und wie du per Code-Injection gezielt Barrierefreiheits-Fixes umsetzt.

Hinweis: Dieser Artikel dient der allgemeinen Orientierung und ersetzt keine Rechtsberatung. Für verbindliche Aussagen zur BFSG-Pflicht deiner konkreten Webseite wende dich an einen spezialisierten Anwalt.

Squarespace 7.1 Architektur: Was du über Sections wissen musst

Seit Squarespace 7.1 arbeitet die Plattform mit einem Section-basierten Layout. Statt frei platzierbarer Blöcke wie in 7.0 baust du Seiten aus vorgefertigten Sections zusammen – Titelbilder, Galerien, Textabschnitte, Formulare. Weitere Informationen finden Sie im BFSG-Glossar.

Für die Barrierefreiheit hat das Vor- und Nachteile:

• Vorteil: Squarespace erzeugt automatisch semantisches HTML mit <section>-Elementen und setzt Heading-Level (<h1> bis <h3>) in der richtigen Reihenfolge. Das erfüllt WCAG SC 1.3.1 (Info und Beziehungen) besser als viele andere Baukästen.
• Vorteil: ARIA-Landmark-Rollen (role="navigation", role="main") sind in 7.1-Templates standardmäßig vorhanden.
• Nachteil: Du hast keinen Zugriff auf den generierten HTML-Code der Sections. Wenn Squarespace eine Section mit ungünstiger Struktur ausgibt, kannst du das nicht direkt korrigieren.
• Nachteil: Die Reihenfolge der Sections bestimmt die Tab-Reihenfolge. Squarespace bietet kein tabindex-Management – die visuelle Reihenfolge muss also der logischen Reihenfolge entsprechen (WCAG SC 1.3.2, Bedeutungsvolle Reihenfolge).

Was Squarespace für Barrierefreiheit bietet

Squarespace-Templates haben seit 2023 deutlich verbesserte Barrierefreiheit: semantisches HTML, ARIA-Labels für Navigation, Skip-to-Content-Links und responsive Designs. Der Alt-Text-Editor ist gut integriert und erinnert sogar beim Upload an fehlende Alt-Texte. Auch die Tastatur-Navigation funktioniert in den meisten Templates ordentlich.

Konkret liefert Squarespace folgende Barrierefreiheits-Grundlagen:

• Skip-to-Content-Link: In allen 7.1-Templates automatisch vorhanden – erfüllt WCAG SC 2.4.1 (Blöcke umgehen).
• Alt-Text-Editor: Beim Bild-Upload erscheint ein Feld für Alt-Text. Squarespace warnt bei leeren Alt-Texten – aber erzwingt sie nicht.
• Responsive Design: Alle Templates passen sich an Bildschirmgrößen an und unterstützen Pinch-to-Zoom, was WCAG SC 1.4.4 (Textgrößenänderung) abdeckt.
• Fokus-Indikatoren: Grundlegende Fokus-Styles sind vorhanden, allerdings oft visuell dezent und schwer erkennbar (WCAG SC 2.4.7).

Problematisch bleiben: benutzerdefinierte Code-Blöcke (keine Validierung), einige ältere Templates mit Kontrast-Problemen und der Shop-Checkout bei komplexen Produktoptionen. Auch der Vergleich mit anderen Baukästen wie Wix und Jimdo zeigt, dass kein Baukasten automatisch BFSG-konform ist.

CSS-Einschränkungen: Was du anpassen kannst – und was nicht

Squarespace erlaubt Custom CSS über Design → Custom CSS. Das ist mächtig, hat aber klare Grenzen:

• Kontraste anpassen: Du kannst Textfarben, Hintergrundfarben und Link-Farben per CSS überschreiben. So erreichst du die geforderten 4,5:1 für Normtext und 3:1 für großen Text (WCAG SC 1.4.3).
• Fokus-Styles verstärken: Der Standard-Fokus-Indikator ist oft kaum sichtbar. Mit *:focus { outline: 3px solid #1e40af; outline-offset: 2px; } machst du Fokus-Zustände deutlich sichtbar.
• Schriftgrößen erhöhen: Relative Einheiten (rem, em) funktionieren und erlauben Nutzern die Vergrößerung per Browser-Zoom.
• Nicht möglich: Checkout-Styles überschreiben, HTML-Struktur ändern, ARIA-Attribute per CSS setzen, Drittanbieter-Widget-Styles anpassen (Shadow DOM).

Für ähnliche Einschränkungen bei anderen Anbietern lies unseren Artikel zur IONOS Homepage-Baukasten und BFSG-Konformität.

Der Squarespace-Checkout: Barrierefreiheit außerhalb deiner Kontrolle

Wenn du Squarespace Commerce nutzt, ist der Checkout-Prozess zentral von Squarespace gehostet. Du kannst weder HTML noch CSS des Checkouts anpassen. Das bedeutet:

• Kontrast-Probleme im Checkout kannst du nicht beheben.
• Fehlende ARIA-Labels bei Formularfeldern sind Squarespaces Verantwortung.
• Komplexe Produktoptionen (Varianten-Selektoren, Custom Fields) sind oft nicht vollständig tastatur-bedienbar – ein Verstoß gegen WCAG SC 2.1.1 (Tastatur).

Empfehlung: Dokumentiere bekannte Checkout-Einschränkungen in deiner Barrierefreiheitserklärung und biete einen alternativen Bestellweg an (z. B. Telefon oder E-Mail). Für einen detaillierten Vergleich mit einem anderen Shop-Baukasten, der mehr Kontrolle bietet, lies unseren Artikel zu Shopify und BFSG.

Blog auf Squarespace: Besondere Herausforderungen

Der Squarespace-Blog ist ein häufig genutztes Feature, hat aber eigene Barrierefreiheits-Fallstricke:

• Bilder in Blog-Posts: Der Alt-Text-Editor ist verfügbar, aber bei Massen-Uploads leicht zu übersehen. Prüfe jeden Post einzeln.
• Heading-Hierarchie: Squarespace setzt den Blog-Titel als <h1>. Wenn du im Post selbst auch <h1> verwendest, verletzt du WCAG SC 1.3.1. Nutze in Posts nur <h2> und darunter.
• Eingebettete Medien: YouTube-Videos, SoundCloud-Player und andere Embeds bringen eigenes HTML mit. Prüfe, ob Embeds ein title-Attribut auf dem <iframe> haben (WCAG SC 4.1.2, Name, Rolle, Wert).
• Kommentarfunktion: Falls aktiviert, müssen Formularfelder Labels haben. Squarespace liefert hier teilweise nur Placeholder-Text statt echte <label>-Elemente.

Code-Injection für gezielte Barrierefreiheits-Fixes

Über Settings → Advanced → Code Injection kannst du JavaScript in den Header oder Footer jeder Seite einfügen. Das ist dein mächtigstes Werkzeug für Barrierefreiheits-Fixes auf Squarespace:

Typische Code-Injection-Fixes:

• Fehlende ARIA-Labels ergänzen: Per JavaScript kannst du aria-label auf Buttons und Links setzen, die Squarespace ohne beschreibenden Text ausgibt.
• Skip-Link sichtbar machen: Wenn der vorhandene Skip-Link zu dezent ist, kannst du ihn per CSS/JS bei Fokus prominent anzeigen.
• Sprach-Attribut prüfen: Squarespace setzt lang="en" als Standard. Für deutsche Seiten musst du per Code-Injection document.documentElement.lang = 'de'; setzen – sonst liest ein Screenreader deinen deutschen Text mit englischer Aussprache vor (WCAG SC 3.1.1, Sprache der Seite).
• Formular-Labels nachrüsten: Squarespace-Formulare verwenden teilweise Placeholder statt Labels. Per JavaScript kannst du <label>-Elemente hinzufügen und mit for-Attribut verknüpfen.

Wichtig: Code-Injection wird von Squarespace nicht auf Barrierefreiheit validiert. Teste jeden Fix mit einem Screenreader (NVDA oder VoiceOver) und per Tastatur-Navigation.

BFSG-Konformität mit Squarespace erreichen: Schritt für Schritt

Schritt 1 – Template wählen: Nutze ausschließlich 7.1-Templates. Sie haben bessere Heading-Hierarchien, ARIA-Landmarks und Tastatur-Navigation als 7.0-Templates.

Schritt 2 – Sprache setzen: Stelle sicher, dass das lang-Attribut auf de steht. Bei Squarespace musst du das oft per Code-Injection korrigieren.

Schritt 3 – Alle Bilder mit Alt-Texten versehen: Squarespace macht das einfach über den Editor. Dekorative Bilder erhalten ein leeres alt="".

Schritt 4 – Kontraste prüfen und anpassen: Nutze ein Tool wie den WCAG Contrast Checker. Passe Farben per Custom CSS an, bis du mindestens 4,5:1 für Normtext erreichst.

Schritt 5 – Fokus-Styles verstärken: Füge per Custom CSS einen deutlichen Fokus-Indikator hinzu (mindestens 3px, kontrastreiche Farbe).

Schritt 6 – Drittanbieter-Widgets minimieren: Jedes externe Widget (Cookie-Banner, Chat, Social Feeds) ist ein potenzielles Barrierefreiheits-Risiko. Verwende so wenige wie möglich und teste jedes einzeln mit der Tastatur.

Schritt 7 – Formulare testen: Tabble durch jeden Buchungs- und Kontakt-Prozess. Prüfe, ob alle Felder Labels haben und Fehlermeldungen verständlich sind (WCAG SC 3.3.1, Fehlererkennung).

Schritt 8 – Regelmäßig mit bf-check.de scannen: Automatisierte Scans decken technische Probleme auf, die du manuell leicht übersiehst.

Squarespace vs. WordPress für Barrierefreiheit

WordPress bietet mehr Kontrolle: Jedes HTML-Element, jedes ARIA-Attribut kann angepasst werden. Squarespace ist eingeschränkter, liefert aber eine bessere Grundlage out-of-the-box. Für einfache Business-Webseiten ohne komplexe Interaktionen kann Squarespace ausreichen.

Für Online-Shops mit vielen Produkten oder interaktive Webanwendungen ist WordPress die sicherere Wahl. Der entscheidende Unterschied: Bei WordPress kannst du jedes WCAG-Kriterium direkt im Code adressieren. Bei Squarespace bist du an die Plattform-Grenzen gebunden – und musst Einschränkungen in deiner Barrierefreiheitserklärung dokumentieren.

Checkliste: Die häufigsten WCAG-Verstöße auf Squarespace-Seiten

Diese Probleme finden wir regelmäßig bei Squarespace-Seiten, die wir mit dem bf-check Scanner prüfen:

• SC 1.1.1 – Fehlende Alt-Texte: Besonders bei Galerie-Sections und Blog-Header-Bildern.
• SC 1.4.3 – Kontrast zu gering: Hellgraue Texte auf weißem Hintergrund, besonders bei Footer-Links und Metadaten.
• SC 2.4.7 – Fokus nicht sichtbar: Standard-Fokus-Styles sind oft zu dezent oder werden per CSS entfernt.
• SC 3.1.1 – Falsches Sprach-Attribut: lang="en" statt lang="de" ist der häufigste Fehler bei deutschen Squarespace-Seiten.
• SC 4.1.2 – Fehlende Names/Rollen: Hamburger-Menüs und Accordion-Elemente ohne aria-expanded.

Häufig gestellte Fragen