@@Rolf B > Ganz wichtig finde ich, dass die Untermenüs kein `div` sind, sondern ebenfalls ein `ul`, und die Einträge darin `li`. Weil nur dann ein Screenreader daraus eine saubere Listenstruktur abliest. Nei-en. Ein Screenreader soll ja hier gar keine *Listen*struktur ablesen – genau dazu ist ja `role="tree"`/`"treeitem"`/`"group"` da: dass der Screenreader daraus eine *Baum*struktur abliest. Da macht es keinen Unterschied, ob die ursprüngliche Rolle von Elementen überschrieben oder einem Element eine Rolle gegeben wird, das vorher gar keine hatte. `ul`/`li` statt `div`/`div` ist natürlich trotzdem angebracht, ganz einfach weil die Menüstruktur eine verschachtelte Liste *ist*.   > Was mir zuerst nicht ganz klar war, ist dein aria-expanded am menu-button. Nach etwas Recherche habe ich aber gefunden, dass das ok ist, es fehlt aber was. Der Button selbst ist nicht expanded/collapsed, sondern der Menü-Baum. Deswegen musst Du dem Menü-Baum eine id geben und am Button mit aria-controls="id" angeben, welches Element expanded ist. [Aria-Controls is Poop.](http://www.heydonworks.com/article/aria-controls-is-poop) (in Heydons einzigartiger Ausdrucksweise) > Das ist etwas, das man gemäß W3C machen SOLL. WAI-ARIA Authoring Practices 1.1, [3.15 Menu Button](https://www.w3.org/TR/wai-aria-practices/#menubutton) spricht von *„optionally“*{:@en}. Es schadet aber nicht, wie auch Heydon im Abschnitt [Aria-Controls](https://inclusive-components.design/menus-menu-buttons/#ariacontrols) des *Inclusive-Components*{:@en}-Artikels „Menus & Menu Buttons“ sagt. Aber wichtiger ist wohl, dass der ein-/ausgeblendete Bereich dem zugehörigen Steuerelement (dem Button) unmittelbar folgt. Sagt auch Marco Zehe in [Easy ARIA Tip #5: aria-expanded and aria-controls](https://www.marcozehe.de/2010/02/10/easy-aria-tip-5-aria-expanded-and-aria-controls/).   > Wenn Du aria-controls nicht nutzen willst, dann müsstest Du das aria-expanded für die Submenüs auf die li Elemente legen. Den expanded-Zustand für den ganzen Baum würde ich auf das nav-Element legen, bin aber nicht sicher. Ich hätte gedacht, das `aria-expanded`-Attrbut gehört immer an das Steuerelement (den Button), nicht an den ein-/ausgeblendeten Bereich. Steht allerorts so zu lesen – außer in [WAI-ARIA 1.1](https://www.w3.org/TR/wai-aria-1.1/#aria-expanded) / [WAI-ARIA 1.2](https://www.w3.org/TR/wai-aria-1.2/#aria-expanded), wenn ich das richtig verstehe. Auch in [diesem Fall](https://github.com/zurb/foundation-sites/issues/11049) wurde das angekreidet. LLAP 🖖 -- *„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“* —Kurt Weidemann

@@Rolf B > Ganz wichtig finde ich, dass die Untermenüs kein `div` sind, sondern ebenfalls ein `ul`, und die Einträge darin `li`. Weil nur dann ein Screenreader daraus eine saubere Listenstruktur abliest. Nei-en. Ein Screenreader soll ja hier gar keine *Listen*struktur ablesen – genau dazu ist ja `role="tree"`/`"treeitem"`/`"group"` da: dass der Screenreader daraus eine *Baum*struktur abliest. Da macht es keinen Unterschied, ob die ursprüngliche Rolle von Elementen überschrieben oder einem Element eine Rolle gegeben wird, das vorher gar keine hatte. `ul`/`li` statt `div`/`div` ist natürlich trotzdem angebracht, ganz einfach weil die Menüstruktur eine verschachtelte Liste *ist*.   > Was mir zuerst nicht ganz klar war, ist dein aria-expanded am menu-button. Nach etwas Recherche habe ich aber gefunden, dass das ok ist, es fehlt aber was. Der Button selbst ist nicht expanded/collapsed, sondern der Menü-Baum. Deswegen musst Du dem Menü-Baum eine id geben und am Button mit aria-controls="id" angeben, welches Element expanded ist. [Aria-Controls is Poop.](http://www.heydonworks.com/article/aria-controls-is-poop) (in Heydons einzigartiger Ausdrucksweise) > Das ist etwas, das man gemäß W3C machen SOLL. WAI-ARIA Authoring Practices 1.1, [3.15 Menu Button](https://www.w3.org/TR/wai-aria-practices/#menubutton) spricht von *„optionally“*{:@en}. Es schadet aber nicht, wie auch Heydon im Abschnitt [Aria-Controls](https://inclusive-components.design/menus-menu-buttons/#ariacontrols) des *Inclusive-Components*{:@en}-Artikels „Menus & Menu Buttons“ sagt. Aber wichtiger ist wohl, dass der ein-/ausgeblendete Bereich dem zugehörigen Steuerelement (dem Button) unmittelbar folgt. Sagt auch Marco Zehe in [Easy ARIA Tip #5: aria-expanded and aria-controls](https://www.marcozehe.de/2010/02/10/easy-aria-tip-5-aria-expanded-and-aria-controls/).   > Wenn Du aria-controls nicht nutzen willst, dann müsstest Du das aria-expanded für die Submenüs auf die li Elemente legen. Den expanded-Zustand für den ganzen Baum würde ich auf das nav-Element legen, bin aber nicht sicher. Ich hätte gedacht, das `aria-expanded`-Attrbut gehört immer an das Steuerelement (den Button), nicht an den ein-/ausgeblendeten Bereich. Steht allerorts so zu lesen – außer in [WAI-ARIA 1.2](https://www.w3.org/TR/wai-aria-1.2/#aria-expanded), wenn ich das richtig verstehe. Auch in [diesem Fall](https://github.com/zurb/foundation-sites/issues/11049) wurde das angekreidet. LLAP 🖖 -- *„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“* —Kurt Weidemann

@@Rolf B > Ganz wichtig finde ich, dass die Untermenüs kein `div` sind, sondern ebenfalls ein `ul`, und die Einträge darin `li`. Weil nur dann ein Screenreader daraus eine saubere Listenstruktur abliest. Nei-en. Ein Screenreader soll ja hier gar keine *Listen*struktur ablesen – genau dazu ist ja `role="tree"`/`"treeitem"`/`"group"` da: dass der Screenreader daraus eine *Baum*struktur abliest. Da macht es keinen Unterschied, ob die ursprüngliche Rolle von Elementen überschrieben oder einem Element eine Rolle gegeben wird, das vorher gar keine hatte. `ul`/`li` statt `div`/`div` ist natürlich trotzdem angebracht, ganz einfach weil die Menüstruktur eine verschachtelte Liste *ist*.   > Was mir zuerst nicht ganz klar war, ist dein aria-expanded am menu-button. Nach etwas Recherche habe ich aber gefunden, dass das ok ist, es fehlt aber was. Der Button selbst ist nicht expanded/collapsed, sondern der Menü-Baum. Deswegen musst Du dem Menü-Baum eine id geben und am Button mit aria-controls="id" angeben, welches Element expanded ist. [Aria-Controls is Poop.](http://www.heydonworks.com/article/aria-controls-is-poop) (in Heydons einzigartiger Ausdrucksweise) > Das ist etwas, das man gemäß W3C machen SOLL. WAI-ARIA Authoring Practices 1.1, [3.15 Menu Button](https://www.w3.org/TR/wai-aria-practices/#menubutton) spricht von *„optionally“*{:@en}. Es schadet aber nicht, wie auch Heydon im Abschnitt [Aria-Controls](https://inclusive-components.design/menus-menu-buttons/#ariacontrols) des *Inclusive-Components*{:@en}-Artikels „Menus & Menu Buttons“ sagt. Aber wichtiger ist wohl, dass der ein-/ausgeblendete Bereich dem zugehörigen Steuerelement (dem Button) unmittelbar folgt. Sagt auch Marco Zehe in [Easy ARIA Tip #5: aria-expanded and aria-controls](https://www.marcozehe.de/2010/02/10/easy-aria-tip-5-aria-expanded-and-aria-controls/).   > Wenn Du aria-controls nicht nutzen willst, dann müsstest Du das aria-expanded für die Submenüs auf die li Elemente legen. Den expanded-Zustand für den ganzen Baum würde ich auf das nav-Element legen, bin aber nicht sicher. Ich hätte gedacht, das `aria-expanded`-Attrbut gehört immer an das Steuerelement (den Button), nicht an den ein-/ausgeblendeten Bereich. Steht allerorts so zu lesen – außer in [WAI-ARIA 1.1](https://www.w3.org/TR/wai-aria-1.1/#aria-expanded), wenn ich das richtig verstehe. Auch in [diesem Fall](https://github.com/zurb/foundation-sites/issues/11049) wurde das angekreidet. LLAP 🖖 -- *„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“* —Kurt Weidemann