Ich erinnere mich noch an meine Aufregung, als ich lernte, ein durch Hover ausgelöstes Untermenü nur mit CSS zu erstellen. (Wahrscheinlich nachdem ich diesen Artikel von A List Apart aus dem Jahr 2003 gelesen hatte.) Damals war es ein echter CSS-Trick. Ernsthaft. Wilde Zeiten.
Das sah ungefähr so aus
<ul class="my-menu">
<li>
<a href="page-a.html">Page A</a>
<ul>
<li><a href="page-b.html">Page B</a></li>
<li><a href="page-c.html">Page C</a></li>
<li><a href="page-d.html">Page D</a></li>
</ul>
</li>
<!-- etc... -->
</ul>
/* Position submenus relative to parent list item */
.my-menu li {
position: relative;
}
.my-menu ul {
/* Hide my submenus by default */
display: none;
/* Position submenus, when open */
position: absolute;
left: 0;
top: 100%;
}
/* Look, Ma! No onclick handler! */
.my-menu li:hover > ul {
display: block;
}
Heutzutage können wir die Barrierefreiheit von rein CSS-basierten Menüs mit einem neueren Trick verbessern! Menüs können sich öffnen und schließen, wenn sie mit der Tastatur navigiert werden, dank :focus-within.
/* No IE11 support */
.my-menu li:focus-within > ul {
display: block;
}
Versuchen Sie, sowohl Ihre Maus als auch die TAB-Taste zu verwenden, um durch die Demo zu navigieren.
Aber die Zeiten haben sich seitdem ich diese Tricks zum ersten Mal gelernt habe, geändert, und ich mich auch. Seitdem habe ich eine Menge Websites erstellt und viel mehr über Benutzerfreundlichkeit, Barrierefreiheit und Content-Strategie gelernt. Jetzt finde ich Hover-Menüs in all diesen Bereichen mangelhaft. Vor ein paar Jahren habe ich aufgehört, Hover-Menüs zu erstellen und bin zu Klick-Menüs übergegangen. (Von nun an werde ich sie nur noch „Hover-Menüs“ und „Klick-Menüs“ nennen.)
Ich denke, Sie sollten auch aufhören, Hover-Menüs zu erstellen. Ich bin hier, um Ihnen zu sagen, warum.
Hover-Menüs sind inkonsistent
Werfen Sie einen Blick auf dieses reale Menü von einer Website, die ich erstellt habe

Einfach genug, oder? Die Pfeil-Icons zeigen uns, dass es Untermenüs für jeden Punkt außer „Home“ gibt. Aber wenn diese Untermenüs beim Überfahren mit der Maus erscheinen, gibt es mindestens vier Möglichkeiten, wie das Menü funktionieren könnte, und Sie haben wahrscheinlich alle vier erlebt.
- Der obere „Eltern“-Menüpunkt verlinkt zu einer Seite und jeder Untermenüpunkt verlinkt zu einer anderen Seite. Für das obige Beispiel wäre „Services“ eine eindeutige Seite und ebenso jeder Link im „Services“-Untermenü.
Aber irgendwo auf dem Weg entstand ein zweites, sehr gängiges Muster.
- Der Elternpunkt hat
href="#"— oder gar keinenhrefüberhaupt 😱 — und die einzigen funktionalen Links befinden sich in den Untermenüs. In unserem Beispiel ist „Services“ immer noch ein Link, aber es passiert nichts, wenn Sie darauf klicken.
Diese Inkonsistenz — ist der Elternpunkt ein Link oder nicht? — führt zu viel Verwirrung, wenn ich beobachte, wie Leute Websites nutzen. Manche Leute überspringen hilfreiche Top-Level-Seiten, weil sie davon ausgehen, dass diese Punkte keine Links sind. Wieder andere gehen davon aus, dass die Top-Level-Links Seiten sind und versuchen, sie anzuklicken.
Dies führt zu den dritten und vierten nicht so tollen Mustern, denen Sie begegnen werden. Ich vermute, dass diese aus Versuchen entstanden sind, die Verwirrung zu kompensieren, die durch die ersten beiden Setups verursacht wurde.
- Der Elternpunkt und der erste Untermenüpunkt verlinken zur selben Seite. Was die Sache noch schlimmer macht, ist, dass die Links des Elternpunkts und die Links des ersten Untermenüs unterschiedliche Link-Texte haben, was gegen einen WCAG 2.1 Level AA Barrierefreiheitsstandard verstößt.
- Der Elternpunkt verlinkt zu einer Seite, die nutzlosen Füllinhalt oder nur die Links im Untermenü enthält. Die Seite selbst hat keinen wirklichen Zweck für jemanden, der sie besucht.
Diese letzten beiden Konfigurationen verschwenden Zeit für Leute, die wissen, dass die Elternpunkte Links mit redundantem oder nutzlosem Inhalt sind.
Hier ist ein Diagramm, das alle vier möglichen Hover-Menü-Setups zeigt.

