Die Gliederungselemente in HTML5 sind <nav>, <aside>, <article> und <section>. <body> ist auch eine Art Gliederungselement, da der gesamte Inhalt darin Teil des Standard-Dokumentabschnitts ist.
Hier ist eine kurze Erklärung jedes Abschnittselements und wie es verwendet wird
<nav>– Äquivalent zurole="navigation". Wichtige Seitennavigation, die auf der Website häufig und konsistent erscheint. Beispiele hierfür sind die primäre Navigation, die sekundäre Navigation und die In-Page-Navigation.<aside>– Äquivalent zurole="complementary". Inhalt, der nur tangential mit dem Hauptinhalt zusammenhängt (oder nicht zusammenhängt). Denken Sie an eine Seitenleiste mit ergänzenden Informationen, eine Notiz in einem Artikel oder den äußeren Container für eine Liste verwandter Artikel am Ende eines Blogbeitrags.<article>– Äquivalent zurole="article". Inhalt, der in sich geschlossen ist, d. h. wenn er aus dem Kontext genommen wird, ist er sinnvoll. Das könnte ein Widget, ein Blogbeitrag oder sogar ein Kommentar innerhalb eines Blogbeitrags sein.<section>– Äquivalent zurole="region". Inhalt, der zusätzlichen Kontext von seinem übergeordneten Abschnittselement benötigt, um sinnvoll zu sein. Dies ist ein generisches Abschnittselement, das immer dann verwendet wird, wenn die Verwendung der anderen, semantischeren Elemente keinen Sinn ergibt.
👋 Wir wurden in den Kommentaren (und auf Twitter) darauf aufmerksam gemacht, dass einige der in diesem Artikel verwendeten Techniken zu einer schlechten Benutzererfahrung für Screenreader-Benutzer führen. Wir werden Aktualisierungen vornehmen, um sicherzustellen, dass der Artikel die bestmöglichen Informationen widerspiegelt. Sehen Sie sich bis dahin Adrian Rosellis Pen unten an, um einen angemesseneren Ansatz für die Gliederung des Beispiel-Layouts zu erhalten. Danke, dass Sie eine so großartige Community sind, in der wir alle gemeinsam lernen und wachsen können!
Inhalt
Dies ist ein sehr langer Artikel, den Sie wahrscheinlich mehrmals wieder aufrufen und referenzieren möchten. Um dies zu erleichtern, finden Sie hier eine Liste aller Überschriften des Artikels
Inhaltsverzeichnis
- Wann man
<nav>verwendet - Vermeiden Sie, ein
<aside>in ein<aside>zu verschachteln - Artikel ist wie „Block“; Sektion ist wie „Element“
- Tauschen Sie
<div>nicht gegen<section> - Kopf- und Fußzeilen
- Abschnittselemente und der Dokumentgliederungsalgorithmus
- Abschnittsinhalt
- Das
<main>-Element - Sie müssen Ihre Abschnitte kennzeichnen. Hier sind drei Methoden.
- Verwenden Sie nur eine Methode auf einmal
- Hinzufügen von Abschnitts-Labels zu unserem Beispiel-Layout
- H1 zur ersten Überschrift machen
- Bedenken bezüglich der vereinfachten Gliederungsalgorithmen-Spezifikation
- Verwendung von aria auf den Abschnittselementen des Beispiel-Layouts
- Was passiert, wenn Sie
<h7>benötigen? - Hat Ihre Website eine gute Struktur?
- Laden Sie einen Screenreader herunter und verwenden Sie ihn
Wann man <nav> verwendet
Das <nav>-Element muss nur einmal pro Navigationsblock verwendet werden. Untergeordnete Navigation, die sich bereits innerhalb eines <nav>-Elements befindet, muss nicht in ein zweites <nav>-Element eingeschlossen werden.
<nav aria-label="Primary">
<ul>
<li><a href="#">Primary link</a></li>
<li><a href="#">Primary link</a></li>
<li>
<a href="#">Primary link</a>
<!-- <nav> element is *not* needed again here -->
<ul>
<li><a href="#">Secondary link</a></li>
<li><a href="#">Secondary link</a></li>
</ul>
</li>
</ul>
</nav>Das <nav>-Element ist nur für **wichtige** Navigationsblöcke vorgesehen. „Wichtig“ ist jedoch ein sehr subjektiver Begriff. html5doctor.com hat eine ziemlich gute Erklärung dafür, wann die Verwendung von <nav> angemessen ist und wann nicht. Bedenken Sie, dass die folgenden Punkte Meinungen und keine offiziellen W3C-Regelungen sind.
Der Schlüsselbegriff ist „wichtige“ Navigation. Wir könnten den ganzen Tag über die Definition von „wichtig“ diskutieren, aber für mich bedeutet es
- Primäre Navigation
Websitesuche- Sekundäre Navigation (argwöhnisch)
- In-Page-Navigation (z. B. innerhalb eines langen Artikels)
Obwohl es hier kein Richtig oder Falsch gibt, sagt eine Stichprobe zusammen mit meiner eigenen Interpretation, dass die folgenden Punkte nicht von <nav> umschlossen werden sollten:
- Paginierungssteuerelemente
- Social-Media-Links (obwohl es Ausnahmen geben kann, bei denen Social-Media-Links die Hauptnavigation darstellen, z. B. auf Websites wie About me oder Flavours).
- Tags auf einem Blogbeitrag
- Kategorien auf einem Blogbeitrag
- Tertiäre Navigation
- Umfangreiche Fußzeilen
— html5doctor.com (durchgestrichen von mir)
Breadcrumbs sind ein weiterer Inhalt, der mit einem <nav>-Element umschlossen werden sollte, wie das W3C-Beispiel für Breadcrumb-HTML zeigt.
Ein <nav> ist um ein Suchformular herum unnötig
Ich widerspreche der Meinung von HTML5 Doctor, dass ein Suchformular einer Website in ein <nav>-Element eingeschlossen werden sollte (deshalb habe ich es durchgestrichen). <nav> ist dazu gedacht, um Navigations-Links gewickelt zu werden, nicht um ein Formular. Die Websitesuche hat tatsächlich ihre eigene spezielle Rolle, die sie als Such-Landmark definiert. Wenn Sie role="search" zum <form>-Element hinzufügen, wird es für Screenreader-Benutzer als Such-Landmark angekündigt. Screenreader-Benutzer können es auch beim Navigieren über Landmarks erreichen. Wenn mehrere Suchformulare auf der Seite vorhanden sind, sollten sie mit aria-label oder aria-labelledby (mehr Details zu diesen Attributen später) differenziert werden. Beziehen Sie das Wort „search“ nicht in das Aria-Label ein – das ist wie „Bild von“ in Alt-Text für Bilder; es ist unnötig. Konzentrieren Sie sich stattdessen darauf, wonach das Suchformular sucht. Für die globale Seitensuche wäre es also angemessen, ihr aria-label="site" zu geben.
<!-- <nav> is not needed on a search form. -->
<!-- role="search" is enough -->
<form role="search" aria-label="site">
<label>
<span>Search</span>
<input type="search" />
</label>
<button type="submit">Submit</button>
</form>Ein role="search"-Formular erscheint nicht in einer Dokumentgliederung, aber ich denke, das ist in Ordnung, da Suchformulare oft klein und in sich geschlossen sind. Es erhält dennoch die meisten Vorteile, die Sie durch die Verwendung von Abschnittselementen erhalten. Das Hinzufügen eines Abschnittselements zur Mischung bombardiert den Screenreader-Benutzer mit Meldungen, die ihm mitteilen, dass es sich um ein Suchformular handelt (eines für das Abschnittselement, eines für die Suchrolle und eines für das Such-Input-Label).
Verwenden Sie nicht das Wort „nav“ oder „navigation“ im Label
Wie bei role="search" führt das Hinzufügen von „navigation“ zum Label eines <nav>-Elements nur dazu, dass ein Screenreader zweimal „navigation“ sagt.
<nav aria-label="primary navigation">
<!-- Screen reader: "primary navigation navigation landmark" -->
</nav>
<nav aria-label="primary">
<!-- Screen reader: "primary navigation landmark" -->
</nav>Fragen, die Sie sich stellen sollten
derselbe Artikel von HTML5 Doctor listet zwei Fragen auf, die Sie sich stellen können, um herauszufinden, ob etwas in ein <nav> eingeschlossen werden sollte oder nicht.
- Wäre ein anderes Abschnittselement auch angemessen? Wenn ja, verwenden Sie vielleicht stattdessen dieses.
- Würden Sie einen Link dazu in einem „Springen zu“-Block für Barrierefreiheit hinzufügen? Wenn nicht, dann ist es vielleicht nicht wert, ein
<nav>-Element zu verwenden.
In Fällen, in denen die Navigation zu geringfügig ist, um die Verwendung des <nav>-Elements zu rechtfertigen, ist <section> höchstwahrscheinlich das Element, das Sie stattdessen verwenden sollten.
Ein <nav> muss keine Linkliste sein
Der häufigste Anwendungsfall für ein <nav> ist es, es um eine Linkliste zu wickeln, aber es muss keine Linkliste sein. Wenn Ihre Navigation auf andere Weise funktioniert, können Sie das <nav>-Element trotzdem verwenden.
<!-- Example taken from the <nav> element specification -->
<!-- https://html.spec.whatwg.org/multipage/sections.html#the-nav-element:the-nav-element-5 -->
<nav>
<h1>Navigation</h1>
<p>You are on my home page. To the north lies <a href="/blog">my
blog</a>, from whence the sounds of battle can be heard. To the east
you can see a large mountain, upon which many <a
href="/school">school papers</a> are littered. Far up thus mountain
you can spy a little figure who appears to be me, desperately
scribbling a <a href="/school/thesis">thesis</a>.</p>
<p>To the west are several exits. One fun-looking exit is labeled <a
href="https://games.example.com/">"games"</a>. Another more
boring-looking exit is labeled <a
href="https://isp.example.net/">ISP™</a>.</p>
<p>To the south lies a dark and dank <a href="/about">contacts
page</a>. Cobwebs cover its disused entrance, and at one point you
see a rat run quickly out of the page.</p>
</nav>In diesem Sinne ist es in Ordnung, kleine Teile wie Einführungstext im <nav>-Element zu haben, solange der Hauptfokus des Inhalts auf den Navigationslinks liegt. Einführungsinhalte werden am besten innerhalb eines <header> im <nav>-Element platziert. Ich werde später ausführlicher auf Kopf- und Fußzeilen eingehen.
<nav>
<header>
<h2>In this section</h2>
<p>This is some intro text describing what you will find in this section.</p>
</header>
<ul>
<li><a href="#">Sub section one</a></li>
<li><a href="#">Sub section two</a></li>
</ul>
</nav>Vermeiden Sie, ein <aside> in ein <aside> zu verschachteln
So wie <nav> eigentlich nie in ein anderes <nav>-Element verschachtelt werden sollte, werden auch <aside>-Elemente selten ineinander verschachtelt. <aside> wird verwendet, um Inhalte darzustellen, die tangential mit dem umgebenden Inhalt zusammenhängen. Das bedeutet, eine aside in eine aside zu platzieren, kündigt im Grunde eine Abweichung von etwas an, das selbst eine Abweichung vom Hauptinhalt ist.
<!-- Don't do this -->
<aside aria-label="Side bar">
<aside>
<h2>Share</h2>
<ul>
<!-- List of social media links -->
</ul>
</aside>
<aside>
<h2>Recommendations:</h2>
<ul>
<li>
<article>
<h2><a href="#">Related article title</a></h2>
<p>Article description</p>
</article>
</li>
<!-- List of recommended articles continues -->
</ul>
</aside>
</aside>Wenn Sie eine Seitenleiste mit mehreren Abschnitten haben, verschachteln Sie keine <aside>-Elemente innerhalb von <aside>-Elementen wie im obigen Beispiel. Machen Sie stattdessen die Seitenleiste zu einem einzigen <aside> und verwenden Sie dann <section> (oder ein anderes geeignetes Abschnittselement), um die verschiedenen Abschnitte zu erstellen.
<!-- Do this instead -->
<aside aria-label="Side bar">
<section>
<h2>Share</h2>
<ul>
<!-- List of social media links -->
</ul>
</section>
<section>
<h2>Recommended articles:</h2>
<ul>
<li>
<article>
<h2><a href="#">Related article title</a></h2>
<p>Article description</p>
</article>
</li>
<!-- List of recommended articles continues -->
</ul>
</section>
</aside>Artikel ist wie „Block“; Sektion ist wie „Element“
<section> und <article> sind leicht zu verwechseln. Wenn Sie mit der „Block Element Modifier“-Syntax (BEM) vertraut sind, dann ist ein einfacher Weg, den Unterschied zwischen den beiden zu verstehen, dass ein <article> ein bisschen wie das „B“ (oder „Block“) in BEM ist. Es ist ein Container, der in sich geschlossene Inhalte speichert, die auch in einem anderen Kontext sinnvoll sind. Einzelne Tweets auf Twitter und jeder Listeneintrag auf einer Suchergebnisseite wären als <article>-Elemente zu betrachten.
<section> ist wie das „E“ (oder „Element“) in BEM. Es ist ein Unterabschnitt, der den Kontext seines übergeordneten Abschnittselements benötigt, um sinnvoll zu sein. <section> ist ein generisches Auffangelement, das Sie verwenden, wenn die Verwendung der anderen Abschnittselemente keinen Sinn ergibt. Wenn Sie also Zweifel haben, wählen Sie <section>.
Beachten Sie, dass es nicht automatisch bedeutet, dass etwas ein <article>-Element ist, nur weil es in BEM als „Block“ gestylt ist. Dasselbe gilt für BEM-„Elemente“ und <section>-Elemente. Das Element von etwas sollte auf der Bedeutung des Inhalts basieren, nicht darauf, wie der Inhalt aussieht.
Kommentarbereiche
Was manche Leute vielleicht überrascht, ist, dass einzelne Kommentare zu einem Blogbeitrag auch als Artikel gelten, obwohl sie als Antwort auf den Hauptblogbeitrag verfasst sind. Der <article>-Container, der den Hauptblogbeitrag umschließt, sollte jedoch auch die Kommentarfunktion umschließen. Dies dient dazu, darzustellen, dass die Kommentare zum Hauptartikel gehören.
<article>
<h1>I am an awesome blog post!</h1>
<p>I am some body text content.</p>
<section>
<h2>Comments</h2>
<ul>
<li>
<article>
<h2>Username</h2>
<p>This is the comment body text.</p>
<footer>
<p>
Meta data like post date makes sense
in either the header or the footer.
</p>
</footer>
</article>
</li>
</ul>
</section>
</article>
Tauschen Sie <div> nicht gegen <section>
Nur weil wir jetzt diese schicken Abschnittselemente haben, bedeutet das nicht, dass das altbewährte <div>-Element seine Nützlichkeit verloren hat. <div> hat keine semantische Bedeutung und ist daher sehr nützlich, wenn wir das HTML rein zu Styling-Zwecken verändern.
Nehmen wir an, wir haben einen Blogbeitrag in einem <article>-Element, den wir aus Styling-Gründen in etwas anderes einpacken müssen.
<!-- I need a wrapper element -->
<article>
<h1>I am a blog post</h1>
<p>I am some content</p>
</article>In diesem Fall zum <section>-Element zu greifen, ist nicht das Richtige.
<!-- Do not do this -->
<section class="wrapper">
<article>
<h1>I am a blog post</h1>
<p>I am some content</p>
</article>
</section>Obwohl <section> technisch gesehen ein generisches Element ist, ist <div> die weitaus passendere Option in diesem Fall. Dieser neue umhüllende Container soll keine semantische Bedeutung haben und genau dafür ist <div> konzipiert.
<!-- Use a <div> if the element is only used for styling purposes -->
<div class="wrapper">
<article>
<h1>I am a blog post</h1>
<p>I am some content</p>
</article>
</div>Eine weitere Eselsbrücke: Wenn Ihnen keine aussagekräftige Überschrift einfällt, die Sie für ein <section> verwenden können, dann sollte es wahrscheinlich kein <section> sein.
Kopf- und Fußzeilen
Obwohl sie nicht unbedingt müssen, können Abschnittselemente eine *einzige* <header> und eine *einzige* <footer> enthalten, wobei die Kopfzeile am Anfang des Abschnitts und die Fußzeile am Ende steht.
Abschnittselemente können beliebig oft ineinander verschachtelt werden, je nach Inhalt.
Die Kopf- und Fußzeilen in einem Abschnittselement können ebenfalls Abschnittselemente enthalten.
Die einzige größere Einschränkung bei der Verschachtelung von Abschnittselementen ist, dass Kopf- und Fußzeilen nicht in andere Kopf- und Fußzeilen verschachtelt werden dürfen.
Was gehört in Kopfzeilen?
Kopfzeilen werden für einführende Inhalte verwendet. Geeignete Elemente für <header>-Elemente sind (aber nicht beschränkt auf):
- Das Überschriftenelement (
<h1>–<h6>) - Ein einführender Absatz oder eine Aussage.
- Ein Profilbild
- Ein Logo
- Ein Suchformular
- Primäre Navigation
- Name des Autors
- Datum des Beitrags/der Aktualisierung
- Metadaten
- Social-Media-Links
Was gehört in Fußzeilen?
Fußzeilen enthalten hauptsächlich Dinge wie Metadaten und sekundäre unterstützende Inhalte. Geeignete Elemente für <footer>-Elemente sind (aber nicht beschränkt auf):
- Copyright-Informationen
- Rechtliches
- Fußnoten
- Niedrig priorisierte Seitennavigation
- Name des Autors
- Datum des Beitrags/der Aktualisierung
- Metadaten
- Social-Media-Links
Sie werden feststellen, dass es eine gewisse Überschneidung zwischen Kopf- und Fußzeilen bezüglich der für beide geeigneten Inhalte gibt. Dies liegt hauptsächlich daran, dass Metadaten-ähnliche Inhalte gut in beide Elemente passen. Es hängt hauptsächlich vom Design ab, das Sie erreichen möchten. <header>-Elemente tendieren dazu, anzuzeigen, dass die darin enthaltenen Inhalte wichtiger sind als die Inhalte einer <footer>-Element.
Abschnittselemente und der Dokumentgliederungsalgorithmus
Eine wichtige Sache, die Sie über diese Abschnittselemente wissen sollten, ist, dass sie alle ein <h#>-Element darin enthalten sollten (oder auf andere Weise beschriftet sein, aber dazu später mehr). Dies geschieht hauptsächlich aus Gründen, die als Dokumentgliederungsalgorithmus bekannt sind. Dies ist ein Algorithmus, der Abschnittselemente verwendet, um zu bestimmen, auf welcher Ebene eine Überschrift (<h#>) liegen sollte, ohne sich ausschließlich auf die vom Entwickler angegebene Nummer verlassen zu müssen. Haben Sie sich also jemals gefragt, ob es in Ordnung ist, mehr als eine <h1> auf einer Seite zu haben? Dies soll dieses Problem lösen (aber warten Sie einen Moment, denn es gibt mehr zur Geschichte).
<!-- No Document outline algorithm -->
<article>
<h1>Primary heading</h1>
<h2>Secondary heading</h2>
<p>Some text.</p>
<h3>Tertiary heading</h3>
<p>Some text.</p>
</article><!-- With document outline algorithm -->
<article>
<h1>Primary heading</h1> <!-- Recognized as <h1> -->
<!-- sectioning element sets new heading level context -->
<section>
<h1>Secondary heading</h1> <!-- Recognized as <h2> -->
<p>Some text.</p>
<h2>Tertiary heading</h2> <!-- Recognized as <h3> -->
<p>Some text.</p>
</section>
</article>Der Dokumentgliederungsalgorithmus hat noch viel mehr zu bieten. Hier höre ich aber auf, weil...
Kein Browser unterstützt den Dokumentgliederungsalgorithmus
Es gibt keinen einzigen Browser, der diese Methode der Erstellung einer Überschriftenstruktur unterstützt. Das ist schade. Es würde den Aufbau barrierefreier Websites erheblich erleichtern, wenn wir uns nicht so viele Gedanken über die Verwendung der richtigen Überschriftenebene machen müssten.
Nach meinem Kenntnisstand gibt es zwei Hauptgründe, warum kein Browser den Algorithmus implementiert hat. Einer ist, dass Browserhersteller Angst haben, die Überschriftenstruktur von Websites zu brechen, die Abschnittselemente falsch verwendet haben. Der andere Grund ist, dass die aktuelle Spezifikation des Dokumentgliederungsalgorithmus schwer zu implementieren ist und kein Browserhersteller bereit war, die Zeit für die Implementierung aufzuwenden.
Bezüglich des ersten Grundes gibt es eine lange Diskussion über die Einführung eines neuen <h>-Elements anstelle der Verwendung des <h1>-Elements, um Browser anzuweisen, den Dokumentgliederungsalgorithmus zu verwenden. Ich habe die Idee eines neuen <h>-Elements befürwortet, bis ich realisierte, dass ein Attribut auf dem <html>-Element oder das Hinzufügen eines <meta>-Tags zum <head> noch besser funktionieren würde, um Browsern mitzuteilen, dass es sicher ist, den Algorithmus zu verwenden. Es ist auch besser, wenn Überschriften in nicht unterstützten Browsern auf eine <h1> zurückfallen, als auf eine <span>.
Wenn Sie dieses <h>-Konzept ausprobieren möchten, gibt es ein Plugin namens hfill. Es ermöglicht Ihnen, <hx>-Überschriften innerhalb von Abschnittselementen zu verschachteln, um die Dokumentgliederung zu erstellen, ohne sich so viele Gedanken über die Überschriftenebenen machen zu müssen. Es gibt eine Demo, die Sie ausprobieren können. Der große Nachteil dieses Plugins ist jedoch, dass der *einzige* Weg, die Überschriftenebenen zu erhöhen, darin besteht, Abschnittselemente ineinander zu verschachteln. Es gibt keine <h1>-größer-als-<h2>-Dynamik in diesem Plugin, weshalb ich diese <h>-Element-Idee nicht mehr mag. Dieser Mangel an Überschriftenhierarchie würde CMS-Rich-Text-Editoren für Kunden viel zu schwierig machen.
Was die Schwierigkeit der Implementierung angeht, wird an der Erstellung einer vereinfachten Spezifikation gearbeitet, die Browserhersteller eher übernehmen werden. Der Dokumentgliederungsalgorithmus ist seit Jahren Teil der HTML-Spezifikationen. Hoffentlich ermöglicht diese vereinfachte Spezifikation, dass der Algorithmus Realität wird.
Obwohl der Algorithmus noch nirgends unterstützt wird, können wir ihn trotzdem im Hinterkopf behalten. Wenn wir ihn im Hinterkopf behalten, profitieren wir von Folgendem:
- Wir machen unsere Websites zukunftssicher, falls der Algorithmus jemals implementiert *wird*.
- Wir können die Benutzererfahrung für Screenreader-Benutzer *deutlich* verbessern.
- Wir verbessern *potenziell* die Suchmaschinenoptimierung (SEO), da Suchmaschinen die Inhalte der Website besser verstehen können.
- Wir können die Benutzererfahrung für Benutzer verbessern, indem wir ihnen native Browserfunktionen ermöglichen, die Abschnittselemente nutzen, wie z. B. den Reader-Modus.
Abschnittsinhalt
Schauen Sie sich dieses Mockup-Layout an, das ich zusammengestellt habe, und überlegen Sie, wie Sie es in Abschnitte unterteilen würden.
So würde ich das Layout in Abschnittselemente unterteilen (nur die durchgezogenen Linien stellen Abschnittselemente dar).
In Bezug auf die HTML-Markierung sieht es so aus:
<body>
<header>
<a href="/" title="Go to home page">
<img src="logo.png" alt="Site logo">
</a>
<nav>
<ul>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
</ul>
</nav>
<form role="search" aria-label="site">
<label>
<span>Search</span>
<input type="search"/>
</label>
<button type="submit">Submit</button>
</form>
</header>
<nav>
<ul>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
</ul>
</nav>
<main>
<article>
<h1>Main article heading</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p>
<h2>Article secondary heading</h2>
<p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p>
<p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p>
</article>
</main>
<aside>
<section>
<h2>Share</h2>
<ul>
<li><a href="#">Facebook</a></li>
<li><a href="#">Twitter</a></li>
<li><a href="#">Email</a></li>
</ul>
</section>
<section>
<h2>Recommended</h2>
<ul>
<li>
<article>
<h3><a href="#">Related article</a></h3>
<p>Article description</p>
</article>
</li>
<li>
<article>
<h3><a href="#">Related article</a></h3>
<p>Article description</p>
</article>
</li>
</ul>
</section>
</aside>
<footer>
<ul>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
</ul>
</footer>
</body>Das <main>-Element
Es gibt ein sehr wichtiges semantisches Element, das ich im obigen Markup verwendet habe und das ich noch nicht behandelt habe, und das ist das <main>-Element. Das <main>-Element repräsentiert den Hauptinhalt der Seite. Es sollte keine Seitenleisten oder Navigationselemente enthalten. Sie dürfen auch nicht mehr als ein <main>-Element auf der Seite haben, es sei denn, alle anderen <main>-Elemente auf der Seite haben ein hidden-Attribut (dies dient SPAs).
Das <main>-Element ist *kein* Abschnittselement. Das bedeutet, es trägt nicht zum Dokumentgliederungsalgorithmus bei und kann kein <header>- oder <footer>-Element als direkten Nachfahren enthalten. Es ist jedoch ein Landmark-Element, sodass Screenreader-Benutzer es recht einfach erreichen können.
Ich bin mir nicht 100% sicher, ob die Verwendung von <article> im <main>-Element, wie ich es oben getan habe, notwendig ist. Semantisch macht es Sinn. Der Hauptinhalt ist in sich geschlossen und rechtfertigt somit die Verwendung des <article>-Elements auf diese Weise. Aus der Perspektive des Dokumentgliederungsalgorithmus hilft das <article>-Element auch der Dokumentstruktur.
Aus usability-Sicht fühlt es sich etwas unnötig an und der Dokumentgliederungsalgorithmus funktioniert im Moment nirgends. Ich werde es weiterhin in meinen Beispielen verwenden, aber ich wäre interessiert, was andere Leute dazu in den Kommentaren sagen.
Sie müssen Ihre Abschnitte kennzeichnen. Hier sind drei Methoden.
Ich werde das Wort „label“ in diesem Artikel oft verwenden. Denken Sie daran, dass ich nicht vom <label>-Element spreche. **Das <label>-Element wird *nicht* verwendet, um Abschnittselemente zu kennzeichnen.**
Abschnittselemente benötigen Labels, damit Screenreader-Benutzer schnell erkennen können, welche Inhalte sich innerhalb dieses besonderen Bereichs der Website befinden. Ich betrachte die Verwendung von Abschnittselementen ohne zugehörige Abschnitts-Labels als Accessibility-Fehler, es sei denn, es ist das einzige seiner Art auf der Seite. Es wird auch empfohlen, dass derselbe Label-Text nicht auf mehreren Abschnittselementen (oder Überschriftenelementen) verwendet wird. Dies macht jeden Abschnitt für Screenreader-Benutzer besser erkennbar, was ihnen hilft, sich leichter auf der Website zurechtzufinden.
Es gibt drei Möglichkeiten, ein Abschnittselement zu kennzeichnen. In den folgenden Beispielen beziehe ich mich auf „Transport“ und „Portabilität“, um zu erklären, wie einfach es ist, den Abschnitt in eine Komponente zu speichern und diese Komponente mehrmals in verschiedenen Kontexten zu verwenden.
Ich gebe in den Beispielen auch Listen mit positiven und negativen Punkten an. In diesen Listen gehe ich davon aus, dass das Abschnitts-Label von Screenreadern gelesen werden kann, aber für sehende Benutzer *verborgen* bleiben soll.
Methode 1: Ein aria-label-Attribut hinzufügen
Dies ist die schnellste und einfachste Möglichkeit, ein Abschnittselement zu kennzeichnen.
<section aria-label="Label for this section">
<p>Content for this section</p>
</section>Das Problem mit der Übersetzung von aria-label
Der Hauptnachteil von aria-label (zum Zeitpunkt der Erstellung dieses Textes) ist, dass die meisten Browser diese Werte nicht für Benutzer übersetzen können, die eine andere Sprache sprechen als Sie. Die Entwickler bei Google haben diesen Fehler in Chrome kürzlich behoben (behoben), aber das ist immer noch ein Problem für alle anderen Browser.
Wenn Ihre Website ein großes internationales Publikum hat oder Sie wissen, dass viele Ihrer Benutzer Ihre Sprache nicht sprechen, sollten Sie die Verwendung dieses Attributs wahrscheinlich vermeiden, bis alle Browser die Übersetzung dieser Eigenschaft unterstützen. Wenn Sie keine solchen Benutzer haben, können Sie ziemlich sicher davon ausgehen, dass die nicht sehenden Benutzer, die Ihre Website besuchen, Ihre Sprache verstehen können – zumindest gut genug, um Ihre Website zu navigieren.
Wenn Sie noch mehr überzeugt werden müssen: Nehmen wir an, Ihre Website hat sehr wenige internationale Benutzer. Das bedeutet, dass Ihre Benutzer generell aus demselben Land stammen wie Sie. Wenn sie aus demselben Land stammen, sprechen sie wahrscheinlich dieselbe Sprache wie Sie, sodass bereits ein ziemlich geringer Prozentsatz Ihrer Benutzer die Muttersprache Ihrer Website nicht versteht. Berücksichtigen Sie nun, dass aria-label nur Benutzer von Screenreadern betrifft. Das ist jetzt nur noch ein Bruchteil eines bereits kleinen Prozentsatzes Ihrer Benutzer, der von dem Problem betroffen sein wird. Und nun bedenken Sie, dass Chrome (der mit Abstand beliebteste Browser der Welt) die Übersetzung des aria-label-Attributs jetzt unterstützt. Der Benutzer muss *auch* keine aktuelle Version von Chrome als Browser verwenden, damit das Übersetzungsproblem ein Problem darstellt. Wenn Sie all das zusammenrechnen, ist es höchstwahrscheinlich, dass Sie *keine* Benutzer haben werden, die sowohl die aria-label-Attribute wahrnehmen können als auch unfähig sind zu verstehen, was sie sagen. Das gibt mir das Gefühl, dass die schlechte mehrsprachige Unterstützung in aria-label nicht wirklich so wichtig ist, *es sei denn*, Sie haben ein großes internationales Publikum oder viele Benutzer, von denen Sie wissen, dass sie Ihre Sprache nicht sprechen.
Vorteile
- Sehr schnell und einfach zu implementieren.
- Beeinflusst die Überschriftenstruktur nicht.
- Macht Komponenten leicht transportierbar.
- Ist für sehende Benutzer unsichtbar.
Nachteile
- Wird in Nicht-Chrome-Browsern nicht in andere Sprachen übersetzt (zum Zeitpunkt der Erstellung dieses Textes).
- Wird oft von Tools zur Analyse der Seitenstruktur nicht unterstützt.
- Es kann zu Verwirrung kommen, wenn man nicht weiß, auf welcher Ebene sich andere Überschriften innerhalb des Abschnitts befinden sollten.
Methode 2: Fügen Sie ein <h#-Element hinzu
Mit <h#> meine ich <h1>, <h2>, <h3>, <h4>, <h5> oder <h6>, je nachdem, was sinnvoll ist. Das Hinzufügen einer Überschrift zu einem Gliederungselement ist eine schnelle Möglichkeit, es zu beschriften.
Platzierung der Überschrift
Die Überschrift kann entweder direkt im Gliederungselement platziert werden, wie hier
<section>
<h1>Heading</h1>
<p>content</p>
</section>...oder im <header>-Element platziert werden
<section>
<header>
<h1>Heading</h1>
<p>I'm a byline</p>
</header>
<p>Content</p>
</section>Sie können auch beliebig viele <div>-Wrapper-Elemente zwischen dem Gliederungselement und der Überschrift einfügen.
<!-- This is perfectly fine -->
<section>
<div>
<header>
<div>
<h1>Heading</h1>
<p>I'm a byline</p>
</div>
</header>
<p>Content</p>
</div>
</section>Nur eine Überschrift der höchsten Ebene pro Gliederungselement
Es sollte wirklich nur eine Überschrift der höchsten Ebene in einem Gliederungselement geben. Die Spezifikation besagt, dass der Browser, wenn es mehrere Top-Level-Überschriften oder Überschriften einer höheren Ebene als die erste gibt, den vorherigen Gliederungselement schließen und ein neues des gleichen Typs beginnen soll.
Das erste Element des Überschrifteninhalts in einem Element mit Gliederungsinhalt stellt die Überschrift für diesen expliziten Abschnitt dar. Nachfolgende Überschriften gleicher oder höherer Rangstufe beginnen neue implizite Unterabschnitte, die Teil des übergeordneten Abschnitts des vorherigen Abschnitts sind. Nachfolgende Überschriften niedrigerer Rangstufe beginnen neue implizite Unterabschnitte, die Teil des vorherigen sind. In beiden Fällen stellt das Element die Überschrift des impliziten Abschnitts dar.
—HTML 5.3, Überschriften und Abschnitte
In der Realität verwendet der Browser die erste Überschrift als Abschnittsbeschriftung, aber diese impliziten Abschnitte werden nie erstellt. Er kündigt die Überschrift einfach an, wie er sie vorfindet. Das ist nicht katastrophal schlecht, aber es ist etwas verwirrend.
<!-- Avoid this: -->
<section>
<h2>Heading level two labeling a section</h2>
<p>Content</p>
<!-- Don't use same level or higher headings as the one labeling the section -->
<h2>This is also a heading level two</h2>
<p>Content</p>
</section>
<!-- Do this instead: -->
<div>
<section>
<h2>Heading level two labeling a section</h2>
<p>Content</p>
</section>
<section>
<h2>Heading level two labeling a different section</h2>
<p>Content</p>
</section>
</div>Die Überschrift steht *immer* zuerst
Wenn ein Gliederungselement ein <h#-Element enthält, sollte diese Top-Level-Überschrift immer der erste Inhalt dieses Gliederungselements sein. Andernfalls gilt dies als Barrierenfreiheit-Fehler.
Wenn Sie feststellen, dass Sie Inhalt vor Ihrer Überschrift platzieren müssen (z. B. ein Bild), können Sie Flexbox verwenden, um die visuelle Reihenfolge neu anzuordnen. Dadurch sieht es so aus, als ob das Bild vor der Überschrift kommt, aber im Markup kommt die Überschrift vor dem Bild. Es gibt einen Fehler in IE, der manchmal dazu führt, dass Text in einem Element mit flex-direction: column; nicht umbricht. Diesen Fehler können Sie umgehen, indem Sie dem Flex-Child-Element eine maximale Breite zuweisen.
<!-- Don't do this -->
<section>
<img src="image.jpg" alt="Don't place content or images before the heading" />
<h2>Headings should always come first</h2>
<p>Place regular content after the heading</p>
</section>
<!-- Do this instead -->
<section class="example">
<h2>Headings should always come first</h2>
<img src="image.jpg" alt="Don't place content or images before the heading" />
<p>Place regular content after the heading</p>
</section>
<style>
.example {
display: flex;
flex-direction: column;
}
.example img {
order: -1;
}
</style>Beachten Sie, dass die Neuanordnung der visuellen Reihenfolge zur Erfüllung der WCAG-Richtlinie 1.3.2: Sinnvolle Reihenfolge direkt mit der WCAG-Richtlinie 2.4.3: Fokusreihenfolge kollidieren kann. Wenn dieses Bild beispielsweise ein Link zu einem Artikel ist und die Überschrift, über der es platziert wird, *ebenfalls* ein Link zum Artikel ist, bricht die Platzierung der Überschrift zuerst die Fokusreihenfolge. Die Platzierung des Bildes zuerst bricht die sinnvolle Reihenfolge.
In Situationen wie diesen, in denen diese beiden Richtlinien miteinander kollidieren, ist meine Meinung, dass die 1.3.2: Sinnvolle Reihenfolge die wichtigere Richtlinie ist, der man folgen sollte, wenn man den Konflikt nicht auf irgendeine Weise lösen kann. Das Brechen der Fokusreihenfolge führt dazu, dass der Benutzer einen Moment der Verunsicherung erlebt, während er durch den Inhalt tabbt und der Fokus an eine unerwartete Stelle gelangt. Das Nichtbefolgen einer sinnvollen Reihenfolge führt zu einem verwirrten Benutzer, der sich über die Beziehung zwischen verschiedenen Inhaltsstücken unsicher ist.
Visuell versteckte Abschnittsbeschriftungen aus Überschriften erstellen
Überschriften sind standardmäßig für sehende Benutzer sichtbar. Das macht sie sehr nützlich, wenn Sie möchten, dass die Überschrift sichtbar ist. Oftmals möchten wir die Beschriftung für unser Gliederungselement jedoch nicht sichtbar haben. Um unsere sehenden Benutzer daran zu hindern, die Beschriftung zu sehen, müssen wir etwas CSS verwenden.
<style>
.visually-hidden {
position: absolute;
opacity: 0;
pointer-events: none;
}
</style>
<section>
<h1 class="visually-hidden">Heading</h1>
<p>content</p>
</section>Überschriften werden von Tools zur Struktur-Analyse gut unterstützt
Überschriften haben auch einen riesigen Vorteil für Entwickler, da jedes Tool zur Analyse der Seitenstruktur, das Sie finden können, Unterstützung dafür bietet. Dies macht Überschriftenstrukturen leicht zu testen und zu debuggen. Die anderen beiden Methoden zur Abschnittsbeschriftung haben eine sehr schlechte Unterstützung in Test-Tools. Nicht einmal der offizielle W3C-Validator unterstützt die Alternativen derzeit. Ich habe ein Problem gepostet, um dies zu beheben – bitte erwägen Sie, das Problem zu beheben, wenn Sie gut in Java programmieren können.
Vorteile
- Schnell zu implementieren.
- Erscheint zuverlässig in Tools zur Analyse der Seitenstruktur und macht es einfach, zu testen und zu debuggen.
- Alle Browser werden den Text in andere Sprachen übersetzen.
- Keine Verwirrung darüber, auf welcher Ebene sich andere Überschriften innerhalb des Abschnitts befinden sollten.
Nachteile
- Beeinflusst die Dokumentüberschriftenstruktur.
- Es muss sichergestellt werden, dass die Überschrift vor der Verwendung auf der richtigen Ebene liegt.
- Standardmäßig für den Benutzer sichtbar.
- Erfordert CSS, um die Überschrift für visuelle Benutzer auszublenden.
- Kann Komponenten aufgrund von Anforderungen an die Überschriftenstruktur weniger portabel machen.
Methode 3: Verwenden Sie ein aria-labelledby-Attribut
So sieht die Erstellung einer versteckten Abschnittsbeschriftung mit aria-labelledby aus.
<section aria-labelledby="unique-id">
<div hidden id="unique-id">Label for this section</div>
<p>Content for this section</p>
</section>Beschriftungen können ohne CSS versteckt werden
Beachten Sie, dass ich im Beispiel das hidden-Attribut verwendet habe, um das Div zu verstecken, anstatt einer visually-hidden-CSS-Klasse. aria-labelledby kann Text vorlesen, der normalerweise für Screenreader-Benutzer verborgen ist. Dies hat den zusätzlichen Vorteil, dass der Text vom Screenreader nicht zweimal vorgelesen wird. Verwenden Sie jedoch nicht das aria-hidden-Attribut. Screenreader finden die Beschriftung nicht. Nun, NVDA konnte die Beschriftung beim Testen nicht finden. Ich bin mir bei anderen Screenreadern nicht sicher.
Großes Portabilitätsproblem
aria-labelledby ist von allen Methoden zur Abschnittsbeschriftung am schwierigsten zu verwenden. Der Hauptaspekt, der die Verwendung erschwert, ist, dass das aria-labelledby-Attribut auf IDs basiert. Dinge werden immer komplizierter, wenn IDs im Spiel sind. Dies liegt daran, dass Webseiten zu keinem Zeitpunkt nur eine einzige Instanz einer ID auf der Seite haben dürfen. Dies erschwert die Portabilität von Komponenten.
Aufgrund dieses Portabilitätsproblems würde ich diese Option wirklich nur empfehlen, wenn Sie ein mehrsprachiges Publikum unterstützen müssen und sich nicht mit der Überschriftenstruktur auseinandersetzen möchten.
Keine Notwendigkeit, die Beschriftung in die Nähe des Gliederungselements zu platzieren
Sie müssen das Element mit dem Beschriftungstext nicht innerhalb oder in der Nähe des Gliederungselements platzieren, das es beschriftet. Der Text für die Beschriftung kann an einem völlig anderen Ort als das Gliederungselement platziert werden. Dies ist dank der ID, die die beiden Elemente miteinander verbindet. Ich sage nicht unbedingt, dass es eine gute Idee ist, dies zu tun, aber es ist ein Merkmal von aria-labelledby, dessen Sie sich bewusst sein sollten.
<div hidden id="unique-id">Label for this section</div>
<!-- 1,000 lines of other HTML -->
<section aria-labelledby="unique-id">
<p>Content for this section</p>
</section>Nicht-Überschriften-Elemente in Abschnittsbeschriftungen umwandeln
Es gibt noch einen weiteren wichtigen Grund, warum Sie aria-labelledby verwenden möchten. Wenn Sie ein sichtbares Nicht-Überschriften-Element auf der Seite haben, das Sie als Beschriftung für einen Abschnitt verwenden möchten, ist aria-labelledby dafür perfekt geeignet. Ein <legend>-Element innerhalb eines <fieldset> ist ein gängiger Anwendungsfall dafür. Das bedeutet nicht, dass Sie Feldsets in Gliederungselemente einschließen *müssen*. Ich weise nur darauf hin, falls Sie einen Bedarf dafür erkennen.
<section aria-labelledby="section_label">
<fieldset>
<legend id="section_label">
I am both the fieldset legend and the section label
</legend>
<!-- Form fields go here -->
</fieldset>
</section>Vorteile
- Alle Browser werden den Text in andere Sprachen übersetzen.
- Kann ein Nicht-Überschriften-Element als Abschnittsbeschriftung zuweisen.
- Der Text für die Beschriftung muss nicht in der Nähe des zu beschriftenden Abschnitts platziert werden.
Nachteile
- Erfordert die Verwendung von IDs, um zu funktionieren.
- Schwer zu transportieren.
- Es kann potenziell schwierig sein, herauszufinden, wo der Text für die Beschriftung in Ihrem Quellcode gespeichert ist.
- Text ist standardmäßig sichtbar, es sei denn, ein
hidden-Attribut wird verwendet. - Text könnte von einigen Screenreadern zweimal vorgelesen werden, wenn der Text nicht verborgen ist.
- Es kann zu Verwirrung kommen, wenn man nicht weiß, auf welcher Ebene sich andere Überschriften innerhalb des Abschnitts befinden sollten.
Verwenden Sie jeweils nur eine Methode
Verwenden Sie nicht gleichzeitig ein <h#-Element, ein aria-label und/oder ein aria-labelledby-Attribut auf demselben Gliederungselement. Verwenden Sie für jedes Gliederungselement immer nur eine Beschriftungsmethode. Die Verwendung mehrerer Methoden ist sehr verwirrend und führt dazu, dass die Beschriftung überschrieben wird. Es ist ein bisschen so, als würde man dieselbe Eigenschaft zweimal in CSS deklarieren. Ich war mir nicht sicher, wie ein Screenreader dies tatsächlich handhaben würde, also habe ich die lächerlichste <section> aller Zeiten erstellt und sie durch NVDA laufen lassen.
<!-- Don't do this -->
<section aria-label="Is this the section label?" aria-labelledby="is_this_the_label">
<h1>Or is this the section label?</h1>
<p id="is_this_the_label">Only ever use one at a time.</p>
</section>Dies ist die Prioritätsreihenfolge, die NVDA den verschiedenen Beschriftungsmethoden von der stärksten zur schwächsten gab
aria-labelledbyaria-label<h#>
Abschnittsbeschriftungen zu unserem Beispiel-Layout hinzufügen
Lange Zeit verwendete ich Überschriften als einzige Möglichkeit, Abschnitte zu beschriften. Die schlechte mehrsprachige Unterstützung durch aria-label machte mir Angst; und aria-labelledby war viel zu umständlich, um meine primäre Beschriftungsmethode zu sein. Wir stoßen jedoch auf ein Problem, wenn wir nur Überschriften zur Beschriftung von Abschnitten verwenden. Ich zeige Ihnen, was ich meine.
<style>
.visually-hidden {
position: absolute;
opacity: 0;
pointer-events: none;
}
</style>
<body>
<header>
<a href="/" title="Go to home page">
<img src="logo.png" alt="Site logo">
</a>
<nav>
<h2 class="visually-hidden">Primary</h2>
<ul>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
</ul>
</nav>
<form role="search" aria-label="site">
<label>
<span>Search</span>
<input type="search"/>
</label>
<button type="submit">Submit</button>
</form>
</header>
<nav>
<h2 class="visually-hidden">Secondary</h2>
<ul>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
</ul>
</nav>
<main>
<article>
<h1>Main article heading</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p>
<h2>Article secondary heading</h2>
<p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p>
<p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p>
</article>
</main>
<aside>
<h2 class="visually-hidden">Sidebar</h2>
<section>
<h3>Share</h3>
<ul>
<li><a href="#">Facebook</a></li>
<li><a href="#">Twitter</a></li>
<li><a href="#">Email</a></li>
</ul>
</section>
<section>
<h3>Recommended</h3>
<ul>
<li>
<article>
<h4><a href="#">Related article</a></h4>
<p>Article description</p>
</article>
</li>
<li>
<article>
<h4><a href="#">Related article</a></h4>
<p>Article description</p>
</article>
</li>
</ul>
</section>
</aside>
<footer>
<ul>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
</ul>
</footer>
</body>Wenn wir uns unsere Überschriftenstruktur jetzt ansehen, wird sie so aussehen (kursiv = visuell versteckt; fett = sichtbar)
<h2>Haupt-Navigationsbereich<h2>Sekundärer Navigationsbereich
Beachten Sie, dass unsere <h1>-Überschrift nicht am Anfang der Liste steht? Es fühlt sich wirklich nicht richtig an, zwei <h2>-Überschriften über der <h1>-Überschrift zu haben.
Diese Form der Überschriftenstruktur ist tatsächlich vom W3C erlaubt und zählt daher nicht als Barrierenfreiheitsfehler. Ich denke jedoch immer noch, dass dies eine ziemlich schlechte Benutzererfahrung für Screenreader-Benutzer ist. Es ist keine logische Progression von <h1> zu <h2>. Es ist am sinnvollsten, wenn die erste Überschrift, auf die Sie auf der Seite stoßen, eine <h1> ist, dann zu <h2> und so weiter übergehen.
Die Überschrift 1 zur ersten Überschrift machen
Sehr lange Zeit dachte ich, der absolut beste Weg, dieses Dilemma zu lösen, sei, die <h1> visuell zu verstecken und sie zum allerersten Inhalt der Seite zu machen. Das, was alle für die <h1> halten, wird tatsächlich zu einer <h2>.
So sieht diese Art von Struktur in der Praxis aus
<style>
.visually-hidden {
position: absolute;
opacity: 0;
pointer-events: none;
}
</style>
<!-- Don't do this -->
<body>
<header>
<h1 class="visually-hidden">Main article heading</h1>
<a href="/" title="Go to home page">
<img src="logo.png" alt="Site logo">
</a>
<nav>
<h2 class="visually-hidden">Primary</h2>
<ul>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
</ul>
</nav>
<form role="search" aria-label="site">
<label>
<span>Search</span>
<input type="search"/>
</label>
<button type="submit">Submit</button>
</form>
</header>
<nav>
<h2 class="visually-hidden">Secondary</h2>
<ul>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
</ul>
</nav>
<main>
<article>
<h2><span class="visually-hidden">Body:</span> Main article heading</h2>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p>
<h3>Article secondary heading</h3>
<p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p>
<p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p>
</article>
</main>
<aside>
<h2 class="visually-hidden">Sidebar</h2>
<section>
<h3>Share</h3>
<ul>
<li><a href="#">Facebook</a></li>
<li><a href="#">Twitter</a></li>
<li><a href="#">Email</a></li>
</ul>
</section>
<section>
<h3>Recommended</h3>
<ul>
<li>
<article>
<h4><a href="#">Related article</a></h4>
<p>Article description</p>
</article>
</li>
<li>
<article>
<h4><a href="#">Related article</a></h4>
<p>Article description</p>
</article>
</li>
</ul>
</section>
</aside>
<footer>
<ul>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
</ul>
</footer>
</body>Jetzt sieht unsere Dokumentenstruktur so aus (kursiv = visuell versteckt; fett = sichtbar)
<h1>Überschrift des Hauptartikels<h2>Haupt-Navigationsbereich<h2>Sekundärer Navigationsbereich<h2>Text: Überschrift des Hauptartikels<h3>Sekundäre Überschrift des Artikels
<h2>Seitenleiste<h3>Teilen<h3>Empfohlen<h4>Verwandter Artikel<h4>Verwandter Artikel
Das fühlt sich größtenteils richtig an. Die <h1> ist oben und alles fließt perfekt nach unten mit den <h2>-Elementen, die Hauptseitenbereiche darstellen, und den <h3>-Elementen, die Unterabschnitte darstellen. Der hauptsächlich unangenehme Teil ist, dass die tatsächliche <h1> und das, was jeder für eine <h1> hält, im Wesentlichen Duplikate voneinander sind.
Erst als ich die erste Version dieses Artikels aufgeschrieben hatte, ihn fast veröffentlicht hatte und er dann über den Haufen geworfen wurde, begann ich anders zu denken. Ich sprach mit zwei Beratern für Barrierefreiheit über das Problem. Beide stimmten zu, dass dies zwar eine clevere technische Lösung für das Problem sei, aber die Erfahrung der Personen, denen es zu helfen versucht, beeinträchtigt.
Das Problem ist, dass, wenn jede andere Website der Welt die <h1>-Überschrift am Anfang des Hauptinhaltsbereichs platziert, das ist, was Screenreader-Benutzer erwarten. Wenn Ihre Website die besondere Schneeflocke ist, die Dinge anders macht, verwirrt dies Screenreader-Benutzer und es dauert eine Weile, bis sie herausgefunden haben, wie Ihre Überschriftenstruktur funktionieren soll.
Vor diesem Hintergrund habe ich mich für eine neue Methode zur Beschriftung von Gliederungselementen entschieden. Im Grunde genommen verwende ich jetzt überall dort, wo ich eine visuell versteckte Überschrift verwendet hätte, stattdessen ein aria-label-Attribut. Wenn die Website ein großes Publikum von Nicht-Muttersprachlern hat, würde ich stattdessen aria-labelledby anstelle von aria-label verwenden.
Bedenken bezüglich der vereinfachten Outline-Algorithmus-Spezifikation
Wenn der vereinfachte Outline-Algorithmus in seiner jetzigen Form genehmigt wird, müssen wir unsere Seiten tatsächlich wie im Beispiel mit der visuell versteckten <h1> strukturieren (ersetzen Sie einfach die Elemente <h2>, <h3> und <h4> durch <h1>-Elemente).
Die ursprüngliche Spezifikation zielte darauf ab, die Gliederung durch die Beschriftung von Gliederungselementen zu erstellen. Diese neue Spezifikation zielt eindeutig darauf ab, die Gliederung ausschließlich durch Überschriftenebenen zu erstellen. Der Algorithmus berechnet im Grunde die Überschriftenebene basierend auf der Anzahl der übergeordneten Gliederungselemente eines Headers *plus* dem Basiswert der Überschriftenebene des Headers. Es ist in der Spezifikation etwas nuancierter, aber das ist im Allgemeinen die Idee, wie es vereinfacht ausgedrückt funktioniert.
Der vereinfachte Algorithmus erwähnt derzeit weder aria-label noch aria-labelledby. Das bedeutet, dass diese Attribute nicht zur Dokumentengliederung beitragen werden, die der vereinfachte Algorithmus generiert. Bei fehlender aria-label-Unterstützung könnte die Beschriftung eines Gliederungselements mit aria-label leicht zu übersprungenen Überschriftenebenen tiefer im Baum führen.
<!-- Simplified algorithm skipped heading levels issue -->
<body>
<main>
<h1>Primary heading for the page</h1> <!-- interpreted as <h1> -->
<p>This is some content</p>
</main>
<!-- sectioning elements increase heading levels -->
<aside aria-label="Side bar"> <!-- aria-label does not contribute -->
<section>
<h1>Share</h1> <!-- interpreted as <h3> -->
<ul>
<!-- list of social media links -->
</ul>
</section>
<section>
<h1>Recommended articles:</h1> <!-- interpreted as <h3> -->
<ul>
<!-- list of recommended articles -->
</ul>
</section>
</aside>
</body>Die vereinfachte Spezifikation betrachtet es auch als ungültig,
- keine Überschriftenebene 1 am Stamm des Dokuments zu haben (was problematisch ist, wenn Sie den Hauptinhalt in einem
<article>-Element platzieren); und - keine Überschriftenebene 1 als erste Überschrift in einem Dokument zu haben (was größtenteils in Ordnung ist, es sei denn, Sie müssen eine Überschrift im Website-Header oder in einer linken Seitenleiste verwenden).
Es erlaubt jedoch, dass es mehr als eine Überschrift der Stufe 1 am Stamm des Dokuments gibt, was ich sehr seltsam und schlecht für die Barrierefreiheit finde (obwohl meine Bedenken diesbezüglich ignoriert zu werden scheinen).
Ich habe die Probleme, die ich mit der Spezifikation habe, geäußert und mögliche Lösungen in der GitHub-Diskussion vorgeschlagen.
Vorerst ist es immer noch am besten, aria-label- und/oder aria-labelledby-Attribute anstelle von visuell versteckten Überschriften zu verwenden, um Gliederungselemente zu beschriften. Es lohnt sich nicht, die Erfahrung unserer heutigen Benutzer zu mindern, nur um einer Spezifikation willen, die noch nicht einmal fertiggestellt oder akzeptiert ist.
Verwendung von aria bei den Gliederungselementen des Beispiel-Layouts
Verwendung von aria-label
So sieht die HTML-Struktur aus, wenn wir aria-label-Attribute verwenden, um die Gliederungselemente zu beschriften.
<body>
<header>
<a href="/" title="Go to home page">
<img src="logo.png" alt="Site logo">
</a>
<nav aria-label="Primary">
<ul>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
</ul>
</nav>
<form role="search" aria-label="site">
<label>
<span>Search</span>
<input type="search"/>
</label>
<button type="submit">Submit</button>
</form>
</header>
<nav aria-label="Secondary">
<ul>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
</ul>
</nav>
<main>
<article>
<h1>Main article heading</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p>
<h2>Article secondary heading</h2>
<p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p>
<p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p>
</article>
</main>
<aside aria-label="Sidebar">
<section>
<h2>Share</h2>
<ul>
<li><a href="#">Facebook</a></li>
<li><a href="#">Twitter</a></li>
<li><a href="#">Email</a></li>
</ul>
</section>
<section>
<h2>Recommended</h2>
<ul>
<li>
<article>
<h3><a href="#">Related article</a></h3>
<p>Article description</p>
</article>
</li>
<li>
<article>
<h3><a href="#">Related article</a></h3>
<p>Article description</p>
</article>
</li>
</ul>
</section>
</aside>
<footer>
<ul>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
</ul>
</footer>
</body>Hier ist das Layout in CodePen, falls Sie damit herumspielen möchten (sorry, mobile Nutzer, es ist nicht mobilfreundlich).
Verwendung von aria-labelledby
Aber nehmen wir an, Sie haben ein riesiges internationales Publikum, das alle möglichen Sprachen spricht. In diesem Fall ist es besser, das aria-labelledby-Attribut zu verwenden. So würde das aussehen.
<body>
<header>
<a href="/" title="Go to home page">
<img src="logo.png" alt="Site logo">
</a>
<nav aria-labelledby="primary-nav-label">
<div id="primary-nav-label" hidden>Primary</div>
<ul>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
<li><a href="#">Primary nav</a></li>
</ul>
</nav>
<form role="search" aria-labelledby="search-label">
<div id="search-label" hidden>Site</div>
<label>
<span>Search</span>
<input type="search"/>
</label>
<button type="submit">Submit</button>
</form>
</header>
<nav aria-labelledby="secondary-nav-label">
<div id="secondary-nav-label" hidden>Secondary</div>
<ul>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
<li><a href="#">Secondary nav</a></li>
</ul>
</nav>
<main>
<article>
<h1>Main article heading</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quae sunt igitur communia vobis cum antiquis, iis sic utamur quasi concessis; Nihil acciderat ei, quod nollet, nisi quod anulum, quo delectabatur, in mari abiecerat. Unum est sine dolore esse, alterum cum voluptate. Laboro autem non sine causa; Theophrasti igitur, inquit, tibi liber ille placet de beata vita? Nihil opus est exemplis hoc facere longius. Duo Reges constructio interrete. Graecum enim hunc versum nostis omnes Suavis laborum est praeteritorum memoria. Haec et tu ita posuisti, et verba vestra sunt.</p>
<h2>Article secondary heading</h2>
<p>Nos commodius agimus. A mene tu? Tantum dico, magis fuisse vestrum agere Epicuri diem natalem, quam illius testamento cavere ut ageretur. Tenesne igitur, inquam, Hieronymus Rhodius quid dicat esse summum bonum, quo putet omnia referri oportere? Nihilo beatiorem esse Metellum quam Regulum. Sed quanta sit alias, nunc tantum possitne esse tanta. Philosophi autem in suis lectulis plerumque moriuntur. Esse enim, nisi eris, non potes.</p>
<p>Sunt enim quasi prima elementa naturae, quibus ubertas orationis adhiberi vix potest, nec equidem eam cogito consectari. Id Sextilius factum negabat. Quorum sine causa fieri nihil putandum est. Quae autem natura suae primae institutionis oblita est?</p>
</article>
</main>
<aside aria-labelledby="sidebar-label">
<div id="sidebar-label" hidden>Sidebar</div>
<section>
<h2>Share</h2>
<ul>
<li><a href="#">Facebook</a></li>
<li><a href="#">Twitter</a></li>
<li><a href="#">Email</a></li>
</ul>
</section>
<section>
<h2>Recommended</h2>
<ul>
<li>
<article>
<h3><a href="#">Related article</a></h3>
<p>Article description</p>
</article>
</li>
<li>
<article>
<h3><a href="#">Related article</a></h3>
<p>Article description</p>
</article>
</li>
</ul>
</section>
</aside>
<footer>
<ul>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
<li><a href="#">Footer link</a></li>
</ul>
</footer>
</body>Ergebnisse der Verwendung von aria
Die Überschriftenstruktur für die Website sieht zu diesem Zeitpunkt so aus
<h1>Hauptartikelüberschrift<h2>Sekundäre Artikelüberschrift<h2>Teilen<h2>Empfohlen<h3>Verwandter Artikel<h3>Verwandter Artikel
Die Dokumentengliederung (unter der Annahme, dass der ursprüngliche Outline-Algorithmus implementiert ist) sieht so aus
<body>Dokument<nav>Primär<nav>Sekundär<article>Hauptartikelüberschrift<section (impliziert)>Sekundäre Artikelüberschrift
<aside>Seitenleiste<section>Teilen<section>Empfohlen<article>Verwandter Artikel<article>Verwandter Artikel
Sie denken vielleicht, dass die Dokumentengliederung etwas karg aussieht. Sollten Dinge wie die Kopfzeile und die Fußzeile und die Suche nicht auch darin angekündigt werden? Beachten Sie, dass dies nur das Explizite ist. Wir erhalten viele implizite Informationen, die dem Benutzer kostenlos zur Verfügung gestellt werden, indem wir korrekte HTML-Elemente in einer guten Struktur verwenden. Dies ist eine vereinfachte Version, wie ein Screenreader-Benutzer die Website erleben könnte
- [Text aus dem
<title>-Element verwendet]- Banner-Landmark
- Link, Website-Logo [(bei Fokus) „zur Startseite gehen“]
- „Primäre“ Navigations-Landmark
- [Navigationslinks-Liste]
- „Site“-Such-Landmark
- „Secondary“-Navigations-Landmark
- [Navigationslinks-Liste]
- Haupt-Landmark
- „Hauptartikelüberschrift“-Artikel-Landmark, Überschriftenebene 1
- [Inhalt]
- Überschriftenebene 2, „Sekundäre Artikelüberschrift“
- [Inhalt]
- „Hauptartikelüberschrift“-Artikel-Landmark, Überschriftenebene 1
- „Sidebar“-komplementäres Landmark
- „Teilen“-Region-Landmark, Überschriftenebene 2
- [Liste der Teilen-Links]
- „Empfohlen“-Region-Landmark, Überschriftenebene 2
- Liste mit 2 Einträgen
- Eintrag, „Verwandter Artikel“-Artikel-Landmark, Überschriftenebene 3
- [Inhalt]
- Eintrag, „Verwandter Artikel“-Artikel-Landmark, Überschriftenebene 3
- [Inhalt]
- Eintrag, „Verwandter Artikel“-Artikel-Landmark, Überschriftenebene 3
- Liste mit 2 Einträgen
- „Teilen“-Region-Landmark, Überschriftenebene 2
- Inhaltsinfo-Landmark
- [Liste der Fußzeilen-Links]
- Banner-Landmark
Wie Sie sehen können, wird die Seitenstruktur für Screenreader-Benutzer sehr klar und verständlich, wenn man all die zusätzlichen impliziten Informationen berücksichtigt, die man aus einer guten HTML-Struktur erhält.
Auch wenn kein Browser den Dokumentenstruktur-Algorithmus unterstützt, lohnt es sich dennoch, etwas Aufwand in die Überlegung der Struktur zu stecken. Screenreader teilen Benutzern immer noch mit, welche Art von Abschnitt etwas ist, wo Abschnitte beginnen und (manchmal) enden (abhängig vom Screenreader) und wie das Abschnittsetikett lautet. Das bedeutet, dass Ihre Bemühungen um eine gute Dokumentenstruktur nicht umsonst sind.
Diese Art von Struktur bietet mehrere Vorteile
- Die Seite ist zu 100 % mit dem Dokumentenstruktur-Algorithmus kompatibel, was sie zukunftssicher macht, falls der Algorithmus jemals in einem echten Browser implementiert wird.
- Die Überschriftenstruktur ist vollständig logisch.
- Screenreader-Benutzer, die über Überschriften navigieren, können schnell zu wichtigen Informationen springen.
- Screenreader-Benutzer, die über Landmarks navigieren, haben viele nützliche Landmarks, um sich auf der Seite zu bewegen.
- Screenreader-Benutzer können schnell verstehen, was jeder Abschnitt enthält, ohne den gesamten Inhalt darin lesen zu müssen.
- Inhalte werden in semantische Abschnitte gruppiert, sodass Screenreader-Benutzer nicht verwirrt werden, wenn sie einen Abschnitt verlassen und in einen anderen eintreten.
- Suchmaschinen können besser verstehen, welche Informationen jeder Abschnitt enthält, was möglicherweise die SEO verbessert.
- Sehende Benutzer können native Browserfunktionen wie den Lesemodus nutzen.
Was passiert, wenn Sie <h7> benötigen?
Es gibt noch einen weiteren Stolperstein bei der Beschriftung von Abschnittselementen, den ich noch nicht angesprochen habe. Nehmen wir an, Sie haben irgendwie alle sechs nativen Überschriftenebenen aufgebraucht und benötigen nun eine weitere. Was tun Sie?
Sie könnten die aria-labelledby-Technik verwenden, wenn es nur darum geht, einen Abschnitt zu beschriften. Nehmen wir an, Sie möchten wirklich, dass diese Überschrift in der Überschriftenstruktur erscheint, oder vielleicht möchten Sie einfach IDs so weit wie möglich vermeiden. Was auch immer der Grund ist, Sie benötigen ein <h7>-Element, aber <h7> existiert nicht.
Hier kommt das aria-level-Attribut ins Spiel. Das aria-level-Attribut definiert die Überschriftenebene für Elemente, auf die role="heading" angewendet wird. So empfiehlt die W3C die Erstellung eines <h7>-Elements.
<div role="heading" aria-level="7">This is a valid heading level 7 element</div>
Nicht alle Screenreader unterstützen diese Syntax. Ich weiß, dass JAWS diese wie <h2>-Elemente behandelt und nicht wie <h7>-Elemente. Wenn Sie von Screenreadern wissen, bei denen dies nicht funktioniert, melden Sie bitte den Fehler dem Entwickler des Screenreaders und hinterlassen Sie auch einen Kommentar unten.
Wenn ich zu einem <h7> greifen muss, verwende ich oft die implizite role="heading" eines <h6>-Elements. Das aria-level-Attribut überschreibt die implizite „6“-Ebene des <h6>-Elements. Dies wird von der W3C zwar nicht gerade unterstützt. Es ist sauberer und ermöglicht es der Überschrift, weiterhin in Tools zur Überprüfung von Dokumentenstrukturen und Überschriftenstrukturen angezeigt zu werden (obwohl sie normalerweise als <h6>- oder <h2>-Ebene angezeigt werden, nicht als <h7>-Ebene).
<h6 aria-level="7">This is also a valid heading level 7 element</h6>
Durch die Verwendung von aria-level haben Sie jetzt Zugriff auf eine unendliche Anzahl von Überschriftenebenen!
Hat Ihre Website eine gute Struktur?
Nachdem Sie nun wissen, wie man eine ordnungsgemäße HTML-Struktur erstellt, können Sie das Gelernte auf Ihre Website anwenden?
Ich habe eine ziemlich gute Browsererweiterung namens „Headings Map“ gefunden, die sowohl für Chrome als auch für Firefox verfügbar ist. Diese Erweiterung ermöglicht es Ihnen, sowohl eine flache Darstellung der Überschriftenstruktur Ihrer Website (d. h. wie alle Browser derzeit die Überschriftenstruktur lesen) als auch die Dokumentenstruktur in einem Browser, der den Dokumentenstruktur-Algorithmus unterstützt (d. h. wie ein theoretisch zukünftiger Browser, der den Struktur-Algorithmus unterstützt, die Seitenstruktur präsentieren würde), einfach zu sehen. Die HTML5-Strukturansicht muss zuerst im Einstellungsmenü aktiviert werden. Dies soll verhindern, dass Benutzer in die Irre geführt werden und denken, sie könnten den Struktur-Algorithmus auf Produktionswebsites anwenden.
Headings Map unterstützt derzeit nicht die Attribute aria-label und aria-labelledby für Abschnittselemente im HTML5-Struktur-Tab. Ich habe mit dem Entwickler gesprochen und er arbeitet daran, dieses Problem zu beheben. Wenn Sie ein gutes Werkzeug zur Überprüfung der Dokumentenstruktur kennen, das aria-label und aria-labelledby bereits berücksichtigt, teilen Sie bitte einen Link dazu in den Kommentaren.
Sobald Sie ein gutes Werkzeug zur Überprüfung der Dokumentenstruktur haben, überprüfen Sie, ob sowohl die Überschriftenstruktur als auch die Dokumentenstruktur eine logische Reihenfolge mit fehlenden Überschriften oder fehlenden Abschnittsetiketten anzeigen.
Laden Sie einen Screenreader herunter und verwenden Sie ihn
Der beste Weg, die impliziten Semantiken zu testen, die Sie aus der Verwendung von korrektem HTML erhalten, ist das Herunterladen eines tatsächlichen Screenreaders und das Navigieren Ihrer Website damit. NVDA ist einer der meistgenutzten Screenreader, die von echten Screenreader-Benutzern verwendet werden. Er ist außerdem **kostenlos!**
Beachten Sie, dass die Standardeinstellungen für NVDA für die Nutzung durch blinde Benutzer optimiert sind. Diese Standardeinstellungen können sehende Benutzer in den Wahnsinn treiben. Um Ihre Zeit mit NVDA zu genießen, führen Sie die folgenden Schritte aus (Schritte basieren auf einer Windows-Einrichtung, ich habe kein Mac)
- Laden Sie NVDA herunter und installieren Sie es
- Erstellen Sie eine Verknüpfung zu NVDA auf Ihrer Taskleiste (Sie werden es beim Testen regelmäßig öffnen und schließen)
- Öffnen Sie NVDA von der Taskleiste aus
- Finden Sie NVDA in Ihrem System-Tray (siehe unten)
- Klicken Sie mit der rechten Maustaste auf das Tray-Symbol > „Einstellungen“ > „Einstellungen“
- Wählen Sie im linken Bereich „Maus“ aus
- Deaktivieren Sie „Mausverfolgung aktivieren“ (Sie können jetzt Ihre Maus bewegen, ohne dass NVDA Sie anschreit)
- Drücken Sie „OK“
- Klicken Sie mit der rechten Maustaste auf das Tray-Symbol > „Extras“ > „Sprachausgabe-Viewer“ (Sie können jetzt ein Protokoll von allem sehen, was NVDA sagt, verlassen Sie sich aber beim Testen nicht ausschließlich darauf)
- Aktivieren Sie im Sprachausgabe-Viewer das Kontrollkästchen „Sprachausgabe-Viewer beim Start anzeigen“ (Dadurch wird der Sprachausgabe-Viewer geöffnet, wenn Sie NVDA öffnen)
- Machen Sie sich mit einigen der Tastenkombinationen vertraut
- Um NVDA zu schließen, klicken Sie mit der rechten Maustaste auf das Tray-Symbol > „Beenden“ > „OK“
NVDA unterstützt derzeit keine <article>- und <section>-Elemente. Es gibt ein Problem auf GitHub zur Unterstützung von <article>-Elementen. Als ich diesen Artikel zu schreiben begann, wurden <section>-Elemente bereits unterstützt. Die Unterstützung für <section> scheint aus irgendeinem Grund weggefallen zu sein. Das bedeutet, NVDA sollte behoben werden. Das bedeutet jedoch nicht, dass Sie die korrekten Semantiken in Ihrem HTML nicht mehr verwenden sollten.
Bauen Sie Ihre Website mit der Dokumentenstruktur im Hinterkopf auf und testen Sie die Semantiken dann mit Headings Map und NVDA (oder einem anderen Screenreader). Wenn Sie dies tun, werden Sie Ihre Screenreader-Benutzer *sehr* glücklich machen. Möglicherweise machen Sie sogar die Suchmaschinen glücklicher. 😊
Besonderer Dank gilt Kevin Galvin (Principal Consultant bei me 2 accessibility) für Ratschläge zu den Usability-Problemen der Verwendung eines visuell versteckten <h1>-Elements am Anfang der Seite und die Empfehlung von aria-label als Alternative zur Verwendung von visuell versteckten Überschriften.
Kann jemand die Behauptung untermauern, dass das Fußzeilenelement am Ende eines Abschnittselements stehen sollte? Ich weiß, das klingt wie eine dumme Frage, aber ich habe gesehen, dass es zwischen dem Titel eines Artikels und dem Hauptinhalt verwendet wird, um Dinge wie Veröffentlichungsdatum, Autorenname usw. zu umschließen, und dies ist das erste Mal, dass ich höre, dass das nicht erlaubt ist.
Das klingt für mich nach einem Anwendungsfall für das
<header>-Element. Schauen Sie sich den Abschnitt „Was gehört in den Header?“ an. Ich liste sogar die von Ihnen erwähnten Dinge darunter auf.Das tut es, oder? Ich hatte es vorher nicht hinterfragt und angenommen, es gäbe einen Grund, den ich noch nicht verstanden hatte. Vielleicht ist es einfach falsch :)
Nun, laut der Spezifikation, „Fußzeilen müssen nicht unbedingt am Ende eines Abschnitts stehen, obwohl sie es normalerweise tun“. Ich sehe keine Einschränkung, wo sie stehen sollte, in Bezug auf Anfang oder Ende (übrigens, ich denke, bessere Begriffe als oben oder unten ;) ) eines Abschnitts (tatsächlich enthält das erste Beispiel in der Spezifikation eine am Anfang und auch eine am Ende). Damit meine ich, dass es theoretisch keine Einschränkung gibt, wo man sie hinzufügt oder wie viele davon enthalten sein können, nur in der Art und Weise, wie sie verschachtelt sind ;)
Link zur Spezifikation: https://www.w3.org/TR/html52/sections.html#the-footer-element
Das `details`-Element, das Sie für das Inhaltsverzeichnis verwendet haben, sieht übrigens auf Firefox kaputt aus.
Eine wichtige Sache, die man über Menüschalter beachten sollte, ist, dass der
<button>, der die Sichtbarkeit von Menülinks steuert, ebenfalls innerhalb von<nav>liegen sollte, damit Benutzer mit assistiver Technologie, die nach Rollen-Landmarks navigieren, den Schalter tatsächlich umschalten können, um dann auf den Inhalt zuzugreifen.Gibt es einen Grund, warum die Navigation nicht in der Fußzeile sein kann? Ich würde sie selbst nie dort platzieren, aber ich habe Designs gesehen, die das tun.
Die Spezifikation besagt ausdrücklich in Hinweis Nr. 2, dass es nicht notwendig ist, Fußzeilen-Links in ein Nav-Element einzuschließen.
https://www.w3.org/TR/html50/sections.html#the-nav-element
Wenn Sie es für notwendig halten, können Sie es tun. Es ist nicht das Ende der Welt, wenn Sie ein Nav verwenden. Ich denke, wenn Sie mehrere Abschnitte in der Fußzeile haben, dann macht ein Nav um die Nav-Links Sinn. In dieser einfachen Fußzeilen-Beispiel denke ich jedoch, dass es nicht notwendig ist.
Schönes Tutorial.
Ich möchte hinzufügen, dass ein
section-Element (oder ein Element mitrole="region") mit einem zugänglichen Namen (sei es vonaria-labeloderaria-labelledby) zu einem Landmark wird und in der Liste der Landmarks für Screenreader erscheint.Wenn dieses Element ein Landmark sein soll, dann fügen Sie einen zugänglichen Namen hinzu; wenn es kein Landmark sein soll, dann tun Sie das nicht.
Wow, das wird eine großartige Ressource sein! Danke dafür. Ich habe mich gerne als informierten Front-End-Entwickler betrachtet, aber es gibt hier viel, was ich nicht wusste.
Ein verstecktes h1 ist eine schreckliche Idee für SEO.
Ich liebe tiefgehende Artikel, und das war ein Hammer! Danke für die Zusammenstellung.
Das hier ist ziemlich schwer zu verstehen: Artikel ist wie „Block“; Sektion ist wie „Element“
Um diesen Abschnitt zu verstehen, müssen Sie zuerst die BEM-Namenskonvention verstehen.
Versuchen Sie, das hier zu lesen, es wird hoffentlich Klarheit schaffen
Toller Artikel, danke.
Über das Verstecken von Elementen
Opacity:0 versteckt das Element nur visuell. Es nimmt immer noch Platz ein.
Um ein Element visuell zu verstecken, sodass es für assistierende Technologien zugänglich ist und seinen Platz nicht behält, verwenden Sie die Offscreen-Methode.
.offscreen{
position: absolute;
clip: rect(1px, 1px, 1px, 1px);
clip-path: inset(50%);
padding: 0;
border: 0;
height: 1px;
width: 1px;
overflow: hidden;
white-space: nowrap;
}
Das wäre richtig, wenn ich *nur*
opacity: 0verwenden würde. Ich habe aber auchposition: absoluteundpointer-events: noneverwendet.position: absolutenimmt das Element aus dem Dokumentenfluss, sodass es keinen Platz im Seitenlayout einnimmt.pointer-events: noneverhindert, dass Benutzer darauf klicken können, sodass es keine versehentlichen Klicks auf das unsichtbare Element gibt.Dies ist eine moderne Methode für visuell versteckte Elemente.
Es gibt eine sehr gute Browserunterstützung. Die modernste Eigenschaft mit der geringsten Unterstützung ist
pointer-events.https://caniuse.com/#feat=pointer-events
Hallo, eine versteckte Frage zu aria-labeledby, ich dachte, dass das Element mit dem [hidden]-Attribut dasselbe wie display: none ist. Ich habe diese Technik gesehen, die eine visuell versteckte Klasse verwendet. Was wäre der beste Ansatz dafür? Versteckt das [hidden]-Attribut Elemente vor Screenreadern?
Das
hidden-Attribut versteckt Elemente tatsächlich vor Screenreadern.Das
aria-labelledby-Attribut ist jedoch besonders. Es kann Inhalte lesen, die normalerweise vor Screenreadern verborgen sind, dank seiner Verknüpfung mit dem versteckten Element über das ID-Attribut.Vielen Dank für das Schreiben dieses ausführlichen Artikels. Das hat mir wirklich die Augen geöffnet, dass meine HTML-Kenntnisse noch verbessert werden müssen und ich mein Verständnis von Semantik öfter hinterfragen sollte.
Das ist ein langer Artikel und es ist klar, dass Sie viel Zeit in die Recherche Ihres Materials investiert haben. Ich befürchte jedoch, dass Sie möglicherweise einige Schlussfolgerungen im Kopf hatten, die Ihre Recherche beeinflusst haben.
Zum Beispiel widmen Sie viel Platz einem Muster, das Sie letztendlich als untauglich erweisen. Seine Anwesenheit im Artikel macht es nur schwerer, es als Ressource zu nutzen.
Ich werde einige spezifische Punkte hervorheben, die mir beim ersten Lesen aufgefallen sind. Dies ist keineswegs erschöpfend. Zum Beispiel überspringe ich, wie Sie zugängliche Namen für Regionen und Landmarks bereitstellen.
Sie behaupten, dass ein Abschnittselement mit einem
<h#>beginnen *muss*, andernfalls ist es ein Verstoß gegen WCAG 1.3.2: Meaningful Sequence, aber Sie erklären nicht, wie. Sie verwenden diesen behaupteten Verstoß, um die Verwendung derorder-Eigenschaft von Flex zu rechtfertigen, um dies zu umgehen, was sehr leicht zu einem (und normalerweise ist) 1.3.2-Verstoß führen kann.Ich würde Ihr Szenario stattdessen unter 1.3.1: Info and Relationships als bewährte Methode kennzeichnen. Es hat auch nichts mit den Abschnittselementen zu tun und ging deren Existenz voraus. In diesem Fall gilt 1.3.1 für die
<h#>s und den zugehörigen Inhalt.Sie verbringen Zeit damit, den HTML Document Outline Algorithm zu diskutieren (auch während des Artikels), und bezeichnen ihn sogar als Spezifikation (er ist nicht-normativ, keine Spezifikation). Angesichts seiner dokumentierten Fehlschlagshistorie ist die Bezugnahme darauf eine Fehldienstleistung für Entwickler und Endbenutzer. Neue Diskussionen, die Sie zitieren, lehnen sich immer noch an gute Überschriftenstrukturen an (die von Ihnen in diesem Issue vorgeschlagenen
<meta>-Tags werden wahrscheinlich keine Unterstützung finden).Am Ende schlagen Sie vor, dass Benutzer einen Screenreader herunterladen und verwenden, versäumen es aber zu erwähnen, dass VoiceOver, TalkBack, Narrator und Orca in Betriebssysteme integriert sind. JAWS bietet eine kostenlose Testversion an. Dies beunruhigt mich, da es den Eindruck erweckt, dass Sie Ihre Muster nicht mit einer breiteren Palette von Screenreadern getestet haben. Sie alle haben Eigenheiten, die durch den gekoppelten Browser bestimmt werden.
Das Testen mit echten Benutzern hat seinen Wert. Wenn das nicht möglich ist, sehen Sie sich Beispiele an, wie Benutzer Überschriften, Landmarks und Regionen in einem Screenreader nutzen. Es gibt ein großartiges Video von Léonie Watson, die durch Seiten in JAWS scrollt, das ich jedem empfehle anzusehen.
Im Allgemeinen gibt es in diesem Artikel Behauptungen und Schlussfolgerungen, die ich den Lesern empfehle, sorgfältig abzuwägen, bevor sie diese auf Projekten anwenden, die für Menschen bestimmt sind.
Beeinflussen diese Dinge die SEO?
Ich habe den Artikel sehr genossen, muss aber Adrian Roselli zustimmen, dass einige der Prozessbeschreibungen besser in einem Anhang untergebracht werden könnten. Ich würde hinzufügen, dass Heydon Pickering empfiehlt, die
<h#>von<section>überaria-labeled-byzu verknüpfen, da dies bei Screenreader-Fehlern und Inkonsistenzen zuverlässiger ist. Meine eigenen Tests bestätigen dies und ich habe auch keine Probleme, auf die<h2>des ersten Abschnitts für all meine Artikel zuzugreifen, der normalerweise „Introduction“ heißt und das versteckte Attribut hat, da er für sehende Benutzer etwas redundant sein kann. Ich würde Ihnen auch empfehlen, IDs noch eine Chance zu geben. Einen eindeutigen Namen zu finden ist nicht schwer, besonders wenn es um Abschnittsüberschriften für tatsächliche Artikel geht (verwenden Sie einfach den kleingeschriebenen Titel mit Bindestrichen anstelle von Leerzeichen oder Satzzeichen). Im Notfall können Sie HTML und CSS nachbearbeiten, was wir ohnehin tun, wenn uns die Payload-Größe wichtig ist, und automatisch einen eindeutigen Salt basierend auf einem Zufallszahlengenerator hinzufügen. Leider ist das etwas hässlich und ich behaupte, dass Sie auch daran gewöhnt sind, eindeutige Namen zu finden, da Sie auch eindeutige URLs für Ihre Dokumente benötigen.Wüssten Sie zufällig, welche Screenreader die Beschriftung eines Abschnitts mit
<h#>nicht unterstützen?Daniel, leider nicht. Aber warum fragen Sie nicht Heydon (@heydonworks) auf Twitter? Er ist dort eine ziemlich lebhafte Präsenz und beißt nicht (soweit ich weiß).
Ich habe bei Haydon nachgefragt. Er wusste tatsächlich nichts über die automatische Beschriftung von Abschnitten durch Überschriften. Er ist sich nicht sicher, ob alle Browser- und Screenreader-Kombinationen die Überschrift als Abschnittsetikett übernehmen werden. Er hat jedoch keine tatsächlichen Testergebnisse, auf die er sich stützen kann.
Der einzige Weg, um sicher zu sein, ist, es selbst zu testen, wie es aussieht. ☹
Hallo, danke für diesen Artikel. Eine wiederkehrende Frage ist die Notwendigkeit, die H1 um das Logo auf der Startseite zu platzieren (wo die H1 bei anderen Seiten um den Titel des Hauptinhalts herum steht), was mir ziemlich logisch erscheint.
Denken Sie, das ist eine gute Praxis, oder führt es zu anderen Barrierefreiheitsproblemen? Beachten Sie, dass der W3C-Validator dies akzeptiert.
Es ist semantisch nicht ungültig, den Namen/das Logo einer Website in eine h1 zu packen, weshalb der HTML-Validator keinen Fehler ausgibt. Aber es hat meiner Meinung nach wenig Wert.
Am besten arbeitet man entweder mit dem Design zusammen, um eine Möglichkeit zu finden, ein primäres Thema zu vermitteln, oder verwendet die h1, um das hervorstechendste Merkmal auf der jeweiligen Seite/dem jeweiligen Bildschirm (z. B. den oberhalb der sichtbaren Grenze liegenden Inhalt) anzugeben und stellt dann sicher, dass es als primärer Themenindikator für nachfolgende Seiten verwendet wird.
Wie verwendet man HTML5 semantisch? Welches Jahr haben wir?
Es ist 2019. Aber ich schätze, Sie sind bereits ein Experte und haben alles im Griff.
https://validator.w3.org/nu/?doc=http%3A%2F%2Fbrey.co.za%2F
„Verwenden Sie jedoch nicht das aria-hidden-Attribut. Screenreader finden den Beschriftungstext nicht. Nun, NVDA konnte den Beschriftungstext bei meinem Test nicht finden.“
Das scheint ein Fehler zu sein. Gemäß der Accessible Name and Description Computation spec (siehe Schritt 2) sollte aria-labelledby auch auf einem Element funktionieren, das versteckt ist, wie es bei Verwendung des hidden-Attributs der Fall ist. Es gibt kein Verhalten für aria-hidden an, aber bei meinen eigenen Tests funktioniert es normalerweise.
Nebenbei bemerkt, glaube ich, dass dies ein Problem mit dem Browser ist, nicht mit dem Screenreader. Der erstere ist dafür verantwortlich, den zugänglichen Namen zu berechnen und ihn über die Accessibility API an das SR zu kommunizieren.
Das Wichtigste, was man sich merken muss, ist, dass Sectioning-Elemente den Überschriftenkontext **zurücksetzen** (zumindest in der aktuellen Spezifikation); sobald wir eines dieser Elemente einführen, wird unsere Verwendung von
haufh1zurückgesetzt.Ich finde es immer noch nützlich,
role-ARIA-Landmarks für die Wartbarkeit und Explizitheit hinzuzufügen; es hilft nicht nur HTML-Autoren, Landmarks leicht zu identifizieren, sondern gibt Screenreadern auch die Möglichkeit, **nicht raten zu müssen**, wo sich Landmarks befinden.Ich bin so glücklich, einen Artikel wie diesen zu sehen, der die Probleme, mit denen wir HTML-Autoren täglich konfrontiert sind, ausdrücklich erklärt; nachdem ich mehrere Bootcamp-Kurse unterrichtet habe, ist mir klar geworden, dass viele von uns die Bedeutung von semantischem, organisiertem Markup vergessen. Auf eine neue Zukunft, in der wir uns nicht mehr über Dokumentenstruktur-Algorithmen und Überschriften verwirren. Vorwärts!
Hallo Sir, Ihr Blog ist sehr gut, aber ich bin bei einer Sache verwirrt: Was ist der Zweck von „Metadaten im Fußzeilenbereich und Kopfzeilenbereich?“ Bisher habe ich Metadaten nur im Kopfbereich verwendet.
Vielen Dank für den großartigen Artikel. Ich möchte eine Anmerkung hinzufügen. Sie haben geschrieben
… mit der Kopfzeile am oberen Rand des Abschnitts und der Fußzeile am unteren Rand.
Ich würde etwas schreiben wie
… mit der Kopfzeile **vor dem Inhalt des Abschnitts** und der Fußzeile **danach** dem Inhalt.
Die Wörter „oben“ und „unten“ sind verwirrend, und so denken die Leute, dass Header (Footer) am oberen (unteren) Rand einer Webseite oder eines Abschnitts positioniert sein sollten.
Hervorragender Artikel! Großartig, den Wert von gutem HTML-Wissen zu sehen!
Was für ein zeitgemäßer Artikel. Ich arbeite an einem kleinen Barrierefreiheitsprojekt bei der Arbeit und bin auf eine Handvoll offensichtlicher Probleme gestoßen, als ich NDVA auf unserer Website verwendet habe. Ich muss eine Story schreiben, um einige der Dinge anzusprechen, auf die ich gestoßen bin. Wir haben eine Produkt-Suchergebnisseite und die Produkte waren mit dem Screenreader schwer zu finden. Mir ist aufgefallen, dass der Tabellen-Shortcut (T) für NDVA hindurchgesprungen ist, obwohl sie in divs und nicht in Tabellen standen. Aus Sicht eines Screenreader-Benutzers wäre die Navigation über Überschriften oder Landmarks/Regionen besser? Hat jemand Erfahrung mit Produktsuchergebnissen und kann mir ein paar Tipps geben? Ich dachte daran, jedes Produkt als eigenen Abschnitt in einem Main-Element zu gestalten, wobei der Produktname eine h1 ist.
Nach dem, was Scott O’hara mir erzählt hat, sollten Suchergebnisse so markiert werden, wie der Abschnitt mit verwandten Artikeln im Code Pen am Anfang des Artikels markiert ist. So wie hier
Manche Leute denken vielleicht: „Warum nicht ein
<dl>Element?“.Obwohl semantisch korrekt, hat
<dl>einige gravierende Usability-Probleme für Screenreader-Benutzer aufgrund seltsamer Implementierungen in der Screenreader-Technologie. Das werde ich im aktualisierten Artikel behandeln, wenn er veröffentlicht wird.Hallo! Schöner Artikel.
Ich arbeite gerade daran für eine Website, die diesen Artikel als Referenz hat. Danke!
Ich habe einen Zweifel, wie ist Ihrer Meinung nach die richtige Art zu taggen in diesem mobilen Fall?
Option A: https://imgur.com/qwrekBt
Option B: https://imgur.com/R1D8mVd
Andere Optionen/Kommentare?
Danke!
Die primäre Navigation muss nicht unbedingt im Header enthalten sein. Machen Sie es so, wie es für Ihr Layout sinnvoll ist. Es gibt auch sehende Menschen, die Screenreader aus verschiedenen Gründen verwenden. Zu sagen, dass der Header unten auf dem Bildschirm ist, ist für sie etwas verwirrend.
Ich denke, der erste Screenshot, bei dem der Header oben und die Navigation unten ist, ist die richtige Art, dieses Layout zu gestalten.
Ich bevorzuge die Art und Weise, wie Sie es gemacht haben, mit <main>+ <article>. Als Datenbankmensch würde ich lieber zu viele Labels als eines zu wenige haben.