BIK-BITV / BIK-Web-Test

Testverfahren zur Prüfung der Barrierefeiheit von Webanwendungen anhand der Kriterien der WCAG 2.1, EN 301 549 und BITV 2.0
67 stars 21 forks source link

9.1.3.1b HTML-Strukturelemente für Listen vs. role="menu" #447

Open ThomKoeh opened 6 days ago

ThomKoeh commented 6 days ago

Hallo zusammen, habe Fragen bezüglich Navigationsmenüs. Es heißt ja, dass Menüs mit Listen umgesetzt werden sollen. Wie ist es denn prinzipiell, wenn Menüs, mit role="menu" ausgezeichnet sind? Der ARIA Authoring Practices Guide (APG) warnt ja davor, da hier die Bedienung mit den Peiltasten, der Escape-Taste, usw. nach dem entsprechenden Schema, wie es im APG implementiert ist, gegeben sein muss. Viele Kunden setzen die Rollen menu bzw. menuitem auch, wenn die Bedienung zum Beispiel mit der Tabulatortaste funktioniert. Die Listensemantik wird hier dann allerdings überschrieben. Wie ist so etwas denn zu bewerten? Sollen eher verschachtelte Listen verwendet und die Menü-Rollen entfernt werden, wenn die Bedienung nicht der im APG entspricht, oder ist so etwas akzeptierbar? Wie verhält es sich denn bei komplexen Menüs von Webanwendungen, die viele Unterstrukturen beinhalten können? Freue mich auf Eure Einschätzungen.

stefanFarnetani commented 6 days ago

Hallo @ThomKoeh

Website-Navigationen und ARIA menu sind völlig unterschiedliche semantische Elemente.

Klassische Webseiten Navigationen (ungleich ARIA menu) basieren auf Listen mit Links. Also sowas in etw.:

<nav aria-label="Bezeichnung">
   <ul>
      <li>
         <a href="...">Navigationspunkt</a>
      </li>
      ...
   </ul>
</nav>

Nur bei Navigationen sollen Listen verwendet werden. Das ist aber mehr eine starke Empfehlung. Das Fehlen von Listen in Navigationen ist nicht automatisch ein Fehler. Wenn die Navigation sehr klein ist. Nur vier Punkte und ein Nav-Tag darum liegt sind auch vier Links ausreichend.

ARIA menu benötigen in etwa folgenden Aufbau.

