Webblob: Skip Navigation-Links und mehrere Menü-Ebenen

Beitrag lesen

Hallo Mathias,

Verwende ein "source ordered" Layout, d.h. dass die Elemente in der 'richtigen' Reihenfolge im Quelltext stehen.

Also z.B.:
content
section menu
division menu
main menu

Das verlagert das Problem nur.

Ich bin der Meinung, dass man immer ein Problem haben wird, wenn man die (teils) komplexen Inhalte einer Webseite nur der Reihe nach darstellen/ ausgeben kann. Also scheint es in meinen Augen eher darum zu gehen, Prioritäten zu setzen. Womit sich die Frage stellt, was eine höhere Priorität hat - der Content oder die Navigation?

Wenn man mal davon ausgeht, dass viele Websites durchaus aus mehreren Seiten bestehen, wobei sich die Navigation stets wiederholt (der Content jedoch wechseln sollte), stelle ich es mir praktischer vor, wenn zuerst der Inhalt, am besten am Seitenende mit einem Link zur 'nächsten Seite' (sofern eine chronologische Reihenfolge sinnvoll möglich ist), angezeigt wird.

Wenn man einen schnellen Überlick über den Inhalt der Site und den Kontext des Dokuments bekommen will,

reicht bei einem source ordered Layout, bei entsprechend gestalteter Indexseite, eigentlich schon der Auszug, den jede ordentliche Suchmaschine anzeigt!

muss man den gesamten Content-Bereich lesen, um ganz unten die Navigationen zu finden. Dann müsste man also bereits oben irgendwie eine Kontexteinordnung vornehmen. Zum Beispiel durch einen Breadcrumb Trail und einen Link nach unten zur vollen Navigation.

Genau! Für Screenreader bspw. kann man doch trotzdem einen Link vor den Content zur Navigation setzen ala "Skip Content to Navigation" und durch den breadcrumb trail erhält man eine Orientierung, wo man sich befindet.

Das wird ebenfalls ein Tohuwabohu.

Ordentlich gemacht, ist imho aber immer noch die userfreundlichste Variante (s.o.).

Das Problem liegt generell bei der Sitestruktur, die solche Navigationen nach sich zieht.

Das sehe ich auch so.

Muss es soviele Hierarchie-Ebenen geben? Muss auf jeder Seite die komplette Navigation wiederholt werden? Müssen also alle Geschwisterrubriken der ersten Ebene, alle Geschwisterrubriken der zweiten, alle Geschwisterdokumente der dritten Ebene aufgelistet werden? Welchen Umfang hat dann die Navigation (z.B. drei Listen mit je zehn Einträgen)? Ich würde dazu raten, die Navigation zu vereinfachen und zu verkürzen, anstatt die riesigen Blöcke im Dokument herumzuschieben, in der Hoffnung, sie würden unten weniger Konfusion erzeugen als oben.

Ich habe manchmal den Eindruck, dass bei einigen Sites eine 'üppige' Navigation auch viel Inhalt vorgaukeln, bzw. über fehlende Inhalte hinwegtäuschen soll.

Wenn du das nicht willst/ kannst, dann würde ich am ehesten zu Variante A tendieren, vielleicht noch mit Links zu den diversen Submenus am Ende des Contents (diese bei der Screen-Anzeige auf display:none stellen).

Die hierarchische Navigation auseinanderreißen, oben die eine Hälfte, unten die andere? Dass das Übersicht schafft, bezweifle ich.

display:none – wie gesagt, davon wird dann niemand wirklich profitieren.

Nicht mit display:none (siehe anderes Posting), aber mit der anderen Methode haben User mit Screenreadern schon einen Nutzen davon, ohne das Screenuser irritiert/ verwirrt werden.

Ich bin allerdings überzeugt davon, dass die Frage, ob nun der Content vor der Navigation kommen soll oder umgekehrt, genauso zu den 'philosophischen' Fragen zählt, wie die Frage was nun besser
ist em oder px, denn wie eingangs bereits erwähnt, ist mir zumindest keine Methode ohne Nachteile bekannt. Ich lasse mich natürlich gerne eines Besseren belehren.

BTW: Möchte die Gelegenheit (unverschämter Weise) nutzen, nochmal auf meinen eigenen Thread https://forum.selfhtml.org/?t=90660&m=543944 hinzuweisen. Ist ja nicht ganz OT, da es sich bei dem Layout nämlich genau um ein solches source ordered Layout handelt, bei dem leider nach wie vor auch folgendes https://forum.selfhtml.org/?t=90549&m=543184 Problem besteht.

Gruß Gunther