WordPress Elementor barrierefrei machen: BFSG-Konformität mit dem Page Builder

Elementor und Barrierefreiheit: Das Problem

Elementor ist auf Millionen WordPress-Seiten installiert. Der visuelle Page Builder ermöglicht beeindruckende Designs – aber auf Kosten der Barrierefreiheit. Elementor generiert verschachteltes Div-basiertes HTML das von semantischem HTML weit entfernt ist.

Die Elementor-Widgets nutzen oft keine korrekten ARIA-Attribute. Und: Designer die Elementor nutzen fokussieren sich auf das Visuelle, nicht auf die Zugänglichkeit. Das Ergebnis ist eine sogenannte „Div-Suppe“ – tief verschachtelte <div>-Elemente ohne semantische Bedeutung, die Screenreader vor massive Probleme stellt.

Seit dem BFSG (in Kraft seit Juni 2025) müssen Webseiten, die digitale Dienstleistungen oder Produkte anbieten, die Barrierefreiheits-Anforderungen der EN 301 549 und damit WCAG 2.1 Level AA erfüllen. Für Elementor-Nutzer bedeutet das: Jedes einzelne Widget und jede Seite muss geprüft werden. Allgemeine WordPress-Barrierefreiheit behandeln wir ausführlich im Artikel WordPress barrierefrei nach BFSG.

Die Kernfrage lautet: Kann Elementor überhaupt barrierefreie Webseiten erzeugen? Die Antwort ist differenziert. Mit bewusster Konfiguration, Custom CSS und regelmäßigen Tests ist es möglich – aber der Aufwand ist deutlich höher als mit semantisch sauberen Alternativen. Dieser Artikel zeigt dir Schritt für Schritt, wo die Probleme liegen und wie du sie löst.

Elementor Pro vs. Free: A11y-Unterschiede

Nicht alle Elementor-Versionen sind gleich. Die Free-Version hat deutliche Einschränkungen bei der Barrierefreiheit:

Fehlende HTML-Tag-Einstellung: In Elementor Free kannst du für Sections und Columns keinen semantischen HTML-Tag setzen. Alles bleibt ein <div> – ein direkter Verstoß gegen WCAG SC 1.3.1 (Info und Beziehungen), die verlangt, dass die Struktur programmatisch bestimmbar ist.

Kein Custom CSS pro Widget: Elementor Pro bietet ein CSS-Feld pro Widget, in dem du gezielt Focus-Styles und Screenreader-only-Klassen hinzufügen kannst. In der Free-Version musst du über den Theme Customizer oder eine zusätzliche CSS-Datei arbeiten – das ist fehleranfälliger.

Eingeschränkte Formular-Optionen: Das Form-Widget ist nur in Pro verfügbar. Free-Nutzer greifen auf Drittanbieter-Plugins zurück (z.B. WPForms, Contact Form 7), die teilweise bessere Label-Zuordnungen bieten als Elementor Forms selbst.

Fazit: Wenn du bei Elementor bleiben willst, ist die Pro-Version für Barrierefreiheit quasi Pflicht – aber auch sie löst nicht alle Probleme automatisch.

Die größten Barrierefreiheits-Probleme mit Elementor

Div-Suppe statt semantischem HTML (<section>, <article>, <nav> fehlen oft). Kontaktformulare (Elementor Forms) mit fehlenden oder falschen Label-Zuordnungen – das verletzt WCAG SC 1.3.1 und SC 4.1.2 (Name, Rolle, Wert).

Tab-Navigation die nicht der visuellen Reihenfolge folgt – ein Verstoß gegen WCAG SC 2.4.3 (Fokusreihenfolge). Slider und Carousels ohne Tastatursteuerung. Popup-Modals ohne Fokus-Management – wenn ein Modal öffnet, muss der Fokus ins Modal springen und beim Schließen zurückkehren.

Counter, Progress Bars und Animationen ohne Textalternativen oder prefers-reduced-motion-Support. Und: Dekorative Bilder ohne leeres alt="", was Screenreader zwingt, den Dateinamen vorzulesen.

Fehlende Landmark-Regionen: Elementor setzt standardmäßig keine HTML5-Landmarks wie <main>, <aside> oder <footer>. Screenreader-Nutzer navigieren häufig über Landmarks – ohne sie fehlt die Übersicht über die Seitenstruktur. Das verstößt gegen WCAG SC 1.3.1 (Info und Beziehungen) und macht die Navigation unnötig mühsam.

