Bricks Builder barrierefrei einsetzen: Die Elemente, die dir die Konformität zerlegen

Stand: 4. November 2026 · Tutorial-Reihe Barrierefreiheit, Strang Entwicklung · Beitrag 4 von 20

Du baust Websites mit Bricks, der Kunde fragt nach Barrierefreiheit, und du verlässt dich darauf, dass die Standardelemente das schon können. Das ist die teuerste Annahme in diesem Setup. Bricks bringt gute Voraussetzungen mit: sauberes HTML, kein Div-Wust, volle Kontrolle über Tags und Attribute. Aber „volle Kontrolle“ heißt auch: Die Verantwortung liegt bei dir. Dieser Beitrag ist Teil der Tutorial-Reihe Barrierefreiheit. Er zeigt, welche Bricks-Elemente du prüfen musst, wie du sie testest und was du im Projekt festlegst, damit es nicht jedes Mal von vorn losgeht.

Ein Hinweis vorab: Ich beschreibe, wo Probleme dokumentiert sind und wie du sie in deiner Version selbst nachweist. Eine pauschale Aussage wie „Element X ist konform“ gibt es nicht. Das hängt von Bricks-Version, Einstellungen und deinem Inhalt ab.

Was heißt „Bricks barrierefrei einsetzen“?

Ein Page Builder ist weder pauschal barrierefrei noch pauschal unbarrierefrei. Barrierefrei ist das fertige Ergebnis im Browser. Der Builder liefert Bausteine. Ob daraus eine konforme Seite wird, entscheiden Elementwahl, Einstellungen, Design und Inhalte. Für dich als Entwickler heißt das: Du prüfst das ausgelieferte HTML, nicht das Versprechen im Marketing.

Woher die Anforderung kommt

Die relevanten Erfolgskriterien für interaktive Elemente sind in WCAG 2.2 vor allem 2.1.1 Tastatur, 2.4.7 Fokus sichtbar und 4.1.2 Name, Rolle, Wert. Neu in 2.2 sind 2.5.8 Zielgröße (Minimum) mit 24 × 24 CSS-Pixeln und 2.4.11 Fokus nicht verdeckt. Genau an diesen Punkten scheitern Akkordeons, Tabs, Slider und Off-Canvas-Menüs: Sie sind per Maus bedienbar, aber nicht per Tastatur, oder sie sagen dem Screenreader nicht, ob sie offen oder zu sind.

Was dokumentiert ist

Bricks hat die Barrierefreiheit seiner verschachtelten Elemente über die Zeit verbessert. In einem Community-Thread zu Akkordeons und Tabs bestätigte das Bricks-Team im Oktober 2024, dass entsprechende Änderungen in Bricks 1.11 (Beta, später Release) enthalten sind. Ein Nutzerbericht aus dem Forum nennt zu dieser Version unter anderem: ein fehlendes aria-expanded beim ersten Laden des Akkordeons (behoben in 1.11.1), eine zu tiefe Standard-Überschriftenebene im Akkordeon-Titel und falsche aria-labelledby-Verweise bei verschachtelten Tabs. Das zeigt zweierlei: Es bewegt sich etwas, und einzelne Versionen hatten Fehler.

Im August 2025 listete ein Review von Equalize Digital Probleme auf, die in einem Forum-Thread diskutiert wurden. Genannt werden vor allem die älteren, nicht verschachtelbaren Elemente (Tabs, Akkordeon, Slider) sowie die Standard-Seitenvorlagen. Die Teilnehmer fordern dort, diese Altelemente zu entfernen oder auszublenden. Eine offizielle Antwort des Bricks-Teams steht in diesem Thread nicht. Die Quellen findest du unten.

Was ich nicht belegen konnte: wie sich Slider, Off-Canvas und Mega-Menü in der aktuellen Version verhalten. Dazu fand ich keine verlässliche Dokumentation. Deshalb bekommst du unten ein Testprotokoll statt einer Behauptung.

Die Elemente, die du in jedem Projekt prüfst

