Angie, Ki und Tenniel

Das war lange sehr aufwendig. Barrierefreie Navigationen mit Untermenüs brauchen semantisches HTML — verschachtelte Listen, richtig strukturiert —, dazu JavaScript mit komplexen Event-Listenern und ARIA-Zustände, die sich dynamisch aktualisieren müssen. Konkret bedeutet das: viel Code, viel Fehlerquelle, viel Pflegeaufwand. Aber das ändert sich gerade.

Die WHATWG hat sich etwas gedacht. Die Web Hypertext Application Technology Working Group, also das Gremium, das HTML als lebenden Standard weiterentwickelt,  hat erkannt: Manche UX-Elemente sind so universell, dass sie direkt in den Browser gehören. Nicht als Framework-Lösung, nicht als JavaScript-Workaround. Als natives HTML. Das <dialog>-Element war ein erster Schritt, <details> ein weiterer. Die Popover Api ist ein echter Meilenstein.

Popover-API und die Barrierefreiheit

Die Popover-API erlaubt es, Overlays, Tooltips und Menüs mit nur zwei HTML-Attributen, popovertarget und popover, umzusetzen – weitgehend ohne JavaScript. Seit 2024 gehört sie zum Baseline-Set, was bedeutet, dass sie in modernen Browsern (Chrome, Firefox, Safari, Edge) grundsätzlich unterstützt wird. Für die Navigation und vor allem für die Accessibility (Barrierefreiheit) ist das ein deutlicher Fortschritt.Doch Vorsicht: Die API nimmt uns zwar viel Arbeit ab, ist aber kein „Rundum-sorglos-Paket“. Gerade bei komplexen Strukturen wie einem Joomla-Menü muss man verstehen, was der Browser übernimmt und wo weiterhin eigene Umsetzung notwendig ist.

Was der Browser ünernimmt

Sobald Sie einen Button mit popovertarget versehen — der Wert zeigt auf die ID des Zielelements — und am Zielelement popover="auto" setzen, übernimmt der Browser. Das Untermenü erscheint automatisch im sogenannten Top Layer. Und damit nicht genug: Der Browser bringt drei Dinge gleich mit.

• Zustandsverwaltung: aria-expanded wird automatisch auf "true" oder "false" gesetzt, je nachdem ob das Element offen ist. Screenreader kündigen so korrekt „aufgeklappt" oder „zugeklappt" an — ohne dass Sie dafür eine Zeile JavaScript schreiben.
• Fokus Management: Öffnet ein Nutzer das Untermenü per Tastatur, landet der Fokus direkt auf dem ersten Link darin. Beim Schließen kehrt er automatisch zum auslösenden Button zurück.
• Top Layer Management: Das Zielelement wird in den Top Layer befördert. Konkret bedeutet das: kein z-index Chaos mehr. Das Menü liegt immer ganz oben, über allen anderen Elementen.

Barrierefreiheit: Wo wir selbst aktiv werden müssen

Die Popover API hat eine technische Besonderheit, die man kennen muss. Im sogenannten Accessibility Tree — also der Struktur, die Screenreader auslesen — verliert das Menü im Top Layer seinen ursprünglichen Kontext. Es schwebt quasi losgelöst von seiner Umgebung. Damit Nutzerinnen und Nutzer sich trotzdem zurechtfinden, sind vier manuelle Schritte entscheidend.

• Geben Sie dem Dropdown einen Namen. Auch wenn Button und Dropdown Liste semantisch korrekt in einer verschachtelten <ul> eingebunden sind, verliert die Dropdown Liste im Top Layer ihren Bezug zur übergeordneten Struktur. Ein aria-label, das den Bezug zum auslösenden Element herstellt, schafft Abhilfe. Der Unterschied ist spürbar: Ohne Label hört man „Liste, 2 Einträge" — wenig hilfreich. Mit Label: „Menü zu …, Liste, 2 Einträge". Kleiner Aufwand, großer Gewinn.
• Die Ankündigung: aria-haspopup. aria-expanded beschreibt den aktuellen Zustand — offen oder geschlossen. aria-haspopup="true" geht einen Schritt weiter: Es signalisiert, dass dieses Element ein Untermenü öffnen kann. Ohne dieses Attribut wirkt ein Button für Hilfstechnologien wie ein gewöhnlicher Link.
• Das <nav>-Element als Landmark. Screenreader Nutzerinnen und Nutzer navigieren Seiten oft über Sprungpunkte — sogenannte Landmarks. Damit die Navigation dabei überhaupt gefunden wird, gehört die gesamte Struktur in ein <nav>-Element mit einem aussagekräftigen Label. aria-label="Hauptnavigation" reicht dafür völlig aus.

Das Popover liegt im Top Layer — und das ist das Problem. Oberhalb aller anderen Ebenen gibt es keinen normalen Positionierungskontext mehr. position: absolute zum Elternelement funktioniert dort einfach nicht. CSS Anchor Positioning löst genau das. Der neue Ansatz: Ein Element , das Dropdown, richtet sich an einem anderen Element aus , dem auslösenden Button. Ganz ohne  JavaScript.

Konkret bedeutet das: Mit position-area definieren Sie die Position relativ zum sogenannten Anker. Für ein klassisches Dropdown, das unterhalb des Buttons erscheint und nach rechts ausgerichtet ist, sieht das so aus:

Beispiel:

 #mybutton { anchor-name: --mein-button; } 

.joomla-dropdown { position: absolute; position-anchor: --mein-button; position-area: bottom span-right; margin: 2rem 0 0 0; inset: auto; } 

Vorteile von Anchor Positioning

• Reduzierung klassischer z-index-Probleme
• Weniger Bedarf an JavaScript für Positionierungslogik
• Stärkere Bindung zwischen Auslöser und Ziel-Element

Fazit

Die Kombination aus Popover-API und CSS Anchor Positioning zeigt, wohin sich moderne Webentwicklung bewegt: Viele bisher komplexe Aufgaben wie Overlay-Logik und Positionierung werden zunehmend vom Browser übernommen oder standardisiert gelöst.

Dadurch entsteht weniger Bedarf an JavaScript für UI-Grundmechaniken und deutlich weniger Aufwand bei klassischen Problemen wie z-index-Stacking oder manueller Positionierungslogik.

Gleichzeitig bleibt Barrierefreiheit weiterhin ein aktiver Bestandteil der Entwicklung. Auch wenn die Popover-API einige Aspekte wie Fokus-Management und Zustandsdarstellung unterstützt, müssen semantische Struktur, ARIA-Attribute und sinnvolle Landmarken weiterhin bewusst gesetzt werden.

In Kombination ergibt sich damit ein moderner Ansatz: Die API und das Anchor Positioning übernehmen die technische Komplexität der Darstellung, während Entwickler die Verantwortung für saubere Semantik und Accessibility behalten.