Widget-Audit: Die kritischen Elementor-Widgets

Nicht jedes Elementor-Widget ist gleich problematisch. Hier die kritischsten im Detail:

Accordion & Toggle: Elementor nutzt eigenes JavaScript statt nativer <details>/<summary>-Elemente. Die ARIA-Attribute (aria-expanded, aria-controls) werden inzwischen gesetzt – prüfe aber, ob die Tastatursteuerung (Enter/Space zum Öffnen) funktioniert. Das Accordion sollte mit role="tablist" oder als unabhängige Disclosure-Widgets umgesetzt sein.

Tabs-Widget: Muss die Rollen role="tablist", role="tab" und role="tabpanel" korrekt verwenden. Pfeiltasten müssen zwischen Tabs navigieren (nicht Tab-Taste). Elementor setzt das teilweise um, aber teste es mit NVDA oder JAWS.

Slider & Carousel: Fast immer problematisch. Fehlende Pause-Funktion verstößt gegen WCAG SC 2.2.2 (Pause, Stopp, Ausblenden). Keine Tastatursteuerung verletzt SC 2.1.1. Empfehlung: Ersetze Auto-Play-Slider durch statische Inhalte oder nutze das Splide.js-Plugin, das ARIA-konform ist.

Form-Widget (Pro): Labels müssen sichtbar sein – Platzhalter allein reichen nicht (WCAG SC 3.3.2). Fehlermeldungen müssen mit dem Feld verknüpft werden (aria-describedby). Pflichtfelder brauchen aria-required="true".

Image Carousel: Jedes Bild braucht einen Alt-Text. Dekorative Bilder: alt="". Das Widget muss per Tastatur navigierbar sein.

Icon-Box und Icon-List: Icons die Bedeutung tragen (z.B. ein Telefon-Icon neben einer Nummer) brauchen eine Textbeschreibung. Elementor setzt oft aria-hidden="true" auf Icons – das ist korrekt, wenn daneben ein sichtbarer Text steht. Fehlt der Text, wird die Information für Screenreader unsichtbar. Prüfe jedes Icon-Widget: Ist die Bedeutung auch ohne das Icon verständlich?

Navigation Menu (Pro): Das Nav-Menu-Widget erzeugt ein <nav>-Element mit korrektem ARIA-Markup. Problematisch sind aber Mega-Menüs und Dropdown-Untermenüs: Diese müssen per Pfeiltasten navigierbar sein, nicht nur per Tab. Der Focus muss beim Öffnen eines Untermenüs ins Untermenü springen und beim Schließen (Escape-Taste) zum Eltern-Eintrag zurückkehren – gemäß dem ARIA Authoring Practices Disclosure-Pattern.

Custom CSS für Focus-Styles: Code-Beispiele

Elementor entfernt oder überschreibt Standard-Browser-Fokus-Indikatoren. Das verstößt gegen WCAG SC 2.4.7 (Fokus sichtbar). Füge dieses CSS über den WordPress Customizer oder Elementor Pro > Custom CSS hinzu:

/* Sichtbarer Fokus-Indikator für alle interaktiven Elemente */
*:focus-visible {
  outline: 3px solid #1e40af;
  outline-offset: 2px;
  box-shadow: 0 0 0 4px rgba(30, 64, 175, 0.25);
}

/* Fokus nur bei Tastatur-Navigation, nicht bei Mausklick */
*:focus:not(:focus-visible) {
  outline: none;
}

/* Elementor-Buttons: Hover UND Fokus gleichwertig */
.elementor-button:focus-visible {
  outline: 3px solid #1e40af;
  outline-offset: 2px;
}

/* Elementor-Nav-Menu: Fokus für Menüpunkte */
.elementor-nav-menu a:focus-visible {
  outline: 3px solid #1e40af;
  outline-offset: 2px;
  text-decoration: underline;
}

Für Reduced-Motion-Support füge zusätzlich hinzu:

/* Animationen respektieren Nutzer-Präferenz */
@media (prefers-reduced-motion: reduce) {
  .elementor-widget-counter .elementor-counter-number-wrapper,
  .elementor-widget-progress .elementor-progress-bar,
  .elementor-widget-animated-headline,
  [data-settings*="animation"] {
    animation: none !important;
    transition: none !important;
  }
}

Elementor Navigator und Heading-Hierarchie