• Akkordeon und Tabs: Nimm die verschachtelbaren Varianten (Nestable), nicht die alten. Prüfe, ob der Auslöser ein echter <button> ist, ob aria-expanded beim Laden stimmt und ob die Überschriftenebene zur Seitenstruktur passt.
• Slider: Autoplay ist das Hauptproblem. Bewegung, die länger als fünf Sekunden läuft, braucht eine Pause-Funktion (WCAG 2.2.2). Bedienelemente brauchen Namen („Nächste Folie“, nicht nur ein Pfeil-Icon).
• Off-Canvas und mobiles Menü: Beim Öffnen muss der Fokus hineinwandern, Escape muss schließen, danach muss der Fokus am Auslöser landen. Der Hamburger-Button braucht einen Namen und einen Zustand.
• Icon-Buttons und Icon-Links: Icons ohne Text haben keinen zugänglichen Namen, bis du ihn setzt. Das betrifft Suche, Warenkorb, Social-Links und Schließen-Buttons.
• Bild- und Hintergrund-Inhalte: Text auf Hintergrundbildern ist ein Kontrastproblem, das erst im Browser sichtbar wird. Alt-Texte setzt du im Element selbst, wie in diesem Beitrag zu Alt-Texten beschrieben.
• Formulare: Das Bricks-Formularelement ersetzt keine Prüfung von Labels, Pflichtfeld-Kennzeichnung und Fehlermeldungen. Dazu gibt es einen eigenen Beitrag: barrierefreie Formulare komplett.
• Dynamische Daten und Query Loops: Schleifen erzeugen schnell Dutzende Links mit identischem Text („Mehr lesen“). Jeder braucht einen eindeutigen Namen.

So gehst du vor: fünf Schritte pro Projekt

1. Legacy-Elemente abschalten

Im Bricks-Elements-Manager kannst du Elemente ausblenden. Blende die alten, nicht verschachtelbaren Varianten aus, damit niemand im Team sie versehentlich nutzt. Das ist die billigste Maßnahme mit dem größten Effekt.

2. Sichtbaren Fokus global festlegen

Viele Designs entfernen den Fokusrahmen, weil er „hässlich“ ist. Setz stattdessen eine Regel für das ganze Projekt. Das gehört in die globalen Custom-CSS-Einstellungen oder, sauberer, in eine eigene Stylesheet-Datei im Child-Theme:

:focus-visible {
  outline: 3px solid var(--focus-color, #0b5fff);
  outline-offset: 3px;
}

/* Fixierte Header verdecken sonst den fokussierten Bereich (WCAG 2.4.11) */
html {
  scroll-padding-top: 6rem; /* an Header-Höhe anpassen */
}

Der Kontrast des Fokusrahmens zur Umgebung muss mindestens 3:1 betragen (WCAG 1.4.11). Teste ihn auf hellen und dunklen Sektionen getrennt.

3. Bewegung respektieren

@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;
  }
}

Das ersetzt keine Pause-Schaltfläche bei Autoplay-Slidern, ist aber eine solide Grundlage. Die Bricks-Animationen und Interaktionen testest du danach mit eingeschalteter Systemeinstellung „Bewegung reduzieren“.

4. Bedienelemente ohne Namen finden

Dieses Snippet läuft in der Browser-Konsole und listet Buttons und Links ohne erkennbaren Namen. Es ersetzt keinen Test mit axe, findet aber die typischen Icon-Fälle in Sekunden:

document.querySelectorAll('button, a[href], [role="button"]').forEach(el => {
  const name = (el.getAttribute('aria-label')
    || el.getAttribute('aria-labelledby')
    || el.textContent
    || el.querySelector('img[alt]')?.alt
    || '').trim();
  if (!name) console.warn('Kein Name:', el);
});

5. Tastaturtest im Browser, nicht im Builder

Der Builder-Canvas ist nicht die Website. Teste im Frontend, ausgeloggt, in einem frischen Fenster. Das Testprotokoll dazu steht gleich unten.

Das Testprotokoll: zehn Minuten pro Template

1. Maus weglegen. Mit Tab von oben nach unten durch die Seite. Springt der Fokus in sinnvoller Reihenfolge, und siehst du immer, wo er steht?
2. Akkordeon: mit Enter und Leertaste öffnen und schließen. Ändert sich der Zustand für den Screenreader (aria-expanded im Inspektor prüfen)?
3. Tabs: Tab-Taste landet auf der aktiven Registerkarte. Pfeiltasten wechseln zwischen den Tabs. Das erwartet das ARIA-Muster für Tabs, ein reiner Tab-Durchlauf durch alle Reiter ist dagegen ein häufiges Abweichen. Prüfe, wie sich dein Bricks-Stand verhält, und dokumentiere es.
4. Off-Canvas: öffnen, Fokus prüfen, Escape drücken, Fokus-Rückgabe prüfen. Hinter dem offenen Menü darf nichts mehr per Tab erreichbar sein.
5. Slider: Läuft er automatisch? Gibt es eine Pause-Schaltfläche, die per Tastatur erreichbar ist?
6. Auf 200 Prozent zoomen und auf 320 CSS-Pixel Breite verkleinern. Nichts darf abgeschnitten oder überlagert sein.
7. axe DevTools oder Lighthouse laufen lassen. Beides findet nur einen Teil der Probleme, ersetzt die Schritte oben also nicht.

