Avada Fusion Builder: So bauen wir barrierefreie Layouts ohne Code
18.02.2026
Katja Hazod
Der Avada Fusion Builder ist das Herzstück unserer Projektarbeit. Er ermöglicht es uns, anspruchsvolle, individuelle Layouts zu erstellen — und gleichzeitig die technischen Anforderungen der WCAG 2.2 zu erfüllen. Wie das konkret funktioniert, zeigen wir in diesem Praxisartikel.
Was ist der Avada Fusion Builder?
Der Fusion Builder ist Avadas eigener Page-Builder — eine visuelle Oberfläche, über die Seiten aus einzelnen Elementen zusammengesetzt werden. Statt HTML-Code zu schreiben, zieht man Elemente auf die Seite, konfiguriert sie über ein Einstellungspanel und sieht das Ergebnis sofort.
Das klingt nach einem dieser inflationär angebotenen „Website-Baukästen“ — ist aber deutlich mächtiger. Der Fusion Builder bietet hunderte Elemente, globale Design-Einstellungen, Responsive-Kontrolle für jedes Gerät und eine saubere Code-Ausgabe, die Screenreadern und Suchmaschinen gefällt.
Für uns als Accessibility-Agentur ist entscheidend: Der Fusion Builder gibt uns die Kontrolle, die wir brauchen, um Barrierefreiheit konsequent umzusetzen — und er gibt Kunden die Einfachheit, die sie brauchen, um die Website danach selbst zu pflegen.
Die Struktur: Container, Spalten, Elemente
Jede Seite im Fusion Builder besteht aus drei Ebenen: Container (der äußere Rahmen eines Abschnitts), Spalten (die horizontale Aufteilung innerhalb des Containers) und Elemente (die eigentlichen Inhalte wie Text, Bild, Button oder Formular).
Diese klare Struktur ist nicht nur für das Design wichtig — sie spiegelt sich direkt im generierten HTML wider. Ein gut aufgebauter Fusion-Builder-Abschnitt produziert sauberes, semantisch korrektes HTML, das Screenreader korrekt interpretieren können.
Accessibility-Grundregel im Fusion Builder: Die visuelle Reihenfolge auf dem Bildschirm und die logische Reihenfolge im HTML müssen übereinstimmen. Wer Elemente rein optisch verschiebt, ohne die HTML-Reihenfolge zu beachten, schafft Barrieren für Tastaturnutzer und Screenreader.
Die wichtigsten Elemente — und was beim Thema Barrierefreiheit zu beachten ist
Der Fusion Builder bietet über 100 Elemente. Diese sind im Alltag am relevantesten und haben die größten Auswirkungen auf die Barrierefreiheit:
Heading-Element
HTML-Tag (h1–h6) und visuelle Größe sind getrennt einstellbar. Das ist ideal: Schriftgröße nach Design, Tag-Ebene nach logischer Hierarchie.
Image-Element
Alt-Text kann direkt im Element gesetzt werden. Dekorative Bilder können mit leerem Alt-Text markiert werden — Fusion Builder unterstützt das korrekt.
Button-Element
Buttons werden als echtes <button>– oder <a>-Element ausgegeben. Beschriftung, ARIA-Label und Fokus-Stile sind konfigurierbar.
Accordion / Toggle
Avadas Akkordeon-Element bringt grundlegende ARIA-Attribute (aria-expanded, aria-controls) mit — eine gute Grundlage für barrierefreie FAQ-Abschnitte.
Slider-Element
Slider sind von Natur aus schwer barrierefrei zu gestalten. Autoplay-Optionen müssen deaktiviert, Pause-Buttons hinzugefügt werden. Wir setzen Slider nur mit Bedacht ein.
Icon-Element
Rein dekorative Icons müssen mit aria-hidden="true" versehen werden. Wenn ein Icon eine Funktion trägt, braucht es ein zugängliches Label.
Schritt für Schritt: Wie wir eine barrierefreie Seite im Fusion Builder aufbauen
Überschriften-Hierarchie planen, bevor man baut
Bevor wir das erste Element setzen, legen wir fest: Welche Heading-Tags hat diese Seite? In der Regel gibt es genau eine <h1> (der Seitentitel im Hero-Bereich), dann <h2> für die Hauptabschnitte und <h3> für Unterabschnitte.
Im Fusion Builder kann man für jedes Heading-Element separat einstellen, welches HTML-Tag verwendet wird — unabhängig von der visuellen Größe. Diese Trennung ist ein großer Vorteil gegenüber einfacheren Page-Buildern.
Tipp: Nach dem Aufbau mit dem Browser-Plugin „HeadingsMap“ prüfen, ob die Hierarchie stimmt.
Bilder immer mit Alt-Text versehen
Jedes Bild-Element im Fusion Builder hat ein Alt-Text-Feld. Informationstragende Bilder erhalten eine beschreibende Textalternative. Rein dekorative Bilder — z.B. Hintergrundgrafiken — werden entweder als CSS-Hintergrundbild gesetzt oder mit einem leeren Alt-Attribut ausgezeichnet.
So ja
Alt-Text: „Team von MyWebsiteService beim Workshop-Gespräch am Tisch"
So nein
Alt-Text: „Bild", „Foto", „img_0472.jpg" oder gar kein Alt-Text
Buttons und Links klar beschriften
Buttons im Fusion Builder werden als echte <button>– oder <a>-Elemente ausgegeben — das ist gut. Was wir immer prüfen: Ist die Beschriftung eindeutig? „Mehr erfahren“ ohne Kontext ist keine gute Button-Beschriftung. „Mehr über barrierefreies Webdesign erfahren“ schon.
Für Icon-Buttons ohne sichtbaren Text konfigurieren wir ein aria-label-Attribut direkt im Fusion-Builder-Einstellungspanel.
Farben und Kontraste über Avada Global Colors steuern
Avada bietet ein Global-Colors-System, in dem wir einmal alle Primär-, Sekundär- und Akzentfarben definieren — und diese dann konsistent im gesamten Fusion Builder verwenden. Das hat einen enormen Vorteil für die Barrierefreiheit: Wenn wir eine Farbe anpassen, ändert sie sich überall auf einmal.
Vor dem Launch prüfen wir alle Text-Hintergrund-Kombinationen mit dem WebAIM Contrast Checker auf WCAG 2.2 AA-Konformität.
Tipp: Schon bei der Farbauswahl im Design-Brief auf WCAG-konforme Kombinationen achten — nachträgliche Anpassungen sind aufwändiger.
Animationen und Effekte bewusst einsetzen
Der Fusion Builder bietet viele Möglichkeiten für Einblend-Animationen, Parallax-Effekte und Hover-Interaktionen. Für Menschen mit Bewegungsempfindlichkeit (vestibuläre Störungen) können übermäßige Animationen problematisch sein.
Unsere Regel: Animationen sind willkommen, wenn sie den Inhalt unterstützen — nicht, wenn sie ablenken. Und wir implementieren immer die CSS-Regel prefers-reduced-motion, damit Nutzer, die Animationen in ihrem Betriebssystem deaktiviert haben, auch auf der Website keine störenden Effekte sehen.
Responsive-Einstellungen für alle Gerätegrößen prüfen
Der Fusion Builder erlaubt es, für Desktop, Tablet und Smartphone separate Einstellungen zu definieren. Das ist mächtig — aber auch eine potenzielle Fehlerquelle. Was auf dem Desktop barrierefrei ist, muss auf dem Smartphone nicht automatisch barrierefrei sein.
Wir testen jede Seite auf mehreren Gerätegrößen und prüfen dabei besonders: Schriftgröße (mindestens 16px Bodytext), Abstände zwischen anklickbaren Elementen (mindestens 24px nach WCAG 2.2) und die logische Lesereihenfolge im mobilen Layout.
Was der Fusion Builder nicht automatisch löst
Ehrlichkeit ist uns wichtig: Der Fusion Builder ist ein Werkzeug — kein Autopilot für Barrierefreiheit. Es gibt Aspekte, die wir immer manuell prüfen und konfigurieren müssen:
Unser Fazit: Der Avada Fusion Builder ist das leistungsfähigste Werkzeug, das wir für unsere Arbeit kennen — weil er uns maximale Gestaltungsfreiheit gibt, ohne uns in Bezug auf Barrierefreiheit einzuschränken. Was er nicht ersetzt, ist das Wissen und die Sorgfalt, die eine barrierefreie Umsetzung erfordert.
Über MyWebsiteService
MyWebsiteService ist die Münchner Agentur von Katja Hazod — seit 2012 an der Seite von Unternehmen, NGOs und Selbständigen. Der Fokus auf barrierefreies Webdesign begann 2018 mit einer Anfrage eines Gehörlosen-Verbands. Seitdem sind wir beflügelt von der Idee, jede Website für wirklich jede Person zugänglich zu machen — mit viel Liebe, Empathie und Wertschätzung.
Unsere Werte: wertschätzend · offen · ehrlich · liebevoll
Unser Motto: Liebe. Lebe. Lache.
Häufig gestellte Fragen zum BFSG
Avada bietet die beste Kombination aus Gestaltungsfreiheit, technischer Barrierefreiheits-Grundlage, Kundenbedienbarkeit über den Fusion Builder und langfristiger Verlässlichkeit. Nach vielen Jahren Projekterfahrung hat sich Avada als die zuverlässigste Wahl erwiesen.
Theoretisch ja, aber der Aufwand ist oft größer. Viele kostenlose Themes haben keine saubere HTML-Struktur, keine ARIA-Unterstützung und werden nicht regelmäßig auf Barrierefreiheit hin weiterentwickelt. Das bedeutet mehr manuelle Nacharbeit.
Avada ist nicht das einzige barrierefreie Theme, aber eines der besten im Verhältnis aus Flexibilität, Barrierefreiheits-Grundlage und Kundenbedienbarkeit. Kein Theme ist automatisch WCAG 2.2 AA-konform — fachkundige Konfiguration und Testing sind immer notwendig.
Avada bietet keine eingebaute automatische Dark-Mode-Umschaltung. Es ist jedoch möglich, über CSS und das prefers-color-scheme Media Query einen Dark Mode zu implementieren. Für die meisten Websites empfehlen wir, stattdessen auf sehr gute Kontraste im Standard-Design zu setzen und keine Dark-Mode-Variante zu bauen.
Schnellster Weg: Hex-Werte aus Avada Global Colors kopieren und im WebAIM Contrast Checker eingeben. Für eine vollständige Prüfung der gesamten Website empfehlen wir das Browser-Plugin axe DevTools oder WAVE, die alle Kontrastverstöße auf einer Seite automatisch markieren.
WCAG 2.2 AA fordert mindestens 4,5:1 für normalen Text und 3:1 für großen Text (ab 18pt unformatiert bzw. 14pt fett) sowie für UI-Komponenten wie Buttons und Formularrahmen. Mit dem WebAIM Contrast Checker lässt sich das schnell prüfen.
Avada Global Colors ist ein zentrales Farbverwaltungssystem im Theme Options Panel. Hier werden alle Farben einmalig definiert und stehen dann im gesamten Fusion Builder zur Verfügung. Ändert man eine Global Color, wirkt sich das sofort auf alle Stellen aus, wo diese Farbe verwendet wird.
Avada ist ein kommerzielles Theme und wird über ThemeForest verkauft. In unseren Projekten ist die Avada-Lizenz in der Regel Teil des Projektangebots — sprechen Sie uns an.
Absolut. Avada skaliert von der kleinen Vereinsseite bis zum komplexen Unternehmensauftritt. Die Einstiegshürde ist niedrig — dank vorgefertigter Demo-Layouts kann man schnell starten. Für speziellere Anforderungen bietet Avada die nötige technische Tiefe.
Ja, das ist einer der großen Vorteile von Avada. Der Fusion Builder erlaubt es, Inhalte visuell zu bearbeiten, ohne Code schreiben zu müssen. Nach einer kurzen Einweisung können Kunden Texte, Bilder, neue Seiten und viele Layouts eigenständig pflegen.
Avada liefert eine solide technische Grundlage für Barrierefreiheit — semantisches HTML, ARIA-Unterstützung und barrierefreie Komponenten sind im Theme angelegt. Eine vollständige WCAG 2.2 AA-Konformität entsteht jedoch erst durch die fachkundige Konfiguration und Umsetzung. Avada alleine reicht nicht — aber es ist ein sehr guter Ausgangspunkt.
Im Fusion Builder kann beim Heading-Element das HTML-Tag (h1 bis h6) unabhängig von der visuellen Schriftgröße eingestellt werden. Wichtig: pro Seite genau eine h1, dann logisch verschachtelte h2 und h3. Die Browser-Extension „HeadingsMap“ hilft beim schnellen Prüfen.
Gutenberg ist der native WordPress-Editor mit Block-Prinzip. Der Avada Fusion Builder bietet deutlich mehr Gestaltungsoptionen pro Element, globale Einstellungen für Farben und Schriften sowie engere Integration mit dem Avada-Theme. Für komplex gestaltete Seiten mit hohem Designanspruch bietet der Fusion Builder mehr Möglichkeiten.
Ja. Der Fusion Builder ist so aufgebaut, dass Kunden nach einer kurzen Einweisung Texte, Bilder und viele Layoutelemente selbst bearbeiten können. Wir konfigurieren Avada dabei so, dass nur die für den Kunden relevanten Bereiche editierbar sind — das verhindert versehentliche Änderungen am Design.
Der Fusion Builder liefert eine gute Grundlage: Die generierten Elemente verwenden semantisches HTML und grundlegende ARIA-Attribute. WCAG 2.2 AA-Konformität erfordert jedoch zusätzlich korrekte Konfiguration — Alt-Texte, zugängliche Formularlabels, korrekte Überschriften-Hierarchie. Diese Konfiguration ist im Fusion Builder gut möglich, passiert aber nicht automatisch.
Eine Tastaturfalle entsteht, wenn ein Nutzer, der ausschließlich die Tastatur verwendet, in einen Bereich der Website gelangt — z.B. ein Modal oder Dropdown — und diesen nicht mehr verlassen kann. Das passiert häufig, wenn Dialoge den Fokus nicht korrekt einfangen und beim Schließen zurückgeben.
Ohne Alt-Text hören Screenreader-Nutzer entweder gar nichts oder den Dateinamen des Bildes — beides ist nutzlos. Zusätzlich können Suchmaschinen das Bild nicht indexieren. Fehlende Alt-Texte sind einer der häufigsten und gleichzeitig am einfachsten zu behebenden Accessibility-Fehler.
WCAG 2.2 AA fordert mindestens 4,5:1 für normalen Text und 3:1 für großen Text (ab 18pt unformatiert oder 14pt fett). Mit dem kostenlosen WebAIM Contrast Checker lassen sich Farbkombinationen schnell prüfen.
Kostenlose Tools wie WAVE oder der Lighthouse-Audit in Chrome geben einen ersten Überblick. Wichtig: Diese Tools erkennen nur ca. 30–40 % aller Barrieren. Der Rest erfordert manuelles Testing — mit einem echten Screenreader und vollständiger Tastaturnavigation.