Der Elementor Navigator (Shortcut: Strg+I) zeigt dir die Struktur deiner Seite als Baumansicht. Nutze ihn, um die logische Reihenfolge zu prüfen – aber Vorsicht: Der Navigator zeigt die visuelle Struktur, nicht unbedingt die HTML-Reihenfolge im Quellcode.

Heading-Hierarchie prüfen: Gemäß WCAG SC 1.3.1 muss die Überschriften-Hierarchie logisch und lückenlos sein. Typische Elementor-Fehler:

– H1 mehrfach auf einer Seite (durch Header-Templates und Seiten-Titel)
– Sprünge von H2 direkt zu H4 (weil H3 „optisch nicht passt“)
– Überschriften im Text-Widget statt im Überschriften-Widget (semantisch unsauber)

Lösung: Nutze immer das Heading-Widget für Überschriften. Setze genau eine H1 pro Seite. Passe die Größe über CSS an – nicht über die Heading-Ebene. Eine H3 darf visuell groß sein, solange sie semantisch korrekt unter einer H2 steht.

Container vs. Section Layout: Was ist barrierefreier?

Elementor hat 2023 das neue Container-Layout (Flexbox) eingeführt, das das alte Section/Column-Modell ersetzt. Für die Barrierefreiheit ist das ein Fortschritt:

Weniger DOM-Tiefe: Das alte Modell erzeugt pro Abschnitt mindestens 3 verschachtelte Divs (Section > Column > Widget-Wrap > Widget). Container reduzieren das auf 1–2 Ebenen. Weniger Verschachtelung bedeutet bessere Screenreader-Kompatibilität und schnellere Navigation.

Flexbox-Reihenfolge: Mit order kannst du die visuelle Reihenfolge ändern, ohne die DOM-Reihenfolge zu verändern. Vorsicht: Wenn visuelle und DOM-Reihenfolge abweichen, verletzt das WCAG SC 1.3.2 (Bedeutungsvolle Reihenfolge). Nutze order nur für rein dekorative Änderungen.

Empfehlung: Wenn du eine bestehende Elementor-Seite überarbeitest, migriere auf Container. Das allein löst nicht alle Barrierefreiheits-Probleme, aber es reduziert die HTML-Komplexität deutlich.

Semantisches HTML in Elementor erzwingen: Code-Beispiele

Elementors größte Schwäche ist das fehlende semantische HTML. Mit gezieltem Code kannst du das kompensieren. Füge folgendes in dein Child-Theme oder über ein Code-Snippets-Plugin ein:

/* Skip-Link als erstes Element nach body */
<a class="skip-link screen-reader-text"
   href="#main-content">
  Zum Inhalt springen
</a>

/* CSS für den Skip-Link */
.skip-link {
  position: absolute;
  left: -9999px;
  top: auto;
  width: 1px;
  height: 1px;
  overflow: hidden;
}
.skip-link:focus {
  position: fixed;
  top: 10px;
  left: 10px;
  z-index: 99999;
  padding: 15px 23px;
  background: #1e40af;
  color: #fff;
  font-size: 1rem;
  width: auto;
  height: auto;
  text-decoration: none;
  border-radius: 4px;
}

Setze auf deinem Hauptinhalt-Container in Elementor die CSS-ID main-content und den HTML-Tag auf <main> (nur in Pro möglich). In der Free-Version füge role="main" über Custom Attributes hinzu.

Landmarks für Screenreader definieren: Setze den HTML-Tag für den Header-Bereich auf <header>, für die Navigation auf <nav>, für den Footer auf <footer> und für Seitenleisten auf <aside>. In Elementor Pro findest du diese Einstellung unter dem Reiter „Layout“ jedes Containers.

Elementor-Formulare BFSG-konform gestalten

Formulare sind ein häufiger Schwachpunkt in Elementor – sowohl im Pro-Form-Widget als auch bei Drittanbieter-Plugins. Die Anforderungen gemäß WCAG SC 3.3.1 (Fehlererkennung), SC 3.3.2 (Beschriftungen oder Anweisungen) und SC 4.1.2 (Name, Rolle, Wert) werden oft nicht erfüllt.

Labels immer sichtbar lassen: Aktiviere in den Formularfeld-Einstellungen „Label anzeigen“. Platzhalter-Text allein ist kein Ersatz für ein Label – er verschwindet beim Tippen und ist für viele Nutzer schlecht lesbar (zu geringer Kontrast).

