Wenn Sie googeln, ob Sie Listen als Markup für die Navigation auf Websites verwenden sollten, werden Sie keine Debatte finden. Jeder Artikel deutet darauf hin, dass Sie es tun sollten. Die überwiegende Mehrheit der Tutorials, die Sie lesen, wird Listen für die Navigation verwenden. Die überwiegende Mehrheit der Vorlagen, die Sie sehen, wird Listen für die Navigation verwenden. Aber ist dieses allgegenwärtige Markup-Muster absolut korrekt? Lassen Sie es uns herausfinden.
Was Sie heute wahrscheinlich sehen werden
<nav>
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About</a></li>
<li><a href="#">Clients</a></li>
<li><a href="#">Contact Us</a></li>
</ul>
</nav>Oder vor HTML5 gäbe es kein <nav>-Tag, sondern <ul class="nav">
Alternative: Listenlose Navigation
<nav>
<a href="#">Home</a>
<a href="#">About</a>
<a href="#">Clients</a>
<a href="#">Contact Us</a>
</nav>Eine alte Schlacht
2005: Bruce Lawson führt tatsächliche Forschung mit Screenreadern durch. Die Schlussfolgerung war, dass Listen am besten sind, aber es wurde mit der Kennzeichnung von Listen in Tabellen verglichen, was Sinn macht.
2007: Ich habe über listenlose Navigation gepostet und Dustin Brewer widersprach vehement, dass dies jemals verwendet werden sollte. Dustins Artikel spricht über Semantik, Barrierefreiheit und Screenreader, hat aber keine Forschung und erklärt nicht, warum die listenlose Navigation unsemantisch ist oder Screenreader-Probleme verursachen würde.
Reinhard Stebner betritt die Bühne
Im Januar 2011 sprach Reinhard bei einer Refresh-Veranstaltung in Baltimore und hinterließ anscheinend einen RIESIGEN Eindruck beim Publikum. Er ist komplett blind und spricht über Markup-Barrierefreiheit.
Reinhard schlägt vor, keine Listen für die Navigation zu verwenden, sondern stattdessen Divs und Spans.
Leah Vogely war bei der Veranstaltung und schreibt
Ich glaube, jeder im Raum kratzte sich am Kopf, als das gesagt wurde. Eines der ersten Dinge, die man beim Codieren lernt, ist, wie man eine Navigation strukturiert, und das geschieht normalerweise mit einer ungeordneten Liste. Diese Listenstruktur ist jedoch der Logik des Screenreaders nicht zuträglich. Das Span-Tag wird vom Screenreader nicht erkannt, daher ist es eine der Möglichkeiten, Ihren Inhalt für die Barrierefreiheit zu vereinfachen.
Ein weiterer Teilnehmer schreibt:
Divs und Spans sind der richtige Weg, da sie für Screenreader unsichtbar sind. Stebner tabulierte durch die viel zu vielen Listen auf mica.edu und sie gaben ihm keinerlei Hinweise darauf, wo er sich auf der Seite befand, und keine Informationen außer „Liste, 10 Elemente. Liste, 6 Elemente…“ Mit Divs und Spans ist der Inhalt sofort für die Screenreader verfügbar.
Jim Doran war auch dabei
Eine Navigationsstruktur, die lediglich eine Sammlung von Hyperlinks ist, in eine Liste zu packen, soll Screenreadern ermöglichen, zwischen jedem Link zu pausieren, anstatt alle Links als einen Satz zu lesen. Semantisch macht das Sinn. Wir verwenden HTML, um Inhalten aussagekräftiges Markup zuzuweisen – Dinge zu Listen zu machen, scheint eine gute Idee zu sein. Dennoch gibt es keine einfache Möglichkeit, eine Liste als eine Reihe von Links zu identifizieren, sodass eine Seite mit 12 Linkgruppen sehr verwirrend sein kann. Er demonstrierte dies mit Jaws.
Wir haben ARIA als eine Möglichkeit angesprochen, damit umzugehen, und anstatt Listen für Links zu verwenden, würde er gerne mehr
<div>und<span>s sehen.
Reinhard Stebner hat es ziemlich deutlich gemacht. Er benutzt JAWS als Screenreader und Navigation in Listen macht es ihm schwerer.
VoiceOver
Alle bisher erwähnten Forschungen bezogen sich auf JAWS. Nach meinem Verständnis ist JAWS der beliebteste Screenreader. Es gibt auch den nativen VoiceOver, der auf OS X verfügbar ist. Bei meinen Tests navigiert VoiceOver auf genau die gleiche Weise, ob es sich in einer Liste befindet oder nicht. So wie Cross-Browser-Tests wichtig sind, sind auch Cross-Screenreader-Tests wichtig.
HTML5
Einige dieser Gespräche liegen vor der weit verbreiteten Verwendung von HTML5. HTML5 verfügt über das <nav>-Tag, das meiner Meinung nach das Semantik-Argument beilegt. Wenn Sie Navigation kennzeichnen, fügen Sie sie in ein <nav>-Tag ein. Anstelle von HTML5 oder wenn Sie einfach ein anderes Wrapperelement verwenden müssen, haben Sie die ARIA-Rolle: <div role="navigation">.
Update: Auf Nachfrage sollte man die ARIA-Rolle auf dem nav-Tag verwenden, auch wenn sie impliziert ist, da einige Browser sie nicht so anwenden, wie sie es sollten. Also <nav role="navigation">. Danke Dave!
Die Spezifikation
Sagt:
Ein Nav-Element muss keine Liste enthalten...
Und zeigt dann ein Beispiel für einen Navigationsabsatz.
Inline vs. Block
Keine Liste für die Navigation zu verwenden, bedeutet, dass die Links in einer Reihe angeordnet werden, anstatt wie bei einer Standardliste jeder in einer neuen Reihe. Ich persönlich finde das eine praktische leere Leinwand und genieße es, keine User-Agent-Stylesheet-Stile für Listen entfernen zu müssen. Sollten Sie möchten, dass Links wie eine Liste funktionieren, könnten Sie jederzeit die display-Eigenschaft für die Links über CSS ändern.
Also
Was denkst du? Sinnlose Verfolgung? Eine würdige Diskussion?
Ich persönlich bin schon eine ganze Weile listenfrei. Solange ich keine solide Forschung sehe, die das für dumm erklärt, bleibe ich dabei. Wie immer wäre es am besten, mehr Informationen von echten Screenreader-Benutzern wie Reinhard zu erhalten.
Und wenn wir weiterhin Listen verwenden, warum ist es immer eine ungeordnete Liste? Ich erinnere mich, wie Ryan Singer einmal deswegen ausgeflippt ist. Steht es nicht außer Frage, dass wir die Reihenfolge dieser Liste sehr bewusst gewählt haben?
Stellen Sie sicher, dass Sie den Zusammenfassungsbeitrag darüber lesen, was wir nach diesem Beitrag über all dies gelernt haben.
Was ist mit verschachtelter Navigation?
Auch hier bin ich neugierig – Listen bieten eine großartige Hierarchie für Unterlinks. Gibt es eine empfohlene Methode, dies ohne Listen zu tun?
Man kann auch
<div>s verschachteln... Aber mich würde vor allem interessieren, was ein Screenreader-Benutzer dazu zu sagen hat. Sicherlich muss das Untermenü bei :focus ausgelöst werden.Sie können Elemente in Linkelemente verschachteln, sollte keinen Unterschied machen. Es sei denn, Sie sprechen von etwas Komplizierterem?
Ich denke mehr über den Vorteil der natürlichen Hierarchie nach. Auch ohne CSS werden Navigation und ihre Untermenüs in einer Liste brauchbar angezeigt, mit deutlich gekennzeichneten Ebenen.
Interessantes Thema. Ich bin zu einer listenlosen Navigation gewechselt, habe aber noch keine verschachtelte Navigation damit gemacht.
Wenn ich ein <div> verwende, bedeutet das, dass es in das übergeordnete <a>-Tag eingefügt werden sollte, richtig?
Ich habe versucht, es auf jsfiddle zu tun, das verschachtelte <div> wird nicht als Kind, sondern als benachbartes Element erkannt. Und man kommt nicht zur Unter-Navigation, da sie verschwindet, wenn man den übergeordneten Link verlässt. Stimmt etwas mit diesem Code nicht?
Ein NAV-Element ist ein Gliederungselement. Und Sie können einfach NAV in ein anderes NAV verschachteln, um so Unterabschnitte zu erstellen (streng genommen sollte jedes NAV eine Überschrift haben, wenn nicht, erhält es eine implizite „leere Überschrift“).
@Marc Racho: In Ihrem jsfiddle haben Sie Links (A) in einen anderen Link verschachtelt, dies ist NICHT erlaubt.
Ich wünschte, ich könnte meine eigene Antwort korrigieren. Während man ein NAV in ein NAV verschachteln kann, wäre es offensichtlich besser, ein SECTION zu verwenden, um Untermenüs zu erstellen.
Man kann jedoch keine Link-Elemente in Link-Elementen verschachteln. Das wäre sowohl mehrdeutig als auch ungültig.
@Evert – das war es, was ich tatsächlich dachte, man kann keinen Link in einen anderen Link verschachteln. Aber ja, ich habe missverstanden, was Chris über die Verschachtelung von <div>s gesagt hat LOL, es hätte so sein sollen.
Ich denke, das Verschachteln von DIVs/SPANs könnte uns immer noch im gleichen mentalen Modell halten wie die Verwendung von UL & LI. Vielleicht sollten „verschachtelte“ Menüs mit NAV eher so aussehen: http://jsfiddle.net/g4kMG/1/ (Ich habe jedoch keine Auswirkungen davon untersucht).
Ich habe UL & LI für Navigationsmenüs verwendet, weil ich glaubte, dass Screenreader zwischen dem Vorlesen jedes Listenelements pausierten. Wenn sie zwischen den Links innerhalb von NAV pausieren, ist das meiner Meinung nach in Ordnung.
Ich bin so froh, dass du das aufgeschrieben hast, Chris – auch ich habe mich gefragt, warum jeder Listen für die Navigation verwendet und sich dann die Zeit nimmt, Stile zu schreiben, die die meisten, wenn nicht alle, der standardmäßigen Listenattribute entfernen, um sie nicht wie Listen aussehen zu lassen. Danke!
Und übrigens, ich stimme zu, es scheint, „sie“ sollten geordnete/ungeordnete Listen in nummerierte/aufzählungslisten umbenennen, denn beide sind von Natur aus durch die Reihenfolge geordnet, in der man sie codiert, wie du es angedeutet hast.
Sie als „nummeriert“ oder „aufgezählt“ zu bezeichnen, bindet sie an die Präsentation – nicht an die Definition, wie sie behandelt werden sollten.
„Ungeordnet“ bedeutete nie, dass Elemente zufällig angezeigt würden: lediglich, dass ihre Anzeigereihenfolge willkürlich ist und dass eine Neuanordnung keine negativen Auswirkungen auf ihre Bedeutung hätte.
Ja, aber könnte man nicht argumentieren, dass „nummerierte“ Listen mehr als nur die Präsentation implizieren könnten, so wie „geordnete“ Listen – was bedeutet, dass sie aus einem bestimmten Grund nummeriert sind, um eine „Ordnung“ anzuzeigen? Designer, die Adobe-Produkte wie InDesign verwenden, würden dies sicherlich bejahen, da die beiden Arten von Listen, über die wir sprechen, geordnete und ungeordnete in HTML-Markup, als nummerierte und Aufzählungslisten bezeichnet werden und dasselbe gilt für die meisten Texteditoren. Nur in HTML scheinen wir sie anders zu nennen. Dasselbe passiert, wenn ich eine geordnete Liste in HTML neu anordne, wie wenn ich eine nummerierte Liste in einem Word-Dokument neu anordne. Ich verstehe nicht einmal, warum wir mehr als nur eine „Liste“ brauchen. Lassen Sie mich einfach einen Stil dafür festlegen, um zu bestimmen, ob wir Aufzählungspunkte oder Zahlen oder was auch immer verwenden, und lassen Sie die Liste sich entsprechend verhalten, wobei das erste li #1 oder Buchstabe ‚A‘ oder was auch immer darstellt… wenn ich das besagte Stilattribut deaktiviere, könnte es auf „Aufzählungszeichen“ anstelle von Zahlen zurückfallen. In beiden Fällen ordne ich die Liste hinter den Kulissen an.
Fürs Protokoll: Ich stimme zu, dass aus der Sicht des Benutzers eine nummerierte Liste eine andere Bedeutung vermittelt als eine lediglich Aufzählungsliste – nämlich, dass die Reihenfolge wichtig ist (z.B. Gold, Silber, Bronze). Worüber ich jedoch spreche, ist hinter den Kulissen – im Code wird alles dadurch bestimmt, wie ich, der Entwickler, jedes Listenelement anordne, unabhängig davon, ob ich <ol> oder <ul> verwendet habe. Eine geordnete Liste, die Bronze, Gold, Silber lautet, macht für den Benutzer nicht mehr Sinn als eine ungeordnete Liste, die Gold, Silber, Bronze lautet. Der Punkt ist, es kommt immer noch darauf an, dass ich, der Entwickler, den Code für sowohl geordnete als auch ungeordnete Listen korrekt anordne.
Aufzählungspunkte und Zahlen werden mit CSS angewendet. Sicher, ols haben automatisch Zahlen und uls automatisch Aufzählungszeichen, aber uls können beliebig viele Indikatoren haben, und noch wichtiger, ols könnten a. b. und c. statt 1. 2. und 3. sein.
Geordnet und ungeordnet mag etwas umständlich sein, aber sie sind immer korrekt, unabhängig vom Stil.
Das mag ein Neuling-Kommentar sein, aber warum kann Sass nicht etwas wie das Listen-Markup innerhalb eines Navigations-Tags in der Vorverarbeitung hinzufügen?
Sass (und scss und less und stylus) manipulieren nur Ihr CSS. Es berührt das Markup nicht. JQuery wäre wahrscheinlich am besten, wenn Sie diesen Weg gehen wollten.
Das scheint etwas zu sein, womit der JAWS-Browser besser umgehen könnte. Ich schätze, das wäre heutzutage ein ziemlich häufiges Problem.
Ich stimme dem zu. Man hätte denken müssen, dass, wenn die Verwendung von Listen die De-facto-Methode ist, sie damit umgehen könnten. Man könnte dem ul eine Rolle hinzufügen, und der Reader könnte das verwenden.
Es ist verrückt, dass das eine, womit JAWS nicht sehr gut umgehen kann, die Navigation ist? Scheint ein großes Versäumnis zu sein?
Genau das habe ich die ganze Zeit gedacht, als ich das gelesen habe. Wir haben semantische Tags genau aus diesem Grund. Sollten sie nicht die Erfahrungen ihrer Nutzer bewerten und Wege finden, diese Nuancen zu verbessern/zu beheben? Das ist (größtenteils) in der Welt der regulären Webbrowser der Fall.
Ich gehe davon aus, dass so etwas wie HTML5 Shiv einen ziemlich guten Job beim Fallback für IE macht?
Ich verwende Listen für das Menü. Da meine Seite hauptsächlich für 3D ist, glaube ich nicht, dass die Blinden es stören werden, ob es eine Liste gibt oder nicht, da sie die Bilder sowieso nicht sehen können. Ich werde aber wahrscheinlich weiterhin Listen verwenden.
Zur Info: Screenreader werden auch von sehbehinderten Nutzern verwendet, nicht nur von blinden Menschen. Nicht alle sehbehinderten Nutzer, es hängt von vielen Faktoren ab, aber diese werden Ihre Seite sehen und/oder über ihre Screenreader anhören.
Eine UL ist angemessener als eine OL, da es sich nicht um eine Abfolge von Ereignissen handelt, die in einer bestimmten Reihenfolge ablaufen MÜSSEN. http://www.w3.org/TR/html401/struct/lists.html
Ich habe immer gedacht, dass die Spezifikation geändert werden sollte, um das Nav-Element als eine spezielle Art von Liste zu behandeln. Wäre es nicht sinnvoll, alle Links in einem Nav als NavItems zu haben?
Ich persönlich verwende immer Listen für die Navigation, weil ich das Gefühl habe, dass jedes Navigationselement ein Teil davon ist.
Was ich aber wirklich nicht mag, ist
nav > ul > li, zu viele Elemente. Warum nicht einfachnav > li. Ok, es ist nicht semantisch, aberul.nav > liist weniger semantisch im Sinne der HTML5-Spezifikation, wonavfür die Navigation konzipiert ist. Was ist also der Plan?.navist lediglich der Name einer HTML-Klasse, es hat keine Semantik, keine Bedeutung außer für uns Webdesigner und Webentwickler, die den Quellcode sehen (hier nicht von Mikrodaten sprechend, für die Barrierefreiheit im Moment irrelevant).navist ein HTML5-Element, und Sie können ihm beliebige Klassen hinzufügen, sie werden seine Semantik nicht ändern.Sind es zu viele Elemente, die Ihrem Code hinzugefügt werden? Nun, im Allgemeinen fügen Sie Ihrer Seite 1 Navigation hinzu, vielleicht 2 oder 3. Mehr davon ist eher ungewöhnlich, daher ist es meiner Meinung nach keine große Sache, da es viel bringt.
Wenn Sie kein
nav > ul > limachen wollen, können Sienav limachen, das alle Listenelemente innerhalb Ihres navs auswählt.nav > lifunktioniert nicht, da Sie keine li's als direktes Kind von nav haben.Ich mag diesen Ansatz. Ich hasse es, die Listenstile zu löschen, um meine Navigation anzupassen, und ich habe mich schon länger gefragt, warum die meisten unserer Community an diesem Listen-Navigations-Ding festhalten. Wenn also sowohl ich als auch die Leute, die Seiten mit einem Screenreader lesen, von einer nicht gelisteten Navigation profitieren können, warum sollte ich dieses Muster nicht ändern? Ich mag es sehr, danke Chris und all den Leuten, die geholfen haben, das herauszufinden.
Ich persönlich mag die UL innerhalb der NAV. Aber wie bei allem gibt es mehrere Möglichkeiten, eine Navigation zu erstellen.
Aber ich mag die NAV ohne UL und LI-Elemente darin. Jeder nach seinem Geschmack.
Es ist zur Routine geworden, die UL als Navigationsprozess zu verwenden.
Ich stimme dir zu, Chris. Ich habe die Verwendung von ul als Navigationsblock aufgegeben, da der semantische Zweck mit der Einführung des Nav-Elements verloren ging. Eine ul innerhalb eines Navs fühlt sich redundant an.
Wie codiert man Unterpunkte?
Das würde Dropdown-Menüs ziemlich schwierig machen… Lol.
Wie wäre es stattdessen mit verschachtelten NAVs? Dann ist es nicht so schwer. nav class="top-level" und nav class="sub-level".
Ich wollte nur etwas über die Benennung „ungeordnet“ und „geordnet“ klarstellen. Die Namen kommen von der Idee, dass Elemente entweder ordinal sind oder nicht. Natürlich ist jede Liste in einer Reihenfolge, aber in einigen Fällen spielt die Reihenfolge keine Rolle, mit anderen Worten, der Platz jedes Elements in der Liste ist willkürlich. In einigen Listen spielt die Reihenfolge jedoch eine Rolle, daher ist es sinnvoll, Ziffern oder Buchstaben zu verwenden, um diese Reihenfolge zu kennzeichnen. Die Navigation ist in einer Reihenfolge, die vom Designer oder Entwickler festgelegt wird, aber wir betrachten die Navigation normalerweise nicht als ordinal. Wohingegen eine Top-Ten-Liste ordinal ist und die Position eines Elements in der Liste eine Bedeutung in Bezug auf seine nummerierte Position hat.
Ich bevorzuge die Verwendung einer Liste, da sie mir viele zusätzliche Elemente kostenlos bietet (die Handles zum Stylen sind – denken Sie an Rollovers und hinzugefügte Symbole), auch in Nicht-CSS-Umgebungen gut rendert (wie ein RSS-Reader, der ein Inhaltsverzeichnis mit Ankern im Dokument anzeigt) und sie fügt Platz zwischen Links hinzu, was die Bedienung auf Touch-Geräten erleichtert, ohne etwas stylen zu müssen.
Screenreader sind verdammt langsam in der Aktualisierung und variieren immens zwischen verschiedenen Versionen. Ich denke, ARIA kann das alles einfacher machen, aber ich habe schon vor langer Zeit aufgegeben, etwas als zugänglich oder nicht zu bezeichnen, wenn es in Jaws funktioniert.
Barrierefreiheit hat viele Facetten, blinde Nutzer sind nur eine Gruppe, um die man sich kümmern muss. Jemand mit Legasthenie oder Lernschwierigkeiten könnte von einer richtigen Listenstruktur, insbesondere bei verschachtelten Menüs, profitieren. Natürlich kann man das mit CSS auf jedem Element erreichen, aber warum nicht die verwenden, die funktionieren und für die Aufgabe der Gruppierung von Inhalten gedacht waren?
Nochmals die Frage: Was ist zu gewinnen, wenn man eine gängige Praxis ändert? Die Screenreader-Erfahrung ist eine sehr subjektive, da ich andere blinde Nutzer kenne, die die Navigation mit Tastenkombinationen in Listen lieben. Und das Argument der „leeren Leinwand“ ist auch Geschmackssache.
Einige der Antworten hier machen mir Angst. ul > li > a sind nicht zu viele Elemente, es ist eine korrekte HTML-Struktur, nav > li ist nicht richtig, da nav kein Listenelement ist. Man kann es mit der Einsparung von Tastenanschlägen übertreiben. Dasselbe gilt für die SASS-Antwort – es scheint einen seltsamen Glauben zu geben, dass SASS alles kann. Ist es also das neue PHP? :) Manche Dinge müssen geändert werden, andere müssen wirklich nur geändert werden, wenn sie kaputt sind, anstatt sie zu zerstören, nur um eine neue heiße Technologie anzuwenden oder Code zu sparen.
Das war auch mein erster Gedanke. Die <ul>- und <li>-Elemente organisieren die Links für die Navigation nicht nur, sondern bieten auch viel mehr Optionen, wie diese Links präsentiert werden können.
Ein Screenreader wird immer eine andere Erfahrung beim Zugriff auf eine Seite machen als ein sehender Benutzer, der eine Maus verwendet. Die Herausforderung der Barrierefreiheit besteht nicht darin, allen Benutzern die gleiche Erfahrung zu bieten, sondern sicherzustellen, dass alle Benutzer die benötigten Informationen erhalten können. Wenn eine Seite für Screenreader verwirrend ist, weil sie mehrere Navigationslisten enthält, scheint dies eher ein Problem der Gestaltung und Organisation der Seite zu sein als ein Problem mit Navigationslinks in Listen.
Die Idee, dass Listen-basiertes Markup „zusätzliche“ Elemente kostenlos bietet, ist kein einzigartiger Vorteil. Die Verwendung von Divs und Spans in einer listenlosen Einrichtung bietet Ihnen die gleiche Freiheit (und noch mehr Raum zum Atmen). Darüber hinaus würde ich argumentieren, dass die Verwendung einer Listen-basierten Einrichtung nur für die Präsentationsvorteile nicht den Standards entspricht.
Nebenbei bemerkt, dank des Lernens, ein ul > li > a Setup für die Navigation zu verwenden, reduziert mein Gehirn manchmal alles auf „OH! Das ist auch eine Liste, weil es eine Reihe ähnlicher Elemente ist!“ Und ich muss mich selbst davon abhalten (und bestrafen), das ol > li > article Flotsam und Jetsam zu verwenden, das unweigerlich folgen würde.
Hallo Chris, du hast geschrieben
Als Antwort
Ganz genau. Es riecht nach etwas Neuem und Hip für seinen eigenen Zweck.
Ich denke, auf einer gewissen Ebene sollte es eine Art Liste geben, in der Leute li-Tags einfügen können und vielleicht mit einem href-Attribut. Navigation impliziert standardmäßig, dass es sich tatsächlich um eine Liste handelt.
Einer der Gründe, warum Navigation eine Liste ist, ist, dass es eine Anstandspflicht gibt, dass Webseiten keine Links enthalten sollten, die auf sich selbst verweisen.
Im Beispiel sind wir auf der Startseite einer Website, daher ist der Menüpunkt „Home“ kein Link (
A), aber es ist immer noch ein Menüpunkt (LI).P.S. Markdown in Kommentaren scheint hier nicht zu funktionieren (zumindest bei der Vorschau).
Oh, es ist die Vorschau, die hier kaputt ist. Korrektes Codebeispiel
Ich kann mich nicht erinnern, wann ich das letzte Mal eine Navigation gesehen habe, bei der die aktuelle Seite kein Link blieb. Ich habe diese Art von Muster definitiv in einer Brotkrümel-Navigation gesehen, aber für die Navigation?
Um das Problem, das Sie in Chris' Markup präsentieren, zu lösen, umwickeln Sie die aktuelle Seite einfach mit etwas anderem, wie z. B. einem Span. Oder wenn Sie die Zeichenanzahl kurz halten möchten, verwenden Sie i oder b.
Marat, du brauchst kein Listenelement, um bloßen unankernbaren Text zu platzieren…
Ich könnte genauso gut schreiben
Startseite
Produkte
Kontakt
nur mit Spans…
Mein Punkt ist, dass die Annahme, dass „konsequente Links bereits eine offensichtliche Liste sind“, falsch ist, da einige Elemente nicht notwendigerweise Links sind. Für Styling (präsentative) Zwecke könnten wir natürlich
SPANanstelle vonAfür inaktive Elemente verwenden, aber aus semantischer Sicht gibt es nichts Semantisches inSPAN, so dass nicht verknüpfter Text überhaupt kein Element mehr ist, es ist einfach ein semantikloser Text unbekannten Zwecks. Im Gegenteil, ein Listenelement ist immer ein Listenelement, unabhängig davon, ob sein Inhalt ein Link ist oder nicht.Sean
Zum Beispiel verwenden die meisten Websites, die von Art. Lebedev Studio (führendes Webstudio in Russland) erstellt wurden, dieses Muster. Das Verfolgen, ob ein bestimmter Link genau der aktuellen Seite entspricht, ist manchmal technisch problematisch (das wäre im DOM ziemlich trivial, aber zum Beispiel ist DOM in PHP [tatsächlich die beliebteste serverseitige Sprache] sehr fehlerhaft und in der Praxis fast unbrauchbar) und kann bei der „Fließbandproduktion“ von Websites unvernünftig sein, aber das Muster selbst ist ziemlich sinnvoll und nützlich (Übrigens sollte das Logo auf der Startseite einer Website aus demselben Grund kein Link zu ihrer Startseite sein).
Definitiv eine interessante Diskussion, also habe ich beschlossen, ein wenig zu recherchieren. Ich denke, die Bedenken, die Sie im Beitrag erwähnen, sind hauptsächlich darauf zurückzuführen, dass es mehrere Listen von Links auf einer Seite gibt, was bei SR-Benutzern Verwirrung stiftet.
Hauptsächlich sollten SR-Nutzer selbst die letzte Instanz dafür sein, was die beste Praxis ist, und daher kann ich verstehen, warum Reinhards Aussage so ernst genommen wurde (wie es auch sein sollte).
Dennoch hier einige bemerkenswerte Zitate und Links
Von Roger Johansson, 2009
Von einer Seite der University of South Florida (die auch eine Videodemo von VoiceOver beim Lesen einer Linkliste enthält)
Von Userite, einem Unternehmen, das sich auf Web-Barrierefreiheit spezialisiert hat (dieses Zitat könnte von einer alten Seite stammen, es gibt kein Datum)
Dieses W3C-Dokument empfiehlt die Gruppierung von Links über Listen.
Diese Barrierefreiheitsseite der Penn State University bietet einige Vorschläge für Linkgruppen, erwähnt aber nichts über Listen.
In WebAIMs jüngster Screenreader-Umfrage, unter Problematische Elemente, werden Linklisten nicht erwähnt, obwohl andere navigationsbezogene Elemente als problematisch angesehen werden.
Diese alte Diskussion auf WebAIM bespricht Linklisten, aber es ist ein alter Beitrag, daher bin ich mir nicht sicher, wie relevant er heute ist.
Weiterhin von WebAIM, erklären sie unter der Überschrift „Screenreader informieren Benutzer, dass ein Textstück (oder eine Grafik) ein Link ist“
Und hier ist ein interessanter Hinweis von derselben Seite
Auch hier wäre es großartig, weiteres Feedback von tatsächlichen Screenreader-Benutzern zu erhalten. Ich halte es für bedeutsam, dass die WebAIM-Umfrage Linklisten nicht als problematisches Element erwähnt, daher würde ich die Verwendung der ungeordneten Liste für Links nicht so schnell ablehnen. Schließlich ist doch das, was die Mehrheit der SR-Benutzer am wichtigsten findet, nicht nur eine Person?
Wie auch immer, ich bin sicher, andere mit aktuellerem Wissen werden sich hier melden, und ich denke, Christian Heilmanns Kommentar oben ist gut, weil, wie er vorschlägt, es wirklich keine perfekte Universallösung gibt.
Lee, er hat Recht. Das richtige Ziel der Skip-Navigation ist der Seiten-
<h1>, damit er gelesen wird. Chrome verschiebt den Fokus ohne JavaScript nicht darauf. Zumindest war es letzten Monat noch so.Ich fühle deinen Schmerz, wenn es ums Posten von Code geht. Ich setze ein
<code>, dann entkomme ich alle<s und der Rest ist normal.Chuck, ich kämpfe immer noch, ich habe gerade ein paar HTML-only Skip-Nav-Links getestet und kann kein Problem finden. Sagst du, dass #Links in Chrome kaputt sind? Wie testest du, dass der Fokus verschoben wurde?
Ah, Tastaturfokus! Habe es herausgefunden, es ist immer noch ein 'Bug'.
Warum ist das (der Barrierefreiheitsaspekt) immer noch ein Problem? Es gibt bereits eine Lösung
https://developer.mozilla.org/en-US/docs/Accessibility/ARIA/ARIA_Techniques/Using_the_link_role
Laut den Arbeitsbeispielen,
<nav><ul role="navigation">
<li><a href="about.html" role="link">About</a></li>
. . .
</ul>
</nav>
funktioniert auch mit Divs (vorausgesetzt, die Verknüpfung wird durch JavaScript behandelt)
<div class="nav" role="navigation"><span role="link">About</span>
. . .
</div>
Warum wird das also nicht verwendet? Barrierefreiheit sollte kein Grund sein, eine Markup-Lösung gegenüber anderen zu wählen. Es sollte einfach eine zusätzliche Ebene sein.
Hier ist meine Liste
Warum muss ich immer noch JavaScript hinzufügen, damit Skip-Nav funktioniert?
Warum kann ich CSS, das für visuelle Browser gedacht ist (
display: none), nicht verwenden, ohne mir Gedanken darüber machen zu müssen, wie nicht-visuelle Tools damit umgehen? Schließlich gibt es auch einenhiddenARIA-Status.Warum sollte CSS überhaupt blinden Benutzern zur Verfügung gestellt werden?
Diese Fragen werden durch Christians Kommentar beantwortet: „Screenreader aktualisieren sich verdammt langsam und variieren immens zwischen verschiedenen Versionen“.
Ist es so schwer, einen nicht-visuellen „Browser“ zu erstellen, anstatt zu versuchen, sich an einen visuellen anzuhängen? Er hätte die vollständige Kontrolle, wie zum Beispiel das Ignorieren von „target=_blank“ und Pop-ups. Es muss jemanden geben, der bei Webkit oder Gecko arbeitet und etwas zusammenstellen könnte.
Ich glaube nicht, dass Sie jemals JavaScript verwenden mussten, um die Skip-Navigation zu aktivieren.
role=link ist für ein <a>-Element nicht erforderlich, da seine Rolle bereits im Browser abgebildet ist. ARIA-Rollen sind nur auf den meisten Elementen erforderlich, wenn Sie a) die native Semantik ändern möchten oder b) fehlende Browserunterstützung polyfillen möchten (siehe: Using ARIA in HTML. Siehe meinen Kommentar unten bezüglich Christians Kommentar zu Screenreadern).
@Lee: Es gibt einige sehr alte Fehler (ich kann es jetzt nicht nachschlagen, aber ich glaube, in Webkit), die dazu führen, dass die Skip-Navigation für Tastaturbenutzer nicht funktioniert (Fokusproblem). Ohne JS können Sie eine Skip-Navigation für diese Benutzer nicht zum Laufen bringen.
Steve, mein Punkt ist, ARIA-Attribute so zu behandeln, wie wir Klassen behandeln. Wir können Tags in CSS ansprechen, aber wenn wir Klassen ansprechen, können sich die Tags ändern (z. B. beim Update auf HTML 5). Dasselbe würde hier gelten. Wenn die Screenreader nach role=link suchen, ist es egal, was das Tag ist. Mit anderen Worten, ARIA-Attribute sollen unabhängig von HTML/XML/WhateverML sein, sodass alle Rollen auf allen Tags gültig wären. Das würde auch helfen,
<a href="javascript:void(0)">und<a href="#">zu vermeiden, die eigentlich keine Links sind.Zu Ihrem Kommentar bezüglich der Browserunterstützung stimme ich zu. Das ist ein weiteres Argument für einen separaten Browser speziell für Barrierefreiheit. Lassen Sie die Community, die sich mit Barrierefreiheit befasst, ihren eigenen Browser haben, der auf ihre Bedürfnisse zugeschnitten ist. Das würde Entwicklern auch eine definitive Validierung geben, ob eine Website konform ist.
@glev: Ich bezweifle das, meine Skip-Nav-Links waren immer reine HTML-Links
„Warum sollte CSS überhaupt blinden Benutzern zur Verfügung gestellt werden?“
Ich könnte zu 80 % blind sein und Schwierigkeiten haben, Text zu lesen und auf Webseiten zu navigieren, aber visuelle Elemente können mir bei der Navigation mit Tastatur/Maus helfen. Daher ist es wichtig, das CSS zu rendern.
Aber ich bin mir nicht sicher, ob das für dieses Publikum wichtig ist. Ich versuche nur, ein Beispiel zu finden, warum CSS immer noch gelesen wird.
Auch ich habe aufgehört, Listen für meine Navigation zu verwenden, rein um des Code-Bloats willen. Wann immer ich ein Element in meinem Code sehe, das nur ein anderes Element enthält, entferne ich es, es sei denn, es gibt einen sehr zwingenden Grund, dies nicht zu tun. 98% der Zeit kann ich das erreichen, was ich brauche, indem ich nur ein Element verwende. Ich war es auch wirklich leid, die <a>s immer auf display: block zu setzen, nur damit der klickbare Bereich bis zu den Rändern des <li>s reichen würde. Ich werde immer noch ein <ul> für Menüsysteme verschachteln, aber ich habe mich befreit! Es ist wirklich ziemlich befreiend.
Finden Sie es nicht etwas seltsam, wie Webdesigner so viel ihrer Zeit und Energie auf Sehbehinderte konzentrieren?
Verstehen Sie mich nicht falsch, es ist wichtig, dass sie auf Websites zugreifen können – aber der Aufwand, der in die Barrierefreiheit gesteckt wird, steht in keinem Verhältnis zum Prozentsatz der Internetnutzer, die tatsächlich Screenreader verwenden.
Ich könnte nicht mehr zustimmen. Ich habe einen behinderten Onkel, und ich glaube, es ist sehr wichtig für ihn, Zugang zum Internet zu haben.
Ich kann jedoch kein völlig gültiges Argument für die Verwendung oder Nichtverwendung einer Listenavigation finden. Es scheinen mir alles nur Meinungen zu sein.
Meiner Meinung nach ist HTML und die Art, wie wir es schreiben, nicht kaputt. Das Problem selbst sind die Screenreader. Warum verbringen wir all diese Zeit damit, an dem festzuhalten, was wir wissen, dass es funktioniert und gut funktioniert, anstatt das eigentliche Problem zu beheben? Bauen Sie etwas Besseres, das es Sehbehinderten ermöglicht, modernes HTML korrekt zu nutzen.
Ich schätze die progressiven Einstellungen, das Beste zu bauen, was wir können, für jeden, Gleichheit im Code, wenn Sie so wollen. Ich bin nur nicht davon überzeugt, dass HTML hier das eigentliche Problem ist.
Jeremy Keith beschrieb kürzlich das „Problem des Zahlenspiels“ (in einem anderen Kontext): „Prozentual gesehen ist diese demografische Gruppe winzig. Aber das ist keine Zahl. Es ist ein Mensch. Dieser Mensch zählt.“
Außerdem muss es nicht „viel Aufwand“ sein. Wenn Sie klar schreiben, HTML-Elemente für ihren vorgesehenen Zweck verwenden, Ihre Informationen klar präsentieren und sich daran erinnern, dass Menschen unterschiedliche Fähigkeiten haben, wird Ihre Arbeit für viel mehr Menschen zugänglich sein. Und Sie werden sich gut fühlen.
Sind das alles Zahlen?
Welcher Prozentsatz der Benutzer verwendet noch IE8? Bei welchem Prozentsatz hören Sie auf, sich um sie zu kümmern? Screenreader werden nicht NUR von komplett Blinden verwendet. Sie werden auch von Menschen mit eingeschränkter Motorik verwendet.
Ist Barrierefreiheit nicht im Grunde alles Metadaten? Je besser Sie Ihren Inhalt beschreiben können, desto einfacher ist es für Ihren Inhalt, von einem größeren Teil des Webs konsumiert und verbreitet zu werden.
Ich unterstütze die Idee eines Navigationselements. Vielleicht: ni
http://www.youtube.com/watch?feature=player_detailpage&v=QTQfGd3G6dg#t=38s
Haha, zu lustig !!
Wir sind die Ritter, die "ni" sagen
Das verstehen nur Briten ;)
So ein lustiger Film!
Sehr interessanter Artikel, Chris, werde in Zukunft definitiv mehr darauf achten!
Listenlose NAV klingt gut. Aber wie könnte man ‚Dropdown-Menüs‘ handhaben? Speziell WordPress-Dropdown-Menüs mit zwei oder mehr Ebenen.
Ich habe nicht einmal über dieses Problem nachgedacht und verwende Listen für die Navigation, seit ich CSS benutze. Wie Christian Heilmann sagte, sind die Vorteile, dass sie auch ohne CSS gut angezeigt werden und man einige zusätzliche Container (UL und LI) für Styling-Zwecke erhält. Und wenn man das alles mit role="navigation" kombiniert, sollte es wirklich überhaupt kein Problem geben. Die angesprochene „Code-Aufblähung“ ist in diesem Kontext etwas lächerlich (es gibt wirklich schlimmere Probleme), es sind nur ein paar ULs und LIs – und wenn man eine Navigation nur mit Links richtig stylen will, braucht man irgendwann eine Art von Containern.
Ich stimme @Charles @ CodeConquest.com zu.
Zu viel Zeit nur für Screenreader aufwenden? Das Web muss stabil sein und aufhören, jeder Änderung nutzloser Geräte zu folgen. Geräte müssen der Webentwicklung folgen.
(Entschuldigung für mein schlechtes Englisch)
Das ist eine interessante Idee, Chris. Ich werde es mal ausprobieren und sehen, wie es funktioniert.
Unverwandt und OT
@Chris – Ich finde es toll, dass du dich entschieden hast, IE7 und IE8 nicht mehr zu unterstützen, eine konsequente und mutige Entscheidung, ich denke, dass alle Seiten, die sich an Entwickler/Designer richten, diesem Trend folgen sollten, weil es einfach Sinn macht.
Obwohl mir der Gedanke gefällt, mache ich mir Sorgen um die Navigation der Untermenüs. Listen scheinen der perfekte Weg zu sein, um Unter-Navigationen zu verschachteln. Sicher, man kann ein weiteres Div verschachteln, aber es fühlt sich etwas falsch an.
===
Ist die Idee einer geordneten Liste nicht, dass die Reihenfolge der Elemente zueinander relevant ist? D.h. eine Reihe von Anweisungen, bei denen man die Reihenfolge nicht wirklich ändern kann und trotzdem erwartet, sein Ziel zu erreichen.
Möglicherweise mit Ausnahme des Menüpunkts „Home“ (der wohl von den meisten als erster in der Liste erwartet wird), ist die Reihenfolge der meisten Navigationselemente nicht relevant.
Nehmen Sie Ihre Navigationsleiste auf dieser Seite: Es spielt keine Rolle, dass „Snippets“ vor „Videos“ steht, was die Funktionsweise der Navigation angeht. Sie könnten sehr wohl in einer anderen Reihenfolge sein und würden im Kontext eines Navigationsmenüs immer noch „Sinn ergeben“.
Eine ungeordnete Liste hat immer noch eine „Ordnung“ – insofern, als es beim Durchlesen ein erstes Element, ein letztes Element und eine Reihe dazwischen gibt. Es ist nur so, dass die Reihenfolge der Elemente für das Verständnis ihrer Bedeutung nicht wichtig ist.
Ihr Navigationsmenü könnte zum Beispiel genauso gut so aussehen und würde immer noch „Sinn ergeben“
Interessanter Artikel, Chris. Der Tipp mit
role="navigation"ist in der Tat sehr nützlich.Ja, eine geordnete Liste beschreibt eine Abfolge, die stattfinden muss. Das ist bei der Navigation nicht der Fall. Man könnte argumentieren, dass Breadcrumbs das sein könnten.
Ich war bei diesem Refresh dabei und Reinhard sagte tatsächlich, dass er es für logisch hielt, die Breadcrumbs in eine geordnete Liste zu setzen.
Ein weiterer Punkt, den er ansprach, war, keine Listen zu verwenden, um Nicht-Listeninhalte anzuzeigen. Er bezog sich auf schlecht geschriebene CMS, die ungeordnete Listen verwenden, um alles anzuzeigen.
Danke fürs Gegen-den-Strom-Schwimmen!
Ich habe nach einer Möglichkeit gesucht, dies mit
wp_nav_menuin WordPress zu tun, aber natürlich hast du das schon vor einigen Monaten behandelt: Entfernen von LI-Elementen aus der Ausgabe von wp_nav_menuWenn ich mich richtig erinnere, würde Bobby (das alte Barrierefreiheits-Validierungstool) aufeinanderfolgende Hyperlinks als Fehler kennzeichnen, wenn sie nur durch Leerzeichen getrennt wären. Wenn die Links ohne angewandtes CSS (aus irgendeinem Grund) dargestellt werden, kann man visuell nicht erkennen, wo der eine endet und der nächste beginnt. Sind das zwei Wörter oder zwei separate Links?
Ist es uns also wichtig, wie eine Seite aussieht, wenn CSS nicht angewendet wird? Wenn ja, dann brauchen Sie etwas zwischen diesen Links. Eine Liste bietet ausreichend Leerraum und funktioniert daher gut.
Wenn keine Listen verwendet werden, sollten Sie vielleicht Kommas zwischen die einzelnen Elemente setzen und die Kommas dann mit CSS ausblenden??!?!
Ich mochte Listen für Navigationsmenüs immer, man kann immer eine weitere ul in eine andere setzen, um Untermenüs zu erstellen, genau so, wie Listen gedacht waren.
und was ist mit Screenreadern? role="navigation" scheint die beste Lösung zu sein…
„Entschuldigung für meine schlechte englische Grammatik“
Ich stimme dir zu, Chris, ich mache das schon lange so.
Mit freundlichen Grüßen.
Hier ist mein Grund, weiterhin eine ungeordnete Liste für meine Navigationslinks zu verwenden: Es ist eine Möglichkeit, der Welt (Menschen oder Maschinen) durch eine semantische Organisationsstruktur mitzuteilen, dass diese Links Teil eines einzigen Navigationssystems sind. Die Reihenfolge, in der die Links erscheinen, spielt keine Rolle. Aber die Tatsache, dass sie zusammen in einer ungeordneten Liste organisiert sind, besagt unmissverständlich, dass diese Links organisatorisch miteinander verbunden sind.
Die Verwendung anderer Markups (Divs, Spans oder sogar nur reine Anker-Tags) bietet keine so klare Bedeutung. Was die Barrierefreiheit betrifft, mögen ungeordnete Listen mühsamer sein, aber anscheinend ist die Jury in dieser Frage noch nicht zu einem Ergebnis gekommen, und zukünftige Barrierefreiheits-Tools werden das Argument vielleicht hinfällig machen. Ich denke, technisch gesehen würde das Nav-Tag auch eine rationale organisatorische Gruppierung bieten, aber es ist nicht so klar wie eine Liste (weil das Nav-Tag auch andere Inhalte außer Navigationslinks enthalten kann).
Könnte nicht eine Reihe von Links innerhalb eines nav-Tags dieselbe Bedeutung vermitteln, dass sie miteinander verwandt sind, da sie Kinder des nav-Tags sind, ohne eine Liste unpassend für etwas zu verwenden, das keine echte Liste ist, nur um Beziehungen herzustellen?
@MaccG – ich verstehe, was du meinst – das Nav-Tag würde automatisch die Gruppe/Assoziation erstellen, die die Liste normalerweise erstellen würde. Aber wie assoziiert man spezifische Linkgruppen innerhalb des Nav-Tags? Da das Nav-Tag mehr als nur Links (assoziierter Text zur Navigation) enthalten kann – wie erstellt man eine semantische Trennung verschiedener Inhalte innerhalb des Nav-Tags?
Darauf will ich hinaus – die ungeordnete Liste bietet diese Unterscheidung.
Was die Verwendung geeigneter ARIA-Rollen (wie z. B. role="navigation") angeht, neige ich stark zu Steve Faulkners Using ARIA in HTML. Es ist eine ausgezeichnete Ressource (insbesondere die Empfehlungstabelle).
Aus diesem Artikel: Wie wäre es mit
role="presentation"auf dem<ul>Es würde die Semantik aus der Liste entfernen?
Ich stimme vielen Kommentaren zu, die die Verantwortung den Screenreadern zuschreiben, kontextuell korrekte und verbreitete Codierungspraktiken für ihr Publikum sinnvoll zu interpretieren. Ich bin mir sicher, dass dies leichter gesagt als getan ist, da es noch nicht geschehen ist. Ich habe versucht, mit einem Screenreader im Web zu surfen, und es ist quälend. Aber so wie es die Aufgabe des Browsers ist, das Markup für fähige Menschen sinnvoll zu interpretieren, ist es die Aufgabe des Screenreaders, das Markup für Menschen mit Behinderungen sinnvoll zu interpretieren.
Wenn nav>ul>li>a der allgegenwärtige, de facto Standard ist… dann müssen Screenreader damit umgehen!
Die Idee eines „De-facto-Standards“ ist etwas ekelhaft. Das ist kein Standard, das ist ein Muster oder ein Trend, und einer Nischengruppe von Entwicklern zu sagen, sie sollen „damit umgehen“, legt ihnen eine ziemlich unhandliche Last auf: „ERWARTET, WAS DER REST DES WEBS FÜR EINE GUTE, UNDOKUMENTIERTE PRAXIS HÄLT, DIE SICH IN EINEM ODER ZWEI JAHREN ÄNDERN KANN ODER VON WEBSITE ZU WEBSITE JE NACH DEN VORLIEBEN DES ENTWICKLERS VARIIEREN KANN!“ Ich meine, ja, es ist keine unüberwindbare Aufgabe, aber immer noch eine ziemliche Scheißerwartung.
Und vielleicht habe ich es übersehen, aber wurde festgestellt, dass ein Screenreader keine sinnvolle Markup-Interpretation liefert? Ich habe es so gelesen, dass es nur ein umständlicher Prozess für den Endbenutzer ist.
@Vince, Punkt verstanden. Ich bin definitiv für Standards, und diese Diskussion ist großartig. Ich sage nur, sobald der Entwickler dem Standard entspricht, hat er theoretisch seine Arbeit getan. Der Rest obliegt dem Browser, diesen Standard so zu interpretieren, dass er für sein Publikum sinnvoll und nutzbar ist.
Hmm… versuchen wir es noch einmal
Das funktioniert einwandfrei
<ul role=”naviagtion”>
<li><a href=”http://www.google.com>Google</a></li>
</ul>
Wenn Sie es ausgefallener gestalten möchten, wickeln Sie es in ein <nav>-Element.
Aber was ist mit dem ganzen Teil des Artikels, in dem Reinhard vorschlägt, dass das nicht „gut funktioniert“?
@Chris – aber spricht hier Reinhard für jeden Benutzer, der einen Screenreader verwendet, oder spricht er nur aus seiner Erfahrung? Ein Datenpunkt macht den Fall nicht für alle Situationen. Letztendlich denke ich, dass es an den Entwicklern von Barrierefreiheitssoftware liegt, bessere Software zu entwickeln, und an uns Webdesignern und Entwicklern, nach den Standards und Best Practices zu codieren.
Vielleicht wird sich die beste Praxis dahingehend ändern, Links einfach innerhalb eines Nav-Elements zu platzieren und „Assoziationen von Links“ durch Zusammenfassen von Links innerhalb eines Section-Elements zu erstellen. Aber im Moment funktioniert eine ungeordnete Liste für mich und bietet diese semantische Gruppierung und Organisation.
Interessante Konversation.
Es ist sicherlich nur ein Datenpunkt. Aber lasst uns mehr bekommen! Es ist buchstäblich der einzige, den ich je von einem echten Screenreader-Benutzer gesehen habe, was ihm für mich mehr Gewicht verleiht als einem ganzen Thread von Nicht-Screenreader-Benutzern.
Es gab ein paar Umfragen von WebAim – dies ist die jüngste (leider schon 2009)
Screenreader-Umfrage #2
Auch wenn die präsentierten Daten über 3 Jahre alt sind und die Anzahl der Befragten gering ist (im Vergleich zur Anzahl der registrierten behinderten Internetnutzer), ist es eine interessante Lektüre. Besonders der Abschnitt über „Problematische Elemente“, der Navigationspunkte nicht einmal als Problem erwähnt (Argument für die Konvention dort?)
Abgesehen davon, dass es das Problem der Subjektivität gibt, wie zuvor vorgeschlagen, können wir auch erwarten, dass die Lösung einer Person das Problem einer anderen Person ist, wie Chris Heilmann in seinem Szenario der Erfahrungen blinder und dyslexiker Benutzer vorgeschlagen hat.
ARIA-Rollen überschreiben native Rollenabbildungen im Browser. role=navigation auf ul ist in HTML5 nicht konform. Erlaubte Rollenwerte sind directory, listbox, menu, menubar, tablist, toolbar, tree und presentation.
Ich sehe
UL > LI > Aimmer noch als logische Struktur für die Navigation. Schließlich ist es immer noch eine Liste von Seiten. Sitemaps sind üblicherweise so strukturiert und stimmen oft auch visuell überein (in Bezug auf Verschachtelung und Einrückung usw.), so dass dies gut passt.Es wäre schön, wenn Screenreader zwischen einer Navigationsliste und Listen mit anderen Datentypen unterscheiden könnten, entweder mit dem
<nav>-Element oder dem ARIA-Rollenattribut. Mit anderen Worten, vielleicht nur die Tatsache vorlesen, dass es sich um einen Navigationsblock handelt und sie dann auf Untermenüs (Dropdowns) aufmerksam machen. Das alles wird im Markup bei Verwendung von Listen ziemlich klar dargestellt.Ich möchte mich zu den Fehlinformationen über die „Bildschirmleser-Verzögerung“ äußern. Es ist oft der Fall, dass die Verzögerung durch ein Versagen der Browser bei der Implementierung der entsprechenden Barrierefreiheitsunterstützung verursacht wird, und nichts mit Bildschirmlesern zu tun hat. Ein Beispiel: Ein neues Element wurde kürzlich zu HTML hinzugefügt. In der letzten Woche oder so wurde es in die Nightly Builds von Firefox, WebKit und Chrome integriert. Es wird auch von JAWS, VoiceOver und NVDA am selben Tag unterstützt, an dem der Browser es implementiert hat. Warum? Im Gegensatz zu den meisten neuen Elementen, die zu HTML hinzugefügt werden, umfasste die Implementierung auch die Barrierefreiheit (Rolle in der Browser-Zugänglichkeits-API abgebildet) zusammen mit der Mainstream-Implementierung wie Parsing und Styling, so dass Bildschirmleser sofort in der Lage sind, es zu verstehen und seine Bedeutung den Benutzern zu vermitteln. Beachten Sie, dass aufgrund eines Browser-Fehlers in Chrome das Element derzeit nicht mit der spezifischen Rolle, die es haben sollte, sondern mit einer generischeren "Gruppe"-Rolle übermittelt wird.
Vielleicht können wir webAIM dazu bewegen, eine Testfrage oder eine Frage zu diesem Thema in ihre nächste Umfrage aufzunehmen? http://webaim.org/projects/screenreadersurvey4/
Meine Güte. Ich hatte völlig vergessen, diese eigentliche Forschung zu betreiben. Es muss auch das erste Mal sein, dass ich mich über XHTML2 beschwert und zu HTML zurückgekehrt bin!
aus dem Artikel „Liste, 10 Elemente. Liste, 6 Elemente…“
Das ist eine einfache JAWS-Steuerung. Wenn Sie all diese Informationen nicht möchten, schalten Sie sie einfach ab. JAWS und die meisten Screenreader verfügen über viele Einstellmöglichkeiten für die Ausführlichkeit. Benutzer können auswählen, was sie hören möchten. Und die Meinung einer Person macht noch keinen Standard, noch spricht diese Person für eine ganze Gruppe.
Ausgezeichnete Informationen! Benutzen Sie JAWS regelmäßig? Können Sie einen Blogbeitrag darüber teilen, wie man diese Einstellungen anpasst? Haben Sie Meinungen zu Markup-Mustern, die für die Navigation besser/schlechter sind, oder zu irgendetwas anderem? Ich hasse es, große Entscheidungen aufgrund der Meinung einer einzelnen Person zu treffen, aber es ist buchstäblich die einzige, die ich je von jemandem gehört habe, der es tatsächlich benutzt.
Ich arbeite an einer Schule für Blinde. Ich bin nicht blind. Ich war 10 Jahre lang Lehrer für sehbehinderte Menschen. Ich habe JAWS unterrichtet. Ich teste mit JAWS. Es ist eine tiefgründige Software und hochgradig konfigurierbar... WENN ein Benutzer dies wünscht.
Hier sind einige nützliche Links, die einige der konfigurierbaren Dinge erklären.
http://webaccessibility.gmu.edu/docs/Accessible%20Documents%20Creation/6%20HTML/Tab%205%20–%20A.%20JAWS%20and%20HTML.doc
Dies ist spezifischer für HTML – obwohl etwas veraltet, immer noch gute Ausgangsinformationen. Die fehlenden Teile beziehen sich eher auf Landmarks und neuere Funktionen. JAWS hat etwa einen 12-18-Monats-Zyklus mit vierteljährlichen (oder häufigeren) Unterversionen und Builds.
Auch viele Menschen mit Sehbehinderungen (blind und sehbehindert) haben bei der Entwicklung der WCAG, ATAG, UAAG, 508, europäischen, australischen, (hier Land einfügen) Standards geholfen. Sie wurden nicht in einem Vakuum entwickelt.
und
http://www.indiana.edu/~iuadapts/technology/software/jaws/jaws_guide.html (dies ist eher eine Einführung)
Jim,
Können Sie weitere Informationen zu einigen Testfällen bereitstellen? Zum Beispiel JAWS mit minimaler Optimierung (wie es reagiert) vs. JAWS-Ausgabe mit mittlerer/maximaler Optimierung? Ihr Beitrag war der wertvollste, den ich bisher gelesen habe. Ich war auch neugierig darauf.
Vielen Dank
Das ist die Art von Inhalt, die ich gerne lese. Danke, Chris, dass du das zusammengestellt hast.
Sie verstehen den Punkt nicht! Das Problem mit „einer Seite mit 12 Link-Sets“ ist, dass es sich um eine schlecht gestaltete Webseite handelt.
„Zu viele Links oder Navigationselemente“ auf einer Webseite ist eines der größten Probleme für Screenreader-Benutzer: http://webaim.org/projects/screenreadersurvey4/#problems. Ich würde lieber einen Artikel über dieses Problem sehen.
Ich stimme Ihrer Aussage nicht zu. Sagen Sie das jemandem wie Amazon, Overstock oder einem großen E-Commerce-Unternehmen mit potenziell Millionen bis Hunderttausenden von Artikeln im Inventar. Gilt Ihre Theorie dann immer noch? Navigationselemente sind ein integraler Bestandteil vieler Websites, die sie immer noch benötigen. Während ich zustimme, dass weniger mehr ist, wenn es richtig gemacht wird, trifft es nicht immer zu.
In den schlechten alten Zeiten stimmte es sicherlich, dass die Websites von Amazon (sowohl .co.uk als auch .com) von RNIB als Beispiele für schlechte Praxis verwendet wurden, aber dies hatte mehr damit zu tun, dass jeder Link auf der Seite mit „hier klicken“ formuliert war und für jemanden, der die Website mit einem Screenreader nur zwischen Links sprang (Link: hier klicken, Link: hier klicken, Link: hier klicken, ad infinitum), überhaupt nicht nützlich war.
Ich habe die Way Back Machine durchsucht, um ein Beispiel zu finden, aber leider funktionieren keine der Schnappschüsse von vor 2007.
Diese Methode der Link-Erstellung ist auf vielen modernen Websites immer noch problematisch, aber ich verwende ein verstecktes Span, um dieses Problem zu umgehen, wenn das Design dies vorschreibt, z.B. „Link: Weitere Informationen (zu etwas), Link: Weitere Informationen (zu etwas anderem)“.
@David Aimi
Das ist eine interessante Frage. Ich denke, meine Theorie trifft zu. Eine Webseite muss nicht 12 Sätze von Links haben, nur weil das Unternehmen einen großen Lagerbestand hat. Luke Wroblewskis „Mobile First“-Präsentation zeigte, dass viele große Unternehmen zu Webseiten mit weniger, aber gezielteren Inhalten übergehen.
Ich sage nicht, dass Navigationselemente schlecht sind. Ich beziehe mich auf Beweise, die besagen, dass Webseiten mit zu vielen Links oder Navigationselementen ein Problem für Menschen sind, die Bildschirmlesegeräte verwenden.
@Alan Dalton
Ich stimme mit so ziemlich allem, was Sie gesagt haben, zu 100% überein. Unabhängig vom Gerät oder Standort, wenn Ihre Website nicht minimalistisch, funktional und darauf ausgelegt ist, dem Benutzer bei der Erledigung einer Aufgabe zu helfen, ist es an der Zeit, die gesamte Website zu überdenken.
Listen sind für Screenreader-Benutzer aus mehreren Gründen hilfreich…
1. Sie dienen als Anker für die Navigation durch den Seiteninhalt. Alle Screenreader erkennen Listen, aber nur einer (den ich kenne) erkennt Divs auf diese Weise, und keiner hat die Möglichkeit, nach Spans zu navigieren.
2. Wenn ein Screenreader auf eine Liste stößt, informiert er den Benutzer über die Anzahl der enthaltenen Elemente. Dies hilft, eine mentale Karte des kommenden Inhalts zu erstellen, grob vergleichbar mit einem schnellen Blick auf den gesamten Navigationsblock.
3. Listen vermitteln die Navigationshierarchie mit absoluter Klarheit. Die Beziehung zwischen verschachtelten Listen wird von Screenreadern leicht verstanden.
Neuere Versionen einiger Screenreader unterstützen das nav-Element und/oder Navigations-Landmarks. Es ist möglich, nach nav oder Navigations-Landmarks zu navigieren, wodurch der erste oben beschriebene Vorteil dupliziert wird (wenn auch nur für einige Screenreader-Benutzer).
Die einzigen Elemente in der HTML5/5.1-Spezifikation, die den oben beschriebenen zweiten Vorteil duplizieren, sind geordnete oder ungeordnete Listen. Es sind die einzigen Elemente (in diesem Fall relevant), die dazu bestimmt sind, Gruppen von Elementen darzustellen.
Verschachtelte Nav-Elemente werden derzeit von keinem Screenreader unterstützt. Die einzelnen Nav-Elemente würden erkannt, aber nur als unabhängige Entitäten. Mit dem Nav-Element gibt es keine Möglichkeit, den oben beschriebenen dritten Vorteil zu duplizieren.
@Chuck Barlow
Das erste von Ihnen bereitgestellte Beispiel würde besser funktionieren, wenn die Navigationsrolle auf das Nav-Element angewendet würde. Dies würde die Zuordnung zwischen den beiden besser widerspiegeln und auch verhindern, dass ARIA- und HTML5-fähige Screenreader die Ankündigungen im Stil „Navigationsbereich“ duplizieren.
@Chris G
nav – ul – li ist mit ziemlicher Sicherheit der kommende Standard (es wird noch einige Zeit dauern, bis es sich überall durchsetzt), aber alle Screenreader können es bereits perfekt handhaben. Diejenigen Screenreader, die nav unterstützen, werden es als solches ankündigen, diejenigen, die es nicht tun, werden es ignorieren, als wäre es ein div, und in jedem Fall wird die Liste als Liste behandelt.
Tatsächlich würde ich dieses Designmuster als die robusteste, semantisch nützlichste und am besten unterstützte Option empfehlen.
Eine schnelle informelle Umfrage unter etwa 30 Screenreader-Benutzern heute Nachmittag deutet darauf hin, dass viele Listen in diesem Kontext nützlich finden. Einige sagten, eine Liste sei möglicherweise nicht notwendig, wenn eine Überschrift vor dem Navigationsblock vorhanden wäre, und einige sagten, sie würden es vorziehen, die Funktionen ihres Screenreaders zu verwenden, um auf Links zuzugreifen, räumten aber ein, dass dies nicht helfen würde, wenn sie nach einer bestimmten Gruppe von Links suchten.
Nur um diese nützliche Passage hervorzuheben
Das ist genau das Problem. Warum muss HTML ein Faktor sein? Die Sprache sollte keinen Unterschied machen. Es ist ein visuelles Medium und könnte sich ändern. Lassen Sie die Barrierefreiheit eine zusätzliche Ebene sein, unabhängig von der Sprache. Wenn ARIA-Attribute verwendet werden, um Listenelemente anzuzeigen, sollte es keine Rolle spielen, ob diese Elemente
<li>s,<span>s oder<newTagThatDoesNotExistYet>s sind.Ich schlage nicht vor, dass jedes einzelne Tag ein ARIA-Attribut haben sollte. Sie könnten ein Attribut haben, das anzeigt, welche Tags für Listenelemente verwendet werden. Ob Sie also
<ul>und<li>s oder<nav>und<div>s verwenden, das Containerelement hätterole=navigation nav-items=[Tag-Name]. Optional, wenn weggelassen, könnte der Wert vonnav-itemsals das erste Kinderelement angenommen werden.Und wo steht geschrieben, dass Bildschirmleser Webseiten verstehen müssen? Warum kann die Accessibility-Community nicht den Open-Source-Code nehmen und ihren eigenen Browser erstellen? Dann wäre sie nicht so sehr von anderen abhängig, um Funktionen zu implementieren.
@Chuck Barlow
Weil Webseiten darin geschrieben werden.
Nein, ist es nicht.
Das ist, als würde man nachträglich eine Rampe an ein Gebäude anbauen, das am Eingang eine Stufe hat: zeitaufwändig, teuer und wird manchmal nicht erledigt. Etwas von Anfang an barrierefrei zu gestalten, ist schneller, billiger und inklusiver.
Sie wären ziemlich nutzlos, wenn sie es nicht täten.
Mainstream ist besser als Segregation.
Jeder, der das Web nutzt, ist von Webdesignern abhängig, um Webseiten zu erstellen, die er nutzen kann. Gute Designer können Dinge schaffen, die jeder nutzen kann. Hören Sie auf, in Begriffen von „ihnen“ und „uns“ zu denken.
Und? Wenn eine neue Sprache eingeführt wird, die ebenfalls Tag-basiert ist, sollten wir dann bei der Barrierefreiheit wieder von vorne beginnen müssen? Wenn es nur eine zusätzliche Ebene wäre, müsste sich nichts ändern. Siehe HTML 4 -> 5 als reales Beispiel, aber es würde auch für eine völlig neue Sprache gelten.
Ja, das ist es. XML vielleicht nicht, aber HTML sehr wohl. Es begann mit
<font>,<b>,<center>,bgcolorusw. Für die meisten visuellen Eigenschaften haben wir jetzt CSS, aber wir haben immer noch<div>und<span>, die ansonsten identisch sind, außer wie sie standardmäßig visuell dargestellt werden. Screenreader nehmen<span>nicht einmal zur Kenntnis. Ähnlich sind<em>und<strong>einfach semantische Ersatzstoffe für<i>und<b>. Es gibt keinen Grund, warum wir nicht dasselbe Tag in allen Situationen verwenden könnten, in denen Betonung benötigt wird, und CSS verwenden, um die visuelle Unterscheidung zu treffen.Außer, dass wir eine Welt von Entwicklern haben, die über die Feinheiten der besten Implementierung von Barrierefreiheit debattieren. Das würde einige Zeit in Anspruch nehmen, würde aber (verzeihen Sie das Wortspiel) relativ schnell an Fahrt aufnehmen. Und einmal etabliert, wäre die Implementierung unkompliziert.
Sie wären immer noch äußerst nützlich. Bildschirmleser gab es schon, bevor das Web existierte. Sie funktionieren mit allen anderen Anwendungen auf dem Computer.
Weil „Mainstream“ die Quelle aller Innovationen ist. Etwas Kohärentes, Wendiges und von denselben Experten gemacht zu haben, die es benutzen, ist besser als die langsam zu implementierende, inkonsistente Gruppe von Screenreadern und Browsern, die derzeit verfügbar sind.
Ich spreche von anderen Browser-Entwicklern, nicht von Webdesignern/Entwicklern.
HTML begann nicht als visuelle Sprache. Es begann als strukturelle Sprache. Es hatte i-, b- und u-Elemente (sowie strong und em) und ein align-Attribut für Bilder, um Text um sie herum „fließen“ zu lassen, aber das war es auch schon – siehe http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
Andere Dinge wurden später hinzugefügt – und dann entfernt, als CSS Mainstream wurde.
Mein Fehler. Ich hätte es nicht so formulieren sollen, als wären sie alle in 1.0 enthalten, sondern „HTML, wie wir es kennen“ sagen sollen. Die Einbeziehung dieser und von
<pre>, zusammen mit der Tatsache, dass es in diesem Vorschlag Standard-Renderings gibt, deutet jedoch ziemlich gut darauf hin, dass die visuelle Darstellung im Vordergrund stand. Aber ich weiß es natürlich nicht mit Sicherheit, daher werde ich das einräumen.@Chuck Barlow
Barrierefreiheit ist in HTML integriert und hat bisher recht gut funktioniert. Die Strukturierung des Inhalts mit HTML ist der erste Schritt, um Ihren Inhalt barrierefrei zu gestalten. Außerdem – und das ist absolut entscheidend – ist es für neue Designer und Entwickler einfacher zu lernen, wie man HTML-Elemente richtig verwendet, als zu lernen, wie man ARIA auf Elemente anwendet. Das bedeutet, dass es realistischerweise wahrscheinlicher ist, dass sie tatsächlich HTML-Elemente verwenden, um Inhalte barrierefrei zu gestalten, als dass sie ARIA-Rollen in realen Projekten anwenden.
…und jedes andere denkbare Thema. Das ist kein Grund, gute Praktiken aufzugeben.
Das ist eine Vermutung. Das ist nicht besonders nützlich. Die Verwendung von semantisch korrektem HTML macht Informationen für Menschen mit allen Arten von Behinderungen zugänglicher. Viele Designer und Entwickler tun das bereits. Ich sehe keinen Grund, das zu ändern.
Wie viel davon ist das Versagen von Screenreadern?
Im Falle von Vorteil 2, könnte dies nicht dadurch erreicht werden, dass Screenreader ihren Benutzern mitteilen, wie viele „a“-Elemente sich im nav- (oder role=”navigation”-)Block befinden?
Vorteil 3 könnte behoben werden, wenn Screenreader verschachtelte Navigationsbereiche verstehen würden.
Warum versuchen wir, das Markup von buchstäblich Millionen von Webautoren zu reparieren, von denen praktisch niemand diese Diskussion oder Ähnliches jemals lesen wird, anstatt das Verhalten der wenigen heute verwendeten Screenreader zu beheben?
Es sind nicht nur Bildschirmleser!!! Deshalb. Auch normale Benutzer können verwirrt sein, wenn Links mehrdeutig angeordnet sind. Wenn man nicht aufpasst, kann ein umbrochener Link wie zwei Links aussehen, oder aufeinanderfolgende Links können als einer erscheinen.
Zum Beispiel in Wikipedia, wo Links zu anderen Artikeln nicht unterstrichen sind, könnte das, was wie ein Link zu „Europäische Union“ aussieht, enttäuschenderweise nur zwei Links sein, zu „Europäische“ und „Union“.
Im Allgemeinen möchte man in der Barrierefreiheit so viele Semantiken wie möglich hinzufügen, damit ein Screenreader-Benutzer schnelle Navigationsschlüssel verwenden kann, um effizient auf Ihrer Website herumzuspringen. Wenn Sie eine Liste verwenden, können sie L für Listen drücken. Ich würde sagen, verwenden Sie die Listen für die Site-Navigation, um ihr Semantik zu geben und dem Benutzer mitzuteilen, wie viele Elemente in der Navigation enthalten sind. Wenn Sie keine Listen für die Site-Navigation verwenden, würde ich das nicht als Fehler bezeichnen, aber wenn Sie keine Listen für eine sichtbar aufzählbare Liste von Links wie im Footer verwenden, würde ich das als Fehler bezeichnen.
Machen Sie sich keine Sorgen um die Ausführlichkeit des Screenreaders, der Benutzer hat die Kontrolle darüber, je nachdem, welchen Screenreader er verwendet. Alle Screenreader funktionieren unterschiedlich, und wenn sie vor dem Link „Liste, 6 Elemente“ hören, ist das überhaupt kein großes Problem. Sie haben Ihre Aufgabe erfüllt, indem Sie semantischen HTML-Code implementiert haben. Die Screenreader-Software und der Benutzer sollten ihre Aufgabe erfüllen, die Ausführlichkeit der Sprachausgabe zu steuern.
Auch Menschen mit Behinderungen sind sehr unterschiedlich und können sehr wählerisch sein, wie die Dinge für sie kodiert werden sollen. Aber sie repräsentieren nicht alle Menschen mit Behinderungen. Oftmals sieht man, dass Menschen Kodierungsentscheidungen treffen, die auf „was sie von diesem einen blinden Mann gehört haben“ oder „was sie von diesem einen Barrierefreiheitsspezialisten gehört haben“ basieren. Sehbehinderte Benutzer können sogar wählerischer sein als blinde Benutzer. Die beste Wahl ist, sich an standardbasierte Kodierung zu halten, die Semantik zu verwenden und den Benutzer und seine assistive Technologie-Software zu lassen, wie diese Semantik präsentiert wird.
Kurz gesagt, die Ausführlichkeit ist nicht Ihr Anliegen, sondern das Anliegen des AT & AT-Benutzers.
Ich bin nur ein Barrierefreiheitsspezialist mit einer Meinung, die auf Tests und Forschung basiert, aber wiederum würden nicht alle Barrierefreiheitsspezialisten mir zustimmen.
Sehen Sie, was passiert, wenn Sie sich gegen strukturelles Markup auflehnen? In dem Moment, in dem wir uns entscheiden, keine Listen zu verwenden, fangen wir an, uns zu fragen, ob wir stattdessen Divs, Spans, Paragraphen, Abschnitte oder was auch immer verwenden sollten. Reparieren Sie nicht, was nicht kaputt ist. :)
Für mich als Screenreader-Nutzer bieten Navigationslisten
die Sicherheit, dass sich keine anderen Elemente als die Navigationslinks im Navigationsblock befinden.
die Größe des Navigationsblocks, d.h. wie groß er ist (hier stimme ich dem anderen Screenreader-Benutzer nicht zu).
Die Kenntnis der Größe des Navigationsblocks ermöglicht es mir zu entscheiden, ob ich weiter durchtabulieren oder die Liste ganz überspringen soll (Screenreader erlauben es mir insbesondere, Blöcke strukturellen Markups auf der Seite zu überspringen).
Ich hoffe, das klingt nicht zu barsch, aber… Der Grund, warum vieles davon für euch keinen Sinn ergibt, ist, dass ihr beim Testen auf den Bildschirm schaut. Versucht, Webseiten mit geschlossenen Augen zu navigieren, und ihr werdet vielleicht die Bedeutung struktureller Informationen zu schätzen wissen.
+1 für das Tag.
Hat jemand die Postfachnummer von Tim Berners-Lee? Ich werde einen nachdenklichen Brief schreiben.
Das nav-Element ist ein neues Element, genau zu dem Zweck, Navigation für Screenreader anzuzeigen und eine unterschiedliche Gestaltung zu ermöglichen. Im Gegensatz zu <nl>, das für XHTML2 vorgeschlagen wurde, kann es kein <li> als direktes Kind haben, da HTML5 mit alten Inhalten und alten Browsern kompatibel sein muss.
Das hätte +1 für das <ni>-Tag sein sollen.
Persönlich gefällt mir das <nav>-Element mit <a> gut, es ist eine einfachere Methode und macht Sinn, wenn man es Anfängern im Webdesign beibringt.
Wie viele von Ihnen jedoch angemerkt haben, wie sieht es mit verschachtelten Links aus? Dann gibt es WordPress, das Listen verwendet, so dass Sie beim Themeing immer noch Listen berücksichtigen müssen.
Ich denke jedoch, es wäre schön, wenn das Element wie z.B. Beschreibungslisten funktionieren könnte, so dass wir zum Beispiel so etwas haben könnten:
<nav>
<nl><a href=”link.htm”>Link 1 </a></nl>
<sl><a href=”linkA.htm”>Link 1 A</a></sl>
<sl><a href=”linkA.htm”>Link 1 B</a></sl>
<nl><a href=”link.htm”>Link 2 </a></nl>
</nav>
In diesem Beispiel könnten wir einen „Navigationslink“ <nl> und einen „Sub-Link“ <sl> haben. Das würde natürlich nur in einer perfekten Welt geschehen. ;)
oder <ni>, wie andere vorgeschlagen haben
Ich denke, die Verwendung einer Liste oder nicht hängt eher von der Art der Navigation im Inneren ab, als von der pauschalen Allerweltslösung.
Wenn man sie als normalen Inhalt innerhalb eines Tags betrachtet, wäre es die Art von Inhalt, die man in ein ul packen würde? Oder ist es nur eine Reihe von Elementen?
Besonders bei einfachen Navigationen sehe ich wenig Grund, warum alles in ein zusätzliches Element verpackt werden sollte.
Auch gibt es viele verschiedene Arten von Navigation, daher bezweifle ich, dass es für alle Situationen einen „richtigen Weg“ gibt.
tl;dr Wenn es eine Liste ist, dann sollte sie in einer Liste in einem Nav sein, aber wenn es nur eine Gruppe von Links ist, sehe ich keinen Grund, sie in ein ul zu packen
Beim Durchlesen der Kommentare sehe ich insbesondere nicht, wie „die Waage in Richtung“ der Verwendung von Listen kippt, wie Sie in Ihrem Tweet erwähnt haben.
Hier sind einige Testergebnisse von VoiceOver, NVDA und Windows Eyes
Die zwingenden Gründe, ol oder ul zu verwenden, sind normalerweise
Dies ist die Art und Weise, wie es im Großteil des Webs getestet und implementiert wurde.
Dies bietet Unternavigationselementen eine sinnvolle Hierarchie.
<ul role=”navigation”> bietet ein nahezu identisches Markup zu einer div- und span-Lösung.
Die zwingenden Gründe, ihre Verwendung zu vermeiden, sind normalerweise
Dies entfernt ungerechtfertigte Bedeutung von der Seite.
Dies vereinfacht das Markup und entfernt unnötige Elemente, insbesondere bei Breadcrumbs und flachen Navigationen.
Dies rechtfertigt all die Klassennamen, die ich verwenden wollte/musste (und hat das HAML-Markup wirklich verkleinert).
Es scheint, als gäbe es eine Präferenzsache, sogar bei denen, die Screenreader verwenden. Solange man Screenreader berücksichtigt, denke ich nicht, dass es „eine richtige Antwort“ gibt.
Ohne tatsächlich jemand zu sein, der einen Screenreader benutzt, ist es schwer, nur durch Ansehen zu urteilen, und es ist eine gefährliche Haltung anzunehmen, dass jeder, der einen Screenreader (oder eine beliebige Gruppe von Menschen) benutzt, das Internet auf eine bestimmte Weise durchsucht oder es vorzieht, dies zu tun.
Ich finde es seltsam, wie viele Leute kommentieren: „Was ist mit Dropdowns?“ …Was ist mit ihnen!?
Ich liebe diese Idee, aber wie bringen wir WordPress dazu? WordPress will alles und den Blink-Tag in die Navigation einfügen. Irgendwelche Ideen?
Als Zwischenstation versuche ich, die wichtigsten Pro- und Contra-Argumente hier zu sammeln: http://codepen.io/chriscoyier/details/ztxvw
Ich weiß, dass die HTML5-Spezifikation diese Einschränkung festlegt, aber sie gibt nicht an, woher diese Einschränkung stammt. Weder die ARIA-Spezifikation noch die W3C ARIA-Autoren-Dokumente behaupten diese Einschränkung. Tatsächlich wird role=navigation als globales Attribut betrachtet und kann somit auf alles angewendet werden.
Dies trifft nur auf „flache“ Navigationen zu. Wie ich bereits erwähnt habe, wird die ganze Sache komplexer, wenn man Untermenüs benötigt. Ein einfaches Beispiel
<nav> <h1>Menu-title</h1> <a>item-1</a> <a>item-2</a> <section> <h2>Submenu title</h2> <a>sub-item-1</a> <a>sub-item-2</a> </section> <a>item-3</a> </nav>Und das ist nicht einmal die komplexeste Struktur. Um eine korrekte HTML5-Gliederungsstruktur beizubehalten, wäre es am besten, jedes Menüelement und Unterelement in ein eigenes Abschnittselement zu verpacken. Auch muss jeder Abschnitt eine Überschrift haben.
Der Punkt, den ich machen möchte, ist, dass bei der Verwendung eines UL die Struktur flexibel bleibt, egal wie komplex die Navigation wird, aber wenn kein UL verwendet wird, wird die Struktur zunehmend komplexer.
Rolle ist ein globales Attribut, das einzige globale Token für Rolle in HTML ist „Präsentation“. Die Konformitätsbeschränkungen in HTML5 basieren auf dem Konzept „starker nativer Semantik“ und „impliziter ARIA-Semantik, wie in der ARIA-Spezifikation definiert. In der ARIA-Spezifikation heißt es
Ich mische mich mal mit meinen zwei Cent ein…
Vor langer Zeit, um 2005, arbeitete ich eng mit dem RNIB und speziell mit blinden Testnutzern zusammen, als wir die Website der Scottish Qualifications Authority für Barrierefreiheit neu aufbauten. Diese Testnutzer griffen sowohl mit JAWS als auch mit Supernova auf das Web zu.
Die gesamte Hauptnavigation auf der Website wurde mit ungeordneten Listen erstellt, und zu keinem Zeitpunkt verursachte dies den Benutzern ungebührliche Probleme bei der Navigation.
Tatsächlich trugen die Tags dazu bei, dass Links nicht ineinander übergingen (dies könnte vor der expliziten Ankündigung von Links als solche in Jaws gewesen sein), und es funktionierte auch gut für Benutzer, die das Web ohne aktivierte Stylesheets betrachteten, da eine Standardliste von Links immer noch schön in einzelne Elemente unterteilt ist, obwohl Divs als Blöcke dasselbe tun würden, wäre dies bei Spans usw. nicht der Fall.
Ich denke, die Barrierefreiheit von Websites sollte auf allen Websites mit guter Codierungspraxis erreichbar sein. Es gibt jedoch immer wieder seltene Gelegenheiten, bei denen selbst die Jungs von RNIB sich am Kopf kratzen müssen…
Wir haben nie einen Weg gefunden, eine Grafik des Periodensystems mit Alt- oder Longtext-Alternativen zu beschreiben…
Was wäre, wenn man ein neues Element für Navigationslisten schaffen würde, das dann von Screenreadern separat interpretiert und für das Styling anders behandelt werden könnte?
Das ist eine Option, aber es ist immer noch eine Liste innerhalb einer NAV, nur eine andere Art von Liste als eine UL.
Ich habe oft über den Grund nachgedacht, warum wir Listen als Menüstrukturen verwenden.
Das ist eine sehr interessante Lektüre.
Ich frage mich, ob dies Auswirkungen auf SEO hat?
Was ist mit SEO?
In meinem letzten Job sagte die SEO-Abteilung, die behauptet, eine der besten in Großbritannien zu sein, immer, dass eine navigierte Liste, sei es die Haupt- oder Fußzeilennavigation, in einer li-Struktur sein müsse, damit Suchmaschinen-Bots die Haupt-Sitemap-Struktur leicht identifizieren könnten?
Was mich überrascht, ist, dass die Leute früher Links mit einem |-Zeichen oder ähnlichem trennten, wie es in den Barrierefreiheitsratschlägen stand: http://joeclark.org/book/sashay/serialization/Chapter07.html#h1-2935.
Dann basierte der Rat, Listen für die Navigation zu verwenden, ebenfalls auf Barrierefreiheit: http://www.brucelawson.co.uk/2005/navigation-lists/
Jetzt haben wir ein Nav-Element, wir verwenden immer noch Listen: http://www.w3.org/WAI/GL/wiki/Using_HTML5_nav_element
Die ganze Vorstellung, keine Listen mehr zu verwenden, ist also höchst eigenartig.
Lassen Sie mich Ihnen ein Beispiel geben, wie „Linklisten“ klangen, bevor sie mit ungeordneten Listen weit verbreitet ordnungsgemäß strukturiert wurden. Um sie visuell zu trennen, waren sie entweder Grafiken, wobei 80% des Alt-Textes fehlten, weil der jeweilige Designer sich nicht darum kümmerte, oder es waren Textlinks, die entweder in Klammern [] eingeschlossen oder durch Dinge wie vertikale Balken | getrennt waren. Eine „Linkliste“ hätte sich also so anhören können, wenn man bedenkt, dass dies so spezielle Zeichen sind, dass Bildschirmleser sie nur im strengsten Ausführlichkeitsmodell unterdrücken würden
„linke Klammer Home rechte Klammer Link“ „linke Klammer Produkte rechte Klammer Link“
oder, besonders beim kontinuierlichen Lesen
„Home Link vertikaler Balken Produkte Link vertikaler Balken Support Link …“
Mit der Verbreitung einer ordnungsgemäßen strukturellen Auszeichnung für diese hat sich die Situation für diejenigen, die den ganzen Tag ihrem Computergeplapper lauschen müssen, insbesondere bei Textlinks, IMMENS verbessert!!! All diese zusätzlichen Zeichen verschwanden, weil sie für die visuelle Trennung zweier Links voneinander nicht mehr benötigt wurden.
Wenn man nun plötzlich wieder zu Spans und Divs zurückkehrt, selbst wenn sie in ein Nav-Element eingeschlossen sind, geht die strukturelle Auszeichnung größtenteils wieder verloren. Spans sind nichts weiter als Texteinfügungen innerhalb anderer Texte, und Divs sind schwache Abschnittselemente. Sie sind oft so tief verschachtelt, dass die Kommunikation von Einrückungsebenen völlig lächerlich ist, so dass es keine zuverlässige Möglichkeit gäbe, klar zu kommunizieren, was beabsichtigt ist. Ja, darauf läuft es hinaus: ABSICHTEN MÜSSEN KLAR UND EINDEUTIG SEIN! Listenauszeichnungen sind die zuverlässigste Methode, dies auf eindeutige Weise zu tun. Dies ist nicht nur für Bildschirmleser wichtig, sondern auch, wie bereits erwähnt, um Styling und Einrückungen zu erhalten, die für verschiedene Bildschirmgrößen wichtig sein können, um vom Browser korrekt berücksichtigt und interpretiert zu werden usw. usf.
Meiner Meinung nach ist die Idee, Gruppen von Links wieder mit Divs und Spans zu gestalten, fast so schlimm wie der Vorschlag, dies in Layouttabellen zu tun!
Reinhard Stebner spricht sicherlich nicht für mich, wenn er sagt, dass Linklisten nicht mehr sein sollten. Und ich glaube, er hat einfach eine bestimmte Seite mit entsetzlicher Benutzerfreundlichkeit ausgewählt und davon verallgemeinert, und das sollten wir definitiv nicht tun.
Gut gesagt. Und ja, viele Probleme würden mit besserem Code und besseren UAs gelöst.
Ich schwelge in Nostalgie und gehe auch in die Vergangenheit zurück. Es gibt einen Grund, warum eine Homepage als Index bezeichnet wird.
Dies basiert auf einem Buchindex. Und ein Buchindex ist eine Liste.
Einige Zeit später wurde derselbe Index oben oder an der Seitenleiste der gesamten Website fixiert, so dass wir nicht zum Index zurückkehren müssen.
Sie nannten dies ein Menü, genau wie ein Restaurantmenü, das auch eine Liste ist.
Das ist logisch: Wenn ein Index eine Liste ist, ist ein Menü eine Liste.
Und mehr: Ein Menü ist nicht nur eine „Liste von Links“, ein Menü ist ein Index, eine Liste von Website-Kapiteln oder -Seiten oder -Abschnitten oder -Bereichen…
Dies muss semantisch sein, auch wenn Sie die Links ignorieren.
„Firma | kaufen | Kontakt“ ist wie „Firma, kaufen, Kontakt“. Das hat eine gewisse Logik, weil ich Dinge wie in einem Satz aufzähle.
Aber „Firma kaufen Kontakt“ ist nur eine unlogische Anordnung von Wörtern. Das ist keine Phrase, keine Liste und kein Index. Oder man könnte es als „eine Firma, die Kontakte kauft“ verstehen… seltsam.
Das ist ein Menü, ein Index und eine Liste
– Unternehmen
– kaufen
– Kontakt
Bevor jemand fragt, Registerkarten basieren auch auf Büchern. Benutze die Registerkarten und gehe zu einem anderen Kapitel, damit wir nicht zum Index zurückkehren müssen.
Registerkarten verwenden denselben Index. Also sind sie auch Listen.
Was für ein heißes Thema!
Für mich ist die Navigation eine Liste anderer Seiten auf der Website. Daher markiere ich sie mit einer Liste. Eine interessantere Diskussion ist, ob die Navigation eine geordnete Liste ist oder nicht. UX würde sagen, sie muss unbedingt in dieser Reihenfolge sein, also sollte ich wahrscheinlich ol verwenden; man könnte leicht ein Argument für das Gegenteil machen.
Wenn ein Screenreader Probleme mit Navigationslisten hat (was die Norm zu sein scheint), ist das eine schlechte Wahl auf der Softwareseite, nicht auf der Semantik unseres Markups.
Ich glaube nicht, dass es darum geht, ob das UI-Design eine Reihenfolge vorschreibt. Wenn man mit Screen-Designs arbeitet, werden sie in irgendeiner Reihenfolge sein, zufällig oder nicht.
Ein Szenario, das meiner Meinung nach eine OL für die Navigation anstelle einer UL rechtfertigen würde, wäre, wenn die Navigation eine Reihe von sequentiellen Schritten sein soll, die in dieser Reihenfolge ausgeführt werden, wie der Checkout-Prozess eines Warenkorbs. Sie zeigen gerne alle Schritte an, der aktuelle Schritt ist hervorgehoben, die vorherigen Schritte sind navigierbar, und die nächsten Schritte werden nur zur Information angezeigt.
Aber wenn man nur einige typische Footer-Links hätte und die Screendesigns / der Kunde sagte, sie müssten unbedingt in einer bestimmten Reihenfolge angezeigt werden (nicht ungewöhnlich), ist das immer noch kein Grund, ein OL zu verwenden. Es geht darum, ob die Reihenfolge für den Benutzer wichtig ist, nicht für den Autor.
@Lee: Ich kann der Meinungsverschiedenheit bezüglich OL in der Hauptnavigation zustimmen. Wenn die Reihenfolge geändert würde, würden die Listenelemente ihre Bedeutung nicht ändern (solange verschachtelt verschachtelt bleibt, natürlich).
Dies ist ein interessantes Thema. Ich glaube, dass die Seite logisch gerendert werden sollte, wenn Sie alle Ihre Stile deaktivieren. Dies wäre meiner bescheidenen Meinung nach ein Grund, Navigationslinks in einer Liste zu behalten. Eine geordnete Liste.
Ich stimme dir zu, Rob. Diese Website verwendet Andy Clarkes universelles Stylesheet für IE6 und IE7, und die als Listen markierten Linkgruppen sind – visuell – in diesen Browsern einfacher zu verwenden.
Drei Personen, die Screenreader verwenden – Léonie Watson, Victor Tsaran und Marco Zehe – haben hier gesagt, dass die Kennzeichnung von Navigationslinks als Listen nützlich ist.
Was brauchen wir noch?
Navigationslinks als Listen kennzeichnen.
Vier, wenn man Aaron unten mitzählt, plus die erwähnte informelle Umfrage unter 30, die Listen bevorzugten. Aber auch einer, der es nicht tut und sich dagegen ausspricht. Ich habe jedoch das Gefühl, dass alle Faktoren zu Listen tendieren. Ich werde bald eine Zusammenfassung erstellen.
Als blinder Jaws-Benutzer bevorzuge ich persönlich, dass Navigationselemente in Listen verpackt sind. Wie bereits in dieser Diskussion erwähnt, ermöglicht es dem Autor, hierarchische Informationen darzustellen, und gibt mir schnelle Informationen darüber, wie viele Elemente es gibt, bietet mir eine weitere schnelle Möglichkeit, von Element zu Element zu springen, und lässt die Dinge etwas organisierter erscheinen. Allerdings wird es, wenn ich eine Website besuche, wahrscheinlich keinen wesentlichen Einfluss auf meine Erfahrung haben, ob die Navigation in einer Liste ist oder nicht, und es wird wahrscheinlich auch keinen großen Unterschied machen, ob diese bestimmte Website barrierefrei ist.
Natürlich ist dies mit ARIA, wie bereits erwähnt, weniger ein Problem, aber die Navigationslinks in einer Liste geben etwas mehr semantische Informationen, was immer schön ist.
Wenn man darüber nachdenkt, ist eine Liste von Links immer noch eine Liste, ob man es merkt oder nicht. Das Erscheinen von NAV auf der Bildfläche ändert das nicht. Wir müssen uns kollektiv darüber im Klaren werden, bis wir die entstehende Wahrheit, die hier liegt, vollständig erfassen. Ich sage nicht, dass man das UL-Element verwenden muss, wenn man es nicht möchte. Ich sage, wir sollten nicht denken, dass NAV, nur weil es jetzt hier ist, bedeutet, dass eine Liste von Links keine Liste mehr ist.
Außerdem ersetzt NAV nur <div id=”nav”>, nicht die Liste der Links, die sehr wahrscheinlich innerhalb des <div id=”nav”></div>-Elements war. Aber vielleicht könnten Browser NAV wie den Anfang einer „Navigationsliste“ behandeln. Oder vielleicht könnten sie ein NL-Element für . . . „Navigationsliste“ erstellen. Und vielleicht könnte dieses NL-Element innerhalb von NAV platziert werden, ähnlich wie H1 und H2 innerhalb einer HGROUP platziert werden, die sich innerhalb eines HEADERS befindet. Oder wir könnten weiterhin ein UL innerhalb eines NAV verwenden. Denken Sie nur nicht, dass eine Liste von Links keine Liste mehr ist.
Ich denke, es ist richtig, dass Navigation als Liste ausgezeichnet wird, aber ich habe andere Dinge gesehen, die als Listen ausgezeichnet wurden, die meiner Meinung nach definitiv nicht so sein sollten. Am erstaunlichsten war es, als ich sah, dass ein Formular als Liste von Formularfeldern ausgezeichnet wurde. Die Listenelemente müssen stärker miteinander verbunden sein, als nur demselben Formular anzugehören. Vielleicht, wenn eine Liste erfasst werden soll, aber das war hier nicht der Fall.
Ja, Menschen machen manchmal Fehler. Umso mehr Grund, es richtig zu machen, wenn wir können.
@Christian, ich habe das gleiche mit einem „nl“-Element gedacht. Das Navigation List Element hätte einfach stilfrei sein können, im Gegensatz zu ol und ul, aber die Einrückung beibehalten, aber brauchen wir wirklich ein weiteres Listenelement? Verschachtelte, ungestylte ul’s geben Ihnen einen visuellen Hinweis auf die Verschachtelung (● > ○ > ■), was gut zusammenpasst, wenn man mit gestuften Navigationen arbeitet. Ich wette, als jemand das nav-Element erfunden hat, war seine Absicht nicht, Navigationen durch die bloße Verwendung von nav > a + a zu trivialisieren, das verliert irgendwie an Semantik, andererseits nehme ich an, das kann subjektiv sein.
Ich weiß, sie sprechen in der Spezifikation von nicht-gelisteten Verwendungen von nav, aber in ihren Beispielen zeigen sie auch die Verwendung von ul's, und wenn ich genauer darüber nachdenke, ist nav mehr oder weniger wie section, article oder aside, das den Inhalt darin beschreibt, nicht eine Kurzlösung für die Navigation. Wenn es keine Hierarchie in Ihrer Navigation gibt, funktioniert ul perfekt, aber in Fällen, in denen Wichtigkeit oder Reihenfolge erforderlich sein könnten, könnte ol ein gutes Argument liefern. Für mich macht es Sinn, bei der traditionellen Methode der Erstellung von Navigationen zu bleiben. Was das Styling angeht, habe ich eine schöne kleine Dienstprogramm-Datei _tools.scss erstellt, in die ich leicht ein Mixin einfügen kann, das einige der Browserstile entfernt, wenn ich normalize verwende, falls ich das unbedingt muss.
@Lee: „Das Erstaunlichste war, als ich sah, dass ein Formular als Liste von Formularfeldern ausgezeichnet worden war.“
Was wäre Ihre Wahl?
Semantisch ist eine Reihe von Formularfeldern eher eine Liste (UL und in einigen Fällen OL) als ein Absatz… oder sogar ein Div… oder ein Span. Man könnte auch ein Argument für Definitionslisten anführen. Ich denke, es ist die semantisch korrekte Wahl, ein Formular mit einer Liste auszuzeichnen.
Hey Merne. Mein Erstaunen war reine Bauchreaktion, ich weiß nicht, ob ich es artikulieren kann, aber ich werde es versuchen
Semantisch enthält ein Formular typischerweise keine Liste von Feldern. Für Sie vielleicht, aber nicht für Ihren Benutzer. Das wäre, als würde man sagen, ein Absatz sei eine Liste von Sätzen oder ein Satz sei eine Liste von Wörtern. Sie sind implizit, aber nicht explizit, es würde keinen Wert hinzufügen, sie so zu bezeichnen.
Es ist nicht nötig, in HTML etwas nur deshalb zu tun, weil man eine Sequenz hat, es behandelt Sequenzen bereits gut.
Auch wenn es für Sie aus Implementierungssicht bequem sein mag, Ihre Dokumente mithilfe von Listen zu strukturieren oder zu verarbeiten, ist es für Ihre Benutzer nicht von Vorteil, sie als Listen bereitzustellen. Dafür sind semantische Elemente da (für Ihre Benutzer).
Ich werde versuchen, die Form != Liste von Feldern etwas genauer zu erläutern.
Eine Liste (eine, die für den Benutzer sinnvoll ist) ist nicht nur eine Menge verwandter Elemente, sondern normalerweise Elemente desselben Typs. Formulare enthalten typischerweise nicht nur eine einfache Abfolge von Feldern, sie haben Überschriften, Beschriftungen, Felder, Absätze mit erklärendem Text, Hilfesymbole, Formularfehlermeldungen, Feldfehlermeldungen, felderübergreifende Fehlermeldungen, Schaltflächen, vielleicht eine Liste von Schritten, einen Fortschrittsbalken, horizontale Linien (wer weiß?), Fieldsets und vielleicht sogar noch mehr.
Wenn Sie der Meinung sind, dass einige dieser Dinge außerhalb des Formular-Elements liegen sollten, stellen Sie sich vor, das Formular-Element hätte einen Hintergrund mit einem schönen Rahmen, oder selbst wenn das Formular ein Papierformular wäre, gehören sie semantisch zum Formular, nicht wahr?
Wenn also ein Absatz zwischen zwei Formularfeldern in einem Formular stehen würde, wäre der Absatz dann auch Teil der Liste, oder würde es bedeuten, dass man eine Liste beenden und eine neue beginnen müsste? Ich glaube einfach nicht, dass es überhaupt Sinn macht, eine Liste zu verwenden.
Wenn also keine Listen, was ist meine Wahl? Heutzutage meist nichts, kein div, span, paragraph, definition oder irgendetwas, da Beschriftungen über den Feldern stehen sollten, finde ich die meisten Layouts ohne zusätzliches Markup erreichbar. HTML4.1 Strict erlaubt das Input-Element nicht als direktes Kind des Form-Elements, was ärgerlich war, aber HTML5 tut es.
„Eine interessantere Diskussion ist, ob die Navigation eine geordnete Liste ist oder nicht. UX würde sagen, sie muss unbedingt in dieser Reihenfolge sein, also sollte ich wahrscheinlich ol verwenden; man könnte leicht ein Argument für das Gegenteil machen.“
Merne, ja, die Lösung hier ist, es zu einer geordneten Liste zu machen, wenn die Reihenfolge in diesem speziellen Fall wirklich wichtig ist. Wenn die Reihenfolge keine Rolle spielt, dann bleiben Sie bei UL. Ich habe beides verwendet.
Richtig. Absolut richtig. Wenn Sie Ihre Navigation in einem Absatz wünschen, dann legen/belassen Sie sie in einem Absatz (der dann selbst innerhalb des NAV-Elements wäre). Aber wenn es eine Liste ist, dann belassen Sie sie in einer Liste (die dann auch selbst noch innerhalb des NAV-Elements wäre). Sie sagen nicht: „Nun, da wir das NAV-Element haben, werde ich meinen Absatz von Links aus dem P-Element entfernen, in dem sie sich früher befanden.“
Als blinder Screenreader-Nutzer stimme auch ich der Verwendung von Listen zu, aus all den guten Gründen, die andere genannt haben. Nebenbei bemerkt, ohne ein großes Aufsehen darum zu machen, versuche ich, wenn ich über Web-Barrierefreiheit unterrichte, meine Referenzen sehr deutlich zu machen, d.h. über zehn Jahre Arbeit an und Förderung von Webstandards. Und wenn ich eine persönliche Meinung äußere, versuche ich, dies sehr deutlich zu machen. Ich denke, es gibt Möglichkeiten, Menschen nach der Grundlage ihrer Behauptungen zu fragen, die eine wertvolle Diskussion hervorrufen und nicht als Angriff rüberkommen.
Es ist sehr erfrischend, von Menschen zu hören, die dies direkt betrifft.
Ich führe diese Debatte nun schon seit etwa einem Jahr. Zugegebenermaßen arbeite ich noch nicht sehr lange im Web und wurde nicht klassisch im Web oder in der Programmierung ausgebildet, aber ich bin auch kein Dummkopf und habe die meiste Zeit meines Studiums damit verbracht, schwierige Probleme zu lösen. Ich habe einige Recherchen durchgeführt und die einzigen Argumente für Listen als Navigation, die ich gefunden habe, fallen in einige Kategorien
Semantisches Web: Das Problem ist, dass niemand erklären zu können scheint, warum „ul li a“ semantisch ist und „div span a“ nicht. Es scheint mir klüger, die natürlichen Zustände der HTML-Objekte zu nutzen, um dem Gewünschten nahezukommen, bevor wir überhaupt CSS anfassen.
Screenreader: Anscheinend sind diese Listen für sie nicht so nützlich, wie einige dachten.
Das ist eben so: Dogma. Ich hasse Dogma, und wenn ich zusätzliche Schritte unternehme, um die gleichen Ergebnisse zu erzielen, die ich mit weniger Schritten bekommen könnte, möchte ich wissen, warum. Wieder keine guten Erklärungen.
Bei der Arbeit benutze ich Listen, weil ich mit anderen zusammenarbeite und es wichtig ist, einen Konsens zu haben, aber zu Hause werde ich niemals Listen für die Navigation verwenden, es sei denn, ich möchte eine Navigation, die wie eine Aufzählungsliste aussieht, es erscheint mir albern.
Das andere verrückte Ding, das ich vorgeschlagen habe und das die Leute anscheinend nicht so sehr mögen, ist, niemals, niemals, niemals HTML-Objekte als jQuery- oder CSS-Selektoren zu verwenden. Das scheint mir ein offensichtlicher Weg zu sein, CSS und HTML modularer zu gestalten. HTML-Objekte aus Selektoren herauszuhalten, ermöglicht es, das HTML aus beliebigem Grund zu ändern (z.B. von Span zu Div zu wechseln, weil ich möchte, dass einige Objekte stapeln, ohne meine gesamten jQuery- und CSS-Selektoren ändern zu müssen, wäre fantastisch).
Andererseits, wie ich oben schon sagte, bin ich ziemlich neu. Bis ich also Zeit und Daten habe, um diese Ideen tatsächlich zu testen, werde ich mich für die Arbeit an die Konvention halten.
Antwort: Es liegt daran, dass DIV und SPAN an sich keine semantische Bedeutung tragen und ohne zusätzliche Daten, sei es in Form von Klassen oder IDs, Rollen oder was auch immer, keine Bedeutung haben. Ersteres bedeutet „generisches Block-Level-Element“, während letzteres „generisches Inline-Element“ bedeutet. Aber UL und LI tragen jeweils eine Menge semantischer Bedeutung. Ersteres bedeutet „ungeordnete Liste“, während letzteres „Listenelement“ bedeutet.
Wenn Sie eine Liste von Links haben, dann haben Sie eine Liste, und es wird dann angemessen (wenn auch vielleicht nicht zwingend), sie in HTML als Liste zu charakterisieren.
„DIV SPAN A“ sind mehr Schritte als „UL LI A“.
Und für diejenigen, die befürchten, dass man bei der Erstellung von Navigationslisten manchmal die Standardformatierung aufheben muss, nun, bei DIVs und SPANs müssen Sie die Formatierung hinzufügen. Es gibt schnelle Möglichkeiten, Listen ohne Code-Bloat zu gestalten, wenn Sie wissen, was Sie tun. Und das größere Anliegen ist es, Ihre HTML-Elemente richtig zu charakterisieren und dann zu gestalten.
6 Personen, die Screenreader benutzen, haben hier gesagt, dass das Markieren von Navigationslinks als Listen nützlich ist.
Ich auch.
Lesen Sie die Kommentare hier von Leuten, die Screenreader benutzen. Das sind gute Erklärungen.
Christian
Okay, verstanden, Sie gehen also davon aus, dass das Denken an Navigationen als Listen irgendwie hilfreich ist. Ich halte es immer noch für albern, eine Navigation als Liste zu betrachten, es sei denn, ich möchte, dass meine Navigation eine Aufzählungsliste ist. Die Leute im Web haben diese Konvention übernommen, aber es scheint mir eine willkürliche Übernahme zu sein. Wenn es in den 90er Jahren nicht willkürlich war, dann ist es das heute sicherlich.
Entschuldigung, würden Sie diese Aussage bitte genauer qualifizieren? Ich zähle jeweils 3 Elemente, das heißt, es braucht die gleiche Anzahl von Schritten, um jedes zu konstruieren.
Entschuldigung, das müssen Sie immer tun, nicht manchmal. Immer. Jedes einzelne Mal, wenn Sie Listenelemente als Navigation verwenden, müssen Sie CSS verwenden, um diese Listenstile zu entfernen und in vielen Fällen zu zwingen, inline anzuzeigen.
Ich verstehe diese Aussage nicht. Wir sprechen hier nicht von Stil, wir sprechen von Struktur. Listen haben einen Stil, den man jedes Mal entfernen muss (was man in einer Reset-Datei hinzufügen könnte). Die Sache ist, die meisten Navigationsleisten, die ich heute sehe, sind horizontal. Wenn Sie einen Reset verwenden, um den Listenstil zu entfernen, was passiert dann, wenn dieser Reset aus irgendeinem Grund nicht geladen wird? Ihre horizontale Liste bricht nun aus Ihrem gestylten Container aus und hat diese hässlichen schwarzen Punkte. DIV SPAN A umgeht das ganze Problem, dass ein Reset erforderlich ist, um die natürlich gestylten Listen zu entstylen.
Anders ausgedrückt: Wenn ich eine Navigation so anzeigen möchte
Startseite Nachrichten Kontakt
Ich kann das natürliche strukturelle Verhalten von HTML-Objekten nutzen, um sofort dorthin zu gelangen, ohne CSS… Beispiel (Entschuldigung für die kreative HTML-Darstellung haha)
und ich bin fertig! Wenn ich den Listenweg gehen möchte, gehe ich den obigen Schritt durch und muss auch display: inline und list-style-type-none handhaben. Um es aufzuschlüsseln: Eine nicht-Listen-Navigation zu initialisieren, dauert 1 Schritt und ist weniger wahrscheinlich, dass Ihre Seitenformatierung kaputt geht, wenn etwas schief geht, während die Erstellung einer Listen-Navigation 2 Schritte dauert. Das letzte Mal, als ich nachgesehen habe, ist 2 < 1
WENN die Navigation eine Liste ist, aber nicht, wenn sie es nicht ist.
Das Problem dabei ist, etwas nur dann als Liste zu betrachten, wenn es mit Aufzählungszeichen versehen ist.
All das Gesagte, ich habe auch einige der Screenreader-Kommentare gelesen und sie machen Sinn. Dies macht mir jedoch am meisten Sinn
Könnte dies nicht auch mit einem Plugin gemacht werden? Das scheint ein interessantes Problem zu sein, das man versuchen könnte zu lösen. Ich habe ein Bookmarklet geschrieben, das im Wesentlichen das Fernklicken im Browser ermöglicht und auch als Plugin verwendet werden könnte. Es war eine herausfordernde Übung, etwas zu bauen, das auf jeder Webseite gleich funktioniert, trotz der Struktur des HTML. Wenn ich besser in diesem Web-Zeug werde, wäre es vielleicht lustig, zu versuchen, einen Screenreader zu bauen, der Webseiten intelligent analysiert, unabhängig vom Markup. Das wäre allerdings ein „next level shit“, und ich bin definitiv noch nicht so weit. (noch)
Wie dem auch sei, das Screenreader-Argument scheint das einzige praktikable zu sein, das ich bisher gesehen habe. Es tut mir leid, aber die anderen halten aus den oben genannten Gründen einfach nicht stand.
Es besteht immer das Risiko, dass Styles nicht geladen werden. Das ist kein Problem, das Listen eigen ist.
Ok, danke Christian, dass du mir gezeigt hast, dass ich Recht hatte, dass Listen mehr Arbeit ohne guten Grund sind. Ich werde von nun an in meinen persönlichen Projekten keine Listen mehr verwenden und meine Kollegen vielleicht sogar davon überzeugen können, wie albern Listen sind.
Was Sie an dem nicht ladenden Reset missverstanden haben, ist, dass eine horizontale Navigation mit Listen-Markup in diesem Fall potenziell völlig unbrauchbar sein könnte, während die andere Option mit keinen oder weniger Stilen immer noch brauchbar wäre.
Ich habe kein persönliches Interesse daran, was Sie tun.
Es steht Ihnen frei, etwas, das eine Liste ist, als keine Liste zu charakterisieren, wenn Sie es vorziehen. Ich werde Sie nicht aufhalten. „Eine Liste ist eine Reihe von Elementen, die geschrieben oder gedruckt wird.“ Es muss nicht „vertikal“ und „aufgezählt“ sein, um eine Liste zu sein. Siehe auch hier.
Ich weiß, worauf Sie hinauswollen. Und wenn Leute wollen, können sie alles so kodieren, als ob „Reset“-Stile nur versagen könnten. In letzter Zeit habe ich den Ansatz gewählt, Reset-/Normalize-Stile am Anfang meines eigenen Stylesheets zu platzieren und dann die Werte im Reset-/Normalize-Bereich anzupassen, wenn das hilft. Und oft tut es das. Und wenn dann mein gesamtes Stylesheet nicht geladen wird und nur Benutzeragent-Stylesheets angewendet werden, dann wird die Website immer noch logisch angezeigt, wenn mein HTML korrekt ausgezeichnet wurde.
Damit diktiere ich nicht, wie man ihren Inhalt charakterisieren sollte, sondern erinnere nur daran, dass wir ein Szenario haben, bei dem der „Schwanz mit dem Hund wedelt“, wenn „wie es im Browser aussieht“ bestimmt, wie wir unseren Inhalt markieren.
Als Screenreader-Benutzer und als jemand, der häufig zu diesem Thema berät – einschließlich Tests –, freue ich mich über diese leidenschaftliche Diskussion über Navigation.
Ich stimme den anderen Screenreader-Benutzern zu, die hier über die Vorteile der Verwendung von Listen für die Navigation kommentiert haben. Ich möchte auch auf diese nützliche Ressource für ARIA-Markup für Nav/Menü bei Stack Overflow hinweisen.
http://stackoverflow.com/questions/12279113/recommended-wai-aria-implementation-for-navigation-bar-menu
Ich möchte auch auf den Vorschlag eingehen, dass die Behinderten-Community einen eigenen Browser entwickeln sollte, um die beste Implementierung zu erhalten. Wie andere bereits angemerkt haben, ist dies weder wünschenswert noch ideal. Tatsächlich ist es das Gegenteil. Die meisten Browser-Anbieter haben erhebliche Arbeit in die Integration von Barrierefreiheit gesteckt. Screenreader-Entwickler haben daran gearbeitet, diese Browser zu unterstützen. Es wird angenommen, dass die Erstellung eines „speziellen“ Browsers Designer und Entwickler automatisch von der Verantwortung entbinden würde, nach Spezifikation und Best Practices zu programmieren. Dies ist natürlich weit von der Wahrheit entfernt.
Wie Victor betonte, ist es manchmal schwierig zu verstehen, was Benutzer mit Behinderungen beim Surfen im Netz durchmachen. Manchmal kann die subtilste Sache einen großen Unterschied in der Qualität des Surfens auf einer bestimmten Website ausmachen. Ich ermutige jeden Entwickler, den kostenlosen und aktuellsten Screenreader von http://www.nvda-project.net herunterzuladen und zu verwenden. Wenn Sie Ihre Website testen, versuchen Sie, Ihren Bildschirm auszuschalten oder nicht auf Ihr Gerät zu schauen. Voiceover kann auf Ihren iOS-Geräten verwendet werden, indem Sie zu Einstellungen/Allgemein/Bedienungshilfen/Voiceover gehen. Erfahren Sie, wie die Interaktion tatsächlich abläuft. Denken Sie so darüber nach: Testen Sie und sehen Sie, wie Ihre Navigation oder eine bestimmte Funktion aussieht? Warum testen Sie dann nicht, wie Ihre Website für Benutzer mit Behinderungen erscheint?
Ich nehme an, Sie beziehen sich auf meinen Kommentar, da ich keine andere Erwähnung davon finden kann.
Zunächst einmal habe ich nie gesagt, es würde "Designern und Entwicklern die Verantwortung abnehmen, nach Spezifikation und Best Practices zu codieren". Das sollte immer getan werden.
Die Vorteile, an die ich dachte, würden allen zugutekommen. Es gäbe einen einzigen, plattformunabhängigen Testpunkt für Barrierefreiheit (wer hat die Zeit und Ressourcen, alle Screenreader zu testen?). Native Widgets (z.B. Kalender) könnten erstellt werden, die bekanntermaßen barrierefrei sind, und Skip-Navs könnten richtig behandelt werden (Webkit ist hier der Übeltäter), neben anderen Dingen.
Dieser Vorschlag basiert teilweise auf diesen Ergebnissen, die ziemlich schlecht sind (nur 2 bekamen "grüne" Bewertungen): http://www.html5accessibility.com
Und wenn der Browser auf Webkit basieren würde, könnten einige dieser Beiträge auch an die anderen Webkit-Browser gehen.
Übrigens scheint der von Ihnen angegebene Link falsch zu sein. Er sollte http://www.nvda-project.org sein, nicht .net.
Ein wichtiger Punkt, den ich weggelassen habe, obwohl er in meinem ursprünglichen Kommentar erwähnt wurde, ist, dass der Browser auch die Text-to-Speech-Funktion übernehmen würde. Ich glaube, das war nicht klar. Dort kommt der einzige Testpunkt für Barrierefreiheit ins Spiel.
Als ich das zum ersten Mal las, kochte mein Blut, als ich dachte, jetzt geht es los, HTML wird von Programmierern weggenommen, die versuchen, ein paar Tastenanschläge ihrer Arbeit zu sparen, indem sie etwas eliminieren, das seit vielen Jahren gut funktioniert hat. Nachdem ich die Kommentare gelesen hatte, bin ich froh, dass kühlere Köpfe die Oberhand behalten haben und dass wir von Menschen gehört haben, die Websites tatsächlich durch Hören nutzen. Nach dem, was ich oben gelesen habe, scheinen Listen für die meisten nicht-sehenden Benutzer eine vollkommen gute Möglichkeit zu sein, auf eine Liste von Navigationselementen zuzugreifen.
Sehen Sie, wie ich die Worte "Liste von Navigationselementen" verwendet habe? Ich war in den frühen bis mittleren Neunzigerjahren, als diese ursprünglichen Tags entwickelt wurden, nicht im Webbereich tätig, aber ich glaube, dass HTML für Forscher entwickelt wurde, um Forschungsberichte mit anderen Forschern in einem offenen Standarddokumentformat zu teilen, das von jedem auf jedem Betriebssystem gelesen werden konnte. Oft enthalten Forschungsberichte, glaube ich, eine "Indexseite" oder ein Inhaltsverzeichnis, das eine Liste der Hauptabschnitte des Dokuments und der Seiten, auf denen sie sich befinden, enthält. Eine perfekte Verwendung für eine Liste. Ich glaube, eine Webseiten-Navigation ist einem Inhaltsverzeichnis ähnlich, daher glaube ich semantisch, dass das Platzieren von Navigationselementen in Listen semantisch absolut sinnvoll ist. Nur weil ein "ul", "li" ein paar zusätzliche Bytes Computercode benötigt, ist das kein Grund, es loszuwerden.
Ich schreibe mein HTML immer so, dass es auf einer Seite ohne angewendetes CSS sinnvoll und logisch aussieht, und das Einfügen der Navigation in eine Liste tut genau das. Es platziert die Navigationselemente in einer schönen, ordentlichen Liste, und wenn Sie Unternavigationselemente haben, sind diese schön eingerückt, um eine hierarchische Beziehung zu anderen Navigationselementen zu zeigen.
Wenn es nicht kaputt ist, repariere es nicht. Das sollte natürlich Innovationen nicht aufhalten, und wir sollten immer offen sein, bessere und effizientere Wege zu finden, Dinge zu tun, aber Dinge nur um des Änderns willen zu ändern oder nur um ein paar Tastenanschläge zu sparen, ist nicht der richtige Weg.
Meine zwei Cents…
"Drückt den großen unsichtbaren LIKE-Button"
Ich stimme vollkommen zu. Die grundlegende Frage hier ist: "Sind Navigationslinks eine Liste?" Und die Antwort ist definitiv JA.
Ist ein Inhaltsverzeichnis eine Liste? Ist eine Sitemap eine Liste? Ob Sie "Navigation", "Menü" oder etwas anderes nennen, es ist eine Liste von Links zu Seiten auf Ihrer Website. Warum sollte das anders sein?
Sogar die Definition von Menü ist "eine Liste von Optionen ..." (http://www.thefreedictionary.com/menu)
@Chuck Das Problem ist, dass, genau wie alle anderen Benutzer, Menschen mit Behinderungen ihre eigenen Vorlieben haben. Können Sie erwarten, dass jede einzelne Browserfunktion von allen existierenden Browsern in einem separaten, "speziellen" Browser kombiniert wird? Der IBM Home Page Reader war ein Experiment genau in dem von Ihnen vorgeschlagenen Bereich. Aufgrund der Unterschiede und Bedürfnisse der Menschen und der schnellen Veränderungen in den Browsertechnologien sowie Standards konnte er nicht aufrechterhalten werden – selbst als ein großes Unternehmen wie IBM dahinter stand. Woher sollte das Geld für eine solche Anstrengung kommen? Und dann, der Logikkette folgend, warum nicht ein spezielles Betriebssystem für Menschen mit Behinderungen haben? Mit der gleichen Logik, warum nicht einen separaten Browser nur für Geeks haben, weil Geeks Inhalte auf eine andere Weise konsumieren? Ihre Bedürfnisse sind anders.
Wenn wir versuchen, Text-to-Speech in Browser einzubetten, wird jeder seine eigene Implementierung haben, was das grundlegende Problem nicht löst. Die Diskussion, die wir führen, handelt von Inhalt und dessen Struktur. Das Beste, was wir als Benutzer dieser assistiven Technologien tun können, ist, Sie davon zu überzeugen, dass, solange Sie Ihre Websites und Inhalte auf eine bestimmte Weise gestalten und entwickeln – auf eine Weise, die allen zugutekommt –, wir sie mit unseren assistiven Technologien konsumieren können.
Hallo Chris!
Haben Sie diesen Artikel gesehen? http://www.netmagazine.com/features/truth-about-structuring-html5-page
Es geht auch um die (wahrscheinlich?) falsche Verwendung von Elementen, um das Verhalten von Screenreadern zu verbessern. Ich wäre sehr an Ihrer Meinung zu diesem Artikel interessiert.
Zurück zu Ihrem Artikel
„Update: Nach Rückfrage sollten Sie das ARIA-Roll auf dem nav-Tag verwenden, auch wenn es impliziert ist, da einige Browser es nicht so anwenden, wie sie sollten.“
Das habe ich noch nie gehört. Sehr interessant – und sehr... traurig! Das ist eindeutig ein Problem der Browser/Screenreader, nicht von uns Webentwicklern. :( Wir sollten das nicht tun müssen.
@Pipo
Wir leben in einer erstaunlichen Zeit. Das Web ermöglicht Menschen mit Behinderungen, zu kommunizieren, zu arbeiten, einzukaufen und Kontakte zu knüpfen, genau wie alle anderen. Wir haben eine kostenlose Plattform, die es Blinden ermöglicht, Nachrichten aus aller Welt zu lesen, sobald sie geschehen – das wäre in den 1950er Jahren undenkbar gewesen! Selbst wenn Sie morgen Ihr Augenlicht verlieren würden, könnten Sie den gleichen Job ausüben und die gleichen sozialen Netzwerke nutzen wie heute; Sie müssten sich nicht ausgeschlossen fühlen. Im Ernst, das haut mich um. Nie zuvor hat eine Technologie so vielen Menschen ermöglicht, an der Gesellschaft teilzuhaben, anstatt ausgeschlossen zu werden.
Und Sie beschweren sich über das Tippen von 17 zusätzlichen Zeichen auf einer Webseite
Das Wichtigste ist, dass Sie es können.
Nur eine Warnung zu diesem Artikel (obwohl ich mit dem größten Teil davon einverstanden bin). Es gibt dort einige ziemlich elementare Gedanken, nehmen Sie es mit einer Prise Salz. Beispiel: Der Abschnitt "Styling headings HTML5 style is kind of insane" geht davon aus, dass Überschriften klassenlos und individuell gestaltet werden müssen (was das Problem, das im Abschnitt über die Dokumentgliederung umrissen [Wortspiel beabsichtigt] wurde, perpetuiert).
@Alan Dalton
Entschuldigung, ich glaube, Sie haben mich missverstanden oder ich habe mich nicht gut ausgedrückt, aber ich finde WAI-ARIA, modernes HTML5 und die Existenz von Screenreadern absolut großartig! Moderne Technologie ist toll! Und ich möchte mich nicht über das Tippen von 17 zusätzlichen Zeichen beschweren. Ich möchte mich darüber beschweren, dass jeder, den ich kenne (mich eingeschlossen), dachte, dass die Verwendung von "nav" als Element standardmäßig immer "role="navigation"" als Attribut enthalten würde. Aber das scheint falsch zu sein. Ich beschwere mich darüber, dass es zwei oder drei Jahre gedauert hat, seit ich das erste Mal "nav" gespeichert habe, bis mir jemand erklärt hat, dass ich diesem Element eine WAI-ARIA-Rolle hinzufügen sollte, weil die Verwendung von "nav" nicht ausreicht. Und ich lese viele Blogs und Tutorials, aber das habe ich noch nie zuvor gehört.
Ich will das Richtige tun und ich will, dass alle anderen das Richtige tun, aber wie sollen ich und alle anderen das tun, wenn es so aussieht, als könnten alle Mitwirkenden/Evangelisten von HTML5 mir als "einfachem" Webentwickler das richtige Verhalten und die richtige Verwendung einiger HTML5-Elemente nicht erklären?
Ist das auch meine Schuld? Sicher! Aber ich habe diese "falsche" Verwendung auch bei sehr, sehr klugen Leuten gesehen. Und das ist irgendwie traurig :(
@Pipo
Ich habe Sie missverstanden. Entschuldigung!
Ich verstehe, was Sie meinen. Ich verwende normalerweise Attributselektoren basierend auf Landmark-Rollen — [role="banner"]{}, [role="navigation"]{}, [role="main"]{}, [role="contentinfo"]{} — zum Layout von Webseiten. Ich musste mir noch nie Sorgen machen, Rollen hinzufügen zu müssen.
Das ist eine gute Frage. Ich habe es aus Jeremy Keiths Artikel Landmark roles gelernt.
@Pipo – es gibt Ressourcen. Ein guter Ausgangspunkt ist MDN – ARIA. Dieses Dokument: Verwenden von ARIA in HTML bietet Anleitungen für jedes HTML-Element und ob ein Element die Hinzufügung von ARIA benötigt, um fehlende Implementierungen in Browsern auszugleichen. HTML5Accessibility.com bietet einen Überblick über die aktuelle Unterstützung der Barrierefreiheit in gängigen Browsern. Hier ist ein grober Leitfaden für Browser, Betriebssysteme und Screenreader-Unterstützung.
@Steve: Ihr MDN – ARIA-Link führte mich zu einem anderen Link und es stellte sich heraus, dass das W3C selbst eine Empfehlungstabelle (2.10.) zur Verwendung der neuen HTML5-Elemente hat. Jetzt scheint alles so offensichtlich zu sein!
Ich ging sogar zu html5please.com, die ich schon hundertmal besucht hatte, und was denken Sie? Sie sagen, dass nur einige Browser die korrekten Barrierefreiheits-APIs implementieren und dass man ein Polyfill verwenden kann, um dieses Problem zu lösen. Warum habe ich das vorher nicht gesehen?^^°
@Pipo, freut mich, dass Sie gefunden haben, wonach Sie gesucht haben. Hinweis: Ich bin der Editor der Spezifikation, die die Empfehlungstabelle enthält :-)
Von http://www.yourdictionary.com/list
Dies sagt nichts darüber aus, ob sie horizontal oder vertikal ist oder ob jedes Element einen Aufzählungspunkt (oder eine ähnliche visuelle Anzeige) daneben haben muss. Wir müssen darüber nachdenken, unsere Inhalte richtig zu charakterisieren, bevor wir Stile darauf anwenden. Manchmal müssen wir sogar kurz die Formatierung ausblenden, die User-Agent-Stylesheets auf unsere Inhalte anwenden. Mit anderen Worten: Wenn wir uns nur unser HTML ansehen, ist unser HTML korrekt? Damit diktiere ich nicht, wie man seine Inhalte charakterisieren sollte, sondern erinnere nur daran, dass der Schwanz mit dem Hund wedelt, wenn "wie es im Browser aussieht" bestimmt, wie wir unsere Inhalte auszeichnen.
Die Verwendung von verschachtelter Navigation ist "richtig". Ich mache so etwas:
Die Frage ist: Wende ich
role="navigation"auf die zweite Navigation an oder lasse ich es, wie es ist?Ich denke, es muss getestet werden.
Und auch andere Alternativen, das war die erste, an die ich denken konnte.
Wie können Sie Navigation so verschachteln, Marco? Sie können keine Links in Links einfügen. Angenommen, das wäre kein ungültiges HTML, würden Sie zwei Links gleichzeitig anklicken.
Laut der Spezifikation scheint das Verschachteln eines Nav-Elements keine Bedeutung zu haben. Es ist ein Sektionselement, Sie wickeln es einfach um Ihre Website- oder Seiten-Navigation, was auch immer das ist.
Das nav-Element ist ein Orientierungspunkt, damit der Autor dem Benutzer sagen kann: „Hier ist die Navigation“. Ich glaube nicht, dass es zum Verschachteln gedacht ist.
In der W3C-Spezifikation ist klar, wenn er sagt, dass wir das nav-Element ohne Verwendung von Listen markieren können, aber in seinem eigenen Beispiel unter http://www.w3.org/html/wg/drafts/html/master/sections.html#the-nav-element, fügt er einen Code ein, bei dem die nav-Elemente in Absätzen verwendet werden, die Links jedoch nicht benachbart sind, was sicherlich Probleme für Benutzer von Screenreadern verursachen würde. Im obigen Beispiel erstellt Chris benachbarte Links, was in der Barrierefreiheit, seit WCAG 1.0, in Punkt 10.5 – Priorität 3 nicht empfohlen wird.
Interessantes Thema. Gemäß der Definition des
nav-Elements denke ich, dass es ohne Listen verwendet werden soll.navkann nicht nur für die Hauptnavigation verwendet werden, sondern auch für andere Arten von Navigationslinks wie Vor-/Zurück-Links, wo Listen selten verwendet werden. Wenn wir also bei Listen fürnavbleiben, müssen wir auch andere Arten von Navigationslinks in Listen ändern, und ich denke, das ist nicht sehr praktisch.Ich bevorzuge listenlose Navigation. Aber wie bei der ersten Frage von Chris brauchen wir eine gute Methode, um Dinge wie Untermenüs, Dropdown-Menüs usw. zu implementieren.
Ich habe das Gefühl, dass "nav" den Bereich einer Seite beschreibt, aber nicht wirklich "Struktur" verleiht, sozusagen. Vor HTML5 war es, glaube ich, üblich, überall Divs mit einer passenden Klasse/ID zu verwenden, die das Element beschreibt. Und ich denke, die gleichen Regeln sollten nach HTML5 angewendet werden. Sicher, man hat ein Nav, aber was ist es? Es ist (üblicherweise) nur eine Liste von Seiten auf Ihrer Website. Ich habe das Gefühl, wenn wir nur Nav verwenden und keine andere Struktur, wann ziehen wir die Grenze zu Divs? Reichen Artikel und Asides aus, um für sich allein zu stehen?
Vielleicht denke ich nicht richtig darüber nach, aber das ist meine Meinung.
LISTEN sind der Weg, Screenreader können sich daran stören
Als ich ein WordPress-Theme für meinen Blog erstellte, trieb mich der Versuch, die Listen-Navigation loszuwerden, in den Wahnsinn! Ich glaube, diese Website war es, wo ich das Tutorial gefunden habe, wie man die Listenelemente loswird.
Wenn wir über Screenreader sprechen, warum sagt dann niemand etwas über den Tag?
"dfn"-Tag
Gemäß den Checkpoints für Web Content Accessibility Guidelines 1.0, Priorität 3 Checkpoint 10.5 heißt es:
http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-divide-links
Daher entspricht die vorgeschlagene listenlose Navigation (in ihrem aktuellen Zustand) nicht den Anforderungen.
Ich persönlich verwende immer noch Listen für die Navigation, bin aber gespannt, einen passenderen Weg zur Auszeichnung von Navigationen zu finden.
Stacey. „Bis Benutzeragenten benachbarte Links deutlich darstellen“ ist entscheidend. Wenn Links in einer Liste sind, werden sie deutlich dargestellt, sogar von einem Screenreader.
WCAG 2.0 ist jetzt die Empfehlung. Es verwendet UL in seinem Beispiel für die Gruppierung von Links: http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H48.html#H48-ex5
Das ist genau mein Punkt, Lee. :)
Ach, so ist es!
Was halten wir von so etwas für Dropdown-Navigationsmenüs: http://codepen.io/bkbillma/pen/mKkEv
@Alohci
„Wie viel davon ist das Versagen von Screenreadern?“
Nichts. In der Spezifikation ist das nav-Element nicht als Elternteil einer Sammlung definiert. Ein Screenreader könnte die Anzahl der Links innerhalb eines nav-Elements melden, aber das wäre nicht standardkonform – und das ist das Ziel, auf das wir alle UAs zubewegen wollen.
Danke, Léonie.
Sicherlich, wenn das, was AT-Benutzer daran hindert, eine bessere Erfahrung zu machen, die Spezifikation ist, dann muss die Spezifikation geändert werden. Die Semantik des nav-Elements scheint sicherlich konsistent damit zu sein, hauptsächlich als eine Gruppe von Links behandelt zu werden, nur nicht nur als eine Gruppe von Links. Welche Schwierigkeiten würden entstehen, wenn der Standard so geändert würde, dass die Barrierefreiheits-Toolchain erweitert werden könnte, um dies zu unterstützen?
Wie wäre es mit HTML5-Outline?
<nav>
<h3 class=”screen-reader-only”>Menü</h3>
<ul>
…..
</ul>
</nav>
Hinweis zum nav-Element in HTML 5.1 hinzugefügt bezüglich der Verwendung von Listen-Markup
Feedback willkommen, Möglichkeiten dazu sind aufgelistet.
Entschuldigen Sie mich, falls das völlig dumm ist, aber könnte Flexbox dieser Menümethode eine gewisse Sortierfähigkeit bieten? Ich bin neu in all dem (kein Designer, versuche nur, meine erste Website zu gestalten), also lege ich vielleicht Buicks in meinen Korb mit Orangen, aber wenn Sie die Sortier-/Neuanordnungsfunktionen benötigen, die Ihnen die Verwendung von Listen für die Navigation bietet, könnten die von Flexbox erlaubten Anordnungen von Divs und anderen Elementen nicht dasselbe tun?
Auf jeden Fall ein interessanter Beitrag und eine gute Idee. Ich werde es auf meiner Website ausprobieren, da ich versuche, etwas anderes mit meinem Menü zu machen, als ich es auf den meisten Websites gesehen habe.
Werde heute listenlose Navigation machen. Ich mag horizontale Listen und habe vor einiger Zeit darüber nachgedacht, warum man nicht eine Reihe von Links für die horizontale Navigation verwendet. Für persönliche kleine Projekte ist das gut, aber wenn es um etwas Größeres geht, muss man herausfinden, ob es gut für SEO, Screenreader usw. ist.
übrigens @brad sehr schöne Navigation
Dieser Beitrag enthält Kommentare von 6 Personen, die Screenreader verwenden, und alle sagen, dass die Auszeichnung von Navigationslinks als Listen nützlich ist. Ich denke, Sie haben Ihre Antwort!
Siehe: https://css-tricks.de/wrapup-of-navigation-in-lists/
Die Spezifikation besagt auch: "In Fällen, in denen der Inhalt eines nav-Elements eine Liste von Elementen darstellt, verwenden Sie Listen-Markup, um das Verständnis und die Navigation zu erleichtern", was Sinn macht.
Allerdings hat auch Reinhard Stebner Recht. Dies ist ein interessanter Diskussionspunkt und verdient viel Aufmerksamkeit.
http://codepen.io/corysimmons/pen/hbndI
Ich habe eine Idee. Laden Sie einen Screenreader herunter, lernen Sie einige der Steuerelemente, probieren Sie es selbst aus. Ohne Listen ist es unendlich flüssiger, als "Listeneintrag 1, Listeneintrag 2, ..., Listeneintrag 10" anhören zu müssen.
Hier ist eine bessere Idee: Lesen Sie die Kommentare von Leuten, die Screenreader tatsächlich benutzen, anstatt sie nur auszuprobieren. Sie alle sagen, dass die Auszeichnung von Navigationslinks als Listen nützlich ist.
Es ist wirklich eine coole und hilfreiche Information. Ich bin froh, dass Sie diese nützlichen Informationen mit uns geteilt haben. Bitte halten Sie uns weiterhin so auf dem Laufenden. Vielen Dank fürs Teilen.
Chris, eine Gruppe von Links in Spans wird von JAWs als eine Zeichenkette ohne Pausen vorgelesen. Das ist definitiv keine gute Idee. Dies gilt für Navigationen, Filter, Paginierungslinks und andere Gruppen von Links. Spans sollten sowieso niemals für strukturelle Markierungen verwendet werden. Eine Span-Grenze bedeutet nichts.
Der aktuelle JAWS erkennt das NAV-Element und meldet den Navigationsbereich. Also, definitiv die Navigation in ein NAV-Element packen. Innerhalb des NAV würde ich die Links in DIVs legen, damit sie Blockelemente sind. JAWS pausiert nach Blockelementen.
WCAG empfiehlt, Titelattribute zu A-Tags hinzuzufügen. Ich empfehle, es wirklich auszuformulieren, z.B. "Zur Startseite gehen" oder "Navigation, Startseite". Verwenden Sie Kommas, da Kommas als kurze Pause gelesen werden. Sehr nützlich. Ich versuche wirklich, meine Augen zu schließen und darüber nachzudenken, wie es klingen wird.
Das Einfügen von A-Tags in ein UL hat Vorteile. Es geht weniger um Semantik, aber ein bisschen.
Vorteile: (1) Semantik: Bei der UL pausiert JAWS und gibt bekannt, dass ich eine Liste betreten habe, es sagt mir zumindest, dass die nächsten Elemente zusammengehören; NAV ist besser, aber eine Liste von Links ist nicht unbedingt eine Navigation, (2) JAWS versteht li-Tags als separate Elemente und stoppt nach dem Lesen jedes Elements, (3) mehr Semantik: Hierarchie ist klar, wenn eine Liste in einer anderen verschachtelt ist (Subnavigation) – JAWS kündigt die Verschachtelung an. Für verschachtelte Navigation/Links würde ich zu verschachtelten Listen tendieren. (4) Ich bin mir nicht sicher, wie die Leute das genau verwenden, aber JAWS hat eine Tastenkombination, die alle Listen auf der Seite erkennt. Listen sind leichter auffindbar.
Für eine andere Technik: Ich habe mit Tabellen in Barrierefreiheitsszenarien experimentiert. Sie können sehr nützlich sein. In diesem Fall könnten Sie Links in eine Tabelle mit Spaltenüberschriften "Navigation" einfügen, die Kopfzeile ausblenden und den Abschnitt so gestalten, dass er nicht wie eine Tabelle aussieht. JAWS würde "Tabelle, Gehe zu Seite" ankündigen. Wenn Sie fortfahren, würde es die Überschrift und den ersten Zellenwert lesen, also würde es "Gehe zu Seite, Eins" sagen.
Wenn wir ein Div-Tag innerhalb eines "a"-Tags platzieren, sollte dies gemäß den Barrierefreiheitsrichtlinien erfolgen?
Kommentar von Mark Harter
Ich war fasziniert von dem, was Sie geschrieben haben, und der Tatsache, dass Sie eine Rede eines blinden Benutzers erwähnten, der keine Listenelemente für die Navigation mag.
Nun, als blinder Benutzer und selbst Programmierer muss ich Reinhold widersprechen. Ich benutze auch J.A.W.S., und es ist der beste verfügbare Screenreader, aber zunächst einmal verwendet jeder blinde Benutzer einen Screenreader etwas anders, um auf einer Website zu navigieren. Wenn ich beispielsweise eine Website betrachte, verwende ich die Hotkeys von J.A.W.S. und suche gerne nach Überschriften-Tags, indem ich "H" auf meiner Tastatur drücke, was den Fokus des Screenreaders auf diesen Punkt der Website bewegt. Wenn eine Website also richtig formatiert ist, ist der Site-Name ein h1, der Site-Abschnitt ein h2 usw. usw. ... aber ich springe auch gerne mit der Taste "E" herum, die auch Formularfelder für die Suche findet. Wenn ich "V" drücke, führt es mich zu einem besuchten Link auf der Website, falls ich dort schon einmal war, "T" für Tabellen, "L" für Listen usw.
Aber zurück zur Website-Navigation mit Listen: Ich glaube, das ist der kluge Schachzug, und es sollten die ersten Listenelemente einer Website sein. Ich spanne sie gerne über ein Website-Logo, darunter oder nach dem h1-Tag, wenn die Website eine linke Spaltennavigation hat.
Aber ja, wenn eine Website zu viele Listenelemente hat, kann es verwirrend werden, aber wenn diese Listen richtig getaggt sind, sollte es kein Problem geben.
Eine Sache, die ich in den letzten 10 Jahren, seit ich mein Augenlicht verloren habe und J.A.W.S. benutze, entdeckt/gelernt habe, ist: Je screenreader-freundlicher eine Website ist, desto besser wird sie von Suchmaschinen wie Google, Bing usw. indexiert.