Für eine Bundesgesellschaft haben wir eine Homepage mit Enfold aufgebaut. Nun werden hier sehr strenge Anforderungen an die Barrierefreiheit gestellt. Hier tauchen Fragen zum Verhalten der Menüs und eine generelle Frage zum Fokusverhalten auf:

1.: Auf unseren Seiten nutzen wir zwei nav-Elemente (Hauptmenü und Skymenü). Diese sind nicht programmatisch unterscheidbar (z. B. in einer Auflistung von Landmarks, wie sie viele Screenreader anbieten). Zur Behebung ist z. B. per aria-label eine Einordnung zu geben, um welche Navigation es sich genau handelt (Meta, Haupt, usw.)
2.: Für die Navigationen, inklusive der Hauptnavigation wurden die Rollen „menu“ und „menuitem“ verwendet. Diese Rollen lassen laut ARIA-Spezifikation nur bestimmte Kindrollen zu; aber nicht zum Beispiel „list“ (wie hier in der Hauptnavigation in „Untermenüpunkten“ zu finden). Dies ist ein Indikator, dass menu etc. nicht für listenbasierte Navigationen verwendet werden sollte, sondern vielmehr für den webbasierten „Nachbau“ von Betriebssystemmenüs gedacht ist (z. B. „Datei“, „Bearbeiten“ etc. in Webapplikationen).
3.: Auf Grundlage der Regeln für einblendbare Inhalte bei Mausdrüberfahren müssten Untermenüs in der Hauptnavigation per ESC-zu schließen sein, da sie ggf. Inhalte überdecken können.

4.: Im mobilen Menü sollte via aria-expanded der Zustand des folgenden Untermenü-Elements kommuniziert werden.
5.: Das mobile Menü erscheint im offenen Zustand wie ein modaler Dialog, ohne allerdings die nötigen Rollen und Zustandsbeschreibungen dafür zu besitzen. Dies kann mit dem<dialog>-Element, modal gestartet mit .showModal()gewährleistet werden.

6.: Fokushervorhebungen des Browsers sind allgemein mit outline: 0; unterdrückt, eine benutzerdefinierte Gestaltung fehlt. Entsprechend ist die aktuelle Position des Fokus für Nutzende nicht wahrnehmbar.

Haben Sie einen Hinweis für uns, wie wir die geforderten Eigenschaften in die Seite einbauen könnten?

Beste Grüße
Stephan Striewisch

We built the homepage for a federal company using Enfold. Now, very strict accessibility requirements are being set here. Questions arise about the behaviour of the menus and a general question about the focus behaviour:

1: On our pages, we use two nav elements (main menu and sky menu). These are not programmatically distinguishable (e.g. in a list of landmarks, as offered by many screen readers). To fix this, a classification can be given via aria-label, for example, to indicate exactly which navigation is involved (meta, main, etc.).
2: The roles ‘menu’ and ‘menuitem’ were used for the navigation, including the main navigation. According to the ARIA specification, these roles only allow certain child roles; but not, for example, ‘list’ (as can be found here in the main navigation in ‘submenu items’). This is an indicator that menu etc. should not be used for list-based navigations, but rather is intended for the web-based ‘replication’ of operating system menus (e.g. ‘File’, ‘Edit’ etc. in web applications).
3: Based on the rules for pop-up content when the mouse is moved over it, submenus in the main navigation should be closed using ESC, as they may cover up content.

4.: In the mobile menu, the state of the following submenu item should be communicated via aria-expanded.
5.: The mobile menu appears in the open state like a modal dialogue, but without the necessary roles and state descriptions. This can be ensured with the<dialog> element, started in modal fashion with .showModal().

6.: Browser focus highlighting is generally suppressed with outline: 0; a custom design is missing. Accordingly, the current position of the focus is not perceptible to users.

Do you have any advice for us on how we could incorporate the required attributes into the page?

Best regards,
Stephan Striewisch