Pure CSS: Accessible responsive nav

[marctrix]

Hej beatovich,

War nicht leicht zu verfolgen, wo's happert.

Da sich das ganz auf dem mobile wie ein Accordeon verhält, füllt dieses den ganzen Viewport. Wie kann man da eine Sektion schliessen? Man muss auf den deakivierten Link der den aria-page=current entspricht nochmal klicken. So was muss man aber erst rausfinden.

Ja kann man, muss man aber nicht, da alle Inhalte auch bei geöffnetem Menü erreichbar bleiben. Diese werden lediglich nach unten verschoben (hatte das erst anders, also so, dass sich das Menü über die Inhalte legt — das gefiel mir aber nicht, weil man das Menü dazu nämlich wieder schließen müsste.

Ich find das so jetzt besser.

Das überdecken von Inhalten mag ich nicht und wenn man so etwas will, findet man ja genug Alternativen. Das muss ich nicht genauso noch einmal bauen…

Zur Demo

Ich bin sicher, man kann diese Demo noch besser (= als real world applikation überzeugender) ausarbeiten.

Die entscheidende Frage ist ja die, würde der Verfasser selbst diese Demo anwenden?

Sie tut das, was ich mir gewünscht habe. Daher: ja natürlich!

Das einzige, was mir persönlich noch fehlt (weil die Nutzer es so gewohnt sind, nicht weil es nötig wäre): ein Button zum schließen. Mal schauen, wie ich das noch löse.

Im Moment fehlt mir noch die Idee.

Praktisch finde ich die Bedienung gerade bei widescreen per Maus hinderlich, weil ohne Anlass die Boxen aufklappen, ohne dass ich darüber hovere.

Echt? - Das sollte nicht sein! Vielleicht eine ältere Version online gegangen?!?

Dass sich permanent der Bildschirm bewegt und verschiebt ist ein anderes grosses Manko.

Dass sollte nur einmal passieren: wenn man mit der Maus über den ersten Link hovert. Von da an sollte es so bleiben, bis man das Menü schließt, indem man auf eine freie Fläche klickt oder das Menü verlässt (dann kommen die Inhalte freilich wieder hoch. Das sollte aber eine Ausnahme sein, weil man idR wohl über das Menü fährt, um einen Link zu klicken).

Praktisch würde ich es vorziehen, auf die Unternavigation in dem Fall bei nojs ganz zu verzichten, und diese erst mit JS zu ergänzen.

Mit welchem Vorteil?

Besonders muss man aber auch eine Freifläche für das Zuklappen von Navigationen bereitstellen (falls es dazu nicht einen expliziten Button gibt).

Die gibt es. Ich überlege noch, ob ich dazu ein „x“ einblende. Das funktioniert aber noch nicht bei Touch-Geräten.

Daher habe ich das hintenan gestellt.

Aber das zeigt ja nur, wie schwierig das Thema ist.

Yep. Das ist es, hast ja auch schon einiges an Erfahrungen gesammelt.

Selbst meine nav hat Mängel wenn man berücksichtigt, dass focus-within oder details (bei no-js spielen polyfills keine rolle) bei einigen Browsern gar nicht implementiert ist.

details setze ich nicht ein, für das Fehlen von focus-within habe ich als fallback die zweite Navigation, die daher notwendig ist für sehende mausnutzer.

Ich bin auf die nächste Iteration zum Thema gespannt.

Die wird aber nicht in deinem Sinne sein 😉

Das habe ich an deinen Kommentaren hier gemerkt. Umso wertvoller sind die für mich und ich danke dir ganz herzlich!

Auch wenn ich immer „dagegen“ geschrieben habe. Es war eher ein erklären meines Konzepts.

Mir kam es auf drei Dinge an:

1.) das Ding soll schnell sein. Ich mag keine Animationen auf die man warten muss und keine Bibliotheken. 2.) alles kann, nichts muss: es sollte unnötig sein, das Menü zu schließen, daher das verschieben der Inhalte. Da man da u.U. nicht drauf kommt, eventuell noch ein „x“ irgendwo in der Freifläche, wo man auch jetzt sowieso schon klicken kann (viele würden das auch probieren. Warum hat das bei dir nicht geklappt - welche Browser nutzt du?) 3.) Es soll natürlich vollständig zugänglich sein.

Marc