Product Requirements Document

Navigation: Dropdown-Disclosure-Pattern (WCAG 2.1 AA)

approved P2503-84 Parent: P2503-81 Theme
TL;DR — Die SOLCOM-Hauptnavigation erhält Dropdown-Flyouts. Top-Level-Items mit Kindern werden zu WAI-ARIA Disclosure Buttons; Sub-Items zu barrierefreien Link-Listen. Nur Dark-Variante; 2 Ebenen max; Mobile als Accordion. Grounding: Figma-Node 61148:47024 (P2503-84), ADR-0027.

Problem Statement

Nutzer auf solcom.de können nicht erkennen, welche Unterseiten sich hinter den vier Top-Level-Navigationspunkten verbergen. Die aktuelle Hauptnavigation ist flach (Single-Level) — es gibt keine Möglichkeit, direkt aus der Navigation heraus auf eine Unterseite zu springen, ohne die URL zu kennen. Das zwingt Nutzer zu unnötigem Raten oder zur Nutzung der Suche.

Gleichzeitig schließt die aktuelle Implementierung Screenreader- und Keyboard-Nutzer strukturell aus: es gibt keinen maschinenlesbaren Hinweis auf Unterpunkte, keine Keyboard-Navigation in Untermenüs, keine ARIA-States für geöffnete/geschlossene Zustände.

Solution

Erweiterung der bestehenden byte_theme:navbar-SDC um ein 2-stufiges Dropdown-System nach dem WAI-ARIA Disclosure Navigation Pattern:

i
Nur Dark-Variante (navy BG). Light-Variante ist Out of Scope. Das byte_theme:navbar-Schema (Slots logo/navigation/links) bleibt unverändert — nur menu--main.html.twig, CSS und navbar.js werden erweitert.

User Stories

  1. Als Sitebesucher möchte ich beim Klicken auf einen Top-Level-Navigationspunkt eine Liste der Unterseiten sehen, damit ich direkt zu dem Inhalt navigieren kann, den ich suche.
  2. Als Sitebesucher möchte ich erkennen, welche Navigationspunkte Unterseiten haben (Chevron-Indikator), damit ich nicht planlos auf alle Items klicke.
  3. Als Sitebesucher möchte ich, dass ein offenes Dropdown automatisch schließt, wenn ich außerhalb davon klicke, damit meine Arbeitsfläche nicht unnötig verdeckt wird.
  4. Als Sitebesucher möchte ich, dass immer nur ein Dropdown gleichzeitig offen ist, damit die Navigation übersichtlich bleibt.
  5. Als Keyboard-Nutzer möchte ich ein Dropdown mit Enter oder Leertaste öffnen und schließen, damit ich die Navigation ohne Maus benutzen kann.
  6. Als Keyboard-Nutzer möchte ich ein offenes Dropdown mit Escape schließen und den Fokus zurück auf den Trigger-Button erhalten, damit ich meinen Navigationsfluss nicht verliere.
  7. Als Keyboard-Nutzer möchte ich mit Tab durch die geöffneten Sub-Items navigieren, damit ich alle Optionen erreichen kann.
  8. Als Screenreader-Nutzer möchte ich hören, ob ein Navigationspunkt ein Untermenü hat und ob dieses geöffnet oder geschlossen ist (aria-expanded), damit ich die Struktur der Navigation verstehe.
  9. Als Screenreader-Nutzer möchte ich auf dem aktiven Sub-Link aria-current="page" hören, damit ich weiß, auf welcher Seite ich mich befinde.
  10. Als mobiler Nutzer möchte ich im Hamburger-Menü auf einen Hauptpunkt tippen und die Unterseiten direkt darunter aufklappen sehen (Accordion), damit ich nicht in ein weiteres Panel wechseln muss.
  11. Als mobiler Nutzer möchte ich ein aufgeklapptes Accordion durch erneutes Tippen auf den Hauptpunkt wieder schließen, damit die Navigation kompakt bleibt.
  12. Als Nutzer auf einer Unterseite möchte ich im aktiven Parent-Button visuell erkennen, in welchem Hauptbereich ich mich befinde (Active-Trail-Underline), damit ich meinen Kontext nicht verliere.
  13. Als Nutzer möchte ich auf einen Sub-Link klicken und direkt auf die entsprechende Seite navigiert werden, damit die Navigation intuitiv funktioniert.
  14. Als Redakteur möchte ich Untermenü-Punkte einfach über das Drupal-Menü-Interface (/admin/structure/menu/manage/main) anlegen und hierarchisch einordnen, damit ich keine Entwicklerunterstützung für Menü-Änderungen brauche.

