In den letzten Wochen gab es in Webstandardkreisen viele Diskussionen über HTML-Überschriften. Vielleicht haben Sie einige der Blogbeiträge, Tweets und GitHub-Diskussionsfäden gesehen. Überschriften sind seit den allerersten Websites am CERN Teil von HTML, daher mag es überraschend sein, sie 25 Jahre später immer noch umstritten zu finden. Ich werde kurz zusammenfassen, *warum* sie immer noch diskutiert werden, mit vielen Links zu anderen Quellen, bevor ich meine eigenen Meinungen hinzufüge. Wenn Sie über die Debatte auf dem Laufenden sind, können Sie zum Abschnitt „Das größere Dilemma“ springen.
Die bisherige Geschichte...
HTML verwendet Überschriften (`
`, `
`, `
` und so weiter bis `
`) zur Auszeichnung von Titeln für nachfolgende Textabschnitte. Die Zahlen (oder *Ebenen*) der Überschriftenelemente sollen logisch einer baumartigen Struktur von verschachtelten Abschnitten entsprechen, ähnlich wie Bücher Kapitel mit Abschnitten und Unterabschnitten haben.
Die HTML-Auszeichnung hatte jedoch ursprünglich keine Möglichkeit, diese verschachtelte logische Struktur in einer verschachtelten DOM-Struktur abzubilden. Im Gegensatz zu verschachtelten Listen waren verschachtelte Überschriften nicht tatsächlich *verschachtelt* in Elementen, die die übergeordneten Abschnitte definierten. Überschriftenelemente unterschiedlicher Ebenen waren alle Geschwisterelemente und auch Geschwister der Absätze, für die sie einen Titel lieferten. Die „Abschnitte“ waren eine rein logische Struktur, keine DOM-Struktur, die alle Auszeichnungen enthielt, die mit einer Überschrift begannen und andauerten, bis eine andere Überschrift derselben oder einer höheren Ebene erreicht wurde.
Wie Brian Kardell anmerkt, war dies in der „flachen Erde der Auszeichnung“ des frühen HTML perfekt sinnvoll, bei der Tags lediglich typografische Anweisungen waren, die in einen Textfluss eingefügt wurden. Das Konzept einer HTML-Seite als Baumstruktur kam später, als Dynamic HTML ein Document Object Model (DOM) benötigte, um diesen Fluss von Text und Tags als Datenstruktur zu beschreiben, auf die Skripte zugreifen konnten.
Um das Ende nicht zu verraten: HTML hat jetzt ein ``-Element, das (optional) verwendet werden kann, um eine verschachtelte DOM-Struktur zu erstellen, die Ihrer logischen Überschriftenstruktur entspricht. Die Elemente ``, ``, `
Aber es gab noch ein weiteres Problem mit dem ursprünglichen Überschriftenmodell: Es konnte nicht einfach in Vorlagensystemen wiederverwendet werden. Da die Überschriftenebene durch den Tag-Namen (`
` im Gegensatz zu `
`) und nicht durch den Kontext, in dem sie verwendet wird, ausgedrückt wird, können Sie nicht einfach denselben Inhalt in einem anderen Kontext wiederverwenden, in dem die Ebene unterschiedlich wäre. Ein Blog könnte beispielsweise denselben Satz von Artikelüberschriften und Einleitungsparagraphen in vielen Kontexten verwenden: als eigenständige Blogbeitragsseiten; als Abstracts auf einer Hauptindexseite; oder als Abstracts auf einer Archivseite, die auch Überschriften zur Aufteilung der Liste nach Monat oder Jahr hat. Welche Überschriftenebene sollte der Titel des Artikels haben?
Frühe Vorschläge für Sektionierungselemente enthielten auch ein ebenenfreies `
` oder ``-Element, dem basierend auf dem Kontext eine Ebene zugewiesen würde. (Tatsächlich reicht die Idee bis zu den frühesten Diskussionen über HTML zurück.) Aber als Sektionierungselemente schließlich zu HTML hinzugefügt wurden, wurden sie so konzipiert, dass sie mit den vorhandenen Überschriftenelementen funktionieren. Die Spezifikationen definierten jedoch einen „Document Outline Algorithm“, der die Überschriftenebenen für die vorhandenen nummerierten Überschriften-Tags basierend auf der Abschnittsverschachtelung neu berechnen würde.
Mit dem Document Outline Algorithm könnten Sie (theoretisch) `
` für alle Überschriften verwenden, und der Browser würde die Ebene jeder Überschrift basierend auf ihrer Verschachtelung innerhalb von ``, `` und verwandten Elementen ermitteln. Der Outline-Algorithmus würde sicherstellen, dass die oberste Überschrift auf der Seite eine Ebene 1 wäre und dass alle anderen Überschriften in einer konsistenten Reihenfolge verschachtelt wären, ohne Ebenen zu überspringen. Die WHATWG-Version des Outlines definiert auch Regeln für die Behandlung mehrteiliger Überschriften in ``-Elementen, sodass die Unterüberschriften keine Unterabschnitte erstellen. (Die W3C-Version von HTML5 erklärte stattdessen `` als veraltet: Mehrteilige Überschriften sollten als Absätze innerhalb eines ``-Abschnitts oder als Spans innerhalb des Hauptüberschriftenelements ausgezeichnet werden.)
Browser modifizierten ihre Standardstile so, dass Überschriften innerhalb verschachtelter Abschnitte fortschreitend kleinere Schriftgrößen erhielten (ähnlich wie der Standardstil für `
` eine kleinere Schrift als `
` hat, die kleiner als `
` ist). Sie änderten jedoch nicht die Art und Weise, wie sie Überschriftenebenen für die Barrierefreiheits-APIs verfügbar machten, die von Screenreadern verwendet werden. Und Screenreader-Benutzer sind die einzigen, die Überschriftenebenen wirklich als Teil der Benutzeroberfläche erleben.
Screenreader kündigen die nummerierte Ebene beim Lesen von Überschriften an und ermöglichen es Benutzern, schnell durch Überschriften einer bestimmten Ebene zu springen. Laut einer WebAIM-Umfrage scannen zwei Drittel der Screenreader-Benutzer Überschriften als ersten Schritt, um Informationen auf einer langen Webseite zu finden. Für diese Benutzer war die einzige Auswirkung des Document Outline Algorithm, dass einige neue Seiten (die die neue Spezifikation eifrig übernahmen) als flache Listen von Überschriften der Ebene Eins präsentiert wurden, ohne jegliche Struktur.
Warum werden Browser den Outline-Algorithmus nicht für zugängliche Überschriftenebenen verwenden? Viele Argumente wurden vorgebracht, aber das überzeugendste ist, dass dies die Darstellung bestehender Websites für Screenreader-Benutzer verändern könnte und es unklar ist, ob diese Veränderungen größtenteils positiv wären.
Adrian Roselli hat eine gute Übersicht über die Diskussionen zu den Problemen zusammengestellt, die durch die nicht implementierte Outline-Spezifikation verursacht werden, in „There is No Document Outline“. Die neuesten W3C HTML-Specs verwenden den Document Outline Algorithm nur noch, um Vorschläge zu machen, wie Autoren ihre nummerierten Überschriften-Tags mit ihren verschachtelten Sektionierungselementen synchronisieren sollen. Die WHATWG HTML-Specs enthalten immer noch den vollständigen Outline-Algorithmus als normative Anforderung, obwohl es eine offene Frage gibt, bei der viele vorschlagen, ihn ganz zu entfernen. Wie der WHATWG-Spec-Editor Domenic Denicola es ausdrückt:
Irgendwann können wir nicht behaupten, dass User Agents defekt sind. Sie lehnen stattdessen unsere Änderungsanfrage ab.
Die aktuelle Debatte
Die jüngste Debatte wurde ausgelöst, als Jonathan Neal ein Issue im W3C HTML-Spec einreichte, in dem er das schwer fassbare `
`-Element neu vorschlug. Der Kern des Vorschlags ist, dass ein `
`-Überschriftenelement eine Verschachtelungsebene haben könnte, die durch Sektionierungselemente definiert wird, während die vorhandenen nummerierten Überschriften-Tags weiterhin ihre Ebene durch ihren Tag-Namen bestimmt bekommen. Autoren würden durch die Verwendung des neuen Tags den Outline-Algorithmus nutzen. Bis Browser `
` unterstützen, könnte ein JavaScript- (oder serverseitiger) Polyfill die Überschriftenebenen berechnen und sie mit ARIA-Attributen in den DOM einfügen: `role="heading"` und `aria-level="3"` weisen den Browser an, ein Element als Überschrift der Ebene 3 für Barrierefreiheitszwecke zu behandeln, unabhängig von seinem Tag-Namen oder seiner Verschachtelung, sodass der Seitenautor die volle Verantwortung für jegliche Überschriftenverwirrung trägt.
Es gibt viele gute Diskussionen auf dieser Issue-Seite und in längeren verlinkten Blogbeiträgen. Das Hauptargument für die Hinzufügung eines neuen Elements ist, dass es die Bedeutung bestehender Inhalte nicht verändern würde. Zusätzlich zu Neals Argumenten auf GitHub nähert sich Brian Kardells Vorschlag eines benutzerdefinierten Elements und Polyfills dem Thema aus dieser Perspektive. Auf der anderen Seite argumentiert Jake Archibald dafür, die Elemente zu reparieren, die wir bereits haben.
Die Arbeit, die benötigt wird, um das bestehende Web zu reparieren, ist eine Teilmenge der Erstellung eines neuen Elements, das dasselbe tut, aber das bestehende Web nicht repariert.
Mit anderen Worten: Wenn der Outline-Algorithmus so großartig ist, dass er ein neues Element wert ist, warum implementiert man dann nicht einfach den Outline-Algorithmus für bestehende Elemente anstelle dessen?
Wenn Sie immer noch Schwierigkeiten haben zu verstehen, warum sich niemand darauf einigen kann, was mit etwas so scheinbar Einfachem wie HTML-Überschriften zu tun ist, hat Brian Kardell alle technischen Details in einem zweiten Beitrag auf hilfreiche Weise entfernt.
Das größere Dilemma
Unter all den Diskussionen darüber, wie eine Dokumentenstruktur für eine Webseite erstellt werden kann, verbirgt sich eine Annahme. Die Diskussion darüber, *wie* die Dokumentenstruktur erstellt wird, geht davon aus, dass die Struktur einer Webseite als Gliederung definiert werden *kann*: als Baum, bei dem die Verschachtelungsebene einer Überschrift ihre Bedeutung bestimmt.
Ich persönlich glaube nicht, dass eine einfache verschachtelte Gliederung alle Bedeutungsebenen erfassen kann, die von HTML-Überschriftenebenen im Web vermittelt werden. Warum, dazu komme ich gleich. Aber es gibt einen Grund, warum sich alle Diskussionen auf diese Art von Gliederung konzentriert haben: weil dies die Art von Gliederung ist, die Screenreader erwarten.
Für die meisten Webnutzer und Webautoren ist die Dokumentenstruktur irrelevant. Sie wissen nicht und kümmern sich nicht darum, wie die Überschriften und Abschnitte verschachtelt sind, sie sehen nur, was auf dem Bildschirm ist. Und was auf dem Bildschirm ist, ist in den meisten heutigen Webseiten ein zweidimensionales Layout von Inhalten, einige davon verschachtelt, einige davon unabhängig, wobei jedem Teil implizite Bedeutung und Beziehungen durch Layout, Farben und Typografie verliehen werden.
Die Frage, die wir diskutieren sollten, ist also nicht: „Wie sollen wir Überschriften Gliederungsebenen zuweisen?“ Sie lautet: „Wie können wir die aussagekräftige Struktur einer Webseite zusammenfassen, damit Menschen, die assistierende Technologien nutzen, Inhalte leicht finden können?“
Ich persönlich würde es lieben, wenn Browser eine Funktion für alle Benutzer hinzufügen würden, um die Gliederung als Inhaltsverzeichnis anzuzeigen und es zu ermöglichen, mit der Tastatur schnell zu Überschriften zu navigieren. Vielleicht würden dann mehr Webautoren darauf achten, wie ihre Gliederung aussieht. Aber die Browser tun es nicht, und so tun es die meisten Autoren nicht.
Wenn Sie sehen möchten, wie die Überschriftenstruktur Ihrer Website aussieht – und wie sie theoretisch mit dem Document Outline Algorithm aussehen würde – können Sie den W3C Nu HTML Validator Service mit aktivierter Option „Show Outlines“ verwenden.
Wie die Dinge derzeit stehen, ist die Dokumentenstruktur nur für Screenreader-Benutzer von täglicher Bedeutung, und diese Benutzer sind es derzeit gewohnt, mit dem Durcheinander von unregelmäßigen Überschriftenebenen in Webseiten umzugehen. Ich bin sicher, viele Screenreader-Benutzer würden es begrüßen, wenn die Überschriftenebenen behoben würden. Aber das Beheben von Überschriften für Screenreader-Benutzer bedeutet nicht nur, einen Baum aus ordentlich verschachtelten Überschriften ohne übersprungene Ebenennummern zu erstellen. Es bedeutet, eine Überschriftenstruktur zu erstellen, die die vom Erstellern der Webseite beabsichtigte *Bedeutung* genau widerspiegelt, die Bedeutung, die visuelle Benutzer aus Stil und Layout ableiten. Und um das zu erreichen, müssen wir berücksichtigen, wie Bedeutung an alle Benutzer von Webseiten kommuniziert wird, die nicht jede Überschrift mit einer numerischen Ebene angekündigt hören.
Eine Sprache wird von denen definiert, die sie sprechen
HTML ist einzigartig unter den Programmiersprachen, da es so viele Konstrukte definiert, ohne ihnen spezifisches Verhalten zuzuweisen. Bedeutung in Computersprachen wird als die *semantische* Seite der Sprache bezeichnet, im Gegensatz zu den syntaktischen Strukturen ihrer Grammatik. Aber in den meisten Programmiersprachen sind die semantischen Aspekte von eingebauten Objekten immer noch stark an Anweisungen für den Computer gebunden. In JavaScript haben `new Date()` und `new Promise()` dieselbe Syntax – Aufruf einer Konstruktorfunktion –, aber Ihr JS-Interpreter versteht die semantische Unterscheidung zwischen den beiden Objektbezeichnungen und verhält sich für jede sehr unterschiedlich.
Im Gegensatz dazu kommt ein HTML `` oder `` nicht mit Anweisungen, was Ihr Webbrowser damit tun soll (abgesehen vom nicht implementierten Outline-Algorithmus). Stattdessen liegt der Unterschied zwischen den beiden in der Bedeutung des Inhalts, einer Möglichkeit, maschinenlesbare Annotationen für die Informationen bereitzustellen, die von einem Menschen, dem Webautor, zu einem anderen, dem Leser, übermittelt werden.
Bedeutung in menschlicher Kommunikation ist schwer zu definieren und niemals statisch. Aber vor allem wird sie von den Menschen definiert, die die Sprache verwenden. Wörterbücher fassen Zusammenfassungen der verwendeten Bedeutungen zusammen, aber sie beschränken sie nicht. Wenn Menschen anfangen, Wörter auf neue und andere Weise zu verwenden, wird das Wörterbuch (wenn es gut ist) seine Definitionen aktualisieren.
Als ich in der Grundschule war, zeigte mir eine Bibliothekarin die mehrbändige Oxford English Dictionary, indem sie uns eine Auswahl an wilden und verrückten Wörtern vorstellte. *Google* war der Name für die Zahl, die als 1 gefolgt von 100 Nullen geschrieben würde (10^100 in wissenschaftlicher Notation). Verrückt, oder? Wer müsste jemals ein solches Wort kennen? Aber die Zeiten ändern sich. Im Jahr 2006 fügte die OED eine neue Definition hinzu, *google* als Verb (was bedeutet, die Google-Suchmaschine zu benutzen), die vielleicht hundertmal öfter verwendet wird als die Zahlenmenge in der modernen englischen Konversation.
*Korrektur:* Wie Mark in den Kommentaren anmerkt, ist die richtige Schreibweise des Wortes, das mir damals gezeigt wurde, tatsächlich *googol*. Und jetzt weiß ich nicht mehr, was ich glauben soll.
Wenn es um die Bedeutung von HTML-Tags geht, sind die Äquivalente von Wörterbüchern die beiden konkurrierenden HTML-Spezifikationen (WHATWG und W3C). Und genau wie Wörterbücher begannen sie beide als Bemühungen, die Sprache so zu beschreiben, wie sie derzeit verwendet wurde.
Die Tatsache, dass es zwei verschiedene HTML-Spezifikationen gibt, erschwert die Diskussion über Änderungen, aber sie unterstreicht auch stark die kollektive, konsensbasierte Natur von HTML als Sprache. Es gibt kein einziges definierendes Dokument, das die Regeln für HTML festlegt. HTML wird von den Menschen definiert, die es schreiben, und von den Webbrowsern, die es interpretieren.
Aber so einfach ist es natürlich nicht. HTML wird nicht nur von Menschen verwendet, sondern auch von Computern. Und Computer sind nicht sehr gut darin, mit vager und sich ändernder Bedeutung umzugehen.
Immer wenn Sie einen Computer bitten, etwas mit Ihren Inhalten zu tun – wie zum Beispiel dem Screenreader mitzuteilen, welche Überschriften es auf dieser Website gibt und wie sie organisiert sind –, benötigt er klare und eindeutige Regeln dafür. Wenn einige Webautoren Überschriften-Tags auf eine Weise und einige Autoren dieselben Tags mit unterschiedlicher Bedeutung verwenden, benötigt Ihr Browser zusätzliche Regeln, um herauszufinden, welche welche sind – oder er wird es zumindest manchmal falsch machen.
Die treibende Kraft hinter der Webstandards-Bewegung war die Hoffnung, dass alle Webbrowser auf den Code von Webseiten (ungefähr) gleich reagieren würden. Und das bedeutet, neue Funktionen in Standarddokumenten zu definieren, bevor sie im Web verwendet werden können. Anstatt beschreibend zu sein, wie ein Wörterbuch (das beschreibt, wie Dinge sind), sind sie vorschreibend, wie ein Gesetzbuch (das beschreibt, wie Dinge sein *sollten*).
Das langsame Tempo der Standardentwicklung mit viel Input von Browser-Teams soll sicherstellen, dass das Endergebnis sowohl vorschreibend als auch beschreibend ist, zumindest für die Teile der Sprache, die das Browserverhalten beschreiben. Aber es funktioniert nicht immer. Es gibt viele Details in beiden Spezifikationen, die nicht mit dem tatsächlichen Browserverhalten übereinstimmen. Das Issue-Repo des W3C hat sogar ein beruhigend benanntes Label „Match Reality Better“, das darauf abzielt, diese Teile zu beheben.
Und das gilt nur für die Features, die beschreiben, was *Browser* tun sollen. Was ist mit all den HTML-Elementen, die die Semantik von Inhalten definieren? Sollten diese nicht auch „besser zur Realität passen“?
Vor ein paar Monaten schlug Sara Soueidan der W3C HTML Working Group vor, dass das `
`-Element für alle Adressen gültig sein sollte (und nicht nur für Kontaktadressen von Seitenbesitzern). Viele Leute vor ihr haben sicherlich die gleiche Beschwerde geäußert. Aber diesmal geschah etwas. Nach ein wenig rohem Data Scraping, das darauf hindeutete, dass die tatsächliche Nutzung in freier Wildbahn nicht auf die ursprüngliche Definition beschränkt war, wurde die Definition in den W3C-Spezifikationen aktualisiert.
Macht es einen Unterschied? Vielleicht nicht. Browser tun nichts mit `
`, außer es kursiv zu machen. Und die WHATWG HTML-Specs haben immer noch die alte Definition. Aber es bedeutet, dass die Spezifikation der Art und Weise, wie Code tatsächlich im Web verwendet wird, nicht mehr so imaginär ist, wie sie einst erdacht wurde, ein wenig näher kommt.
Was uns schließlich zurück zu den Überschriften bringt: Wie werden sie tatsächlich im Web verwendet? Und ist es überhaupt möglich, einen vorschreibenden Satz von Anweisungen für Webautoren und Webbrowser zu definieren, der sicherstellt, dass die Bedeutung von Überschriften korrekt an Screenreader (und möglicherweise andere Software) kommuniziert werden kann?
Die vielen Bedeutungen von Überschriften
Was ist eine Überschrift? Es ist ein kurzer Titel für einen Abschnitt eines Dokuments. Die Überschrift für diesen Abschnitt lautet „Die vielen Bedeutungen von Überschriften“. Soweit so gut.
Aber nicht alle Überschriften sind gleich.
Es gibt große Überschriften
Eine große Überschrift
und es gibt viel kleinere Überschriften
Eine Überschrift, so klein, dass sie kaum eine Überschrift ist
Wenn Sie den Code untersuchen, werden Sie sehen, dass eine davon eine `
` und die andere eine `
` ist. Beide sind in ``-Tags eingeschlossen, die – gemäß dem Document Outline Algorithm – sie kapseln und sie davon abhalten sollten, die Hauptdokumentstruktur zu verunreinigen. Aber wir wissen jetzt alle, dass der Document Outline Algorithm von Webbrowsern nicht tatsächlich verwendet wird, also Entschuldigung an alle Screenreader-Benutzer, die versehentlich auf halbem Weg durch den Artikel gelandet sind.
Für jeden, der diesen Artikel in einem modernen Browser mit den Augen liest, wird der Unterschied zwischen den beiden Überschriften durch die Schriftgröße und möglicherweise den Schriftschnitt kommuniziert. Die genauen Details hängen davon ab, ob Sie die CSS der Website oder die Lese-Modus-CSS Ihres Browsers betrachten, und davon, wie kürzlich Chris die Stile von CSS-Tricks geändert hat. Aber es sei denn, Chris hat es *wirklich* vermasselt, wird es für visuelle Leser ziemlich klar sein, dass die `
` größer und wichtiger ist als die `
`. Wir könnten das CSS ändern, damit sie identisch aussehen, aber zu diesem Zeitpunkt ist es schwer zu verstehen, warum Sie das tun sollten. Wenn sie gleich aussehen sollten, warum nicht denselben Tag-Namen verwenden?
Lassen Sie uns also einen Schritt weiter gehen und diese beiden Überschriften mit etwas Fülltext dazwischen zusammenfügen. Hier ist eine Möglichkeit, wie wir das tun könnten, mit einer Hauptüberschrift, etwas Text, dann einer Unterüberschrift und etwas mehr Text
Wenn Sie sich nur die Ergebnisregisterkarte dieser Pens ansehen und dabei Ihre Augen benutzen, könnten Sie verzeihen, dass die zweite und die dritte identisch und sehr unterschiedlich von der ersten sind. Visuell haben sowohl Beispiel #2 als auch Beispiel #3 einen Hauptabschnitt mit einer großen Überschrift und einen Seitenleistenabschnitt mit einer kleineren Überschrift. Der Unterschied ist, dass das eine `
`-Elemente zur Erstellung der Struktur verwendet und das andere HTML-Sektionierungselemente verwendet.
Wenn Sie bis hierher gelesen haben, werden Sie wahrscheinlich nicht allzu überrascht sein zu entdecken, dass diese beiden Beispiele unterschiedliche Strukturen erzeugen, wenn sie vom HTML-Dokumentenoutline-Algorithmus verarbeitet werden. Unter diesem Algorithmus werden Divs ignoriert, sodass Beispiel #2 exakt wie Beispiel #1 behandelt würde: eine Hauptüberschrift, etwas Absatztext, dann eine Unterüberschrift und ein weiterer Absatz. Die Gliederung zeigt überhaupt nicht an, dass die Seitenleiste eine separate, parallele Struktur zum Hauptartikel ist.
Eine große Überschrift
Eine Überschrift, so klein, dass sie kaum eine Überschrift ist
Wenn ich dagegen den Outline-Algorithmus auf Beispiel #3 anwende, sagt er mir, dass es ein unbeschriftetes Hauptdokument gibt (keine Top-Level-Überschrift) mit zwei gleichberechtigten Geschwister-Kindelementen (beide Überschriften werden als Ebene 2 behandelt). Jetzt vermittelt es klar die parallele Struktur, aber nicht den Unterschied in der Überschriftenbedeutung.
[body-Element ohne Überschrift]
Eine große Überschrift
Eine Überschrift, so klein, dass sie kaum eine Überschrift ist
Ich glaube nicht, dass *eine* dieser Gliederungen diese visuelle Darstellung genau beschreibt. Auch die Gliederung, die auf Tag-Namen basiert, behandelt die Seitenleiste nicht nur als Teil des Hauptartikels, sondern wird auch durch meine Verwendung von `
` auf einer Seite ohne `
/3/4/5`-Elemente abgelenkt.
Wenn ich gebeten würde, dieses Layout jemandem zu beschreiben, würde ich ihm *zwei* Dinge erzählen
Es gibt zwei nebeneinander liegende Abschnitte;
einer dieser Abschnitte ist wichtiger als der andere.
Die relative Bedeutung der Komponenten ist eine separate Information von der Verschachtelungsstruktur – oder deren Fehlen, in diesem einfachen Beispiel. In einem komplexeren Beispiel haben Sie einige Inhaltsblöcke mit aussagekräftigen verschachtelten Überschriften (wie dieser Artikel) und andere Blöcke (wie die Seitenleisten oder der Kommentarbereich unten), die parallele, unabhängige Gliederungen haben, deren innere Überschriftenebenen sich von denen im ersten Block unterscheiden. Jede parallele Blockgleichbehandlung ignoriert die relative Bedeutung, die ihnen im Markup verliehen wurde. Aber diese zusätzlichen Überschriften am Ende des Hauptartikels anzuhängen, nur weil es keine größere Überschrift dazwischen gibt, scheint irgendwie schlimmer zu sein.
Auch wenn Komponenten verschachtelt sind, haben sie oft eine Bedeutungsebene, die unabhängig von der Anzahl der sie umgebenden Abschnitte ist. Ich schreibe Bücher über SVG für O’Reilly. Die Auszeichnung, die wir für die Bücher verwenden, wird in HTML konvertiert. Das Buch (Überschrift Ebene 1) hat Kapitel (Überschriften Ebene 2) mit Abschnitten (Überschriften Ebene 3), die manchmal Unterabschnitte oder sogar Unter-Unterabschnitte (Ebene 4 und 5) haben. Aber es hat auch Beispiele, Warnhinweise und Seitenleisten, die alle ihre eigenen Überschriften haben können, die identisch formatiert werden, unabhängig davon, ob diese Komponente sich in einem regulären Abschnitt oder einem Unter-Unterabschnitt befindet. Wenn wir die „korrekten“ HTML-Überschriftenelemente verwenden würden, hätten sie unterschiedliche Tag-Namen, abhängig von der Abschnittstiefe, würden aber identisch formatiert werden.
Im Webdesign und im Content Management haben wir zwei sehr unterschiedliche Arten, über die Ebene einer Überschrift zu sprechen: die Ebene der Wichtigkeit oder die Ebene der Verschachtelung. Ich denke, der Hauptgrund, warum sich Webstandards-Experten nicht auf einen Algorithmus zur Umwandlung von Überschriften in eine Gliederung einigen können, ist, dass die Leute einen Algorithmus wollen, bei dem beide übereinstimmen, und das tun sie oft nicht.
Vielleicht muss man aufhören, über Gliederungen zu sprechen, als ob sie die Wichtigkeitsebenen von Überschriften neu nummerieren würden. Aufhören, Webentwicklern zu sagen, dass sie falsch liegen, wenn sie die Überschriftenebenen verwenden, die für ihren Inhalt sinnvoll sind. Lassen Sie den Kontext die Gliederungsverschachtelung definieren, aber definieren Sie die Gliederungsverschachtelung nicht so, als ob sie austauschbar mit Tag-Namen wäre. Idealerweise sollte ein Weg gefunden werden, wie Browser Screenreadern *sowohl* die verschachtelte Struktur von Abschnitten als auch die rohen Überschriften-Ebenennummern mitteilen, damit Screenreader ihren Benutzern die Navigation nach Struktur ermöglichen können, während sie gleichzeitig die relative Bedeutung jeder Überschrift kommunizieren.
Dann konzentrieren Sie sich auf die eigentliche Frage
Wie können wir die aussagekräftige Struktur einer Webseite zusammenfassen, damit Menschen, die assistierende Technologien nutzen, Inhalte leicht finden können?
Mein Instinkt ist, dass die Gliederung, die Abschnittselemente verwendet, normalerweise besser für die Navigation ist als Abschnitte, die nur auf Tag-Namen basieren, aber dass die Details verbessert werden müssen. Insbesondere
Es müssen möglicherweise bessere Regeln für die Behandlung von mehrteiligen Überschriften geben, die durch ein <hgroup>- oder <header>-Element gruppiert sind.
Um Browser oder Screenreader dazu zu bringen, ihr Verhalten zu ändern – geschweige denn, all die Hunderttausende von Webentwicklern zu überzeugen, die Überschriften in ihren Inhalten verwenden –, werden wir mehr als nur Ahnungen und Meinungen brauchen. Wie ich schon früh argumentiert habe, brauchen wir Daten. Sowohl Jake als auch Brian haben diesen Ruf wiederholt.
Aber die Art von Daten, die wir brauchen, ist nicht die Art, die von einem Webcrawler gesammelt werden kann. Wir brauchen Daten über Bedeutung, die Art von Bedeutung, die nur echte menschliche Gehirne liefern können.
Die HTML-Abschnittselemente gibt es nun schon seit Jahren. Sie sind nicht mehr theoretisch. Sie sind Teil der Sprache, die Sie, Webentwickler, verwenden, um zu kommunizieren. Wenn Sie Abschnittselemente verwenden, hoffentlich haben Sie einen Grund dafür. Wenn Sie ein Überschriften-Tag auswählen, hoffentlich haben Sie einen Grund dafür. Es ist an der Zeit, die HTML-Standards zu überprüfen, um sicherzustellen, dass sie die Gründe und Bedeutungen widerspiegeln, die von den meisten Entwicklern verwendet werden.
Haben Sie das Gefühl, dass eine der Gliederungen sinnvoll ist?
Können Sie sie mit vernünftigen Anpassungen der Markup sinnvoll gestalten, die Sie mit Ihren Build-Systemen oder Komponenten-Frameworks implementieren können?
Welche Gliederung ist besser?
Welche Aspekte der Dokumentstruktur verursachen die meisten Probleme?
Und während wir dabei sind, noch eine Frage
Wie möchten Sie als Webnutzer auf Dokumente zugreifen und sie navigieren können, basierend auf Überschriften oder Gliederungen?
Psst! Erstellen Sie ein DigitalOcean-Konto und erhalten Sie 200 $ kostenloses Guthaben für Cloud-basiertes Hosting und Services.
Und so ist es. Das kommt davon, wenn man sich auf 25 Jahre alte Erinnerungen verlässt, anstatt nachzuschauen!
Ich habe eine Korrektur im Text vorgenommen, aber den Absatz dort gelassen, da mein Hauptpunkt derselbe ist, auch wenn dieses Beispiel nicht ganz so relevant ist, wie ich dachte.
Wir sind uns auch einig, dass alle diese Antworten wahrscheinlich einer weiteren Verfeinerung bedürfen – daher denke ich, dass wir wirklich eine Möglichkeit brauchen, eine Reihe von Beispielen zu sammeln und dann zu sehen/diskutieren, was sie „tun“. Ich sage nicht „es sollte so sein“, aber ich habe darüber nachgedacht, dass wir wahrscheinlich ein Repository brauchen, um damit anzufangen – etwas wie https://github.com/bkardell/outline . Ich würde gerne einige Kapitel-Sitzungen durchführen, um beim Ausfüllen zu helfen, aber ich habe darauf gewartet, darüber zu sprechen, bis ich mit mehr Leuten gesprochen habe/den Plan etwas verfeinert habe… wdyt?
Es sieht nicht so aus, als wären die in diesem WHATWG-Log besprochenen Änderungen bereits live geschaltet. Die Gliederung des Validators verbirgt immer noch Überschriften, die sich innerhalb eines „Abschnitts-Root-Elements“ wie einem figure oder einem blockquote befinden. Z. B. siehe die Gliederung für diesen Artikel: Die Überschriften-Tags in den Abbildungen sind nicht enthalten.
Ich mag die Idee, einen organisierten Satz von Anwendungsfällen zu sammeln, und eine standardisierte Methode, um verschiedene Vorschläge zu beschreiben und zu vergleichen. Ich muss mir die von Ihnen erstellten Vorlagen genauer ansehen und Vorschläge machen. Idealerweise würden die Anwendungsfälle einen minimalen Testfall enthalten (wie mein Beispiel eines Hauptartikels plus einer unabhängigen Seitenleiste) und eine Beschreibung, wie der menschliche Autor erwarten würde, dass dieser Markup/dieses Design interpretiert wird.
Es gibt dort derzeit buchstäblich wie 1 Testfall, aber wenn wir diesen Ansatz mitmachen, kann ich damit beginnen, sie auszufüllen und die Sammlung durch ein breiteres Publikum zu fördern.
Die Art und Weise, wie Gliederungen aus verschachtelten Abschnitts-Roots fehlen, ist entweder ein Fehler in der Spezifikation oder in der Implementierung. Ich glaube nicht, dass es da Meinungsverschiedenheiten gibt.
Wenn es ein Fehler in der Implementierung ist, dann einer, den wir in mehreren Implementierungen gesehen haben, so dass die Spezifikation zumindest geklärt werden muss.
Die WHATWG HTML-Spezifikationen enthalten immer noch den vollständigen Gliederungsalgorithmus, der als normative Anforderung beschrieben wird
Die Implementierung des Gliederungsalgorithmus in einer der HTML-Spezifikationen ist keine normative Anforderung.
Um Browser oder Screenreader dazu zu bringen, ihr Verhalten zu ändern
Screenreader melden dem Benutzer Informationen, die von Browsern über die Barrierefreiheits-APIs bereitgestellt werden. Wenn Browser den Gliederungsalgorithmus implementieren, wird der Rang der Überschrift entsprechend der Verschachtelung und nicht der fest kodierten Nummer im Elementnamen vermittelt.
Hinweis: Screenreader bieten bereits eine Methode, um die Verschachtelung und Bedeutung der Elemente <main>, <section><header>, <footer>, <aside> und <nav> über ihre Zuordnung zu Landmark-Rollen, Informationen, die über die Browser-Acc-APIs exponiert werden, zu navigieren und zu vermitteln.
Ich bin erstaunt, dass wir als Gemeinschaft das noch nicht gelöst haben.
Ich persönlich bin für das Opt-in-neues-Tag-Lager – dann muss ich nicht so viel nachdenken (oder so denke ich zumindest).
Mit diesem Ansatz bräuchten wir jedoch wirklich einen weiteren CSS-Selektor, um das Unvermeidliche zu vermeiden section section section h {} Selektoren, die versuchen, section ... n von h(n) Level zu finden.
Was uns zurück zu h1 ... h6 und/oder dem Anwenden von Klassen führt.
Wie können wir die aussagekräftige Struktur einer Webseite zusammenfassen, damit Menschen, die assistierende Technologien nutzen, Inhalte leicht finden können? Browser könnten Webentwicklern/Designern/Autoren helfen, die Meldungen zu verstehen, die sie an assistierende Technologien senden, aber das tun sie nicht Konsens steht dem Fortschritt im Weg Browseränderungen müssen abwärtskompatibel sein Browseränderungen müssen für Browserhersteller überzeugend sein
Meine Ergänzungen
Niemand kümmert sich um Nutzer assistierender Technologien Etwas milder ausgedrückt: Der durchschnittliche Webentwickler/Designer/Autor (Content Creator) hat wenig bis gar keine Ahnung, wie seine Website für jemanden aussieht, der assistierende Technologien nutzt. Integrierte Browserfunktionen sind die beste Option, um Content Creators dabei zu helfen, zu verstehen, wie Nutzer assistierender Technologien ihre Seiten wahrnehmen.
Meine Empfehlung
Ich schlage vor, wir geben alle zu, dass sich niemand außer Nutzern assistierender Technologien und Elfenbeinturm-Denkern um assistierende Technologien kümmert. Schauen Sie, ich benutze Google Chrome und es denkt, ich hätte „assistive“ falsch geschrieben. Ja, das ist immer noch nichts. Als nächstes: **Fragen Sie, wie diese Gremien, die Influencer und die Mächte, die das Web gestalten, dem durchschnittlichen Content Creator helfen können, sich dafür zu interessieren.** Los!
Meine Spekulationen
Verknüpfen Sie assistierende Technologien mit SEO (wie heute HTTPS). Eine gute Punktzahl für assistierende Technologien verbessert Ihre SEO-Punktzahl. Wahrscheinlich schon wahr, aber machen Sie es zu einer stärkeren Kraft. Eine Kraft, die dazu führt, dass die Leute aufmerksam werden. Erstellen und/oder fördern Sie einfach zu verwendende Bibliotheken für CMS, und Browser-Erweiterungen, die eine Seite wie assistierende Technologien interpretieren. Bieten Sie visuelles Feedback, das uns hilft zu verstehen, und produzieren Sie eine Punktzahl. Das „nu“ ist ein Schritt in diese Richtung, aber ein Werkzeug, das sich nur auf die Seiten- und Website-Gliederung konzentriert, muss in die Werkzeugkiste des Content Creators eingebettet sein, und es muss eine Punktzahl produzieren, denn Punktzahlen motivieren Veränderungen. Der Google Chrome Debugger (und andere) sollten einen Interpreter und Bewerter für assistierende Technologien wie die Bibliotheken oder Erweiterungen enthalten, die ihnen vorausgehen. Es könnte eine Option unter dem Reiter „Audit“ sein. Wenn es mehrere Möglichkeiten gibt, eine Seite zu interpretieren (aufgrund von Spezifikationsvarianten), lassen Sie die Content Creators entweder die Spezifikation bei der Interpretation und Bewertung auswählen oder auditieren Sie basierend auf allen „aktuellen“ Spezifikationen. Fordern Sie die Nutzer solcher Werkzeuge auf, anonyme Datensammlung zu akzeptieren. Lassen Sie die Leute, die sich genug kümmern, um solche Werkzeuge zu nutzen, die Richtung bestimmen, in die sich Spezifikationen entwickeln. Wenn Spezifikation A im Durchschnitt besser abschneidet als Spezifikation B, dann wissen wir, dass Spezifikation A näher an dem ist, was Content Creators tendenziell bevorzugen. Das Auflisten der Spezifikationen hilft auch bei der Bildung. Vielleicht wird Spezifikation B bevorzugt gegenüber Spezifikation A, wenn die Leute sich dessen bewusster werden, weil sie das Werkzeug nutzen. Die Spezifikation(en) muss/müssen CMS-Entwickler befähigen, es ihren Autoren leicht zu machen, Seiten zu erstellen, die für assistierende Technologien freundlich sind. Helfen Sie Content Creators, nicht nur auf Seiten-, sondern auch auf Site-Ebene und darüber hinaus zu denken. Das Kapitelbuch ist ein großartiges Beispiel. Ich möchte vielleicht ein 300-seitiges Buch in eine einzige HTML-Seite quetschen oder auch nicht. Wie könnte das HTML so strukturiert werden, dass ich es in einzelne Seiten aufteilen oder zu einer einzigen Seite zusammenfügen kann, indem ich nur Elemente verschiebe? Also keine Elemente mutieren, außer a[href]-Attribute. Entwerfen Sie etwas, das Ihr durchschnittlicher CMS-Entwickler, Site-Designer und Autor als leistungsstark, wertvoll, zeitsparend wahrnimmt und leicht verstanden werden kann. Hinweis: Die Erhöhung der Anzahl der Tags hat mir nicht geholfen. headerhgroup was zum Teufel!? Hinweis: Content-Autoren verwenden sehr wenige Elemente: strong, h1, h2, p, img, und viele haben keine Ahnung, was unter der Haube passiert. Hinweis: Uns nicht genau zu sagen, was ein Element bedeutet oder wofür es verwendet werden sollte, hilft nicht. article vs section was zum Teufel!? Hinweis: Überlappende Elemente und aria-\* Attribute sind verwirrend. Wirklich verwirrend, und CMS-Content-Autoren (der übliche Fall) arbeiten nicht auf dieser Ebene.
Meine Sicht auf dieses Problem vom Boden aus
Dies hat sich als inspirierenderer Artikel als erwartet herausgestellt. Leider habe ich mich angesichts dessen, was Sie präsentiert haben, noch negativer gegenüber dem Zustand des assistierenden Technologieproblems eingestellt. Was für eine Herabsetzung für diejenigen, die auf assistierende Technologien angewiesen sind. Bitte treffen Sie einfach eine Entscheidung und ziehen Sie sie durch. Die nächste Generation wird mit negativen Konsequenzen umgehen können und werden. Sagen Sie uns, was wir tun sollen, und so viele, die sich kümmern, werden tun, was verlangt wird. SEO motiviert. Partner mit großen Playern. Edge will einen größeren Marktanteil. Wenn Edge ein großartiges SEO- und assistierendes Technologie-Audit-Tool (zweitklassiger Bürger) hätte, dann würden sich vielleicht mehr Entwickler Edge zuwenden. Wenn Edge ein großartiges Seiten- und Website-Navigationswerkzeug (erstklassiger Bürger) hätte, dann würden sich vielleicht mehr Benutzer über Edge und seine Hilfsbereitschaft unterhalten. Befähigen Sie uns, gute Arbeit zu leisten, und definieren Sie, was gute Arbeit ist. Beginnen Sie mit der Förderung und dem Prototyping von Add-on-Tools, und bauen Sie dann Tools in Browser ein, die die Interpretation(en) guter Arbeit lehren und verstärken. Daten hin oder her, Design! Sie wissen, welches Problem Sie lösen wollen. Sie kennen die Einschränkungen. Bitte, lösen Sie es einfach!
Danke für all diese Punkte, Jeremy – von denen viele breiter gelten als nur für Überschriften und Gliederungen. Ich würde mir wirklich mehr Feedback und Hilfe zur Barrierefreiheit in den Tools wünschen, die Entwickler bereits verwenden. Die Browser-Entwicklertools fangen gerade damit an, aber es ist immer noch nicht überall und es ist immer noch nicht ganz vorne. Bei wirklich schlimmen Verstößen, warum gibt es keine Browserwarnungen in der Konsole?
Ich schätze den Punkt, dass der durchschnittliche Entwickler einfach klare Anweisungen wünscht. Wir wissen, dass sich Webentwicklungs-Muster in der Vergangenheit geändert haben, als es einen klaren Konsens über die „korrekte“ Wahl gab: Umstellung von Tabellenlayouts auf CSS, oder Umstellung von b und i auf strong und em (obwohl das keine so große Verbesserung der Barrierefreiheit ist, wie uns weisgemacht wurde), oder die Verwendung von <nav> und <main> (das sind wichtige Verbesserungen der Barrierefreiheit für Screenreader-Nutzer). Aber für die anderen semantischen Elemente gab es keine klare Anleitung, was zu tun ist, und keine negativen Konsequenzen, wenn man etwas anderes tat, und so hatten sie keine der erhofften Auswirkungen.
Vielen Dank für Ihre nachdenkliche Antwort, Amelia!
Seitdem ich diesen Kommentar geschrieben habe, versuche ich, meine Perspektive neu auszubalancieren und nach dem Silberstreif am Horizont zu suchen. Die Tatsache, dass Barrierefreiheit heute eine Funktion von Webbrowsern ist, ist das Wichtigste! Was hier in Betracht gezogen wird, ist nicht Inklusion, sondern inkrementelle Verbesserung. Ich hoffe, dass die nächste Überarbeitung der Seiten- (und Site-) Navigation in einer klaren und vorhersehbaren Spezifikation formalisiert werden kann, die allen Webnutzern, Browsern, Suchmaschinen und Content Creators zugute kommt.
Vielleicht, wenn es dem Denkprozess hilft, kann es als inhaltsorientierter Ansatz für REST (Representational State Transfer) formuliert werden, der es Menschen und Maschinen gleichermaßen erleichtert, das Web zu navigieren und Inhaltsbeziehungen zu verstehen.
Ich versuche seit einiger Zeit, mich mit Dokumentengliederungen auseinanderzusetzen und hatte Mühe, gute Ressourcen für den „richtigen“ Weg zur Strukturierung von Seiten und zur Verwendung von Abschnittselementen zu finden. Das ist ein wirklich erhellender Artikel. Danke!
Ich bin mir nicht sicher, was Sie mit „Annotation“ meinen.
Als ob Stile verwendet werden, um berechnete Überschriftenebenen widerzuspiegeln? Das könnte als visuelle Validierungsmethode hilfreich sein, wie eine fortgeschrittenere Version von Linting HTML mit CSS. Es würde immer noch erfordern, dass Entwickler tatsächlich wissen und sich genug darum kümmern, zu validieren, aber es könnte persönlicher sein, die Informationen als Ergänzungen zu Ihrer Website zu sehen, anstatt als analysierte Ergebnisse auf einem Validierungsdienst.
Es wäre eine interessante Übung zu sehen, ob Sie ein Set von CSS-Regeln erstellen könnten, um den vollständigen Algorithmus zu implementieren, um die Ebenen zu verfolgen. Wenn Sie CSS-Zähler verwenden würden (anstelle von Schriftgrößenänderungen), könnte dies auch eine visuelle Darstellung sein, wie die DOM-Reihenfolge im Quellcode in Ihrem Layout verteilt ist.
Wenn Sie über die Verwendung von reinem CSS zum Erstellen eines Inhaltsverzeichnisses sprechen, glaube ich nicht, dass das derzeit aus Gründen möglich ist, die nicht mit den Gliederungsproblemen zusammenhängen.
„Annotation“ war nicht das Wort, nach dem ich gesucht habe, „definieren“ kommt dem näher. Heute bietet CSS die Flexibilität, wie eine Seite von den Augen interpretiert wird (in naher Zukunft noch mehr mit Grid). Ich frage mich, ob CSS-Eigenschaften verwendet werden könnten, um Webbrowsern (assistierenden und anderen) mitzuteilen, wie eine Seite für Navigationszwecke interpretiert werden sollte. Ich teile die Seitenavigation in zwei Arten auf: kontextuelle Gruppierung (in HTML5 haben wir Elemente wie main, aside, nav, footer, adbar usw.) und Elementhierarchie/Priorität (h1, h2 usw.).
Anstatt sich auf HTML5-Elemente oder aria-role zu verlassen, lassen Sie CSS-Autoren mitteilen, was vor sich geht.
.main {
/* Group is an arbitrary string. The same group could be set on multiple elements. Allowing priority to flow across elements with the same group. */
group: main;
}
.title {
/* The element's priority within the nearest group. */
priority: 1;
}
.search-results .title {
/* Priority can be affected by context, media queries, etc. */
priority: 2;
}
Bemerkenswert ist, dass dies CSS-Autoren ermöglichen würde, Einschränkungen oder schlechte Implementierungen vieler CMS zu umgehen.
Danke für einen so detaillierten Artikel. Eine Sache, über die ich während des gesamten Artikels nachgedacht habe, ist, dass es wirklich nicht viel Erwähnung des anderen Elefanten im Raum gab. Wie die SEO-Seite des Geschäfts Überschriften interpretieren möchte.
Diese zusätzliche Ebene kann sehr frustrierend sein, wenn sowohl das visuelle Erscheinungsbild als auch die zugrunde liegende Struktur solide sind, was an sich schon problematisch sein kann, wie Sie in Ihrem Artikel so elegant dargelegt haben. Wir müssen nun auch daran denken, dass es Marketing-/Ranking-Regeln gibt, die ihre eigenen Standards haben, von denen einige nicht geschrieben oder von einer bestimmten Autorität geregelt werden und oft stark umstritten sind. Wir haben also diesen dritten, sich entwickelnden, trendigen Satz von „Praktiken“, über den wir auf dem Laufenden bleiben müssen, wenn wir erstklassige Web-Entwickler sein wollen.
Junge, dieser Beruf kann manchmal ganz schön anstrengend sein!
Dieser Kommentarbereich ist geschlossen. Wenn Sie wichtige Informationen teilen möchten, kontaktieren Sie uns bitte.
Es gibt einen kleinen Fehler im Artikel. Die Zahl Googol wird anders geschrieben als die Suchmaschine.
Und so ist es. Das kommt davon, wenn man sich auf 25 Jahre alte Erinnerungen verlässt, anstatt nachzuschauen!
Ich habe eine Korrektur im Text vorgenommen, aber den Absatz dort gelassen, da mein Hauptpunkt derselbe ist, auch wenn dieses Beispiel nicht ganz so relevant ist, wie ich dachte.
Die Wörter sind natürlich immer noch verwandt, da Sergei und Larry ihr Unternehmen nach dem Konzept eines Googol benannt haben, auch wenn sie die Schreibweise absichtlich oder unabsichtlich geändert haben.
Ich stimme definitiv zu, dass wir Daten brauchen – ich glaube, wir müssen uns auch auf eine gute Methode zur Sammlung von Daten abstimmen.
Der Validator implementiert eigentlich keine der beiden Spezifikationen perfekt, soweit ich weiß, sondern etwas leicht anderes (siehe auch http://logs.glob.uno/?c=freenode%23whatwg&s=23+Feb+2017&e=23+Feb+2017&h=Mike%27s#c1021547)
Wir sind uns auch einig, dass alle diese Antworten wahrscheinlich einer weiteren Verfeinerung bedürfen – daher denke ich, dass wir wirklich eine Möglichkeit brauchen, eine Reihe von Beispielen zu sammeln und dann zu sehen/diskutieren, was sie „tun“. Ich sage nicht „es sollte so sein“, aber ich habe darüber nachgedacht, dass wir wahrscheinlich ein Repository brauchen, um damit anzufangen – etwas wie https://github.com/bkardell/outline . Ich würde gerne einige Kapitel-Sitzungen durchführen, um beim Ausfüllen zu helfen, aber ich habe darauf gewartet, darüber zu sprechen, bis ich mit mehr Leuten gesprochen habe/den Plan etwas verfeinert habe… wdyt?
Es sieht nicht so aus, als wären die in diesem WHATWG-Log besprochenen Änderungen bereits live geschaltet. Die Gliederung des Validators verbirgt immer noch Überschriften, die sich innerhalb eines „Abschnitts-Root-Elements“ wie einem
figureoder einemblockquotebefinden. Z. B. siehe die Gliederung für diesen Artikel: Die Überschriften-Tags in den Abbildungen sind nicht enthalten.Ich mag die Idee, einen organisierten Satz von Anwendungsfällen zu sammeln, und eine standardisierte Methode, um verschiedene Vorschläge zu beschreiben und zu vergleichen. Ich muss mir die von Ihnen erstellten Vorlagen genauer ansehen und Vorschläge machen. Idealerweise würden die Anwendungsfälle einen minimalen Testfall enthalten (wie mein Beispiel eines Hauptartikels plus einer unabhängigen Seitenleiste) und eine Beschreibung, wie der menschliche Autor erwarten würde, dass dieser Markup/dieses Design interpretiert wird.
Es gibt dort derzeit buchstäblich wie 1 Testfall, aber wenn wir diesen Ansatz mitmachen, kann ich damit beginnen, sie auszufüllen und die Sammlung durch ein breiteres Publikum zu fördern.
Die Art und Weise, wie Gliederungen aus verschachtelten Abschnitts-Roots fehlen, ist entweder ein Fehler in der Spezifikation oder in der Implementierung. Ich glaube nicht, dass es da Meinungsverschiedenheiten gibt.
Wenn es ein Fehler in der Implementierung ist, dann einer, den wir in mehreren Implementierungen gesehen haben, so dass die Spezifikation zumindest geklärt werden muss.
Die Implementierung des Gliederungsalgorithmus in einer der HTML-Spezifikationen ist keine normative Anforderung.
Screenreader melden dem Benutzer Informationen, die von Browsern über die Barrierefreiheits-APIs bereitgestellt werden. Wenn Browser den Gliederungsalgorithmus implementieren, wird der Rang der Überschrift entsprechend der Verschachtelung und nicht der fest kodierten Nummer im Elementnamen vermittelt.
Hinweis: Screenreader bieten bereits eine Methode, um die Verschachtelung und Bedeutung der Elemente
<main>,<section><header>,<footer>,<aside>und<nav>über ihre Zuordnung zu Landmark-Rollen, Informationen, die über die Browser-Acc-APIs exponiert werden, zu navigieren und zu vermitteln.Ich bin erstaunt, dass wir als Gemeinschaft das noch nicht gelöst haben.
Ich persönlich bin für das Opt-in-neues-Tag-Lager – dann muss ich nicht so viel nachdenken (oder so denke ich zumindest).
Mit diesem Ansatz bräuchten wir jedoch wirklich einen weiteren CSS-Selektor, um das Unvermeidliche zu vermeiden
section section section h {}Selektoren, die versuchen,section ... nvonh(n)Level zu finden.Was uns zurück zu
h1 ... h6und/oder dem Anwenden von Klassen führt.*seufz*
Mitnehmen
Wie können wir die aussagekräftige Struktur einer Webseite zusammenfassen, damit Menschen, die assistierende Technologien nutzen, Inhalte leicht finden können?
Browser könnten Webentwicklern/Designern/Autoren helfen, die Meldungen zu verstehen, die sie an assistierende Technologien senden, aber das tun sie nicht
Konsens steht dem Fortschritt im Weg
Browseränderungen müssen abwärtskompatibel sein
Browseränderungen müssen für Browserhersteller überzeugend sein
Meine Ergänzungen
Niemand kümmert sich um Nutzer assistierender Technologien
Etwas milder ausgedrückt: Der durchschnittliche Webentwickler/Designer/Autor (Content Creator) hat wenig bis gar keine Ahnung, wie seine Website für jemanden aussieht, der assistierende Technologien nutzt.
Integrierte Browserfunktionen sind die beste Option, um Content Creators dabei zu helfen, zu verstehen, wie Nutzer assistierender Technologien ihre Seiten wahrnehmen.
Meine Empfehlung
Ich schlage vor, wir geben alle zu, dass sich niemand außer Nutzern assistierender Technologien und Elfenbeinturm-Denkern um assistierende Technologien kümmert. Schauen Sie, ich benutze Google Chrome und es denkt, ich hätte „assistive“ falsch geschrieben. Ja, das ist immer noch nichts. Als nächstes: **Fragen Sie, wie diese Gremien, die Influencer und die Mächte, die das Web gestalten, dem durchschnittlichen Content Creator helfen können, sich dafür zu interessieren.** Los!
Meine Spekulationen
Verknüpfen Sie assistierende Technologien mit SEO (wie heute HTTPS). Eine gute Punktzahl für assistierende Technologien verbessert Ihre SEO-Punktzahl. Wahrscheinlich schon wahr, aber machen Sie es zu einer stärkeren Kraft. Eine Kraft, die dazu führt, dass die Leute aufmerksam werden.
Erstellen und/oder fördern Sie einfach zu verwendende Bibliotheken für CMS, und Browser-Erweiterungen, die eine Seite wie assistierende Technologien interpretieren. Bieten Sie visuelles Feedback, das uns hilft zu verstehen, und produzieren Sie eine Punktzahl. Das „nu“ ist ein Schritt in diese Richtung, aber ein Werkzeug, das sich nur auf die Seiten- und Website-Gliederung konzentriert, muss in die Werkzeugkiste des Content Creators eingebettet sein, und es muss eine Punktzahl produzieren, denn Punktzahlen motivieren Veränderungen.
Der Google Chrome Debugger (und andere) sollten einen Interpreter und Bewerter für assistierende Technologien wie die Bibliotheken oder Erweiterungen enthalten, die ihnen vorausgehen. Es könnte eine Option unter dem Reiter „Audit“ sein.
Wenn es mehrere Möglichkeiten gibt, eine Seite zu interpretieren (aufgrund von Spezifikationsvarianten), lassen Sie die Content Creators entweder die Spezifikation bei der Interpretation und Bewertung auswählen oder auditieren Sie basierend auf allen „aktuellen“ Spezifikationen.
Fordern Sie die Nutzer solcher Werkzeuge auf, anonyme Datensammlung zu akzeptieren. Lassen Sie die Leute, die sich genug kümmern, um solche Werkzeuge zu nutzen, die Richtung bestimmen, in die sich Spezifikationen entwickeln. Wenn Spezifikation A im Durchschnitt besser abschneidet als Spezifikation B, dann wissen wir, dass Spezifikation A näher an dem ist, was Content Creators tendenziell bevorzugen. Das Auflisten der Spezifikationen hilft auch bei der Bildung. Vielleicht wird Spezifikation B bevorzugt gegenüber Spezifikation A, wenn die Leute sich dessen bewusster werden, weil sie das Werkzeug nutzen.
Die Spezifikation(en) muss/müssen CMS-Entwickler befähigen, es ihren Autoren leicht zu machen, Seiten zu erstellen, die für assistierende Technologien freundlich sind.
Helfen Sie Content Creators, nicht nur auf Seiten-, sondern auch auf Site-Ebene und darüber hinaus zu denken. Das Kapitelbuch ist ein großartiges Beispiel. Ich möchte vielleicht ein 300-seitiges Buch in eine einzige HTML-Seite quetschen oder auch nicht. Wie könnte das HTML so strukturiert werden, dass ich es in einzelne Seiten aufteilen oder zu einer einzigen Seite zusammenfügen kann, indem ich nur Elemente verschiebe? Also keine Elemente mutieren, außer a[href]-Attribute. Entwerfen Sie etwas, das Ihr durchschnittlicher CMS-Entwickler, Site-Designer und Autor als leistungsstark, wertvoll, zeitsparend wahrnimmt und leicht verstanden werden kann.
Hinweis: Die Erhöhung der Anzahl der Tags hat mir nicht geholfen.
headerhgroupwas zum Teufel!?Hinweis: Content-Autoren verwenden sehr wenige Elemente: strong, h1, h2, p, img, und viele haben keine Ahnung, was unter der Haube passiert.
Hinweis: Uns nicht genau zu sagen, was ein Element bedeutet oder wofür es verwendet werden sollte, hilft nicht.
articlevssectionwas zum Teufel!?Hinweis: Überlappende Elemente und aria-\* Attribute sind verwirrend. Wirklich verwirrend, und CMS-Content-Autoren (der übliche Fall) arbeiten nicht auf dieser Ebene.
Meine Sicht auf dieses Problem vom Boden aus
Dies hat sich als inspirierenderer Artikel als erwartet herausgestellt. Leider habe ich mich angesichts dessen, was Sie präsentiert haben, noch negativer gegenüber dem Zustand des assistierenden Technologieproblems eingestellt. Was für eine Herabsetzung für diejenigen, die auf assistierende Technologien angewiesen sind. Bitte treffen Sie einfach eine Entscheidung und ziehen Sie sie durch. Die nächste Generation wird mit negativen Konsequenzen umgehen können und werden. Sagen Sie uns, was wir tun sollen, und so viele, die sich kümmern, werden tun, was verlangt wird. SEO motiviert. Partner mit großen Playern. Edge will einen größeren Marktanteil. Wenn Edge ein großartiges SEO- und assistierendes Technologie-Audit-Tool (zweitklassiger Bürger) hätte, dann würden sich vielleicht mehr Entwickler Edge zuwenden. Wenn Edge ein großartiges Seiten- und Website-Navigationswerkzeug (erstklassiger Bürger) hätte, dann würden sich vielleicht mehr Benutzer über Edge und seine Hilfsbereitschaft unterhalten. Befähigen Sie uns, gute Arbeit zu leisten, und definieren Sie, was gute Arbeit ist. Beginnen Sie mit der Förderung und dem Prototyping von Add-on-Tools, und bauen Sie dann Tools in Browser ein, die die Interpretation(en) guter Arbeit lehren und verstärken. Daten hin oder her, Design! Sie wissen, welches Problem Sie lösen wollen. Sie kennen die Einschränkungen. Bitte, lösen Sie es einfach!
Danke für all diese Punkte, Jeremy – von denen viele breiter gelten als nur für Überschriften und Gliederungen. Ich würde mir wirklich mehr Feedback und Hilfe zur Barrierefreiheit in den Tools wünschen, die Entwickler bereits verwenden. Die Browser-Entwicklertools fangen gerade damit an, aber es ist immer noch nicht überall und es ist immer noch nicht ganz vorne. Bei wirklich schlimmen Verstößen, warum gibt es keine Browserwarnungen in der Konsole?
Ich schätze den Punkt, dass der durchschnittliche Entwickler einfach klare Anweisungen wünscht. Wir wissen, dass sich Webentwicklungs-Muster in der Vergangenheit geändert haben, als es einen klaren Konsens über die „korrekte“ Wahl gab: Umstellung von Tabellenlayouts auf CSS, oder Umstellung von
bundiaufstrongundem(obwohl das keine so große Verbesserung der Barrierefreiheit ist, wie uns weisgemacht wurde), oder die Verwendung von<nav>und<main>(das sind wichtige Verbesserungen der Barrierefreiheit für Screenreader-Nutzer). Aber für die anderen semantischen Elemente gab es keine klare Anleitung, was zu tun ist, und keine negativen Konsequenzen, wenn man etwas anderes tat, und so hatten sie keine der erhofften Auswirkungen.Vielen Dank für Ihre nachdenkliche Antwort, Amelia!
Seitdem ich diesen Kommentar geschrieben habe, versuche ich, meine Perspektive neu auszubalancieren und nach dem Silberstreif am Horizont zu suchen. Die Tatsache, dass Barrierefreiheit heute eine Funktion von Webbrowsern ist, ist das Wichtigste! Was hier in Betracht gezogen wird, ist nicht Inklusion, sondern inkrementelle Verbesserung. Ich hoffe, dass die nächste Überarbeitung der Seiten- (und Site-) Navigation in einer klaren und vorhersehbaren Spezifikation formalisiert werden kann, die allen Webnutzern, Browsern, Suchmaschinen und Content Creators zugute kommt.
Vielleicht, wenn es dem Denkprozess hilft, kann es als inhaltsorientierter Ansatz für REST (Representational State Transfer) formuliert werden, der es Menschen und Maschinen gleichermaßen erleichtert, das Web zu navigieren und Inhaltsbeziehungen zu verstehen.
Ich versuche seit einiger Zeit, mich mit Dokumentengliederungen auseinanderzusetzen und hatte Mühe, gute Ressourcen für den „richtigen“ Weg zur Strukturierung von Seiten und zur Verwendung von Abschnittselementen zu finden. Das ist ein wirklich erhellender Artikel. Danke!
Amelia, was denkst du über die Annotation der Gliederung eines Dokuments über CSS?
Ich bin mir nicht sicher, was Sie mit „Annotation“ meinen.
Als ob Stile verwendet werden, um berechnete Überschriftenebenen widerzuspiegeln? Das könnte als visuelle Validierungsmethode hilfreich sein, wie eine fortgeschrittenere Version von Linting HTML mit CSS. Es würde immer noch erfordern, dass Entwickler tatsächlich wissen und sich genug darum kümmern, zu validieren, aber es könnte persönlicher sein, die Informationen als Ergänzungen zu Ihrer Website zu sehen, anstatt als analysierte Ergebnisse auf einem Validierungsdienst.
Es wäre eine interessante Übung zu sehen, ob Sie ein Set von CSS-Regeln erstellen könnten, um den vollständigen Algorithmus zu implementieren, um die Ebenen zu verfolgen. Wenn Sie CSS-Zähler verwenden würden (anstelle von Schriftgrößenänderungen), könnte dies auch eine visuelle Darstellung sein, wie die DOM-Reihenfolge im Quellcode in Ihrem Layout verteilt ist.
Wenn Sie über die Verwendung von reinem CSS zum Erstellen eines Inhaltsverzeichnisses sprechen, glaube ich nicht, dass das derzeit aus Gründen möglich ist, die nicht mit den Gliederungsproblemen zusammenhängen.
Linting mit CSS ist ein interessanter Gedanke.
„Annotation“ war nicht das Wort, nach dem ich gesucht habe, „definieren“ kommt dem näher. Heute bietet CSS die Flexibilität, wie eine Seite von den Augen interpretiert wird (in naher Zukunft noch mehr mit Grid). Ich frage mich, ob CSS-Eigenschaften verwendet werden könnten, um Webbrowsern (assistierenden und anderen) mitzuteilen, wie eine Seite für Navigationszwecke interpretiert werden sollte. Ich teile die Seitenavigation in zwei Arten auf: kontextuelle Gruppierung (in HTML5 haben wir Elemente wie main, aside, nav, footer, adbar usw.) und Elementhierarchie/Priorität (h1, h2 usw.).
Anstatt sich auf HTML5-Elemente oder aria-role zu verlassen, lassen Sie CSS-Autoren mitteilen, was vor sich geht.
Bemerkenswert ist, dass dies CSS-Autoren ermöglichen würde, Einschränkungen oder schlechte Implementierungen vieler CMS zu umgehen.
Langer, aber hilfreicher Artikel. Wird die Header-Hierarchie in jedem neuen semantischen Element neu gestartet?
Danke für einen so detaillierten Artikel. Eine Sache, über die ich während des gesamten Artikels nachgedacht habe, ist, dass es wirklich nicht viel Erwähnung des anderen Elefanten im Raum gab. Wie die SEO-Seite des Geschäfts Überschriften interpretieren möchte.
Diese zusätzliche Ebene kann sehr frustrierend sein, wenn sowohl das visuelle Erscheinungsbild als auch die zugrunde liegende Struktur solide sind, was an sich schon problematisch sein kann, wie Sie in Ihrem Artikel so elegant dargelegt haben. Wir müssen nun auch daran denken, dass es Marketing-/Ranking-Regeln gibt, die ihre eigenen Standards haben, von denen einige nicht geschrieben oder von einer bestimmten Autorität geregelt werden und oft stark umstritten sind. Wir haben also diesen dritten, sich entwickelnden, trendigen Satz von „Praktiken“, über den wir auf dem Laufenden bleiben müssen, wenn wir erstklassige Web-Entwickler sein wollen.
Junge, dieser Beruf kann manchmal ganz schön anstrengend sein!