Ein Beispiel aus der Praxis

Ein typisches Muster in Agenturprojekten: Das Design verlangt ein Hero-Slider mit Autoplay, ein Off-Canvas-Menü für Mobilgeräte und ein FAQ-Akkordeon. Im Frontend sieht alles gut aus. Der Test zeigt dann meist dieselben drei Funde: Der Hamburger-Button hat keinen Namen, der Fokusrahmen ist per Reset-CSS entfernt, der Slider läuft ohne Pause-Möglichkeit. Alle drei sind in einer Stunde behoben, wenn du sie früh findest. Nach dem Launch kosten sie ein Vielfaches, weil dann Design, Kunde und Freigabe wieder im Spiel sind.

Mein Rat für Agenturen: Leg eine Projekt-Checkliste fest und prüf damit schon im Wireframe. Wer „Slider mit Autoplay“ im Entwurf sieht, kann die Diskussion führen, bevor das Element gebaut ist.

Rechtslage in Deutschland, Österreich und der Schweiz

Deutschland und Österreich: BFSG (DE) und BaFG (AT) gelten seit dem 28. Juni 2025 für viele private Angebote, etwa Online-Shops und Dienstleistungen im elektronischen Geschäftsverkehr. Kleinstunternehmen mit weniger als 10 Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz oder Jahresbilanzsumme sind bei Dienstleistungen ausgenommen. Das schützt dich als Entwickler nicht: Dein Kunde ist verantwortlich, aber du lieferst die Umsetzung. Als Prüfmaßstab dient bisher die EN 301 549 in der Fassung 3.2.1 mit WCAG 2.1 AA. Die Fassung 4.1.1 mit WCAG 2.2 AA ist von ETSI veröffentlicht, aber noch nicht im EU-Amtsblatt zitiert, hat also noch keine Konformitätsvermutung. Mein Rat: Baue gegen WCAG 2.2 AA. Das schließt 2.1 AA ein.

Schweiz: Für private Anbieter besteht heute noch keine gesetzliche Pflicht. Die Teilrevision des Behindertengleichstellungsgesetzes (BehiG) würde sie erstmals erfassen. Ein verbindliches Inkrafttreten steht nach meinem Stand noch nicht fest, ich prüfe das in jedem Beitrag neu. Wer Kunden in der EU bedient, fällt schon jetzt unter EU-Recht.

Wo KI hilft und wo sie schadet

KI spart dir hier Zeit bei der Auswertung. Du kannst das gerenderte HTML eines Templates (nicht den Builder-JSON) in ein Sprachmodell geben und nach Auffälligkeiten fragen: Buttons ohne Namen, doppelte IDs, Überschriften-Sprünge. Auch die Ergebnisse eines axe-Laufs lassen sich sortieren: erst Fehler an globalen Elementen wie Header und Footer, weil eine Korrektur dort jede Seite betrifft.

Wo sie schadet: Sie kann Tastaturverhalten nicht prüfen und Fokusreihenfolge nicht erleben. Sie erfindet gern ARIA-Attribute, die das Problem verschlimmern. Ein falsches role ist schlimmer als keins. Und sie sieht nur den Code, den du ihr gibst, nicht das Zusammenspiel von Bricks-JavaScript und deinem CSS. Jede Empfehlung testest du im Browser. Der Beitrag funktioniert auch ohne diesen Abschnitt.

Warum es Sinn macht und wann du es anwendest

Es lohnt sich in jedem Bricks-Projekt, das unter BFSG oder BaFG fallen kann oder bei dem Kunden Wert auf Qualität legen. Der Aufwand pro Template ist gering, wenn du ihn in den Ablauf einbaust. Er wird groß, wenn du erst nach dem Launch prüfst.

Wo es wenig bringt: bei Elementen, die du im Projekt gar nicht einsetzt, und bei reinem „Plugin-Zukauf“. Ein Barrierefreiheits-Overlay repariert den Code nicht und ersetzt keine Prüfung. Typische Fehler: Reset-CSS entfernt den Fokus; Icon-Buttons ohne Namen; Slider mit Autoplay ohne Pause; Altelemente aus alten Vorlagen bleiben im Einsatz; Test nur im Builder statt im Frontend.

