Warum „leere Links“ in Elementor ein echtes Barrierefreiheits-Problem sind
Ein spannender Fall in einem Elementor-Blog-Widget:
Die Beitragsbilder sind klickbar. Der Accessibility-Check meldet: „Link ohne Text“.
Im Code stand:
<a class=“elementor-icon” href=”…”></a>
Kein Text. Kein aria-label Kein img. Nur ein Overlay-Link.
Für sehende Nutzer:innen kein Problem.
Für Screenreader: unbenutzbar.
Der Screenreader liest nur “Link” und Nutzende erhalten keinen Kontext. Man hört “Link” und weiß nicht, wohin der Link führt, noch was als Nächstes passiert. Öffnet der Link eine neue Seite oder ist es ein Download-Link?
Das eigentliche Problem
Viele Page-Builder arbeiten mit:
Overlay-Links
Background-Images statt <img>
dekorativen Icon-Containern
Das Ergebnis:
Ein <a>-Element ohne zugänglichen Namen.
Und das ist nach WCAG 2.1 ein klarer Verstoß gegen 2.4.4 Link Purpose (In Context).
Warum der Alt-Text hier nicht hilft
Das Bild war kein <img> im Link.
Sondern ein Background-Image.
Der Link selbst war leer.
Die Lösung
Der leere Overlay-Link bekommt ein dynamisches aria-label, z. B.:
<a class=“elementor-icon“
href=”…“
aria-label=“Beitrag lesen: Unterschied Wahrnehmung”>
</a>
Ergebnis:
Screenreader bekommen einen sinnvollen Namen
Keine Layout-Änderung
Keine Design-Einschränkung
Accessibility-Check bestanden
Was man daraus lernen kann
leeren Links
aria-hidden an falscher Stelle
dekorativen Containern mit Interaktion
Links zum Thema
Fazit
Wer mit Page-Buildern arbeitet, sollte nicht nur visuell denken, sondern strukturell.
Accessibility beginnt im DOM.
Nicht im Layout.
Bei amselrehhase entwickeln und prüfen wir barrierefreie Projekte. Buchen Sie uns für barrierefreie Kommunikationsmittel! Schreiben Sie uns eine E‑Mail!
amselrehhase | 20.01.2026
Vereinfachte Zusammenfassung
Leere Links sind ein Problem für den Screenreader und müssen im Code behoben werden. Eine Anleitung.