Implementation Decisions

Disclosure Navigation Pattern (nicht ARIA Menubar)

Das WAI-ARIA Disclosure Navigation Pattern wird gegenüber dem ARIA Menubar Pattern bevorzugt. Disclosure ist für Site-Navigation geeignet, erfordert keine Arrow-Key-Behandlung zwischen Top-Level-Items und ist für Screenreader-Nutzer auf Navigation-Sites intuitiver. Quellen: WAI-ARIA Authoring Practices Guide. Entscheidung dokumentiert in ADR-0027.

Template-Erweiterung: menu--main.html.twig

Das bestehende Template wird um item.below-Rendering erweitert. Conditional auf item.below: wenn Kinder vorhanden, <button aria-expanded> mit aria-controls statt <a>. Drupal-Menü-Semantik (in_active_trail, item.attributes) bleibt vollständig erhalten. Maximale Tiefe: 2 Ebenen — 3. Ebene wird nicht gerendert.

Neue CSS-Klasse: .solcom-nav-sub-link

Eigene CSS-Klasse für zweite Navigationsebene. Differenzierung zu .solcom-btn-link: führender Lime-Arrow via ::before-Pseudo-Element. Kein byte_theme:button-link-Include — Drupal-Menü-Semantik bleibt erhalten, kein SDC-Overhead. Zu definieren in src/main.css.

JavaScript: navbar.js-Erweiterung

Bestehender Hamburger-Toggle bleibt unverändert. Neue Mechanismen:

WCAG 2.1 AA — Pflicht-Attribute

Active-Trail

solcom-btn-link--active-trail-Modifier auch auf Parent-<button>, wenn item.in_active_trail true. Konsistent mit dem bestehenden Underline-Pattern aus ADR-0008. aria-current="page" kommt ausschließlich auf den aktiven Sub-<a>-Link.

Flyout-Panel-Styling

Absolut positioniertes Panel unterhalb des Trigger-Buttons. White Background, Rounded Corners, Shadow. Sichtbarkeit via CSS-Klasse, gesteuert durch JS (nicht via display:none — für Transitions). Nur Dark-Navbar-Kontext.

Navbar-SDC-Schema bleibt unverändert

Das byte_theme:navbar-Schema (logo/navigation/links-Slots, menu_align-Prop) wird nicht geändert. Cherry-Pick-Kompatibilität zum Upstream-Byte-Theme bleibt erhalten (ADR-0008-Prinzip).

Testing Decisions

Was ein guter Test ist

Tests prüfen das externe Verhalten des gerenderten HTML — nicht den Twig-Code selbst. Ein Test beschreibt einen Contract: „Wenn das Menu ein Item mit Kindern enthält, MUSS das gerenderte Markup einen <button aria-expanded> enthalten, kein <a>." Tests sind unabhängig von CSS-Klassen-Implementierungsdetails und JS-Interaktionen.

Zu testende Module

Nicht getestet: JS-Interaktion (navbar.js), CSS-Animation, visuelle Darstellung. Diese können optional als Playwright E2E-Tests ergänzt werden (WCAG 2.1 AA Keyboard-Navigation), sind aber nicht Pflicht für den initialen PR.

Out of Scope

Further Notes