<div` role="menu">
   <button role="menuitem">Menüeintrag 1</button>
   <a role="menuitem" href="...">Menüeintrag 2</a>
   ...
</div>

Die Umsetzung von ARIA menu als HTML-Liste, die dann mittels ARIA role="menu" überformt. Ist meist unnötig. Wenn die Überformung richtig gemacht wurde, bleibt von der Liste nichts übrig. Das steht zwar im HTML-Code, aber im accessibiltiy tree steht nur noch ein, hoffentlich korrektes ARIA menu. Wichtig ist zu verstehen, dass menuitem die Aktion direkt auslöst. menuitem ist nicht der container für ein button oder link. Das ist der häufige Denkfehler, wenn ein Vergleich zu Navigationen mit Listen gezogen wird.

Ob Website Navigationen und ARIA Menu ungesetzt werden hängt vom Kontext ab. ARIA Menu dürfen nur verwendet werden, wenn eine applikationsähnliches Menü umgesetzt werden soll. Der Einsatz auf "normalen" Websites ist so gut wie nie sinnvoll.

Erst bei Webanwendungen kann man überhaupt darüber nachdenken. Ist die Anwendung eher simpel wie z.B. goole drive (Dateiverwaltung) würde ich davon absehen. Es wäre aber kein Fehler. Um so mehr die Webanwendung in Richtung google word geht, desto gerechtfertigter ist die Anwendung von ARIA menu.

Die Steuerung von ARIA menu mittels Pfeiltasten ist es kein Kriterium um zu entscheiden, ob das Element korrekt als ARIA menu oder Website Navigation umzusetzen wäre. Das hängt eher von den oben genannten Kontext ab. Normale Website oder nicht. Starker Anwendungscharakter oder nicht.

ThomKoeh commented 5 days ago

Hallo @stefanFarnetani,

danke für die Antwort! Das hat sehr geholfen. Ich verstehe jetzt wann eher eine Liste und wann eher ein ARIA menu verwendet wird.

Hab jetzt noch eine konkrete Frage zur Bedienung. Muss, wenn ein ARIA menu verwendet wird, die Bedienung wie im ARIA APG gegeben sein oder kann hier auch eine andere, funktionierende Art der Bedienung verwendet werden, wenn alle Attribute korrekt gesetzt sind?

Ganz konkret geht es um ein Menü einer Webanwendung eines Kunden. Hier wird Listensemantik verwendet, die allerdings mit role="none" auf den Listitems entfernt wird. Das wäre ja korrekt, denn die Bedienelemente selbst weisen die Rolle menuitem auf. Die Liste selbst (ul-Tag) ist mit role="menubar" ausgezeichnet. Jedoch ist das Menü ausschließlich mit der Tabulatortaste bedienbar. Das Menü ist in der Standardansicht vertikal und responsiv horizontal angeordnet.

stefanFarnetani commented 5 days ago

Hallo @ThomKoeh

Es ist ein Diskussionspunkt. Es ist nicht 100% geklärt, ob die Navigations-Pattern (Pfeiltasten) absolut verpflichtend sind. In der WAI ARIA steht bei dem Attribute für menu und menubar "Author should handle ...". Das gibt Raum für Interpretationen,

Was aber ganz klar dafür spricht, dass mit ARIA Menu auch immer die Pfeiltasten-Steuerung implementiert werden soll:

Meine Linie ist: Wer ARIA menu nutzt, muss sie komplett implementieren. Nur in wirklich begründeten Ausnahmen akzeptiere ich ein ARIA menu ohne Pfeiltesten-Steuerung. Diese Ausnahme ist für mich so selten, dass mir gerade nicht mal ein Beispiel einfällt.

MarcHaunschild commented 5 days ago

Hallo @ThomKoeh,

kurz: empfehle ihnen das ARIA raus zu nehmen und sich an die Beispiele der WCAG zu halten (im Link Example5).

Alles andere ist unnötiger Aufwand.

https://www.w3.org/WAI/WCAG21/Techniques/html/H48.html#examples

Ansonsten halte ich es mit @stefanFarnetani : wenn man selber etwas baut, sollte es auch korrekt funktionieren. Aber noch mal: nicht selber bauen!

Zur Bewertung: der Test fordert für Menüs Listen, nciht für Navigationen. Das sind unterschiedliche Dinge. Ein Menü stellt Optionen bereit, eine Navigation Verweise auf andere Ressourcen.

stefanFarnetani commented 5 days ago

Hallo @MarcHaunschild Du hast natürlich für normale Seiten recht. Ich will nur nochmal hervorheben, dass @ThomKoeh geschrieben hat, dass es sich um eine Webanwendung handelt. Ohne die Anwendung gesehen zu haben, kann man meiner Meinung nach nicht pauschal sagen, dass sie keine ARIA menu verwenden sollen. Von weitem kann man nur sagen, dass man sich für ein Konzept entscheiden muss und dass dann konsequent umsetzten muss.

Hallo @ThomKoeh,

kurz: empfehle ihnen das ARIA raus zu nehmen und sich an die Beispiele der WCAG zu halten (im Link Example5).

Alles andere ist unnötiger Aufwand.

https://www.w3.org/WAI/WCAG21/Techniques/html/H48.html#examples

Ansonsten halte ich es mit @stefanFarnetani : wenn man selber etwas baut, sollte es auch korrekt funktionieren. Aber noch mal: nicht selber bauen!

Zur Bewertung: der Test fordert für Menüs Listen, nciht für Navigationen. Das sind unterschiedliche Dinge. Ein Menü stellt Optionen bereit, eine Navigation Verweise auf andere Ressourcen.

MarcHaunschild commented 5 days ago

Du hast natürlich recht, @stefanFarnetani. Mir klang es nach "Navigation". Aber ohne mehr Infos ist das nur eine Annahme, die falsch sein kann. Gerade im Kontext einer Anwendung!

pkra commented 5 days ago

Adrian Roselli hat einen guten Artikel (auf Englisch) über die Probleme rund um den Begriff "Menu" https://adrianroselli.com/2023/05/be-careful-using-menu.html

ThomKoeh commented 5 days ago

Vielen Dank Euch!

Das ist echt verzwickt. Vor allem, weil das Menü in der nicht gezoomten Ansicht von oben nach unten angeordnet ist. Wäre es hier sinnvoll, die Hauptmenüpunkte mit Pfeiltaste nach rechts aufzuklappen und mit Pfeiltaste nach unten den nächsten Hauptmenüpunkt erreichbar zu machen? Das wäre für sehende Nutzende der Tastatur schlüssiger, jedoch stoßen hier eventuell blinde Nutzende auf Probleme. Das aria-orientation Attribut wird anscheinend aktuell von NVDA nicht ausgegeben.

Prinzipiell bin ich auch der Meinung, dass, wenn ein ARIA-Menü verwendet wird, auch die Bedienung mit den Pfeiltasten usw., wie im APG beschrieben, funktionieren sollte.

MarcHaunschild commented 5 days ago

@ThomKoeh - ist es denn ein Menü oder eine Hauptnavigation oder (worst case) eine Mischung aus beidem?

Erst wenn das geklärt ist, kann man etwas konkreteres sagen.

ThomKoeh commented 5 days ago

@MarcHaunschild - Tatsächlich ist es eine Mischung aus beidem. Es ist beispielsweise sowohl ein Link zum Dashboard als auch ein Bereich für Tools (zum Beispiel die Ordnerstruktur des Email-Clients mit Posteingang, Papierkorb, usw.) vorhanden.

MarcHaunschild commented 5 days ago

Dann wäre es mir zu kompliziert und zu sehr stochern im Nebel, um hier noch Empfehlungen zu geben. Nur ein Anhaltspunkt: wenn wir eine Hauptnavigation haben, in der ein Eintrag gleichzeitig Button ist (öffnet Unterpunkte) und Link (führt zu einer anderen Seite), werten wir das eigentlich ab.

Ich will jetzt nicht zu viel sagen, aber ich finde, eine Container kann entweder ein Menü oder eine Navigation beinhalten. Beides bekommt man weder als Entwickler, noch als Desinger, noch als Nutzer geistig unter einen Hut. Das verwirrt und führt zu Mist... - meine 2 Cent

Aber je komplexer das Problem erscheint desto weniger möchte ich das als klares Statement verstanden wissen. Für mehr müsste ich es mir ansehen.

johannesFischer84 commented 3 days ago

Hab jetzt noch eine konkrete Frage zur Bedienung. Muss, wenn ein ARIA menu verwendet wird, die Bedienung wie im ARIA APG gegeben sein oder kann hier auch eine andere, funktionierende Art der Bedienung verwendet werden, wenn alle Attribute korrekt gesetzt sind?

Vieles wurde schon gesagt und auch auf die von mir zitierte Frage ist Stefan / @stefanFarnetani schon sehr gut eingegangen. Ich möchte dazu noch dies ergänzen:

Der ARIA Authoring Practices Guide ist nicht normativ. Das kann man in der APG Introduction in einem Unterabschnitt nachlesen. Damit sind die dort vorgestellten Beispiele nicht verpflichtend, sondern nur als gute Anregung oder als eine von mehreren Möglichkeiten zu verstehen. Als Empfehlung/Hinweis für Webentwickler kann man die Beispiele dort meiner Meinung nach aber gut weitergeben.

Wenn ARIA-Attribute verwendet werden bzw. wenn HTML nicht die erforderliche Semantik bietet, dann wäre die WAI-ARIA-Spezifikation verpflichtend anzuwenden für Bedienelemente (WCAG-Kriterium 4.1.2, für Menü zutreffend) oder für statische Dokumentstruktur (WCAG-Kriterium 1.3.1). Man sollte also dort nachlesen, was tatsächlich gefordert ist. Wie Stefan beschrieben hat, steht dort aber nicht immer ein MUST/REQUIRED/SHALL, sodass man z. B. bei SHOULD Spielraum hat. Die Erklärung für die Begriffe MUST usw. ist im Conformance-Bereich der ARIA-Spezifikation verlinkt.

Eine Bewertung, ob WCAG-Konformität gegeben ist, ist aus meiner Sicht auch sehr auf den Einzelfall bezogen, wo man sich die Details ansehen und mit den Forderungen der ARIA-Spezifikation abgleichen müsste. Eine Verallgemeinerung scheint mir da nicht gut möglich.