The Document Outline Dilemma
Im CMSimple_XH–Forum bin ich auf diesen Artikel gestoßen: https://cmsimpleforum.com/viewtopic.php?f=41&t=15732
Daher habe ich für mich selbst versucht den Originalartikel ins Deutsche zu übersetzen:
Das Dilemma der Dokumentengliederung
Amelia Bellamy-Royds on Mar 7, 2017 (Updated on Nov 8, 2018)
In den letzten Wochen wurde in Kreisen der Webstandards viel über HTML-Überschriften gesprochen. Vielleicht haben Sie einige der Blogbeiträge, Tweets und GitHub-Problemlösungen gesehen. Überschriften sind Teil von HTML seit den allerersten Websites am CERN, daher mag es überraschen, dass sie 25 Jahre später kontrovers diskutiert werden. Ich werde kurz zusammenfassen warum sie immer noch diskussionswürdig sind, mit vielen Links zu anderen Quellen, bevor ich meine eigene Meinung in den Mix einbringe. Wenn über die Debatte auf dem Laufenden sind, können Sie direkt zum Abschnitt "Bigger Dilemma" springen.
Die Geschichte bis jetzt...
HTML verwendet Überschriften (<h1>, <h2>, <h3> und so weiter bis <h6>), um Titel für einen nachfolgenden Textabschnitt zu kennzeichnen. Die Nummern (oder Ebenen) der Überschriftenelemente sollen logisch einer baumartigen Struktur von verschachtelten Abschnitten entsprechen, wie bei Büchern, die Kapitel mit Abschnitten und Unterabschnitten haben.
Ursprünglich gab es im HTML-Markup jedoch keine Möglichkeit, diese verschachtelte logische Struktur in einer verschachtelten DOM-Struktur wiederzugeben. Im Gegensatz zu verschachtelten Listen waren verschachtelte Überschriften nicht wirklich in Elementen verschachtelt, die die übergeordneten Abschnitte definierten. Überschriftenelemente verschiedener Ebenen waren alle Geschwisterelemente und auch Geschwister der Absätze, denen sie einen Titel gaben. Die "Abschnitte" waren eine rein logische Struktur, keine DOM-Struktur, die das gesamte Markup enthielt, das mit einer Überschrift begann und bis zu einer anderen Überschrift der gleichen oder einer höheren Ebene fortgesetzt wurde.
Wie Brian Kardell hervorhebt, war dies im "Flat Earth Markup" des frühen HTML, bei dem Tags lediglich typografische Anweisungen waren, die in einen Textfluss eingefügt wurden, durchaus sinnvoll. Das Konzept einer HTML-Seite als Baumstruktur kam später auf, als das so genannte Dynamic HTML ein Document Object Model (DOM) benötigte, um diesen Textfluss und die Tags als Datenstruktur zu beschreiben, auf die Skripte zugreifen konnten.
Ich will das Ende nicht verraten, aber HTML hat jetzt ein <section>-Element, das (optional) verwendet werden kann, um eine verschachtelte DOM-Struktur zu erstellen, die Ihrer logischen Überschriftenstruktur entspricht. Die Elemente <main>, <header>, <footer>, <article>, <aside> und <nav> helfen ebenfalls bei der Erstellung einer verschachtelten Dokumentstruktur, die sich in der DOM-Schachtelung widerspiegelt.
Aber es gab noch ein weiteres Problem mit dem ursprünglichen Überschriftenmodell: Es konnte nicht einfach in Vorlagensystemen neu gemischt werden. Da die Überschriftsebene durch den Tag-Namen (<h1> gegenüber <h4>) und nicht durch den Kontext, in dem sie verwendet wird, ausgedrückt wird, können Sie denselben Inhalt nicht einfach in einem anderen Kontext wiederverwenden, in dem die Ebene eine andere wäre. In einem Blog können beispielsweise dieselben Artikelüberschriften und Einleitungsabsätze in verschiedenen Kontexten verwendet werden: als eigenständige Blogpostseiten, als Zusammenfassungen auf einer Hauptindexseite oder als Zusammenfassungen auf einer Archivseite, die auch Überschriften zur Unterteilung der Liste nach Monat oder Jahr enthält. Welche Überschriftenebene sollte der Artikeltitel haben?
Frühe Vorschläge für Gliederungselemente sahen auch ein stufenloses <h>- oder <heading>-Element vor, dem je nach Kontext eine Stufe zugewiesen werden sollte. (Die Idee geht sogar auf die frühesten Diskussionen über HTML zurück.) Als die Gliederungselemente schließlich zu HTML hinzugefügt wurden, sollten sie mit den bestehenden Überschriftenelementen zusammenarbeiten. In den Spezifikationen wurde jedoch ein "Document Outline Algorithm" definiert, der die Überschriftsebenen für die vorhandenen nummerierten Überschriftentags auf der Grundlage der Abschnittsverschachtelung neu berechnen sollte.
Mit dem Gliederungsalgorithmus für Dokumente könnten Sie (theoretisch) ein <h1> für alle Überschriften verwenden, und der Browser würde die Ebene jeder Überschrift auf der Grundlage ihrer Verschachtelung innerhalb von <Artikel>, <Abschnitt> und verwandten Elementen herausfinden. Der Gliederungsalgorithmus würde sicherstellen, dass die oberste Überschrift auf der Seite der Ebene 1 entspricht und dass alle anderen Überschriften in einer konsistenten Reihenfolge verschachtelt werden, ohne dass Ebenen übersprungen werden. Die WHATWG-Version der Gliederung definiert auch Regeln für den Umgang mit mehrteiligen Überschriften in <hgroup>-Elementen, so dass die Unterüberschriften keine Unterabschnitte erzeugen. (In der W3C-Version von HTML 5 wurde <hgroup> stattdessen für veraltet erklärt: mehrteilige Überschriften sollten als Absätze innerhalb eines Abschnitts <header> oder als Spannen innerhalb des Hauptüberschriftenelements gekennzeichnet werden).
Die Browser änderten ihre Standardformatvorlagen so, dass Überschriften innerhalb verschachtelter Abschnitte eine immer kleinere Schriftgröße haben (so wie die Standardformatvorlage für <h3> eine kleinere Schrift hat als <h2>, die kleiner ist als <h1>). Die Art und Weise, wie die Überschriftsebenen den von Screenreadern verwendeten Zugänglichkeits-APIs zur Verfügung gestellt werden, wurde jedoch nicht geändert. Und die Benutzer von Bildschirmlesegeräten sind die einzigen, die Überschriftenebenen wirklich als Teil der Benutzeroberfläche wahrnehmen.
Bildschirmlesegeräte zeigen beim Lesen von Überschriften die nummerierte Ebene an und ermöglichen es den Nutzern, Überschriften einer bestimmten Ebene schnell zu überfliegen. Laut einer WebAIM-Umfrage überfliegen zwei Drittel der Benutzer von Bildschirmlesegeräten die Überschriften als ersten Schritt bei der Suche nach Informationen auf einer langen Webseite. Für diese Benutzer bestand die einzige Auswirkung des Document Outline Algorithm darin, dass einige neue Seiten (die eifrig die neue Spezifikation annahmen) als flache Listen von Überschriften der Ebene 1 ohne jegliche Struktur dargestellt wurden.
Warum verwenden die Browser nicht den Gliederungsalgorithmus für barrierefreie Überschriftenebenen? Es wurden viele Argumente vorgebracht, aber das überzeugendste ist, dass es die Art und Weise verändern könnte, wie bestehende Websites für Benutzer von Bildschirmlesegeräten dargestellt werden, und es ist nicht klar, dass diese Veränderungen überwiegend positiv wären.
Adrian Roselli hat in "There is No Document Outline" einen guten Überblick über die Diskussionen über die Probleme zusammengestellt, die durch die nicht implementierte Gliederungsspezifikation verursacht werden. Die neuesten W3C-HTML-Spezifikationen verwenden den Gliederungsalgorithmus nur, um vorzuschlagen, wie Autoren ihre nummerierten Überschriften-Tags mit ihren verschachtelten Gliederungselementen synchronisieren sollten. In den WHATWG-HTML-Spezifikationen wird der vollständige Gliederungsalgorithmus immer noch als normative Anforderung beschrieben, obwohl es eine offene Frage gibt, bei der viele vorschlagen, ihn ganz zu entfernen. Domenic Denicola, WHATWG-Spezifikationsredakteur, drückt es so aus:
Irgendwann können wir nicht mehr behaupten, dass die Benutzeragenten kaputt sind. Stattdessen lehnen sie unseren Änderungsantrag ab.
Die aktuelle Debatte
Die jüngste Debatte wurde ausgelöst, als Jonathan Neal in der W3C-HTML-Spezifikation das schwer fassbare <h>-Element erneut vorschlug. Der Kern des Vorschlags besteht darin, dass ein <h>-Überschriftenelement eine durch Gliederungselemente definierte Verschachtelungsebene haben könnte, während die bestehenden nummerierten Überschriften-Tags die durch ihren Tag-Namen bestimmte Ebene beibehalten können. Die Autoren würden sich durch die Verwendung des neuen Tags für den Gliederungsalgorithmus entscheiden. Bis die Browser <h> unterstützten, konnte ein JavaScript- (oder serverseitiges) Polyfill die Überschriftsebenen berechnen und sie mit ARIA-Attributen in den DOM einfügen: role="heading" und aria-level="3" teilen dem Browser mit, dass er ein Element für die Zwecke der Barrierefreiheit als Überschrift der Ebene 3 behandeln soll, unabhängig vom Tag-Namen oder der Verschachtelung, so dass der Seitenautor am Ende die volle Verantwortung für jegliche Überschriftenverwirrung trägt.
Es gibt eine Menge guter Diskussionen auf dieser Seite und in längeren verlinkten Blogbeiträgen. Das Hauptargument für das Hinzufügen eines neuen Elements ist, dass es die Bedeutung des bestehenden Inhalts nicht verändern würde. Neben Neals Argumenten auf GitHub geht auch Brian Kardells Vorschlag für ein benutzerdefiniertes Element und Polyfill von diesem Standpunkt aus an das Problem heran. Auf der anderen Seite plädiert Jake Archibald dafür, die bereits vorhandenen Elemente zu fixieren:
Die Arbeit, die nötig ist, um das bestehende Netz zu reparieren, ist ein Teil der Arbeit, die nötig ist, um ein neues Element zu erstellen, das dasselbe tut, aber das bestehende Netz nicht repariert.
Mit anderen Worten: Wenn der Umriss-Algorithmus so großartig ist, dass er ein neues Element wert ist, warum implementiert man dann nicht einfach den Umriss-Algorithmus für bestehende Elemente?
Wenn Sie immer noch nicht verstehen können, warum sich niemand darüber einigen kann, was mit etwas so scheinbar Einfachem wie HTML-Überschriften zu tun ist, hat Brian Kardell in einem zweiten Beitrag alle technischen Details herausgearbeitet.
Das größere Dilemma
Hinter der Diskussion über die Erstellung einer Gliederung für eine Webseite verbirgt sich eine Annahme. Bei der Erörterung der Erstellung einer Gliederung wird davon ausgegangen, dass die Struktur einer Webseite als Gliederung definiert werden kann: als ein Baum, bei dem die Verschachtelungsebene einer Überschrift ihre Bedeutung definiert.
Ich persönlich glaube nicht, dass eine einfache verschachtelte Gliederung alle Bedeutungsebenen erfassen kann, die durch HTML-Überschriftenebenen, wie sie im Web verwendet werden, vermittelt werden. Ich werde gleich darauf eingehen, warum. Aber es gibt einen Grund, warum sich die ganze Diskussion auf diese Art von Gliederung konzentriert hat: weil dies die Art von Gliederung ist, die Screenreader erwarten.
Für die meisten Webnutzer und Webautoren ist die Gliederung des Dokuments irrelevant. Sie wissen nicht und es ist ihnen egal, wie die Überschriften und Abschnitte verschachtelt sind, sie sehen nur, was auf dem Bildschirm zu sehen ist. Und was auf dem Bildschirm zu sehen ist, ist bei den meisten Webseiten heute ein zweidimensionales Layout von Inhalten, die zum Teil verschachtelt, zum Teil aber auch unabhängig sind, wobei jedem Teil durch Layout, Farben und Typografie eine bestimmte Bedeutung und Beziehung zugewiesen wird.
Die Frage, über die wir diskutieren sollten, lautet also nicht: "Wie sollten wir den Überschriften Gliederungsebenen zuweisen?" Sie lautet: "Wie können wir die sinnvolle Struktur einer Webseite zusammenfassen, so dass Menschen, die Hilfsmittel verwenden, den Inhalt leicht finden können?"
Ich persönlich fände es gut, wenn die Browser eine Funktion für alle Benutzer hinzufügen würden, die die Gliederung als Inhaltsverzeichnis anzeigt und es ermöglicht, mit der Tastatur schnell zu den Überschriften zu navigieren. Vielleicht würden dann mehr Webautoren darauf achten, wie ihre Gliederung aussieht. Aber die Browser tun es nicht, und deshalb tun es die meisten Autoren auch nicht.
Wenn Sie sehen möchten, wie die Gliederung Ihrer Website aussieht - und wie sie theoretisch mit dem Algorithmus für die Gliederung von Dokumenten aussehen würde - können Sie den W3C Nu HTML-Validierungsdienst verwenden, wobei die Option Gliederungen anzeigen aktiviert sein muss.
In ihrer jetzigen Form ist die Gliederung des Dokuments nur für Benutzer von Bildschirmlesegeräten von täglicher Bedeutung, und diese Benutzer sind es derzeit gewohnt, mit dem Chaos der unregelmäßigen Überschriftenebenen in Webseiten zurechtzukommen. Ich bin sicher, dass viele Screenreader-Nutzer es begrüßen würden, wenn die Überschriftenebenen korrigiert würden. Aber Überschriften für Screen-Reader-Benutzer zu fixieren, bedeutet nicht nur, einen Baum von sauber verschachtelten Überschriften ohne übersprungene Ebenennummern zu erstellen. Es bedeutet, eine Überschriftenstruktur zu schaffen, die genau die Bedeutung widerspiegelt, die von den Machern der Webseite beabsichtigt ist, die Bedeutung, die visuelle Benutzer aus Stil und Layout ableiten. Und um das zu erreichen, müssen wir überlegen, wie die Bedeutung allen Benutzern von Webseiten vermittelt wird, die nicht hören, dass jede Überschrift mit einer numerischen Ebene angekündigt wird.
Eine Sprache wird von denen definiert, die sie sprechen
HTML ist unter den Programmiersprachen einzigartig, weil es so viele Konstrukte definiert, ohne ihnen ein bestimmtes Verhalten zuzuweisen. Die Bedeutung im Computercode wird als die semantische Seite der Sprache bezeichnet, im Gegensatz zu den syntaktischen Strukturen ihrer Grammatik. In den meisten Programmiersprachen sind die semantischen Aspekte eingebauter Objekte jedoch immer noch stark an Anweisungen für den Computer gebunden. In JavaScript haben new Date() und new Promise() die gleiche Syntax - sie rufen eine Konstruktorfunktion auf -, aber Ihr JS-Interpreter versteht den semantischen Unterschied zwischen den beiden Objektnamen und verhält sich bei beiden sehr unterschiedlich.
Im Gegensatz dazu enthält ein HTML <Artikel> oder ein <Abschnitt> keine Anweisungen, was Ihr Webbrowser damit machen soll (außer dem nicht implementierten Gliederungsalgorithmus). Stattdessen geht es bei dem Unterschied zwischen den beiden um die Bedeutung des Inhalts, eine Möglichkeit, maschinenlesbare Anmerkungen für die Informationen zu liefern, die von einem Menschen, dem Autor der Website, an einen anderen übermittelt werden: den Leser.
Die Bedeutung in der menschlichen Kommunikation ist schwer zu definieren und niemals statisch. Vor allem aber wird sie von den Menschen definiert, die die Sprache verwenden. Wörterbücher stellen Zusammenfassungen der verwendeten Bedeutungen zusammen, aber sie schränken sie nicht ein. 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, stellte ein Bibliothekar das mehrbändige Oxford English Dictionary vor, indem er uns eine Auswahl wilder und verrückter Wörter präsentierte. Google* war der Name für die Zahl, die als 1 gefolgt von 100 Nullen geschrieben wird (10100, in wissenschaftlicher Notation). Verrückt, oder? Wer sollte so ein Wort jemals kennen müssen? Aber die Zeiten ändern sich. Im Jahr 2006 fügte das OED eine neue Definition hinzu, nämlich google als Verb (was bedeutet, die Google-Suchmaschine zu benutzen), das in der modernen englischen Konversation vielleicht ein google-mal häufiger verwendet wird als die Zahlenmenge.
*Korrektur: Wie Mark in den Kommentaren anmerkt, lautet die korrekte Schreibweise des Wortes, das mir vor all den Jahren 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 beiden konkurrierenden HTML-Spezifikationen (WHATWG und W3C) das Äquivalent zu Wörterbüchern. Und genau wie Wörterbücher begannen beide als Versuche, die Sprache so zu beschreiben, wie sie derzeit verwendet wird.
Die Tatsache, dass es zwei verschiedene HTML-Spezifikationen gibt, erschwert die Diskussion über Änderungen, unterstreicht aber auch den kollektiven, konsensbasierten Charakter von HTML als Sprache. Es gibt kein einheitliches 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, sondern auch von Computern verwendet. Und Computer sind nicht sehr gut darin, mit unscharfen und wechselnden Bedeutungen umzugehen.
Wenn Sie einen Computer bitten, etwas mit Ihren Inhalten zu tun, wie z. B. dem Bildschirmlesegerät mitzuteilen, welche Überschriften es auf dieser Website gibt und wie sie gegliedert sind, braucht er klare und eindeutige Regeln, wie er das tun soll. Wenn einige Web-Autoren die Überschriften-Tags auf eine bestimmte Art und Weise verwenden und andere Autoren dieselben Tags mit anderer Bedeutung, braucht Ihr Browser zusätzliche Regeln, um herauszufinden, was was ist - oder er wird es falsch verstehen, zumindest manchmal.
Die treibende Kraft der Bewegung für Webstandards war die Hoffnung, dass alle Webbrowser auf Webseitencode (ungefähr) gleich reagieren würden. Und das bedeutet, dass neue Funktionen in Standarddokumenten definiert werden müssen, bevor sie im Web verwendet werden können. Anstatt beschreibend zu sein, wie ein Wörterbuch (das definiert, wie Dinge sind), sind sie präskriptiv, wie ein Gesetzbuch (das definiert, wie Dinge sein sollten).
Das langsame Tempo der Entwicklung von Standards mit vielen Beiträgen von Browser-Teams soll sicherstellen, dass das Endergebnis sowohl präskriptiv als auch deskriptiv ist, zumindest für die Teile der Sprache, die das Browserverhalten beschreiben. Aber das funktioniert nicht immer. In beiden Spezifikationen gibt es viele Details, die nicht mit dem tatsächlichen Browserverhalten übereinstimmen. Das Issue Repo des W3C hat sogar ein Label mit dem beruhigenden Namen "Match Reality Better", das darauf abzielt, diese Details zu korrigieren.
Und das sind nur die Funktionen, die beschreiben, was die Browser tun sollen. Was ist mit all den HTML-Elementen, die die Semantik des Inhalts definieren? Sollten diese nicht auch "besser zur Realität passen"?
Vor einigen Monaten schlug Sara Soueidan in der W3C-HTML-Arbeitsgruppe vor, dass das <address>-Element vielleicht für alle Adressen gelten sollte (und nicht nur für Kontaktadressen von Seitenbetreibern). Viele Leute vor ihr haben sicherlich die gleiche Beschwerde vorgebracht. Aber dieses Mal ist etwas passiert. Nach einer groben Datenerhebung, die darauf schließen ließ, dass die tatsächliche Verwendung in der freien Wildbahn nicht auf die ursprüngliche Definition beschränkt war, wurde die Definition in den W3C-Spezifikationen aktualisiert.
Macht das einen Unterschied? Vielleicht nicht. Die Browser machen nichts mit <address>, außer es kursiv zu machen. Und die WHATWG-HTML-Spezifikationen haben immer noch die alte Definition. Aber es bedeutet, dass die Spezifikation ein wenig näher daran ist, die Art und Weise zu beschreiben, wie der Code tatsächlich im Web verwendet wird, und nicht, wie es sich jemand einmal vorgestellt hat.
Womit wir endlich wieder bei den Überschriften wären: Wie werden sie tatsächlich im Web verwendet? Und ist es überhaupt möglich, eine Reihe von Anweisungen für Web-Autoren und Web-Browser zu definieren, die sicherstellen, dass die Bedeutung von Überschriften korrekt an Bildschirmlesegeräte (und möglicherweise auch an andere Software) übermittelt werden kann?
Die vielen Bedeutungen von Überschriften
Was ist eine Überschrift? Sie ist ein kurzer Titel für einen Abschnitt eines Dokuments. Die Überschrift für diesen Abschnitt lautet "Die vielen Bedeutungen von Überschriften". So weit, so gut.
Aber nicht alle Überschriften sind gleich.
Es gibt große Überschriften:
A Big Heading
und es gibt viel kleinere Überschriften:
A heading so small it’s barely a heading
Wenn Sie sich den Code ansehen, werden Sie feststellen, dass eines davon ein <h1> und das andere ein <h6> ist. Beide sind in <Figure>-Tags eingeschlossen, die sie nach dem Gliederungsalgorithmus des Dokuments kapseln und verhindern sollen, dass sie die Gliederung des Hauptdokuments durcheinander bringen. Aber wir alle wissen inzwischen, dass der Gliederungsalgorithmus von Webbrowsern nicht verwendet wird. Ich entschuldige mich daher bei allen Nutzern von Bildschirmlesegeräten, die versehentlich auf der Hälfte des Artikels gelandet sind.
Für jeden, der diesen Artikel mit einem modernen Browser liest, wird der Unterschied zwischen den beiden Überschriften durch die Schriftgröße und möglicherweise den Schriftstil vermittelt. Die genauen Details hängen davon ab, ob Sie das CSS der Website oder das CSS Ihres Browsers im Lesemodus betrachten, und davon, wie kürzlich Chris die Stile von CSS-Tricks geändert hat. Aber sofern Chris nicht wirklich Mist gebaut hat, wird es für visuelle Leser ziemlich klar sein, dass das <h1> größer und wichtiger ist als das <h6>. Wir könnten das CSS so ändern, dass sie identisch aussehen, aber im Moment ist es schwer zu verstehen, warum man das tun sollte. Wenn Sie wollen, dass sie gleich aussehen, warum verwenden Sie dann nicht denselben Tag-Namen?
Gehen wir also einen Schritt weiter und fügen diese beiden Überschriften mit etwas Fülltext dazwischen zusammen. Hier ist eine Möglichkeit, dies zu tun, mit einer Hauptüberschrift, etwas Text, dann eine Unterüberschrift und etwas mehr Text:
Hier ist eine weitere Möglichkeit, dieselben Überschriften und Absätze anzuordnen:
Und hier ist eine dritte:
Wenn Sie nur die Ergebnisregisterkarte dieser Stifte betrachten und dabei Ihre Augen benutzen, könnten Sie denken, dass das zweite und das dritte Beispiel identisch sind und sich stark vom ersten unterscheiden. Optisch haben sowohl Beispiel 2 als auch Beispiel 3 einen Hauptabschnitt mit einer großen Überschrift und einen Seitenleistenabschnitt mit einer kleinen Überschrift. Der Unterschied besteht darin, dass in einem Fall <div>-Elemente für die Strukturierung verwendet werden, während im anderen Fall HTML-Gliederungselemente zum Einsatz kommen.
Wenn Sie bis hierher gelesen haben, wird es Sie wahrscheinlich nicht überraschen, dass diese beiden Beispiele unterschiedliche Strukturen erzeugen, wenn sie vom Algorithmus zur Gliederung von HTML-Dokumenten verarbeitet werden. Bei diesem Algorithmus werden divs ignoriert, so dass Beispiel Nr. 2 genauso behandelt würde wie Beispiel Nr. 1: eine Hauptüberschrift, etwas Absatztext, dann eine Unterüberschrift und ein weiterer Absatz. Die Gliederung weist nicht darauf hin, dass die Seitenleiste eine separate, parallele Struktur zum Hauptartikel darstellt:
a. A heading so small it’s barely a heading
Wenn ich dagegen den Gliederungsalgorithmus für Beispiel Nr. 3 ausführe, sagt er mir, dass es ein unbeschriftetes Hauptdokument (keine Überschrift der obersten Ebene) mit zwei gleichwertigen untergeordneten Elementen gibt (beide Überschriften werden als Ebene 2 behandelt). Damit wird zwar die parallele Struktur deutlich, nicht aber die unterschiedliche Bedeutung der Überschriften:
a. A big heading
b. A heading so small it’s barely a heading
Ich glaube nicht, dass eine der beiden Gliederungen dieses visuelle Layout genau beschreibt. Auch nicht die auf Tag-Namen basierende Gliederung, die nicht nur die Seitenleiste als im Hauptartikel verschachtelt behandelt, sondern auch durch meine Verwendung von <h6> auf einer Seite ohne <h2/3/4/5>-Elemente abgelenkt wird.
Wenn ich gebeten würde, jemandem dieses Layout zu beschreiben, würde ich ihm zwei Dinge sagen:
- es gibt zwei nebeneinander liegende Abschnitte;
- einer dieser Abschnitte ist wichtiger als der andere.
Die relative Bedeutung der Komponenten ist eine von der Verschachtelungsstruktur - oder deren Fehlen in diesem einfachen Beispiel - unabhängige Information. In einem komplexeren Beispiel haben Sie einige Inhaltsabschnitte mit sinnvollen verschachtelten Überschriften (wie diesen Artikel) und andere Abschnitte (wie die Seitenleisten oder den Kommentarbereich unten), die parallele, unabhängige Gliederungen haben, deren innere Überschriftenebenen keinen Bezug zu denen des ersten Abschnitts haben. Wenn man alle parallelen Abschnitte als gleichwertig behandelt, wird die relative Bedeutung, die ihnen im Markup gegeben wurde, ignoriert. Aber diese zusätzlichen Überschriften an das Ende des Hauptartikels anzuheften, nur weil es keine größere Überschrift dazwischen gibt, scheint irgendwie schlimmer zu sein.
Selbst wenn Komponenten verschachtelt sind, haben sie oft eine Wichtigkeitsstufe, die unabhängig von der Anzahl der sie umgebenden Abschnitte ist. Ich schreibe Bücher über SVG für O'Reilly. Das Markup, das wir zur Erstellung der Bücher verwenden, wird in HTML konvertiert. Das Buch (Ebene-1-Überschrift) hat Kapitel (Ebene-2-Überschriften) mit Abschnitten (Ebene-3-Überschriften), die manchmal Unterabschnitte oder sogar Unter-Unterabschnitte (Ebene-4 und 5) haben. Aber es gibt auch Beispiele, Warnhinweise und Seitenleisten, die alle ihre eigenen Überschriften haben können, die identisch gestaltet werden, unabhängig davon, ob sich die Komponente in einem regulären Abschnitt oder einem Unterabschnitt befindet. Würden wir die "richtigen" HTML-Überschriftenelemente verwenden, hätten sie je nach Tiefe des Abschnitts unterschiedliche Tag-Namen, würden aber identisch gestaltet.
Im Webdesign und in der Inhaltsverwaltung gibt es zwei sehr unterschiedliche Arten, über die Ebene einer Überschrift zu sprechen: die Ebene der Bedeutung oder die Ebene der Verschachtelung. Ich glaube, der Hauptgrund, warum sich die Webstandards nicht auf einen Algorithmus für die Umwandlung von Überschriften in eine Gliederung einigen können, liegt darin, dass die Leute einen Algorithmus wollen, bei dem beide übereinstimmen, und das tun sie oft nicht.
Vielleicht sollte man aufhören, über Gliederungen zu reden, als ob sie die Bedeutung von Überschriften neu nummerieren würden. Hören Sie auf, Webentwicklern zu sagen, dass sie falsch liegen, wenn sie die Überschriftenebenen verwenden, die für ihren Inhalt sinnvoll sind. Lassen Sie den Kontext die Verschachtelung von Gliederungen definieren, aber definieren Sie die Verschachtelung von Gliederungen nicht so, als ob sie mit Tag-Namen austauschbar wäre. Idealerweise sollte ein Weg gefunden werden, wie die Browser den Bildschirmlesern sowohl die verschachtelte Struktur der Abschnitte als auch die rohen Überschriftsnummern mitteilen können, so dass die Bildschirmleser ihre Benutzer anhand der Verschachtelungsstruktur navigieren lassen können, während sie gleichzeitig die relative Wichtigkeit der einzelnen Überschriften mitteilen.
Dann konzentrieren Sie sich auf die eigentliche Frage:
Wie können wir die sinnvolle Struktur einer Webseite zusammenfassen, so dass Menschen, die Hilfsmittel verwenden, den Inhalt leicht finden können?
Mein Gefühl sagt mir, dass die Gliederung mit Abschnittselementen in der Regel besser für die Navigation ist als Abschnitte, die nur auf Tag-Namen basieren, dass aber die Details verbessert werden müssen. Im Besonderen:
- Es muss bessere Regeln für das Zusammenfassen von unbenannten Abschnitten geben, die vielleicht als ARIA-Gruppen und nicht als zusätzliche Verschachtelungsebenen in der Gliederung behandelt werden.
- Es muss vielleicht bessere Regeln für die Behandlung von mehrteiligen Überschriften geben, die durch ein <hgroup>- oder <header>-Element gruppiert sind.
- Und es muss wahrscheinlich bessere Regeln dafür geben, welche Elemente (wenn überhaupt) ihre untergeordneten Überschriften insgesamt von der Hauptgliederung abkapseln.
Zeigen Sie mir die Daten
Aber das ist nur meine Meinung.
Um Browser oder Bildschirmlesegeräte dazu zu bringen, ihr Verhalten zu ändern - ganz zu schweigen von all den Hunderttausenden von Webentwicklern, die Überschriften in ihren Inhalten verwenden -, brauchen wir mehr als nur Vermutungen und Meinungen. Wie ich bereits zu Beginn argumentiert habe, brauchen wir einige Daten. Sowohl Jake als auch Brian haben diese Forderung aufgegriffen.
Aber die Art von Daten, die wir brauchen, ist nicht die Art, die von einem Web-Crawler gesammelt werden kann. Wir brauchen Daten über Bedeutung, die Art von Bedeutung, die nur echte menschliche Gehirne liefern können.
Die HTML-Gliederungselemente gibt es nun schon seit Jahren. Sie sind nicht mehr theoretisch. Sie sind Teil der Sprache, die Sie, die Webentwickler, zur Kommunikation verwenden. Wenn Sie Gliederungselemente verwenden, haben Sie hoffentlich einen Grund dafür. Wenn Sie ein Überschriften-Tag auswählen, haben Sie hoffentlich einen Grund dafür. Es ist an der Zeit, die HTML-Standards zu überprüfen, um sicherzustellen, dass sie die Gründe und die Bedeutung widerspiegeln, die die meisten Entwickler verwenden.
Ich bitte Sie also: Lassen Sie Ihre Lieblingswebsites (die Sie erstellt haben oder die Sie verwenden) durch die beiden Gliederungsersteller im HTML-Validator laufen.
- Ist eine der beiden Gliederungen sinnvoll?
- Können Sie sie mit vernünftigen Änderungen am Markup, die Sie mit Ihren Build-Systemen oder Komponenten-Frameworks implementieren können, sinnvoll gestalten?
- Welche Gliederung ist besser?
- Welche Aspekte der Dokumentstruktur verursachen die meisten Probleme?
Und wenn wir schon dabei sind, noch eine Frage:
Wie würden Sie als Webnutzer gerne auf Dokumente zugreifen und anhand von Überschriften oder Gliederungen navigieren können?