focus-Styling eines Toggle/DD-Buttons bleibt nach geöffnetem Menü (Klick, JS) bestehen

- css
Hallo,
ich mache gerade das Styling von hover, focus und active für meine beiden Toggle/DD-Menü-Buttons, die ich responsiv im Media Query habe.
Dabei fällt mir auf, dass das focus-Styling, ein violetter Innenrahmen, nicht mehr verschwindet, wenn das Menü mal ausgeklappt ist. Und auch wenn ich durch erneuten Klick auf den Button das Menü wieder schließe, bleibt der Innenrahmen.
Wenn mal geklickt, dann sieht man ihn also dauernd.
Siehe die beiden screenshots.
Wie läst sich das unterbinden oder sollte das "normal" sein? Kann mich nicht erinnern, das bei anderen Beispielen so gesehen zu haben.
Hier ist der Code:
button.headnav-button:hover, button.sidenav-button:hover {
box-shadow: 0px 0px 0px 4px #fca497;
}
button.headnav-button:focus, button.sidenav-button:focus {
outline: 4px solid #a00565;
outline-offset: -9px;
}
button.headnav-button:active, button.sidenav-button:active {
background-color: #c1ffc1;
}
Hi,
Dabei fällt mir auf, dass das focus-Styling, ein violetter Innenrahmen, nicht mehr verschwindet, wenn das Menü mal ausgeklappt ist. Und auch wenn ich durch erneuten Klick auf den Button das Menü wieder schließe, bleibt der Innenrahmen.
klar, der Button hat ja dann immer noch den Focus.
Wenn mal geklickt, dann sieht man ihn also dauernd.
der Innenrahmen sollte verschwinden, wenn Du auf ein anderes Element klickst. Oder per Tab-Taste zum nächsten fokussierbaren Element weitergehst.
cu,
Andreas a/k/a MudGuard
der Innenrahmen sollte verschwinden, wenn Du auf ein anderes Element klickst. Oder per Tab-Taste zum nächsten fokussierbaren Element weitergehst.
Ja, das geschieht.
Hm, warum kommt mir das subjektiv so ungewohnt vor.. Ich habe so viele Beispiele mit ausklappenden DD-Menüs gesehen, aber mir ist nie aufgefallen, dass deren focus-Styling immer bestehen blieb. Haben die alle gar kein focus-Styling gehabt? In Tutorials ect. könnte das schon sein, weil da geht es dann um irgendwelche andere Themen rund um DD/Button/Menü ect.
Beim Durchtabben ist mir aufgefallen, dass nach dem letzten Menüpunkt dann der Fokusring weiterspringt zu einem anderen Element, aber das ausgeklappte Menü offen bleibt. Ich dachte, ich hätte im JS-Code alle Gründe zum Schließen eines aufgeklappten Menüs mit drin (ESC, erneuter Button-Klick, Klick auf Menü-Link). Oder was "sollte" beim letzten Menüpunkt mit einem weiteren "Tab" passieren und wie erreicht man das?
Liebe(r) Matinee,
Beim Durchtabben ist mir aufgefallen, dass nach dem letzten Menüpunkt dann der Fokusring weiterspringt zu einem anderen Element, aber das ausgeklappte Menü offen bleibt.
dann möchtest Du mit JavaScript bestimmt „merken“, wenn der Fokus aus Deinem Menü verschwunden ist, um ihn entweder darin gefangen zu halten, oder das Menü zu schließen.
Liebe Grüße
Felix Riesterer
Hallo Felix,
dann möchtest Du mit JavaScript bestimmt „merken“, wenn der Fokus aus Deinem Menü verschwunden ist, um ihn entweder darin gefangen zu halten, oder das Menü zu schließen.
Bei meinen Unterlagen zu einem Dropdown-UNTERmenü desktop (hier sind es zwei resp. Hauptmenüs, die aufklappen) habe ich mir vor Jahren mal etwas aufgeschrieben: Wenn der User per Tab beim letzten Menüpunkt ankommt und dann nochmal "tabbed", sollte er zum nächsten top-level-item der desktop-Navi springen und das Untermenü sich schließen. Bei einem DD-Untermenü desktop macht sicher Sinn und ist unstrittig.
Bei zwei resp. Toggle/DD-Hauptmenüs bin ich nicht sicher, ob es evtl. besser wäre, den User nach dem letzten Menüpunkt wieder zum Beginn des Menüs zu schicken. Dagegen spricht m.E. aber zweierlei:
Spricht nicht alles dafür, dass der Tab-User beim letzten Menüpunkt eines responsiv ausgeklappten Menüs angekommen, dann mit weiterem Tab einfach zum nächsten fokussierbaren Element springt und das verlassene Menü sich schließt?
Hallo,
ich habe ans Ende meines Menüs einen unsichtbaren Button gesetzt. Wenn der den Focus erhält, wird das Menü geschlossen.
Gruß
Jürgen
Hi,
ich habe ans Ende meines Menüs einen unsichtbaren Button gesetzt. Wenn der den Focus erhält, wird das Menü geschlossen.
und dann sieht der User nicht mehr, wo der Focus ist …
cu,
Andreas a/k/a MudGuard
Hallo Andreas,
ich habe ans Ende meines Menüs einen unsichtbaren Button gesetzt. Wenn der den Focus erhält, wird das Menü geschlossen.
und dann sieht der User nicht mehr, wo der Focus ist …
so ist es. Erst beim nächsten TAP wird der Focus wieder sichtbar. Ohne diesen Button ist man beim aus der Navi Tabben "irgendwo" beim nächsten fokussierbaren Element gelandet.
Hast du eine bessere Idee?
Gruß
Jürgen
Hi,
ich habe ans Ende meines Menüs einen unsichtbaren Button gesetzt. Wenn der den Focus erhält, wird das Menü geschlossen.
und dann sieht der User nicht mehr, wo der Focus ist …
so ist es. Erst beim nächsten TAP wird der Focus wieder sichtbar. Ohne diesen Button ist man beim aus der Navi Tabben "irgendwo" beim nächsten fokussierbaren Element gelandet.
Hast du eine bessere Idee?
ist das Schließen des Menüs beim An-Tabben des Buttons per Javascript gelöst?
Wenn ja, dann das nächste fokussierbare Element (a/input/button/select/…) per Javascript focussieren, nachdem das Menü geschlossen wurde.
cu,
Andreas a/k/a MudGuard
Hallo Andreas,
ich habe ans Ende meines Menüs einen unsichtbaren Button gesetzt. Wenn der den Focus erhält, wird das Menü geschlossen.
und dann sieht der User nicht mehr, wo der Focus ist …
so ist es. Erst beim nächsten TAP wird der Focus wieder sichtbar. Ohne diesen Button ist man beim aus der Navi Tabben "irgendwo" beim nächsten fokussierbaren Element gelandet.
Hast du eine bessere Idee?
ist das Schließen des Menüs beim An-Tabben des Buttons per Javascript gelöst?
beim alten: ja, beim neuen: nein.
Wenn ja, dann das nächste fokussierbare Element (a/input/button/select/…) per Javascript focussieren, nachdem das Menü geschlossen wurde.
das habe ich damals beim alten Menü ausprobiert und verworfen. Auf meiner Testseite war das erste fokussierbare Element - ein Link - am Ende der Seite. Beim Tabben aus dem Menü beraus landete man dann ganz unten. Daher das versteckte Element und natürlich auch das Schließen mit ESC.
Das neue Menü ist noch in Arbeit.
Gruß
Jürgen
@@MudGuard
Wenn ja, dann das nächste fokussierbare Element (a/input/button/select/…) per Javascript focussieren, nachdem das Menü geschlossen wurde.
Das nächste? Mich deucht, man sollte den Fokus wieder auf den Button setzen, der das Menü wieder öffnet.
🖖 Live long and prosper
@@Matinee
Der User könnte sich tatsächlich etwas "gefangen" fühlen, wenn er beim tabben nach dem letzten Menüpunkt wieder von vorne anfängt, wo er ja schon war. Und sich dann etwas einfallen lassen muss, um zum nächsten Hauptelement nach dem Menü zu gelangen.
Nö. Sie drückt einfach die Taste, die dafür vorgesehen ist, etwas zu verlassen: escape.
Der Webentwickler hat sich doch sicher etwas einfallen lassen, damit die ESC-Taste funktioniert. Wenn nicht: nachholen.
🖖 Live long and prosper
Hallo
Der Webentwickler hat sich doch sicher etwas einfallen lassen, damit die ESC-Taste funktioniert. Wenn nicht: nachholen.
bei popover ist das schon serienmäßig drin: https://wiki.selfhtml.org/wiki/Benutzer:JürgenB#Zug.C3.A4ngliche_Navigation_mit_popover_und_anchor
Gruß
Jürgen
Nö. Sie drückt einfach die Taste, die dafür vorgesehen ist, etwas zu verlassen: escape.
Der Webentwickler hat sich doch sicher etwas einfallen lassen, damit die ESC-Taste funktioniert. Wenn nicht: nachholen.
Im JS für den resp. Toggle-Klick-Button gibt es neben dem Toggle-Klick auf den Button noch drei close-Gründe für das Menü: ESC, Klick auf einen der geöffneten Menüpunkte, Klick irgendwohin außerhalb des Menüs.
Per ESC das Menü schließen kann der User also ohnehin immer, wenn er will. Die Frage ist aber dennoch, was passiert bei einem resp. Toggle-DD-Hauptmenü im Sinne einer guten Acc. und Usability, wenn ein Tab-User beim letzten Menüpunkt angekommen nochmal tabbed.
Grundsätzlich gibt es offenbar zwei Optionen: er kommt wieder hoch zum Button oder er springt zum nächsten fokussierbaren Element, womit sich dann das Menü auf jeden Fall schließen sollte. Anders als bei JürgenB wäre bei mir das nächste Fokuselement
bei Menü 1 das Menü 2 und
bei Menü 2 die erste anklickbare Überschrift im TOC gleich danach.
Sollte da nicht dieser Fall so im JS noch umgesetzt werden, also dass das Menü schließt und der User zum nächsten Fokus-El. tabbed? Ist es nicht das, was er vermutlich will?
Will er das Menü schließen, wird er wohl ESC nutzen. Und will er sich noch länger im Menü bewegen, kann er wieder zurücktabben.
Liebe(r) Matinee,
Per ESC das Menü schließen kann der User also ohnehin immer, wenn er will. Die Frage ist aber dennoch, was passiert bei einem resp. Toggle-DD-Hauptmenü im Sinne einer guten Acc. und Usability, wenn ein Tab-User beim letzten Menüpunkt angekommen nochmal tabbed.
es ist eine gute Idee, das (Unter-)Menü den Fokus einfangen zu lassen, damit ein Schließen des Menüs nur mit der (in diesem Fall auch sicher vorhandenen) Escape-Taste erreicht werden kann. Wenn man per ESC ein (Unter-)Menü schließt, sollte man den Fokus (wieder) dort haben, wo er vor dem Öffnen des (Unter-)Menüs gewesen ist.
Will er das Menü schließen, wird er wohl ESC nutzen. Und will er sich noch länger im Menü bewegen, kann er wieder zurücktabben.
Meine Meinung weicht da etwas von der Deinen ab, aber mit genügend Testpersonen kannst Du bestimmt einen sinnvollen Trend ermitteln, um für diesen dann zu entwickeln.
Liebe Grüße
Felix Riesterer
Hallo Felix,
danke für deine Gedanken.
es ist eine gute Idee, das (Unter-)Menü den Fokus einfangen zu lassen, damit ein Schließen des Menüs nur mit der (in diesem Fall auch sicher vorhandenen) Escape-Taste erreicht werden kann. Wenn man per ESC ein (Unter-)Menü schließt, sollte man den Fokus (wieder) dort haben, wo er vor dem Öffnen des (Unter-)Menüs gewesen ist.
Meine Meinung weicht da etwas von der Deinen ab, aber mit genügend Testpersonen kannst Du bestimmt einen sinnvollen Trend ermitteln, um für diesen dann zu entwickeln.
Wenn ein Tab-User das geöffnete Menü per ESC schließt, egal, wo er sich im Menü gerade befindet, dann ist er wieder beim fokussierten Button. Das macht JS. Das ist im Moment der Stand der noch nicht fertig umgestellten Site; ebenso der Umstand, dass beim Verlassen des Menüs per Tab beim letzten Menüpunkt das Menü sich NICHT schließt und der Fokus zum nächsten Fokus-Element wandert.
Ich kenne ehrlich gesagt niemanden, der sich als Testperson eignet, weil er ein Tastatur-User wäre. Ich kenne lediglich die Aussage einer seriösen Quelle zur Usability eines DD-Untermenüs desktop, wonach ein weiterer Tab beim letzten Menüpunkt zum nächsten Haupt-Item der Nav führen und das Menü schließen solle.
Ich fasse mal die Optionen zusammen zur Frage "was sollte passieren, wenn ein Tab-User beim letzten Menüpunkt einer ausgeklappten resp. DD-Haupt-Nav oder DD-Untermenü desktop. So wie ich es bisher verstanden habe:
Offenbar ist nach Meinung der meisten hier Option 2 die Beste.
Hallo Matinee,
probiere mal :focus-visible statt :focus.
Damit solltest Du den Fokusring nur bei Tastaturnavigation sehen.
Darf ich Dir übrigens die :is()-Pseudoklasse und CSS-Schachtelung ans Herz legen? Das spart Schreibarbeit und Wiederholungen in den Selektoren.
Alt
button.headnav-button:focus, button.sidenav-button:focus {
outline: 4px solid #a00565;
outline-offset: -9px;
}
button.headnav-button:active, button.sidenav-button:active {
background-color: #c1ffc1;
}
Modern
button:is(.headnav-button, .sidenav-button) {
&:hover {
box-shadow: 0px 0px 0px 4px #fca497;
}
&:focus-visible {
outline: 4px solid #a00565;
outline-offset: -9px;
}
&:active {
background-color: #c1ffc1;
}
}
Das & ist nicht immer nötig, hier aber schon, weil der äußere Selektor erweitert werden soll.
Rolf
Hallo Rolf,
das mit dem "is" habe ich noch nie gehört. Ich bin ja nur Hobby-Coder, aber es ist doch erstaunlich, dass es Dinge gibt, die mir noch nicht mal entfernt vom "Hörensagen" irgendwann begegnet sind.
focus-visible funktioniert wie beschrieben, aber einen FI nur bei Tastatur-Usern zu haben... das ist dann wohl im Sinne der Acc. zu wenig.
Wenn die Funktion von focus bei einem DD-Menü so ist, dass das dann immer als sichtbarer Fokusring bestehen bleibt und sowohl die User als auch die diversen Geräte darauf eingestellt sind, dann werde ich keine Sonderlösung für mich anstreben.
So ganz subjektiv gefühlt hatte ich erwartet, dass beim Öffnen eines DD-Menüs der sichtbare Fokus vom geklickten Button verschwindet. Aber wenn es nicht so ist und das ganz normal ist, dann o.k. Die Usability/Acc. muss für die User gut sein und nicht meine eigenen Bedien-Erwartungen erfüllen.
@@Matinee
focus-visible funktioniert wie beschrieben, aber einen FI nur bei Tastatur-Usern zu haben... das ist dann wohl im Sinne der Acc. zu wenig.
Nö, wieso?
focus-visible
ist genau dafür, dass die Fokus-Markierung erscheint, wenn sie gebraucht wird, und nicht erscheint, wenn sie nicht gebraucht wird.
🖖 Live long and prosper
Hallo Matinee,
So ganz subjektiv gefühlt hatte ich erwartet, dass beim Öffnen eines DD-Menüs der sichtbare Fokus vom geklickten Button verschwindet.
Was die Frage aufwirft: Wohin denn?
Wenn Du mit Tastatur arbeitest und auf dem DD-Menübutton die Space-Taste drückst, um das Menü zu öffnen, dann gibt's keinen Grund, den Fokus woanders hin zu setzen. Und da ist es auch sinnvoll, den Fokus sichtbar zu halten.
Bei Maus/Touchbedienung gibt es hingegen die Notwendigkeit einer Fokusmarkierung auf der Oberfläche nicht. Die Maus oder dein Finger sind Zeigegeräte, die sich nicht relativ zu irgendeinem Element bewegen, sondern von Dir absolut auf dem Bildschirm positioniert werden und dann per Klick oder Tap eine Aktion auslösen können. Für die Maus ist ein Hover hilfreich, um das per Klick aktivierbare Element zu verdeutlichen. Ein Fokusrahmen auf dem zuletzt per Maus/Tap ausgewählte Element ist hingegen eher nervig, und deshalb wird es auch schon länger nicht mehr angezeigt. Mit :focus-visible kannst Du Dich an dieses Browserverhalten anpassen, die Kompatibilitätsanforderungen an die Web-Plattform haben verhindert, dass das Verhalten von :focus einfach geändert wird.
Rolf
@@Rolf B
Go home, Silbentrennung, you’re drunk! (Safari, iOS)
🖖 Live long and prosper
Hallo Gunnar Bittersmann,
Go home, Silbentrennung, you’re drunk! (Safari, iOS)
Wenn das deutsche Wörterbuch versagt und man guckt, ob im englischen was zu finden ist…
"Men, take your Übutton and space the DD!"
Rolf
Bei Maus/Touchbedienung gibt es hingegen die Notwendigkeit einer Fokusmarkierung auf der Oberfläche nicht. Die Maus oder dein Finger sind Zeigegeräte, die sich nicht relativ zu irgendeinem Element bewegen, sondern von Dir absolut auf dem Bildschirm positioniert werden und dann per Klick oder Tap eine Aktion auslösen können. Für die Maus ist ein Hover hilfreich, um das per Klick aktivierbare Element zu verdeutlichen. Ein Fokusrahmen auf dem zuletzt per Maus/Tap ausgewählte Element ist hingegen eher nervig, und deshalb wird es auch schon länger nicht mehr angezeigt. Mit :focus-visible kannst Du Dich an dieses Browserverhalten anpassen, die Kompatibilitätsanforderungen an die Web-Plattform haben verhindert, dass das Verhalten von :focus einfach geändert wird.
hover habe ich sowieso, auch active, obwohl das selten gebraucht wird.
Ich habe mich mit den ganzen states schon vor längerer Zeit mal intensiver auseinander gesetzt und so ganz allgemein in Erinnerung, dass man aus Gründen der Usability und Acc. gerade bei focus, dem wichtigsten state, kaum zu viel, aber u.U. zu wenig machen kann. Ich erinnere mich noch, dass es mittlerweile ziemlich viele versch. Geräte geben soll und gehandicapte User diese manchmal irgendwie kombinieren ect. ect. Das Fazit war dann "focus im Zweifelsfall immer stylen". Dann kommt noch das neue Barrierefreiheitsgesetz dazu.
Ich muss mir das vielleicht nochmal anschauen, evtl. habe ich da auch was falsch verstanden.
Ich kann es leider nicht selbst testen. Wenn ich focus-visible setze, dann sieht ein Smartphone-User, der auf den Menü-Button ein Mal tapped, keinen Fokusring und wenn er das Menü öffnet (2. tap oder gleich Doppeltap) auch nicht? Die mobile-Browser machen das alle (?) mittlerweile auch so und verzichten auf ein entsprechendes Browserdefault?