Checkliste: Bricks-Projekt

Hake ab, was in deinem Projekt schon passt. Dein Stand bleibt in diesem Browser gespeichert.

1. Legacy-Elemente sind im Elements-Manager ausgeblendet. Es werden nur verschachtelbare Akkordeons und Tabs genutzt.
2. Der Fokus ist überall sichtbar. Kein outline: none ohne Ersatz, Kontrast mindestens 3:1.
3. Fixierte Header verdecken keinen fokussierten Inhalt. scroll-padding-top ist gesetzt.
4. Jeder Icon-Button und Icon-Link hat einen zugänglichen Namen. Konsolen-Snippet zeigt keine Treffer mehr.
5. Akkordeon, Tabs und Off-Canvas sind per Tastatur bedienbar. Zustand und Fokus-Rückgabe sind geprüft.
6. Slider mit Autoplay haben eine Pause-Funktion. Oder Autoplay ist abgeschaltet.
7. Animationen respektieren „Bewegung reduzieren“.
8. Query Loops erzeugen eindeutige Linknamen. Kein „Mehr lesen“ ohne Bezug.
9. Getestet im Frontend, ausgeloggt, bei 200 Prozent Zoom und 320 Pixel Breite.

Einen ersten Überblick über eine bestehende Seite gibt dir der kostenlose Barrierefreiheit-Schnellcheck. Er findet typische Fehler, kann aber Tastaturverhalten nicht beurteilen. Das bleibt dein Test. Wer Bricks einsetzt und den Aufwand abschätzen will, findet im Vergleich Bricks Builder vs. Elementor die Grundlagen zum Builder. Im Glossar stehen die Begriffe kurz erklärt: zum Glossar.

Häufige Fragen

Ist Bricks Builder barrierefrei?

Das lässt sich nicht pauschal beantworten. Bricks erzeugt sauberes HTML und hat die Barrierefreiheit seiner verschachtelbaren Elemente ab Version 1.11 verbessert. Ob deine Seite konform ist, hängt von Elementwahl, Design und Inhalten ab. Prüfe das ausgelieferte Ergebnis im Browser.

Welche Bricks-Elemente sind am kritischsten?

Interaktive Elemente: Akkordeon, Tabs, Slider und Off-Canvas-Menü, dazu alle Icon-Buttons. Die älteren, nicht verschachtelbaren Varianten sind laut Community-Berichten besonders problematisch und sollten im Elements-Manager ausgeblendet werden.

Reicht ein Accessibility-Plugin oder Overlay?

Nein. Overlays reparieren den zugrunde liegenden Code nicht und ersetzen keine Prüfung. Konformität entsteht im HTML, CSS und in der Bedienung.

Muss ich gegen WCAG 2.1 oder 2.2 bauen?

Als Prüfmaßstab gilt derzeit die EN 301 549 in der Fassung 3.2.1 mit WCAG 2.1 AA. Die Fassung mit WCAG 2.2 AA ist veröffentlicht, aber noch nicht im EU-Amtsblatt zitiert. Wer gegen 2.2 AA baut, erfüllt 2.1 AA automatisch mit und ist auf der sicheren Seite.

Kann ich KI zum Prüfen meiner Bricks-Seite nutzen?

Als Hilfe beim Auswerten von HTML und Testergebnissen ja. Tastaturbedienung, Fokusreihenfolge und das Verhalten mit einem Screenreader prüfst du selbst. Empfehlungen zu ARIA-Attributen testest du immer im Browser.

Du setzt Bricks ein und willst wissen, wo deine Templates stehen? Ich prüfe sie mit dir, richte die globalen Einstellungen ein und liefere dir eine Projekt-Checkliste für dein Team. Mehr dazu unter Webentwicklung & Barrierefreiheit. Sprich mit mir über dein Projekt.

Quellen

• Bricks Forum: Minor Accessibility Improvements for Accordions, Tabs and Builder (Oktober 2024)
• Bricks Forum: Component Accessibility: Accordions, Tabs
• Bricks Forum: Accessibility Issues as Featured in Equalize Digital Builder Review (August 2025)
• W3C: Understanding 2.1.1 Keyboard
• W3C: Understanding 2.4.7 Focus Visible
• W3C: Understanding 4.1.2 Name, Role, Value
• W3C: Understanding 2.5.8 Target Size (Minimum)
• W3C: ARIA Authoring Practices, Tabs Pattern
• Sitebrunch: EN 301 549, Versionen und Rechtsstatus