Fehlermeldungen mit dem Feld verknüpfen: Elementor Pro zeigt Fehlermeldungen unter dem jeweiligen Feld an, verknüpft sie aber nicht immer per aria-describedby. Füge per Custom Code oder Plugin sicher, dass Screenreader die Fehlermeldung im Kontext des Feldes vorlesen.

Pflichtfelder kennzeichnen: Markiere Pflichtfelder nicht nur mit einem Sternchen (*), sondern auch mit aria-required="true" und einer Erklärung am Formularanfang („Felder mit * sind Pflichtfelder“). So erfüllst du WCAG SC 3.3.2 vollständig.

Elementor barrierefrei nutzen: Best Practices

HTML-Tag-Einstellung nutzen (Pro): Für jeden Abschnitt den korrekten HTML-Tag setzen (<section>, <article>, <nav> statt <div>). Überschriften-Widget statt Text-Widget für H2, H3. Formular-Labels immer anzeigen (nicht nur Platzhalter).

Bild-Widget: Alt-Text-Feld immer ausfüllen. Bei dekorativen Bildern das Alt-Feld leer lassen (Elementor setzt dann alt=""). Buttons: Beschreibenden Text verwenden statt nur „Hier klicken“ oder „Mehr erfahren“ – WCAG SC 2.4.4 (Linkzweck im Kontext).

Farben und Kontraste: Elementors Global Colors prüfen – viele vorgefertigte Farbschemata erfüllen den Mindestkontrast von 4,5:1 (WCAG SC 1.4.3) nicht. Nutze ein Tool wie den WebAIM Contrast Checker vor dem Festlegen der globalen Farben.

Skip-Navigation: Elementor setzt keinen Skip-Link. Füge manuell einen „Zum Inhalt springen“-Link als erstes Element nach <body> ein – oder nutze ein Plugin wie WP Accessibility.

Elementor-Alternativen mit besserer Barrierefreiheit

Wenn Barrierefreiheit Priorität hat, sind diese Alternativen einen Blick wert: Der WordPress Block Editor (Gutenberg) erzeugt sauberes semantisches HTML. Kadence Blocks hat expliziten Barrierefreiheits-Fokus. Und: GeneratePress mit GenerateBlocks generiert minimales, barrierefreies HTML.

Der Umstieg ist aufwendig, aber für BFSG-Konformität kann es der richtige Schritt sein. Besonders wenn du einen WooCommerce-Shop betreibst, lohnt sich die Investition in ein sauberes Fundament.

Führe als ersten Schritt einen kostenlosen BFSG-Scan durch, um zu sehen, wie groß der Handlungsbedarf tatsächlich ist.

Elementor-Barrierefreiheit testen: Schritt für Schritt

Ein systematischer Test-Workflow spart Zeit und deckt die meisten Probleme auf. Gehe für jede Elementor-Seite diese Schritte durch:

1. Automatisierter Scan: Starte mit einem BFSG-Schnellcheck, um die offensichtlichen Probleme zu finden – fehlende Alt-Texte, Kontrastverstöße, fehlende Labels.

2. Tastatur-Test: Navigiere die gesamte Seite nur mit der Tastatur (Tab, Shift+Tab, Enter, Escape, Pfeiltasten). Achte darauf, dass der Fokus immer sichtbar ist, die Reihenfolge logisch ist und kein Element den Fokus „einfangt“ (Keyboard Trap – verstößt gegen WCAG SC 2.1.2).

3. Screenreader-Test: Teste mit NVDA (kostenlos für Windows) oder VoiceOver (macOS/iOS). Navigiere über Landmarks, Überschriften und Links. Werden alle Inhalte korrekt vorgelesen? Sind interaktive Elemente verständlich angekündigt?

4. Heading-Audit: Nutze die Browser-Extension HeadingsMap oder den Elementor Navigator (Strg+I), um die Überschriften-Hierarchie zu prüfen. Keine Lücken, genau eine H1.

5. Mobil testen: Elementors Responsive-Modus ändert die DOM-Reihenfolge. Teste auf einem echten Gerät mit aktiviertem TalkBack (Android) oder VoiceOver (iOS), ob die Reihenfolge noch stimmt – gemäß WCAG SC 1.3.2 (Bedeutungsvolle Reihenfolge).

Hinweis: Dieser Artikel dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für die verbindliche Auslegung des BFSG und der zugehörigen BFSGV konsultiere bitte einen spezialisierten Rechtsanwalt. Stand: April 2026.

Häufig gestellte Fragen