Warum soll die Navigation im Quelltext neuerdings über dem Haupttext stehen?
Bimmelbeule
- html
Hallo!
Warum wird mittlerweile öfter empfohlen im Quelltext die Navigation über dem Haupttext zu positionieren (mit einem unsichtbaren Skiplink für Screenreader)? Beispielsweise auch hier unter:
HTML/Tutorials/Seitenstrukturierung
Wenn ich auf einen Link zu einem Artikel klicke, erwarte ich den Artikel zu Gesicht zu bekommen und nicht erst die Navigation der Seite. Warum sollte das bei Benutzern von Screenreadern anders sein?
Lg, Horst
Lieber Horst,
Wenn ich auf einen Link zu einem Artikel klicke, erwarte ich den Artikel zu Gesicht zu bekommen und nicht erst die Navigation der Seite. Warum sollte das bei Benutzern von Screenreadern anders sein?
wenn Du keinen Screenreader selbst ausprobierst, dann kannst Du in dieser Sache nur vermuten - und gründlich an der Wirklichkeit vorbei herumraten. Schnappe Dir eine kostenlose Screenreader-Version und probiere einmal aus, inwiefern die Reihénfolge der Elemente im DOM überhaupt eine Rolle spielt. Es könnte ja sein, dass diese Software sich vom <main>
-Element so beeindrucken lässt, dass sie es sich aus all dem Code wie eine Rosine herauspickt, um es dem Hörer zu präsentieren.
Im Übrigen haben meine Dokumente folgenden Aufbau (schaue nur nicht auf meine private Website, die ist dermaßen veraltet):
<html>
<head>...</head>
<body>
<main>...</main>
<nav>...</nav>
<header>...</header>
<footer>...</footer>
</body>
</html>
Liebe Grüße
Felix Riesterer
Hi
Wenn ich auf einen Link zu einem Artikel klicke, erwarte ich den Artikel zu Gesicht zu bekommen und nicht erst die Navigation der Seite.
Weil ein Inhaltsverzeichnis und Links auf Unterseiten immer oben sind.
Dank CSS sind die Links nebeneinander und machen nur eine Zeile aus. In einem Flyout-Menü ist es nur ein Zeichen, die Navigation klappt bei Klick aus.
Du solltest auch einen Skip-Link einbauen, um die Navigation überspringen zu können.
Warum sollte das bei Benutzern von Screenreadern anders sein?
Eben, auch die wollen erst das Inhaltsverzeichnis /Angebot sehen oder auf den Skiplink klicken.
Im Übrigen haben meine Dokumente folgenden Aufbau (schaue nur nicht auf meine private Website, die ist dermaßen veraltet):
<html> <head>...</head> <body> <main>...</main> <nav>...</nav> <header>...</header> <footer>...</footer> </body> </html>
ungewöhnlich!?
und dann per CSS absolut positioniert?
CU Duncan
Weil ein Inhaltsverzeichnis und Links auf Unterseiten immer oben sind.
Äh. Nein. Stell Dir mal vor, Du lässt Dir eine Webseite vorlesen und musst immer erst immer dies selbe Litanei über Dich ergehen lassen, bevor Du an diese Inhalte kommst.
Genau so gut kann ein Screenreader auch mit einem Go-Back zum Menü geschickt werden…
Weil ein Inhaltsverzeichnis und Links auf Unterseiten immer oben sind.
Äh. Nein. Stell Dir mal vor, Du lässt Dir eine Webseite vorlesen und musst immer erst immer dies selbe Litanei über Dich ergehen lassen, bevor Du an diese Inhalte kommst.
Richtig! Oder jedesmal den Skiplink drücken müssen, damit man endlich zu dem Ziel kommt, weshalb man überhaupt auf den Link gedrückt hat…
Genau so gut kann ein Screenreader auch mit einem Go-Back zum Menü geschickt werden…
Yep! So rum wird nach meiner Logik ein Schuh draus! Sollte ich doch nicht zu dem Text wollen (oder der Text war nicht das was ich hoffte), DANN drückt man auf den (hoffentlich vorhandenen) Navigationslink am Anfang der Seite.
So wie hier:
Skiplink zur Navigation ganz oben
So denke ich… aber offensichtlich ist man jetzt wieder zu anderen Schlüssen gekommen und mich interessiert der Grund.
Früher (<2010) war die Navigation (fast) immer oben. Dann wurde empfohlen, die Navigation unter den Haupttext zu legen und die Argumentation finde ich noch immer sehr einleuchtend! Aber man empfiehlt seit einiger Zeit offensichtlich, die Navigation wieder an den Anfang des Quelltextes zu stellen… ich kann mir den Grund einfach nicht vorstellen, aber ich bin sicher, das sich dabei jemand was gedacht hat… nur was? ツ
Servus!
Weil ein Inhaltsverzeichnis und Links auf Unterseiten immer oben sind.
Hier geht es um das optische Aussehen. Es spricht nichts dagegen, das HTML-Markup nach dem optischen Aussehen entsprechend zu gliedern.
Äh. Nein. Stell Dir mal vor, Du lässt Dir eine Webseite vorlesen und musst immer erst immer dieselbe Litanei über Dich ergehen lassen, bevor Du an diese Inhalte kommst.
Genau! aber deswegen gibt es den Skiplink. Benutzer von Screenreadern kriegen den Inhalt (auf den sie über die Navigation oder eine Suchmaschine gestoßen sind), können aber mittels Skiplink auf die Navi stoßen.
Richtig! Oder jedesmal den Skiplink drücken müssen, damit man endlich zu dem Ziel kommt, weshalb man überhaupt auf den Link gedrückt hat…
Das ist eben die Frage: Die meisten wollen ja doch die Inhalte, weil sie auf einer Unterseite (via Navi oder Suchergebnis) gekommen sind.
Genau so gut kann ein Screenreader auch mit einem Go-Back zum Menü geschickt werden…
Yep! So rum wird nach meiner Logik ein Schuh draus! Sollte ich doch nicht zu dem Text wollen (oder der Text war nicht das was ich hoffte), DANN drückt man auf den (hoffentlich vorhandenen) Navigationslink am Anfang der Seite.
So wie hier:
Die Seite ist cool, würde ich aber trotzdem nicht so machen!
So denke ich… aber offensichtlich ist man jetzt wieder zu anderen Schlüssen gekommen und mich interessiert der Grund.
Früher (<2010) war die Navigation (fast) immer oben. Dann wurde empfohlen, die Navigation unter den Haupttext zu legen und die Argumentation finde ich noch immer sehr einleuchtend!
Weil du so frühen Versionen von Screenreadern, bzw. Nutzer derselben es erleichtert hast, gleich die Inhalte vorgelesen zu bekommen.
Aber man empfiehlt seit einiger Zeit offensichtlich, die Navigation wieder an den Anfang des Quelltextes zu stellen… ich kann mir den Grund einfach nicht vorstellen, aber ich bin sicher, das sich dabei jemand was gedacht hat… nur was? ツ
Mittlerweile scheinen Screenreader besser zu sein, bzw. die Skiplinks ermöglichen das Auslassen der Navigation mit einem klick.
@Marc Ich habe einen Profi angeschrieben, der viel Erfahrungen mit Barrierefreiheit hat. Wir werden ein Video erstellen, in dem gezeigt wird, wie eine Webseite mit Skiplink und Navi von VoiceOver (Apple/Safari) vorgelesen wird.
Dann wird das ganze anschaulicher!
Bitte gebt uns ein paar Wochen Zeit.
Herzliche Grüße
Matthias Scharwies
@@Bimmelbeule
Früher (<2010) war die Navigation (fast) immer oben. Dann wurde empfohlen, die Navigation unter den Haupttext zu legen und die Argumentation finde ich noch immer sehr einleuchtend! Aber man empfiehlt seit einiger Zeit offensichtlich, die Navigation wieder an den Anfang des Quelltextes zu stellen… ich kann mir den Grund einfach nicht vorstellen, aber ich bin sicher, das sich dabei jemand was gedacht hat… nur was? ツ
Erwartungskonformität. [ISO 9241-110][1][2]
Ich will auf der Webseite das Menü suchen müssen. — kein Nutzer, jemals
Nutzer sind es gewöhnt, die Hauptnavigation auf einer Webseite oben vorzufinden. Oder links. (Schreibrichtung von links nach rechts, Zeilen von oben nach unten vorausgesetzt.) Man bräuchte schon sehr gute Gründe, um von dieser Konvention abzuweichen.
Oben bzw. links heißt: am Anfang im DOM. Die visuelle Reihenfolge sollte der Reihenfolge im DOM entsprechen; andernfalls dürften sehende Tastaturnutzer und sehende Screenreader-Nutzer ziemlich verwirrt sein.
Insbesondere für Tastaturnutzer, die keinen Screenreader nutzen, sind auch die Skip-Links gedacht. Screenreader bieten andere Shortcuts, um auf der Seite zu navigieren (wie ich auch im Artikel Skipper ahoj! schrieb).
🖖 Живіть довго і процвітайте
Servus!
Danke! Hatte bei optisch anstelle von visuell schon ein schlechtes Gefühl, wollte aber nicht mehr nachgucken.
Herzliche Grüße
Matthias Scharwies
@@Gunnar Bittersmann
Ich will auf der Webseite das Menü suchen müssen. — kein Nutzer, jemals
Nutzer sind es gewöhnt, die Hauptnavigation auf einer Webseite oben vorzufinden. Oder links. (Schreibrichtung von links nach rechts, Zeilen von oben nach unten vorausgesetzt.) Man bräuchte schon sehr gute Gründe, um von dieser Konvention abzuweichen.
“Put the navigation on the top of the page where people can find it and don’t have to look for it.”
— Vasilis van Gemert, gerade eben auf der beyond tellerrand (Tweet)
🖖 Живіть довго і процвітайте
Hallo Gunnar,
Erwartungskonformität. [ISO 9241-110]
so wie ich erwarten würde, daß in dieser Seite die Sprungmarke zum "Der Grundsatz der Erwartungskonformität" funktioniert, weil sonst meine Fehlertoleranz überstrapaziert wird.
Grüße, Martl
@@Martl
Erwartungskonformität. [ISO 9241-110]
so wie ich erwarten würde, daß in dieser Seite die Sprungmarke zum "Der Grundsatz der Erwartungskonformität" funktioniert
?? Bei mir funktioniert sie.
🖖 Живіть довго і процвітайте
Moin,
Wenn ich auf einen Link zu einem Artikel klicke, erwarte ich den Artikel zu Gesicht zu bekommen und nicht erst die Navigation der Seite.
Weil ein Inhaltsverzeichnis und Links auf Unterseiten immer oben sind.
optisch oder semantisch „oben“?
Du solltest auch einen Skip-Link einbauen, um die Navigation überspringen zu können.
Sofern nach der Navigation überhaupt noch etwas Spannendes kommt. Im Beispiel von @Felix Riesterer bräuchte es eher einen Link zur Navigation.
Warum sollte das bei Benutzern von Screenreadern anders sein?
Eben, auch die wollen erst das Inhaltsverzeichnis /Angebot sehen oder auf den Skiplink klicken.
Was die wollen wissen nur die – aber wir sollten ihnen die nötigen Werkzeuge (Links) geben, damit sie selbst entscheiden können.
Im Übrigen haben meine Dokumente folgenden Aufbau (schaue nur nicht auf meine private Website, die ist dermaßen veraltet):
<html> <head>...</head> <body> <main>...</main> <nav>...</nav> <header>...</header> <footer>...</footer> </body> </html>
ungewöhnlich!?
und dann per CSS absolut positioniert?
Wieso absolut? CSS bietet noch weitere Arten der Positionierung bzw. „flexible Modelle“ 😉
Viele Grüße
Robert
Warum sollte das bei Benutzern von Screenreadern anders sein?
Eben, auch die wollen erst das Inhaltsverzeichnis /Angebot sehen oder auf den Skiplink klicken.
Es wundert mich über alle Maßen, dass du glaubst, irgendjemand würde, nachdem er einen Inhalt aufgerufen hat, zuerst noch einmal klicken wollen, um den Inhalt angezeigt zu bekommen.
Mich erinnert das an die elendigen Flash-Intros, die vor 20 Jahren mal als Vorschaltseite modern waren:
Stichhaltiger dürfte das hier schon gebrachte Argument sein, dass ein Menü, falls es denn gesucht wird, am Anfang der Seite gesucht wird. Das passiert aber auch erst, nachdem der eigentliche Inhalt betrachtet wurde.
Dieses Argument läuft im Kern auf das Gleiche heraus: Niemand will suchen, weder den Inhalt bzw. eine Möglichkeit, sich dorthin zu klicken, noch das Menü.
Der einzige Grund, dass jemand "das Inhaltsverzeichns sehen will", wäre, dass das Inhaltsverzeichnis der eigentliche Inhalt der Seite ist, also das, was unter dieser URL aufgerufen, mithin erwartet wurde.
Und auch wenn man nicht von sich auf andere schließen soll: Kommt mir eine Seite unter, die wegen uMatrix als rohe HTML-Seite angezeigt wird und dabei erstmal mehrere Bildschirmhöhen Menü präsentiert, bin ich weg. Nutzer von Lesegeräten mögen da aus schierer Abstumpfung schmerzbefreiter sein.
Vermutlich ist der güldene Mittelweg, das Menü zwar HTML-mäßig oben, aber inhaltlich kurz zu halten. Dann ist es dort, wo viele es erwarten, erschlägt niemanden mit seinem Informationsüberfluss – und man braucht vielleicht sogar keinen Verweis zum überspringen.
Hallo,
Es wundert mich über alle Maßen, dass du glaubst, irgendjemand würde, nachdem er einen Inhalt aufgerufen hat, zuerst noch einmal klicken wollen, um den Inhalt angezeigt zu bekommen.
kommt ganz drauf an. Wenn ich über die site-interne Navigation auf eine bestimmte Seite gekommen bin, interessiert mich auch vor allem der eigentliche Inhalt, nicht so sehr die Navigation. Die interessiert mich erst wieder, wenn ich beim Inhalt festgestellt habe, dass das doch nicht ganz das Erwartete ist.
Ganz anders sieht es aus, wenn ich über eine Suchmaschine auf eine bestimmte Seite gelangt bin. Dann möchte ich als erstes die Navigation (das Inhaltsverzeichnis, die Sitemap) sehen.
Warum das? Weil Suchmaschinen in der Regel sehr unscharf arbeiten (vielleicht auch weil meine Suchworte an sich sehr unspezifisch waren). Ich gehe also davon aus, dass die verlinkte Seite ungefähr das enthält, was ich suche. Ob es wirklich genau das ist, möchte ich zunächst anhand des Inhaltsverzeichnisses beurteilen.
Mich erinnert das an die elendigen Flash-Intros, die vor 20 Jahren mal als Vorschaltseite modern waren:
Na gut, der Vergleich ist jetzt weit hergeholt. Aber ja, an solche Ärgernisse erinnere ich mich auch noch sehr gut.
Der einzige Grund, dass jemand "das Inhaltsverzeichns sehen will", wäre, dass das Inhaltsverzeichnis der eigentliche Inhalt der Seite ist, also das, was unter dieser URL aufgerufen, mithin erwartet wurde.
Nein. Siehe oben.
Und auch wenn man nicht von sich auf andere schließen soll: Kommt mir eine Seite unter, die wegen uMatrix als rohe HTML-Seite angezeigt wird und dabei erstmal mehrere Bildschirmhöhen Menü präsentiert, bin ich weg. Nutzer von Lesegeräten mögen da aus schierer Abstumpfung schmerzbefreiter sein.
Wer oder was ist uMatrix?
Einen schönen Tag noch
Martin
Hej Wormalsk,
Mich erinnert das an die elendigen Flash-Intros, die vor 20 Jahren mal als Vorschaltseite modern waren:
Das moderne Pendant hierzu sind (viewportfüllende) Slider: an den Inhalt kommt man erst nach Klick (skip to main-Link vs skip Intro) oder längerem Scrollen.
Geschaut wird beides eher selten nie.
Die Slider selber sind nur in Ausnahmefällen barrierefrei.
Marc (marctrix)
Hallo Felix,
Es könnte ja sein, dass diese Software sich vom
<main>
-Element so beeindrucken lässt, dass sie es sich aus all dem Code wie eine Rosine herauspickt, um es dem Hörer zu präsentieren.
schlechter Vergleich: Rosinen pickt man doch höchstens irgendwo raus, um sie wegzuwerfen.
Einen schönen Tag noch
Martin
Wenn ich auf einen Link zu einem Artikel klicke, erwarte ich den Artikel zu Gesicht zu bekommen und nicht erst die Navigation der Seite. Warum sollte das bei Benutzern von Screenreadern anders sein?
wenn Du keinen Screenreader selbst ausprobierst, dann kannst Du in dieser Sache nur vermuten - und gründlich an der Wirklichkeit vorbei herumraten.
Genau das ist der Punkt! Daher hoffte ich hier Betroffene zu finden oder Menschen die sich mit Screenreadern und Barrierefreiheit auskennen. Zum Beispiel den Autor des Selfhtml-Artikels:
Seitenstrukturierung der Navigation
Es wird ja einen Grund haben, wenn er schreibt:
»Während es früher oft empfohlen wurde, das Navigationsmenü unterhalb des Inhalts am Ende der Seite zu notieren und erst mit CSS oben zu positionieren, ist es heute üblich die Navigation unterhalb des header zu platzieren und Benutzern von Screenreadern bei umfangreichen Menüs einen Skip-Link zum Überspringen anzubieten.«
Schnappe Dir eine kostenlose Screenreader-Version und probiere einmal aus, inwiefern die Reihénfolge der Elemente im DOM überhaupt eine Rolle spielt. Es könnte ja sein, dass diese Software sich vom
<main>
-Element so beeindrucken lässt, dass sie es sich aus all dem Code wie eine Rosine herauspickt, um es dem Hörer zu präsentieren.
Ja, kann sein… aber vielleicht beeindruckt das eine andere Screenreadersoftware nicht… bevor ich selber versuche die Bedürfnisse von blinden Nutzern rauszufinden, hoffte ich das hätten vielleicht schon andere Webworker gemacht…
Trotzdem Danke für den Tipp!
Hej Bimmelbeule,
Deinen Beitrag zitiere ich nicht, weil ich mich an einer Antwort auf den gesamten Thread versuche...
Das kann man in der Tat so sehen. Aber es hat sich nie durchgesetzt, daher gilt all das, was @Gunnar Bittersmann dazu geschrieben hat
Der Screenreader liest es wie jeden Link: "Link: [zugänglicher Name]", also zum. Beispiel "Link zum Artikel"
Nein, ist es nicht. Bei Barrierefreiheit geht es auch gar nicht (in erster Linie) um Benutzerfreundlichkeit, sondern erst einmal darum überhaupt mit einer Website zurecht zu kommen. Auch Menschen ohne Behinderung müssen sich nun mal oft mit grottigen Websites auseinander setzen.
Das ist zwar doof, es gibt aber keinen Rechtsanspruch auf "gut" gemachte Websites.
Da Navigationen und andere Blöcke unter Umständen sehr viele interaktive Elemente besitzen, kann es die Konzentration tatsächlich so stark stören, dass eine Seite de facto nicht mehr zugänglich ist. Daher gibt es die Forderung nach einer Möglichkeit wiederkehrende Blöcke überspringen zu können (Bypass Blocks) - die offizielle deutsche Übersetzung der WCAG 2.1 ist aufgrund formaler Gründe leider immer noch nicht öffentlich verfügbar. Dabei habe ich meine Zustimmung bereits gegeben 😉
Vielleicht mal etwas zu dem Begriff der Barrierefreiheit. Das ist erst mal etwas schwammig und umstritten. Im englischsprachigen Raum redet man von Zugänglichkeit, im deutschsprachigen auch von barrierearm. Dahinter steckt der Gedanke, dass es eine 100%-Barrierefreiheit nicht geben kann, also ein digitales oder physisches Produkt, dass von jedem Menschen unabhängig von der Schwere multipler Behinderungen genutzt werden kann.
Wenn man weder hören, sehen oder Tasten kann wird es naturgemäß schwierig eine Website wahrzunehmen - und wenn die Technik reif ist, Text ins Gehirn "einzuspielen", kann es auch noch sein, dass das Gehirn nicht die nötigen kognitiven Fähigkeiten besitzt, Text zu verstehen.
Aber man sieht schon, solche Fälle muss man konstruieren. Auch Menschen mit so starken Einschränkungen wie Stephen Hawking sind in der Lage mit entsprechender Technik viel zu leisten.
Ich finde es pingelig auf solchen Begriffen rumzureiten, verwende persönlich am liebsten "zugänglich".
Das ist keine Antwort auf die Frage, was Barrierefreiheit ist.
Letztendlich ist es eine Sache der Definition. Im Bereich Barrierefreiheit gibt es neben diversen Definitionen auch noch Standards.
Zum Glück lassen sich sehr viel davon wieder auf einen zurückführen, nämlich die hier bereits genannten Richtlinien für die Zugänglichkeit vom W3C, die sogenannten Web Content Accessibility Guidelines".
Überhaupt nicht, es sei denn, man arbeitet z.B. in der EU für den öffentlichen Dienst.
Es gibt Länder, die haben die Barrierefreiheit nämlich gesetzlich als ein Recht festgelegt. Dazu gehören alle Mitgliedsstaaten der EU und ein paar weitere, nämlich als, die in der europäischen Freihandelszone mitmischen wollen (sogenannte EFTA-Staaten). Hier will man für gleiche Rechte und Pflichten sorgen.
Bleiben wir in der EU, weil das schon kompliziert genug ist und uns hier betrifft.
Die EU hat einen Katalog mit Forderungen geschrieben, die europäische Norm EN 301 549 (aktuell Version 3.2.1), in welcher steht, was man erfüllen muss, um die gesetzlich geforderten Mindestbedingungen zu erfüllen.
Neben den gesetzlichen Vorgaben, die einen aber womöglich nicht betreffen, weil man nicht in den Geltungsbereich der Barrierefreien Informationstechnik Verordnung oder dem Barrierefreiheitsstärkungsgesetz fällt, gibt es aber viele gute Gründe barrierefrei zu sein. Unter anderem handvolle ökonomische (Stichwort Wettbewerbsvorteil), aber natürlich auch ethische usw
Insofern komme ich wieder zum Anfang des Threads: was soll man nun machen.
Ein soll im Sinne von einem "Muss" oder einem Weg, der am besten ist, gibt es nicht.
Abhängig von der Anwendung und der konkreten Anwendung können sogar gegensätzliche Ansätze sinnvoll sein.
Wenn man von den Vorteilen von content first überzeugt ist, kann man eine Navigation an das Ende einer Anwendung setzen, wenn es sich um eine bekannte geschlossene Nutzergruppe handelt, der ich sagen kann, dass sich die Navigation unten befindet. Dann kommt es nicht zu der von Gunnar beschriebenen Sucherei.
In allen anderen Fällen wird es sinnvoll sein aus den ebenfalls von Gunnar genannten Gründen, die Navigation "vorne" anzubieten (vermeide "oben" oder "links" - so etwas gibt es für manche Leute nicht 😉).
Die WCAG selber, auf die sich fast alle beziehen, ist bewusst technikneutral verfasst. Es gibt zwar Beispiele, wie man bestimmte Forderungen erfüllen kann, aber man kann gerne auch andere funktionierende technische Lösungen verwenden, die dort nicht genannt werden (viel Spaß bei der Suche).
So wird beispielsweise gefordert, dass für jedes Nicht-Text-Element (z.B. ein Bild) eine Text-Alternative bereit gestellt wird. Aber niemand verlangt, dass das technisch mittels eines Wertes im alt-Attribut zu machen ist. Das ist zwar sinnvoll (oft), aber man darf die Textalternative auch im direkten Kontext hinterlegen, per aria darauf verweisen, das Bild mit dem Text verlinken uswusf
Also auch hier wieder: es gibt unterschiedliche Herangehensweisen und was man als Entwicklerin oder Nutzerin am besten findet, ist ganz oft persönlicher Geschmack…
Marc (marctrix)
Servus!
Hej Bimmelbeule,
Deinen Beitrag zitiere ich nicht, weil ich mich an einer Antwort auf den gesamten Thread versuche...
Vielen Dank!
Das wäre auch ein gutes Thema für den Blog!
So wird beispielsweise gefordert, dass für jedes Nicht-Text-Element (z.B. ein Bild) eine Text-Alternative bereit gestellt wird. Aber niemand verlangt, dass das technisch mittels eines Wertes im alt-Attribut zu machen ist. Das ist zwar sinnvoll (oft), aber man darf die Textalternative auch im direkten Kontext hinterlegen, per aria darauf verweisen, das Bild mit dem Text verlinken uswusf
Das ebenfalls: Titel: Alternativen zum alt-Attribut
Herzliche Grüße und ein schönes Wochenende!
Matthias Scharwies
Hej Matthias,
Deinen Beitrag zitiere ich nicht, weil ich mich an einer Antwort auf den gesamten Thread versuche...
Vielen Dank!
Das wäre auch ein gutes Thema für den Blog!
Du meinst den Beitrag hier?
Das ebenfalls: Titel: Alternativen zum alt-Attribut
Da weiß ich gar nicht, wo ich da anfangen und aufhören soll. Habe das in Vorträgen mal besprochen. Die dauern eine Stunde.
Mal so als Inspiration:
alt
-Attributaria-describedby
figcaption
...Nur gilt auch hier: nicht alles, was man letztlich noch als "konform zur WCAG/ EN 310549" durchgehen lassen kann ist dann sinnvoll.
Wie immer ist es wichtige ein Konzept zu haben, dass man konsistent umsetzt, so dass Nutzer möglichst ohne (großen) Lernaufwand das Produkt intuitiv bedienen können.
Übrigens sind konsistente Navigation und konsistente Bezeichnungen auch Forderungen der Barrierefreiheit.
Marc (marctrix)
Sorry, hat ein bisschen gedauert mit der Antwort…
Warum steht die Navigation oben, es gibt ja gute Gründe, das anders zu machen
Das kann man in der Tat so sehen. Aber es hat sich nie durchgesetzt […]
Ah, hat sich nie durchgesetzt… okay, DAS ist wohl an mir vorbei gegangen… ich dachte, es hätten sich neue Argumente ergeben, warum die Navigation jetzt wieder ganz oben sein sollte… das war mein Denkfehler.
Ich war auch bisher der Meinung, das wenn ich die Seiten einigermaßen logisch mit dem Textbrowser lynx lesen und navigieren kann, wären sie auch rudimentär barrierearm (im Sinne von, zumindest dem Leser keine Knüppel zwischen die Beine werfen). Ich Kitz! ツ
Danke für die Aufklärung! Ich habe mir eure Argumente durch den Kopf gehen lassen.
Erstmal fand ich das "Ist man so gewohnt"-Argument eher schwach. Ich denke, das die Tastatur- und/oder Screenreadernutzer in der Praxis durchaus mit meinen Seiten zurecht kämen (sehend oder nicht). Vermutlich sind die notgedrungen noch ganz andere Dinge "gewöhnt"…
Letztendlich hat mich aber doch das "Standard"-Argument überzeugt, das die Logik dem DOM folgen sollte. Schließlich bin ich ein Anhänger des KISS-Prinzips (alles so einfach wie möglich zu halten). Außerdem sehe ich ein, das "Navigation unten" sehende Tastaturbenutzer verwirren könnte (ich hatte mal einen querschnittgelähmten Bekannten, der die Tastatur mit dem Mund und einem Plastikstab bediente). Und nicht zu letzt bin ich selbst ein Gewohnheitstier…
Ich werde es jetzt mit dem Konzept "Navigation oben" probieren. Hier mal eine Testseite (bisher nur das Gerüst für mobil). Ich habe die Navigation also im Quelltext nach oben gelegt und sie per CSS in ein Hamburger-Menü gesetzt wie hier beschrieben:
Flyout-Menü Alternative: details
Auch habe ich nach dieser Beschreibung einen Skiplink zum Inhalt angelegt:
Skipper Ahoi
Wäre diese Testseite bis hierhin jetzt standardkonform?
Testseite Navigation oben
@@Bimmelbeule
Auch habe ich nach dieser Beschreibung einen Skiplink zum Inhalt angelegt:
Skipper Ahoi
Ah, da war ja noch was. @Rolf B verwies mich unlängst auf ein Update des von mir verlinkten Artikels. Womöglich ist tabindex="-1"
keine so gute Idee mehr. Ich muss mir das nochmal ansehen, ggfs. meinen Artikel aktualisieren.
🖖 Живіть довго і процвітайте