Besucher sind durch Hover-Menüs vernünftigerweise verwirrt
Unabhängig davon, wie wir Hover-Menüs implementieren, können sich unsere Besucher vernünftigerweise fragen:
- Kann ich die Elternpunkte anklicken?
- Wird der Elternpunkt ein Link zur selben Seite sein wie der erste Untermenülink?
- Auch wenn der Elternpunkt ein eindeutiger Link ist, lohnt es sich, ihn anzusehen?
Das lässt uns ohne gute Optionen zurück. Es macht es unmöglich, Jakobs Gesetz der Benutzerfreundlichkeit zu erfüllen, das besagt, dass „Benutzer bevorzugen, dass Ihre Website genauso funktioniert wie alle anderen Websites, die sie bereits kennen“. Es gibt keine Standardimplementierung bei Hover-Menüs, daher müssen wir etwas anderes tun, um eine konsistente Benutzererfahrung zu bieten.
Was ist mit „Split Button“-Menüs?
Wahrscheinlich der am wenigsten verbreitete Menütyp, den ich sehe, verwendet ein „Split Button“-Design, bei dem der Elternpunkt ein Link ist und ein separates Dropdown-Symbol das Menü öffnet und schließt. Das Standard-WordPress-Theme Twenty Fifteen verwendet dieses Muster. Da es so selten ist, stelle ich fest, dass Besucher oft den Link zur Top-Level-Seite übersehen, und Forschungsergebnisse deuten darauf hin, dass Benutzer ein Label und ein Symbol nicht als separat klickbar wahrnehmen.


