Architecture Decision Record · 0027

SOLCOM Navigation: Dropdown-Erweiterung — WAI-ARIA Disclosure Navigation (WCAG 2.1 AA)

TL;DR — ADR-0008's Single-Level-Constraint wird aufgehoben. Top-Level-Items mit Kindern werden zu <button aria-expanded>-Toggles (WAI-ARIA Disclosure Navigation Pattern). 2 Ebenen max, WCAG 2.1 AA, Mobile als Accordion im Hamburger-Overlay. Sub-Items rendern via .solcom-nav-sub-link mit CSS-Arrow. Nur Dark-Variante.

Kontext

ADR-0008 hat menu--main.html.twig explizit als Single-Level-Template implementiert. Der Kommentar lautete: „Submenus are not modelled in the SOLCOM Figma — the template is single-level on purpose."

Das neue Figma-Design für P2503-84 (figma.com/design/CHHDfbpX8Ys2LBiGs5HVK0, Node 61148:47024 „Navigation >1280" + Mobile-Frames) zeigt eindeutig Dropdown-Flyouts:

Eine Grilling-Session am 2026-05-13 hat alle Architekturentscheidungen für P2503-84 systematisch geklärt. Dieses ADR dokumentiert die Ergebnisse.

i
ADR-0008 bleibt accepted — das Navbar-SDC-Schema (logo/navigation/links-Slots), .solcom-btn-link-Reuse, links-Slot mit Account-Menü und Sprachschalter sowie die Kernel-Tests in HeaderTemplatesTest.php bleiben unverändert gültig. Nur der Single-Level-Constraint wird durch dieses ADR aufgehoben.

Entscheidung

WAI-ARIA Disclosure Navigation Pattern als einziges Dropdown-Pattern für die SOLCOM-Hauptnavigation. Konkret:

Rejected alternatives

Expand each rejected option to see the rationale.

Light-Variante (ivory BG) jetzt implementieren rejected

Light-Variante ist Out of Scope für P2503-84. Kein konkreter Anwendungsfall mit Figma-Spec bekannt. Ein neuer Color-Prop am Navbar-SDC-Schema würde Canvas-Config-Overhead erzeugen, ohne aktuellen Mehrwert. Bei Bedarf eigener ADR.

3-Ebenen-Navigation (nested Dropdowns) rejected

Das Figma zeigt ausschließlich 2 Ebenen. Der Macbook-Screenshot zeigt eine flache Flyout-Liste ohne Sub-Kategorien. 3. Ebene wäre rekursives Twig oder separates Template-Include — deutlich mehr Komplexität ohne Figma-Grundlage. Bei Bedarf neuer ADR.

<details>/<summary> als Disclosure-Mechanismus rejected

Natives HTML, kein JS nötig — aber: <details> schließt nicht automatisch bei Klick außerhalb des Elements. Das ist Standard-UX für Dropdowns und WCAG-erwartet. Außerdem eingeschränkte Animierbarkeit für Open/Close-Transitions. navbar.js hat bereits einen Toggle-Mechanismus (Hamburger) — den zu erweitern ist konsistenter als zwei parallele Mechanismen.

Split-Button (Link + separater Toggle-Button) für Top-Level-Items rejected

Zwei Interaktionspunkte pro Top-Level-Item erhöhen die kognitive Last und sind ein bekanntes Antipattern (WCAG 2.5.3: Label in Name). Das Figma zeigt keine separaten Parent-URLs für Dropdown-Items — Parent-Items sind reine Strukturgeber. Option A (reiner Toggle-Button) ist sauberer.

Separates Slide-in-Panel für Mobile (statt Accordion) rejected

Der Figma-Prototyp (Node 61232:65907 „Mobile Nav - Prototyp") zeigt Accordion-Expansion im bestehenden Overlay — kein neues Panel. Slide-in-Panel erfordert zusätzlichen JS-Overhead und würde den bestehenden Hamburger-Mechanismus komplexer machen, ohne Figma-Grundlage.

byte_theme:button-link-Include für Sub-Items rejected

Bereits in ADR-0008 für Top-Level-Items abgelehnt — gleiche Begründung gilt für Sub-Items: byte_theme:button-link kennt keine Drupal-Menü-Semantik (in_active_trail, item.attributes). Direkter Klassen-Reuse via .solcom-nav-sub-link (CSS-Only, ::before-Arrow) ist besser. Kein SDC-Include-Overhead.

ARIA Menubar Pattern (role="menubar", Arrow-Key-Navigation) rejected

Das WAI-ARIA Menubar-Pattern ist für Application-Menus gedacht (Datei → Speichern), nicht für Website-Navigation. Es erfordert komplexe Arrow-Key-Behandlung (/ wechselt Top-Level-Items, / navigiert Sub-Items) und ist für Screen-Reader-Nutzer weniger intuitiv auf Navigation-Sites als das einfachere Disclosure-Pattern. WAI-ARIA Authoring Practices Guide empfiehlt Disclosure Navigation für Site-Navs ausdrücklich.

Consequences