Was also ist die bessere Option? Hier kommt das Klick-Menü!
Klick-Menüs zur Rettung
Anstatt sich auf die Hover-Interaktion oder eine andere „kreative“ (und verwirrende) Lösung zu verlassen, erstellen wir Menüs, bei denen Elternpunkte Schaltflächen sind, die Untermenüs beim Klicken anzeigen und ausblenden. Dies löst sofort das Problem der Hover-Menüs, da Klick-Menüs eindeutig funktionieren.
- Website-Besucher müssen auf den Elternpunkt klicken, um sein Untermenü anzuzeigen.
- Alle Links befinden sich in Untermenüs, mit Ausnahme von Top-Level-Punkten, die kein Untermenü haben (z. B. „Home“). Wir werden uns gleich damit befassen, was mit diesen Top-Level-Seiten passiert.
Wenn man darüber nachdenkt, sind Klick-Menüs eigentlich das, was wir in den meisten anderen Kontexten bereits erwarten
- Verwenden Sie ein Touch-Gerät? Hover ist dort nicht wirklich etwas.
- Verwenden Sie ein Anwendungsmenü (z. B. Datei, Bearbeiten usw.)? Diese erscheinen fast nie beim Hovern!
- Verwenden Sie etwas anderes als eine Maus? Das Drücken von
ENTERoder das Aktivieren eines Links mit jeder Art von Switch-Steuerung ist eher äquivalent zum Klicken als:focuszu:hover.
Unabhängig von Ihrem Gerät oder Eingabemodus ist ein „Klick“ eine universellere und solidere Interaktion. Lassen Sie es uns nutzen, um unsere Website-Menüs großartig zu machen!
Umstellung auf Klick-Menüs
Mein Bauchgefühl sagt mir, dass viele Seiten kürzlich auf Klick-Menüs umgestiegen sind. Machen Sie mit! Da immer mehr Seiten umstellen, werden die Leute wieder einfache und nützliche Erwartungen entwickeln, wie „Websites funktionieren“ (und erfüllen damit Jakobs Gesetz).
Wenn Sie diese Umstellung vornehmen, ist es zwar wahr, dass einige Besucher immer noch Hover-Menüs erwarten könnten. Sie mögen sogar sagen, dass sie sie bevorzugen, wenn Sie sie fragen. Was ich Ihnen jedoch sagen kann, wenn ich beobachte, wie Leute Klick-Menüs benutzen, ist, dass jeder es schnell herausfindet und sich anpasst.
Und glauben Sie nicht nur meinem Wort! Die Navigationsmuster des U.S. Web Design Systems (USWDS) verwenden Klick-Menüs. Hier ist, was sie zu sagen haben:
Vermeiden Sie Hover, um Dropdown-Listen zu erweitern. Hover ist für einige Benutzer schwierig und funktioniert nicht auf Touchscreens. Dropdowns sollten per Klick oder mit Tastaturnavigation erweitert werden.
Bootstrap verwendet aus denselben Gründen auch Klick-Menüs.
Worauf es wirklich ankommt, ist die Benutzerabsicht. Der Zweck eines Hover-Zustands ist es, anzuzeigen, dass etwas klickbar ist (unterstrichener Text)... Der Zweck eines Klicks ist es, tatsächlich etwas zu tun, eine explizite Aktion durchzuführen. Das Öffnen eines Dropdowns ist eine explizite Aktion und sollte nur per Klick erfolgen.
Aus demselben Artikel gibt es diese großartige Perle:
Das Caret in einem Dropdown-Link ist das Äquivalent zur Unterstreichung eines Links: Es bietet eine gewisse Affordanz dafür, was passiert, wenn Sie dieses Element anklicken. Verwechseln Sie das aber nicht damit, genug Informationen zu liefern, um das Dropdown beim Hovern aufpoppen zu lassen.
Es ist also nicht so, dass wir hier unkartiertes Territorium erkunden. Und das UK.gov Design System hat eine weitere gute Erinnerung: Vielleicht brauchen Sie gar keine Untermenüs! Ihre Menüs sind einfach eine Liste von Links, die On-Page-Grids von Links und Akkordeons verwenden, um Besuchern die Navigation zu erleichtern. Selbst auf CSS-Tricks finden Sie keine Untermenüs!
Klick-Menüs bringen zusätzliche Vorteile!
Je mehr Sie mit Klick-Menüs arbeiten, desto mehr Vorteile entdecken Sie
- Sie entscheiden, ob Sie eine Kategorie-/Übersichts-/Landingpage benötigen... oder nicht! Anstatt Inhalte zu zwingen, um sie an die Struktur eines Menüs mit Links anzupassen, die übergeordnete Links sind, diktieren Ihre Content-Strategie und Informationsarchitektur, welche Arten von Seiten Sie benötigen und wie sie benannt sind. Wenn eine Übersicht Ihrer Dienstleistungen für Ihre Besucher hilfreich ist, fügen Sie „Dienstleistungsübersicht“ oder „Alle Dienstleistungen“ als erstes Element in Ihr „Dienstleistungen“-Untermenü ein.
- Untermenüs bleiben geöffnet, bis sie geschlossen werden. Hover-Menüs haben die unangenehme Angewohnheit, zu verschwinden, wenn die Leute mit dem Cursor darüberfahren oder sogar nur versuchen, auf einen Untermenülink zu klicken. Dies ist besonders der Fall bei Untermenüs, die „ausfahren“ und nicht unter dem Elternpunkt liegen. Die Persistenz von Klick-Menüs sorgt für ein „solideres“ Erlebnis, damit die Benutzer der Oberfläche vertrauen und nicht frustriert werden.
- Das persistente Untermenüverhalten ist für Megamenüs noch wichtiger. Wenn Besucher mehr Zeit benötigen, um den Inhalt des Untermenüs zu erfassen, können sie es sich nicht leisten, dass das Menü unerwartet schließt.
- Das JavaScript ist dasselbe für „mobile“ und „Desktop“-Menüs. Ob das Menü hinter einem Hamburger versteckt ist oder auf dem Handy sichtbar ist, die Interaktion ist immer die gleiche. Ich muss nur mein CSS ändern, um ein responsives Klick-Menü zu erstellen.
Klick-Menüs erstellen
Als ich mein eigenes barrierefreies Klick-Menü-Skript erstellen wollte, stellte ich fest, dass es keinen einzigen Standard dafür gab, wie man es macht. Meine eigenen Gedanken und mein Code wurden am stärksten beeinflusst von
- „Link + Disclosure Widget Navigation“ von Adrian Roselli
- „Header-Demo“ vom US Web Design Service
- „Menüdesign: Checkliste mit 15 UX-Richtlinien zur Unterstützung der Benutzer“ von Nielsen Norman Group
- „Beispiel-Disclosure-Navigationsmenü“ in ARIA Authoring Practices
Die wichtigsten Erkenntnisse aus meiner Forschung zur Implementierung:
- Das Element, das Sie anklicken, um das Untermenü anzuzeigen, sollte ein
<button>sein, da es nicht zu einer Seite verlinkt. - Verwenden Sie
aria-expanded(auf dem<button>!), um die offenen und geschlossenen Zustände des Untermenüs zu kommunizieren. - Verwenden Sie
display: noneodervisibility: hidden, damit Tastaturnutzer keine Untermenüs erreichen können, wenn diese geschlossen sind. aria-controlsist Mist, aber Sie können es trotzdem hinzufügen.- Verwenden Sie nicht
role="menu"(und das gesamte ARIA-Menüpattern) oderaria-haspopup. Diese scheinen verwandt zu sein, sind aber nicht zum Erstellen von Navigationsmenüs gedacht. - Schließen Sie ein geöffnetes Untermenü, wenn
- Ein anderes Untermenü geöffnet wird
- Der Benutzer außerhalb des Menüs klickt
- Der Benutzer die
ESC-Taste drückt, wenn der Fokus innerhalb eines geöffneten Untermenüs liegt. (Nicht alle Benutzer erwarten das, aber ich finde, es ist eine nette Geste.)
Da Klick-Menüs JavaScript erfordern, sollten wir in Betracht ziehen, wie dieses Menü progressiv verbessert werden kann, falls JavaScript aus irgendeinem Grund fehlschlägt. Unser klassischer Hover-CSS-Trick ist nach all dem doch noch für etwas gut!
Ich beginne damit, mein Klick-Menü als reines CSS-Hover-Menü zu erstellen, das li:hover > ul und li:focus-within > ul verwendet, um die Untermenüs anzuzeigen. Dann verwende ich JavaScript, um die <button>-Elemente zu erstellen, die aria-Attribute festzulegen und die Ereignishandler hinzuzufügen. Das bedeutet, dass das Menü immer noch weitgehend ohne JavaScript funktioniert und gut mit rein Link-basierten Menüs funktioniert, die in WordPress, meinem bevorzugten CMS, erstellt wurden.
Sie können das Skript, das ich verwende, unten einsehen, aber ich werde der Erste sein, der zugibt, dass es wahrscheinlich bessere gibt. Wichtig ist, dass Sie es mit echten Benutzern testen… und aufhören, Hover-Menüs zu verwenden. 😃
Ich habe mit Details und Summary experimentiert (ja, ja, Polyfill für alte Browser). Die Zusammenfassung enthält den „Gruppennamen“ (es ist nie ein Link) und die Menüpunkte sind nur eine ungeordnete Liste von Links.
Dann habe ich ein wenig JS hinzugefügt, um andere offene Geschwister-Details zu schließen, was durch ein Data-Attribut am übergeordneten Container ermöglicht wird. So kann ich die Komponente für verschiedene Verhaltensweisen wiederverwenden, z. B. um FAQs offen zu halten, bis sie geschlossen werden (Standardverhalten des Browsers).
Nur so zum Spaß habe ich ein Data-Animate-Attribut hinzugefügt, das die Öffnungs- und Schließvorgänge nur mit CSS animiert (siehe Artikel anderswo auf CSS Tricks dazu!).
Da der Inhalt von Details beliebig gestylt werden kann, habe ich sogar die Möglichkeit, zu CSS-Spalten zu wechseln (wieder über ein Data-Attribut), wenn die Liste auf Tablets/Desktops zu lang ist, während die Markup-Minimierung beibehalten wird (nur ein zusätzlicher Umgebungscontainer um die Liste herum)...
Jemand anderes hat diese gleiche Idee auf Twitter als Reaktion auf diesen Artikel geäußert, also sind Sie nicht allein mit Ihren Gedanken! Dies ist auch der Ansatz, den Github verwendet.
Ich würde sagen, dass es *möglich* ist, diesen Ansatz für ein barrierefreies Menü zu verwenden, aber er würde viel Tests erfordern. In allen Diskussionen und Artikeln, die ich überprüft habe, kam dieses Muster praktisch nie vor, also ist es bestenfalls nicht gut untersucht oder getestet.
Die unterschiedlichen Semantiken von Details/Zusammenfassung mit einem Link oder Button machen mir auch Sorgen. Es ist wahrscheinlich lösbar, aber auch hier habe ich noch niemanden gesehen, der es getestet hat.
Am Ende des Tages würde ich immer noch meinen Ansatz empfehlen, da er immer noch ein No-JS-Fallback-Verhalten bietet und in der Barrierefreiheits-Community ausführlicher getestet und diskutiert wurde. Ich stehe sehr auf den Schultern dieser Giganten und vertraue ihrer Arbeit.
Nicht wirklich, wenn Sie Checkboxen und
:checked + .menu { display: block }oder so etwas verwenden. ;)Radio-Buttons wären besser als Checkboxes. Da Sie möchten, dass sich ein Menü schließt, wenn das andere geöffnet wird.
Der Checkbox-Hack ist so cool und macht Spaß zu benutzen! Das Erstellen von benutzerdefinierten Checkboxen und Radio-Buttons damit ist vielleicht eine meiner liebsten CSS-Aufgaben. Wenig überraschend hat CSS Tricks dies schon oft behandelt. Hier ist eine Reihe von Beispielen, die Chris gepostet hat, darunter auch ein Menü. Dennoch würde ich dieses Zitat aus dem Beitrag hervorheben:
Da ein
<form>-Element etwas ganz anderes ist als ein<nav>-Element, ist dies kein Muster, das ich bei meiner Herangehensweise in Betracht gezogen habe.Ich denke, es lohnt sich, Jakobs Gesetz hier speziell im Hinblick auf die Barrierefreiheit anzuwenden. Screenreader-Benutzer und Personen, die mit Tastaturen navigieren, profitieren noch mehr als sehende oder Mausbenutzer, da die Funktionen, auf die sie angewiesen sind, im Allgemeinen nicht sichtbar oder anderweitig wahrnehmbar sind. Wenn Sie also über Barrierefreiheit nachdenken, ist es sehr wichtig, die Semantik und das zu berücksichtigen, was Besucher auf anderen Websites höchstwahrscheinlich angetroffen haben.
Wenn es um Interaktionen geht, fallen mir keine zwei grundlegenderen interaktiven Elemente ein als
<button>s und Links, und daher sind sie ideal für die Erstellung einer Benutzeroberfläche, die ein neuer Besucher sofort als Navigationsmenü verstehen und einfach damit interagieren kann.Die Kombination von
:hover > ulund:focus-within > ulfühlt sich für mich wie ein ausreichend gutes No-JS-Fallback an und unterstützt die semantischen Elemente (Links), die jeder Website-Besucher in einem Menü erwartet.Eigentlich können Sie sowohl Checkboxen als auch Radio-Buttons überspringen und :focus-within mit tabindex=„0“ verwenden
Asaf – das dachte ich auch, bis ein Kunde, der Safari benutzt, sagte, dass die Menüs nicht funktionieren.
Das Problem ist, dass „Fokus“, wie allgemein verstanden/spezifiziert, einfach nicht funktioniert, es sei denn, Sie stellen eine Safari-Präferenz ein, um die Tab-Navigation zu ERMÖGLICHEN.
Safari Fokus-Bug
Immer noch offen seit 2008…
Gute Nachrichten – es sieht so aus, als ob dies bald behoben wird!
(https://blogs.igalia.com/mrego/2021/06/07/focus-visible-in-webkit-may-2021/)
Ich wäre sehr daran interessiert, diesen Ansatz in einem zukünftigen Projekt zu verwenden! Ich hoffe nur, dass das Designteam mitspielt…
Finden Sie, dass es eine angemessene Möglichkeit gibt, dies anzusprechen, ohne wie „Ich weiß es am besten, Ihr Design ist schlecht“ zu klingen?
Schicken Sie ihnen diesen Artikel?
Es kann überraschenderweise eine seltsam schwierige Debatte sein, Menschen voll einzubinden! Was wahrscheinlich am wichtigsten ist, ist, dass es Ihnen gelingt, die Leute über die Phase des „aber es gefällt mir nicht“ bei Usability-Diskussionen hinwegzubekommen (was keine echten Usability-Diskussionen sind).
Ich stelle fest, dass, wenn ich diese 4 widersprüchlichen Hover-Menü-Implementierungen darlege, die Leute oft sehen, dass die Vorteile von Klick-Menüs die geringen (und diskutablen) Kosten der Nichtverwendung von Hover-Menüs überwiegen. Und wenn Ihre Gruppe groß genug ist, werden Sie wahrscheinlich feststellen, dass die Erwartungen der Leute an Hover-Menüs selbst innerhalb der Gruppe unterschiedlich sind! Der einzige Weg, das Problem zu lösen, den ich kenne, ist, den Ansatz vollständig zu ändern und stattdessen Klick zu verwenden.
Ich habe gerade einige der Punkte in diesem Artikel angesprochen, die mich angesprochen haben, insbesondere die Tatsache, dass wir Hover auf Desktop-großen Displays nicht mehr annehmen können, und das Designteam gefragt, was sie davon halten. Jeder einzelne stimmte zu, und wir werden von nun an auf Klick-Menüs setzen.
Hallo Christopher,
Als UX/UI-Designer, der sich über diesen Artikel freut, bezweifle ich, dass Sie Probleme haben werden, das Designteam ins Boot zu holen. Sie warten vielleicht sogar darauf, dass jemand das Problem und die Lösung so klar formuliert wie hier.
Darüber hinaus wären Benutzertests über zwei Versionen (Klick vs. Hover oder gemischt) interessant und die Ergebnisse willkommen, wenn Sie einen interaktiven Test ohne großen Aufwand einrichten könnten. So ziemlich jeder sieht den Wert von evidenzbasierten Designentscheidungen.
Was ich am meisten hasse, sind verzögerte Hover-Menüs mit Links in Headern…
Ich fahre mit der Maus darüber, nichts passiert, ich klicke, das Menü erscheint und dann beginnt die „App“, zu der der Header-Link führt, zu navigieren – das ist einfach ärgerlich
fast so schlimm wie „Spam erhalten“ immer angekreuzt ist
Habe ich die Lösung für die Top-Level-Links verpasst?
Entschuldigung, wenn das im Artikel nicht klar genug war.
Die „Lösung“ besteht darin, sie wegzulassen (wenn sie nur Füllmaterial sind) oder sie mit einer klaren Beschriftung ins Untermenü zu verschieben.
Ich denke, es gibt eine weitere mögliche Hover-Menü-Konfiguration, die HTML-Lesezeichen verwendet, und auch eine Möglichkeit, ein Klick-Menü ohne JavaScript zu implementieren.
Siehe hier
https://frugalwp.com/how-to-build-an-unambiguous-submenu-with-pure-css-and-html-no-javascript/
Danke für Ihre Gedanken! Ich sehe, wir beide lieben es,
:focus-withinzu verwenden. Während ich es liebe, nur CSS zu verwenden, wenn es notwendig ist, gehört zum Lernprozess über Untermenü-Navigation zu lernen, dass JavaScript notwendig ist, um ein barrierefreies Menü zu erstellen. Unter anderem kommunizieren die ARIA-Attribute wichtige Informationen an Screenreader-Benutzer, und das Tastaturnavigationsmuster spart den Benutzern Zeit, indem es nicht durch jeden einzelnen Link in einem Menü getaßt werden muss. (Ein Skip Link ist aus diesem Grund ebenfalls hilfreich. Diese sind sich sehr ergänzend.)Nur CSS ist großartig als erster Schritt in der progressiven Verbesserung, aber ich denke wirklich, dass JavaScript notwendig ist, um die benutzbarste und barrierefreiste Untermenü-Navigation bereitzustellen.
Aus dem Artikel: „Wenn man darüber nachdenkt, sind Klick-Menüs eigentlich das, was wir in den meisten anderen Kontexten bereits erwarten.“
[klopft sich auf die Stirn] Seit über einem Jahrzehnt bin ich fassungslos, dass niemand an etwas so Offensichtliches zu denken schien. Ich meine, der Browser selbst hatte gut funktionierende, Standardmenüs. Bis CSS Web-Dropdown-Menüs ermöglichte, wurde das Verhalten von Dropdown-Menüs in Usability-Laboren (aller möglicher Variationen) ausgiebig getestet und war fast vollständig standardisiert über Windows, Mac, NeXT, BeOS usw.: Menüs, konsistent mit allen Arten von Schaltflächen, warten darauf, dass ihnen gesagt wird, dass sie sich öffnen sollen, was ebenfalls, konsistent, per Maus, Tastatur, Touch, Sprache, Augensteuerung usw. erfolgen kann.
Dann entschied sich ein Webentwickler, Menüs zu erstellen, die nicht darauf warteten, dass man darum bittet. Man klickte auf einen Link in einer bestimmten Scroll-Position, sodass man mit der neuen Seite navigierte, wobei die Maus an einer zufälligen Position war, die dann ein zufälliges Menü auslöste, das sich öffnete und das verdeckte, was man suchte, und einen zwang, einen Weg zu finden, es zu schließen, ohne versehentlich ein anderes Menü auszulösen und von vorne zu beginnen. Und wenn man endlich sah, was man auf einem anderen Teil der Seite wollte und die Maus dorthin bewegte: BLAT! Ein weiteres zufälliges Menü wurde auf dem Weg ausgelöst. Oder man hat Menüs so angeordnet, dass der Versuch, eines zu erreichen, ein anderes in der Nähe auslöst, das es dann verdeckt (ich sehe dich an, Amazon!).
Dann scheinen alle anderen gesagt zu haben: JA, ich möchte auch, dass Besucher meiner Seite das Gefühl haben, als wären sie gerade in ein Minenfeld gestolpert. Anstatt des ausgiebig getesteten, Usability-Research-basierten Standardmenüverhaltens, ein Menü oder eine Schaltfläche anzuklicken, wenn man es möchte, möchte ich, dass sie den Nervenkitzel erleben, nicht zu wissen, was passieren könnte, und dass es anders passiert, je nachdem, wo sie auf der Seite landen und ob sie mit einer Maus oder einem Touch-Gerät landen.
(Tooltips sind in Ordnung, wenn sie so klein sind, dass sie sehr unwahrscheinlich etwas abdecken, das man braucht. Man muss trotzdem die Verzögerung lange genug einstellen, damit sie beim Überfahren nicht auslösen.)
Wir sollten die Lektionen über Menüs verwenden, die bereits in den Win95-Tagen gut recherchiert, gut bekannt, gut gemocht und etabliert waren. Wir können so tun, als ob es ein neu erfundenes Konzept namens „Klick-Menüs“ wäre, wenn das hilft.
Danke für deinen Kommentar! Ich versuche definitiv nicht, ein neues Konzept zu erfinden. Tatsächlich ist fast meine gesamte Forschung und Arbeit darauf ausgerichtet, *zu vermeiden*, etwas zu tun, das nicht bereits von anderen getan und getestet wurde.
Interessanterweise habe ich nie einen guten Begriff für diese Menüs gefunden. In der Welt der Barrierefreiheit sind sie als "Link + Disclosure Widget Navigation" bekannt, aber das rollt nicht gerade vom Zungenbrecher. Es gibt auch eine Menge Mehrdeutigkeit bezüglich der Verwendung von "Dropdown", daher wollte ich das nicht verwenden.
Wenn ich einen offensichtlichen und weit verbreiteten Namen für klickgesteuerte Untermenü-Navigation übersehen habe, würde ich ihn gerne erfahren, damit ich ihn verwenden und in die Fußstapfen derer treten kann, die vor mir kamen!
Warum nicht :active für Klick zum Öffnen verwenden?
:activegilt nur, wenn ein Mausklick nach unten geht und hört (meistens) auf zu gelten, wenn der Mausklick wieder nach oben geht. Daher würde die Verwendung von:activeein Menü nur geöffnet halten, solange die Maustaste gedrückt wird.Hier ist eine Demo, die zeigt, wann
:activegilt: https://codepen.io/mrwweb/pen/eYgYOVY?editors=1100Ganz einfach... einfach klicken, wegziehen und dann loslassen. Das Element bleibt aktiv! Ganz einfach... unterrichten Sie Ihre Besucher einfach diese neue Methode der Menüaktivierung.
/s, falls es nicht offensichtlich war...
Sie könnten meine jsMenus-Bibliothek als nützliches Werkzeug empfinden. Sie hat eine Reihe von netten Funktionen, einschließlich voller Tastaturnavigation – probieren Sie die Demo hier. Ich habe nicht versucht, sie anständig degradieren zu lassen, wenn kein JavaScript vorhanden ist (da ich sie hauptsächlich für Befehle und nicht für Links verwende). Ich habe noch nicht viel getan, um Attribute und Klassen für Barrierefreiheit hinzuzufügen, aber ich habe heute die Elementhierarchie korrigiert, um sie besser geeignet zu machen. Feedback willkommen.
Danke fürs Teilen! Schauen Sie sich unbedingt die Wege an, wie ARIA ein Menü zugänglicher machen kann, indem es den geöffneten/geschlossenen Zustand von Untermenüs kommuniziert! Klingt, als wäre es eine gute Ergänzung zu Ihrem Skript!
Ich habe die meisten Ihrer Hauptvorschläge umgesetzt. Die Hauptausnahme ist aria-controls, das Sie nicht für besonders nützlich halten (aber ich könnte es auf Anfrage hinzufügen). Jeder Menüpunkt ist jetzt ein
<button>; der Menüpunkt-Knoten umschließt sowohl den Button als auch alle Untermenüs; und aria-expanded ist entsprechend gesetzt. Die meisten der von ARIA empfohlenen Tastenkombinationen funktionieren. (Die wichtigsten fehlenden Tastenkombinationen sind Space und Tab, aber ich habe die Empfehlungen nicht sehr genau studiert.) Bitte posten Sie ein Issue, wenn Sie die Bibliothek verwenden möchten und Zugänglichkeits- (oder andere) Bedenken haben.Schöner Artikel! Ich habe zwei Fragen
1: Warum das aria-menu-Muster weglassen? W3C verwendet es in seinen Beispielen? Wofür ist es gut, wenn nicht für Navigationen?
2: Sie sagen "Verwenden Sie Buttons für Top-Level-Einträge". In Ihrem Codepen verwenden Sie Services Warum so?
Es stimmt, dass es dort sogar mehrere Demonstrationsbeispiele für Navigationsmenüs (im Sinne von role=menu) gibt. Das Muster war jedoch umstritten.
Einige Leute glauben, dass sie fast nie verwendet werden sollten. Insbesondere Adrian Roselli hat starke Ansichten dazu und hat Bedenken innerhalb von WCAG geäußert, um ihre Entfernung zu fordern. Sie können seine Ansichten hier lesen: https://adrianroselli.com/2017/10/dont-use-aria-menu-roles-for-site-nav.html
Wie es in der Barrierefreiheit oft vorkommt, können einzelne Blogbeiträge sehr einflussreich sein, besonders wenn sie mit einem bestimmten Ton geschrieben sind. Dieser Artikel ist ein Beispiel – wenn Sie jemanden sagen hören, dass die Menümuster nie verwendet werden sollten, denke ich, dass die Wahrscheinlichkeit ziemlich hoch ist, dass er es dort gelernt hat oder es von jemandem aufgeschnappt hat, der es getan hat, usw. Es ist sicherlich, wo ich es zuerst gelernt habe.
Die Schlussfolgerungen dort wurden nicht von allen akzeptiert und Versuche, das Muster zu entfernen oder einen spezifischen Haftungsausschluss hinzuzufügen, waren erfolglos (seit Jahren). Einige Leute, die assistive Technologien nutzen, bevorzugen Menüverhalten für Navigation und einige nicht. Einige Leute, die keine assistiven Technologien nutzen, bevorzugen Menüverhalten und einige nicht (es sind ganz unterschiedliche Erfahrungen unabhängig davon).
Auf jeden Fall, während einige Leute Menüs bevorzugen, wird niemand überrascht sein, wenn sie nicht verwendet werden. Da Menüs komplizierter sind und es mehr Möglichkeiten gibt, dass Dinge schief gehen, bleibt der Kernrat, selbst wenn man nicht mit allen Schlussfolgerungen von Roselli einverstanden ist, solide.
Die Antwort von @bathos ist großartig!
Ich muss zugeben, dass ich Adrian Rosellis Argumente zu diesem Thema überzeugend und einflussreich für meine eigenen Ansichten fand.
Ich würde sagen, meine eigene Technik läuft letztendlich auf die Schlussfolgerung ihrer Antwort hinaus.
Es scheint sehr klar, dass wir ein solides, nutzbares Muster ohne role="menu" erstellen können, und die zusätzliche Komplexität scheint keinen Vorteil zu bringen (meiner Meinung nach).
Zu Ihrer zweiten Frage zu Buttons: "Buttons für Top-Level-Einträge verwenden" bedeutet, dass Sie das Button-Element anstelle des Link-Elements für ein klickbares Element verwenden sollten, das ein Untermenü anzeigt. "Services" ist der Button-Text (zugänglicher Name) des ersten Buttons im Navigationsmenü. Ich hoffe, das klärt die Sache auf.
Mir gefällt der Rat hier. Menüs sind ein so wichtiger Teil der Navigation im Internet, sie sollten ein Bereich des Fokus auf Benutzerfreundlichkeit sein.
Ich denke, einer der Gründe, warum schlechte Menüs so weit verbreitet sind, ist, dass das Standard-WordPress alle Menüpunkte zu Links macht. Das ist seit vielen Jahren einer meiner größten Kritikpunkte an WordPress.
Toller Artikel, ich bin in letzter Zeit zu denselben Schlussfolgerungen gekommen.
Das Einzige, wofür ich noch keine klare Lösung gefunden habe, ist, wie man mit Breadcrumbs umgeht, wenn die erste Navigationsebene keine dedizierte URL hat.
Ich stimme Nielsen zu, dass alle Elemente einer Breadcrumb-Navigation außer dem letzten einen URL haben müssen (https://www.nngroup.com/articles/breadcrumbs/ Abschnitt 6).
Das Weglassen dieses ersten Kategorieelements aus der Breadcrumb führt jedoch zu einer schlechten Anzeige der aktuellen Position innerhalb der logischen Struktur der Website.
Dann gibt es noch die Option, dass dieser Menüpunkt der ersten Ebene eine URL hat, die nur zur ersten Unterseite weiterleitet. Das führt jedoch zu einem sehr unvorhersehbaren Verhalten, das ich mir auch nicht als gute und leicht verständliche Erfahrung vorstellen kann.
Meine Schlussfolgerung ist vorerst:
– Breadcrumbs für Websites mit Hierarchien <3 Ebenen weglassen (und die Position klar im Menü selbst anzeigen)
– Ein Popover öffnen, wenn auf ein Element der ersten Ebene innerhalb einer Breadcrumb geklickt wird, das Unterelemente anzeigt. Obwohl es sich nicht um Ihren regulären Breadcrumb-Link handelt, denke ich, dass es am besten den Erwartungen entspricht (man kann auf Breadcrumb-Elemente klicken), die aktuelle Position am besten anzeigt und das Muster des Hauptmenüs selbst wiederholt (Klick auf die erste Ebene erweitert die Liste der Elemente der zweiten Ebene).
Ich bin sehr gespannt, wie andere Leute mit Breadcrumbs im Kontext von Klickmenüs umgehen.
Die Antwort ist eher, Fluff-Seiten wegzulassen und diesen Seiten zuerst Wert zu verleihen. Eine "Produkte"-Seite muss kein Fluff sein – sie kann sich an einen Benutzer richten, der noch nicht weiß, welches Produktsegment er benötigt, und ihm helfen, es zu finden.
Ich würde also Fluff-Seiten nicht so abfällig behandeln. Wenn Sie eine schnell ladende Website haben, kann die Zeit zum Klicken auf eine Seite und dann zur Auswahl eines Kindes genauso oder schneller sein als die Menüerweiterung, die Erklärung des Menüs und ein zweiter Klick innerhalb des Menüs selbst.
@Nathan, ich stimme vollkommen zu! Das ist definitiv eine der Optionen, die ich in dem Artikel vorschlage. Ich halte es für wichtig, dass die Leute ausdrücklich entscheiden, ob sie Landing-Pages/Index-Seiten benötigen oder nicht.
Ich wäre mit diesem Argument aus ein paar Gründen vorsichtig.
1) Ein Seiten-Refresh ist fast sicher langsamer, selbst auf den schnellsten Ladewebsites, und wir wollen immer schlechte Netzwerke und langsame Internetverbindungen berücksichtigen.
2) Das Laden einer Seite, um festzustellen, dass sie nicht das ist, was man will, fühlt sich wie eine viel teurere "Interaktionskosten" an als das Öffnen eines Untermenüs.
Ich habe eine Weile jQuery verwendet, aber in letzter Zeit versuche ich, das Programmieren mit reinem Vanilla JS zu lernen, nur um diese Art von Dingen zu tun.
Es ist nicht perfekt, aber hier ist mein Versuch mit einem klickbaren Dropdown-Menü
Ich habe mich entschieden, die Menü-Toggle-Anker nicht in Buttons umzuwandeln, da meine Frau, die verschiedene Screenreader verwendet und als Beraterin für Barrierefreiheit an ihrem Arbeitsplatz tätig ist, sagte, dass die Rolle="button" und die Bereitstellung der richtigen ARIA-Attribute nach Bedarf ausreichend seien.
Ich würde mich sehr über konstruktive Ratschläge freuen, was ich tun kann, um die Funktion des Menüs zu verbessern.
Vielen Dank für Ihre Zeit und Aufmerksamkeit!
Es klingt, als ob Ihre Frau weiß, wovon sie spricht, daher möchte ich ihr nicht widersprechen.
Ich habe mich entschieden, zu einem Button zu konvertieren, wegen der "Ersten Regel von ARIA", die direkt in die Spezifikation geschrieben ist.
Anstatt sich mit einem potenziellen Edge-Case oder Button-Verhalten auseinandersetzen zu müssen, das ich vielleicht nicht kenne, verwende ich lieber einen Button.
Danke @Mark Root-Wiley für diesen Artikel! Und @SiVal für Ihre sehr treffende Beschreibung des Problems. Ich implementiere das gerade in meinen WordPress-Client-Themes.
Mein aktueller Kunde wünscht sich jedoch eine dritte Untermenü-Ebene. Hat jemand, der dies liest, Gedanken oder Empfehlungen, wie man das implementieren kann?
Ein Menüpunkt als Button zu machen mag in Ordnung sein, aber das Klicken darauf schließt die Untermenüliste, und das JavaScript ist mir an diesem Punkt zu hoch. Aber vielleicht gibt es eine bessere Lösung, oder andere Dinge, die ich wissen sollte, bevor ich mich in ein Kaninchenloch damit begebe.
Theme-Entwickler, die dies in ein Theme für die WP-Bibliothek integrieren wollen, müssen sich eine allgemeine Lösung einfallen lassen. Ich bin gespannt, was möglich ist!
@clgolden – Ich freue mich, dass es Ihnen gefällt!
Mehrere Ebenen von Untermenüs ist etwas, das ich in Erwägung gezogen habe, obwohl Sie Recht haben, dass das Skript es derzeit nicht unterstützt. Es ist definitiv ein Fall, in dem ich die Informationsarchitektur von verschachtelten Untermenüs nicht mag, daher unterstütze ich es vorerst nicht. Ich mag es auch, dass es durch die Nichtunterstützung einfach ist, Megamenüs mit diesem Skript zu erstellen, wo ein einzelnes Untermenü mehrere sichtbare Ebenen von verschachtelten Menüpunkten enthalten kann.
Es ist ein interessanter Kompromiss, und ich denke, Sie haben Recht, dass ein WordPress-Theme verschachtelte Untermenüs standardmäßig unterstützen möchte.
Toller Artikel. Ich versuche, dies auf einer neuen Website zu implementieren, an der ich arbeite, und stoße auf die folgende Konsolenfehlermeldung
Uncaught DOMException: Failed to execute ‘closest’ on ‘Element’: ‘#’ is not a valid selector.
Dies wird von der closeOpenMenu-Funktion aufgerufen.
Auf dem Desktop passiert dies jedes Mal, wenn ich auf ein Menü mit einem Dropdown klicke. Es scheint trotzdem zu funktionieren, aber ich bin mir nicht sicher, warum dieser Fehler bei mir immer wieder auftaucht, wenn er in Ihrem CodePen nicht auftaucht.
Irgendwelche Gedanken?
Hey Todd,
Ich glaube, das Problem hier ist, dass das Element, das Ihr Menü umschließt, keine ID hat. Dies ist eine implizite Anforderung, die ich hoffe, in Zukunft zu entfernen oder mit dem Skript zu beheben (hier ist ein Github-Issue).