Waarom je HTML5-artikel boven katern moet verkiezen

Over de auteur

Bruce houdt zich al sinds 2001 bezig met toegankelijkheid, webstandaarden en browsers sinds 2001. Daarom ziet hij er zo slecht uit. Je kunt hem volgen op @brucel, of lees zijn …Meer overBruce↬

Een paar dagen geleden zat ik met een paar vrienden te praten, en een van hen vroeg me wat het verschil was tussen <article> en <section> in HTML. Dit is een van de eeuwige mysteries van webontwikkeling, samen met “waarom is het white-space: nowrap, en niet white-space: no-wrap?” en “waarom is CSS ‘grijs’ een donkerder kleur dan ‘darkgray’?”.

Ik gaf mijn gebruikelijke antwoord: denk aan <article> niet alleen als een krantenartikel, of een blogpost, maar als een kledingstuk – een afzonderlijke entiteit die in een andere context kan worden hergebruikt. Dus je broek is een artikel, en je kunt hem bij een andere outfit dragen; je overhemd is een artikel, en kan bij een andere broek worden gedragen; je knielange lakleren naaldlaarzen zijn een artikel (je zou er toch niet maar één van dragen?).

De spec zegt:

“Het article element vertegenwoordigt een complete, of op zichzelf staande, compositie in een document, pagina, applicatie, of site en dat in principe onafhankelijk distribueerbaar of herbruikbaar is, bijv. in syndicatie. Dit kan een forumbericht zijn, een tijdschrift- of krantenartikel, een blogbericht, een door de gebruiker ingezonden commentaar, een interactieve widget of gadget, of een ander onafhankelijk stuk inhoud.”

Dus een homepage met een lijst van blogberichten zou een <main> element zijn dat een serie <article> elementen omwikkelt, een voor elk blogbericht. Je zou dezelfde structuur gebruiken voor een lijst van video’s (denk aan YouTube) waarbij elke video in een <article> wordt gewikkeld, een lijst van producten (denk aan Amazon), enzovoort. Elk van deze <article>s is conceptueel syndiceerbaar – elk kan op zichzelf staan op zijn eigen speciale pagina, in een advertentie op een andere pagina, als een item in een RSS-feed, enzovoort.

Apple’s WatchOS bevat Reader die het <article> element gebruikt om de primaire inhoud van je pagina te kennen. Apple zegt:

“We hebben Reader naar watchOS 5 gebracht waar het automatisch wordt geactiveerd bij het volgen van links naar webpagina’s met veel tekst. Het is belangrijk ervoor te zorgen dat Reader de belangrijkste delen van uw webpagina naar voren haalt door semantische markup te gebruiken om de betekenis en het doel van elementen in het document te versterken. Laten we eens een voorbeeld overlopen. Eerst geven we aan welke delen van de pagina het belangrijkst zijn door ze in een artikel-tag te wikkelen.”

Het combineren van <article> met HTML5 microdata helpt Reader de optimale weergave voor kleine horlogeschermen te construeren:

“Specifiek zorgt het insluiten van deze koptekstelementen in het artikel ervoor dat ze allemaal in Reader verschijnen. Reader stijlt ook elk header element verschillend, afhankelijk van de waarde van zijn itemprop attribuut. Met behulp van itemprop, kunnen we ervoor zorgen dat de auteur, publicatiedatum, titel, en subkop prominent worden weergegeven.”

En hoe zit het met <sectie>?

Mijn gebruikelijke advies blijft: doe geen moeite met <section> of maak je geen zorgen over hoe het verschilt van <article>. Het is uitgevonden als een generiek omhulsel voor koppen, zodat de browser de HTML5-documentomtrek kan bepalen.

Het wat? Het algoritme voor de documentomtrek is een manier om slechts één koptag te gebruiken – <h1> – en deze op magische wijze het juiste niveau van koptekst te laten “worden” (bijv. in een <h2><h3>, enz.), afhankelijk van hoe diep het genest is in HTML5-sectie-elementen:<article><section>, enzovoort.

Dus, bijvoorbeeld, dit is wat u in uw CMS hebt getypt:

<h1>My Fabulous article</h1><p>Lorem Ipsum Trondant Fnord</p>

Dit werkt briljant wanneer het als een op zichzelf staand artikel wordt getoond. Maar hoe zit het op je homepage, die een lijst is van je laatste artikelen?

<h1>My latest posts</h1><article> <h1>My fabulous article</h1> <p>Lorem Ipsum Trondant Fnord</p></article><article> <h1>Another magnum opus</h1> <p>Magnum solero paddle pop</p></article>

In dit voorbeeld worden, volgens de specificatie, de <h1>s binnen de <article> elementen logische <h2>s “geworden”, omdat <article>, net als <section>, een sectioning element is.

Note: dit is geen nieuw idee. Al in 1991 schreef oom Timbo:

“Ik zou er de voorkeur aan geven, in plaats van <h1><h2>, enz. voor koppen een nestbaar <SECTION></SECTION> element, en een generiek <H></H> die op elk niveau binnen de secties het vereiste niveau van Heading zou produceren.”

Gelukkig genoeg echter implementeert geen enkele browser HTML5 outlining, dus heeft het geen zin <section> te gebruiken. Op een gegeven moment heeft de JAWS schermlezer geprobeerd om het document outlining algoritme te implementeren (in IE, maar niet in Firefox), maar implementeerde het buggy. Het lijkt erop dat browser-ontwikkelaars gewoon niet geïnteresseerd zijn (meer smerige details in de Further Reading sectie voor echte anoraks).

“Maar,” onderbrak een andere vriend in het gesprek, “nu geven browsers verschillende groottes van het lettertype weer, afhankelijk van hoe diep de <h1> is genest in <section>s”, en ging verder met het bewijzen ervan. Verbazingwekkend!

Hier is een soortgelijke demo. De linker kolom toont vier <h1>s, genest in secties; de rechter kolom toont een, <h1><h2><h3><h4> met geen nesting. De Firefox screenshot laat zien dat de geneste <h1>s standaard hetzelfde lettertype hebben als de traditionele <h1><h4> tags:

De resultaten zijn hetzelfde in Chrome, Chromium-derivaten zoals Edge beta voor Mac, en Safari op Mac.

Betekent dit nu dat we allemaal maar <h1> als ons enige heading-element moeten gaan gebruiken, genest in <section>s?

Nee. Want dit is alleen een verandering in de visuele styling van de h1s. Als we de Firefox Accessibility inspector in devtools openen, kunnen we zien dat de tekst “level 2” is gestyled om eruit te zien als een H2, maar nog steeds is ingesteld op “level 1” – de Accessibility Tree is niet gewijzigd om level 2 te zijn.

Vergelijk dit met de Echte H2 in de rechterkolom:

Dit toont aan dat de toegankelijkheidsstructuur correct is geïnformeerd dat dit een koptekst van niveau 2 is. Mozilla heeft inderdaad geprobeerd het berekende niveau aan de toegankelijkheidsstructuur door te geven:

“We hebben daar een beetje mee geëxperimenteerd… maar moesten het terugdraaien omdat mensen in ons a11y team klaagden over te veel regressies (per ongeluk verlagen van <h1> niveaus en dergelijke).”

Voor gebruikers van ondersteunende technologie is een goede hiërarchie van titels van vitaal belang. Zoals het achtste WebAIM-screenreadergebruikersonderzoek laat zien,

“Het nut van goede heading-structuren is zeer hoog, met 86,1% van de respondenten die heading-niveaus zeer of enigszins nuttig vinden.”

Daarom moet u <h1> blijven gebruiken tot <h6>, en section negeren.

Never Say Never

“Maar…” zult u nu verontwaardigd sputteren, “er is een <section> element precies op deze pagina!”. En je zou gelijk hebben, beste lezer. De “snelle samenvatting” is verpakt in een <section>, om toegankelijkheidsredenen. Toen de screenreadergebruiker Léonie Watson haar webinar “How A Screen Reader User Accesses The Web” gaf, wees ze op een gebied waar de opmaak van Smashing Magazine kon worden aangepast om haar ervaring te verbeteren.

Zoals je in het screenshot kunt zien, worden Smashing-artikelen voorafgegaan door een korte samenvatting, gevolgd door een horizontale lijn die de samenvatting van het eigenlijke artikel scheidt.

Maar het scheidingsteken is puur decoratief, dus Léonie kon niet zien waar de samenvatting eindigt en het artikel begint. Ze stelde een oplossing voor: we wikkelden de samenvatting in een <section> element:

<section aria-label="quick summary"> Summary text</section>

In de meeste schermlezers wordt een <section> element niet aangekondigd, tenzij het een toegankelijke naam heeft. In dit geval, de tekst van het aria label. Nu kondigt haar schermlezer aan “Snelle samenvatting regio”, en na de samenvatting “Snelle samenvatting regio einde”. Deze eenvoudige markup maakt het ook mogelijk voor een screenreader-gebruiker om over de samenvatting heen te springen als hij dat wil.

We hadden een eenvoudige <div> kunnen gebruiken, maar dan, zoals Marco Zehe schrijft,

“Als vuistregel geldt: als je iets labelt via aria-label of aria-labelledby, zorg er dan voor dat het een juiste widget- of landmarkrol heeft.”

Dus in plaats van <div role=”region” aria-label=”quick summary”>, kozen we <section> omdat dat een ingebouwde rol van region heeft en Bruce’s onfeilbare wet van ARIA™ geldt: built-in verslaat bolt-on. Enorm.

Conclusie

Hopelijkerwijs heb je de volgende punten meegekregen:

• Gebruik geen massa’s <h1>s. Maak <h1> de hoofdkop van je pagina, gebruik dan <h2><h3><h4>, enz. in een juiste hiërarchie zonder niveaus over te slaan.
• <section> kan worden gebruikt met aria-label om een schermlezer-gebruiker te laten weten waar een bepaald subonderdeel van een artikel begint en eindigt. Anders kun je het vergeten, of een ander element gebruiken, zoals <aside aria-label=”quick summary”> of <div role=”region” aria-label=”quick summary”>.
• <main><header><footer> en <nav> zijn zeer nuttig voor gebruikers van schermlezers, en volledig transparant voor degenen die geen ondersteunende technologie gebruiken. Gebruik ze dus.
• <article> is niet alleen voor blogberichten – het is voor elk op zichzelf staand ding. Het helpt WatchOS ook om je inhoud goed weer te geven.

Ik ben Léonie Watson erkentelijk voor haar hulp bij het schrijven van dit artikel. Eventuele fouten zijn volledig haar schuld.

Verder lezen

• “Headings And Sections,” HTML 5.2W3C Recommendation (14 dec. ’17)Let op de waarschuwing: “Er zijn momenteel geen bekende native implementaties van het outline-algoritme … Daarom kan niet worden vertrouwd op het outline-algoritme om de documentstructuur aan gebruikers over te brengen. Auteurs moeten heading-rang (h1-h6) gebruiken om de documentstructuur over te brengen.”
• “There Is No Document Outline Algorithm,” Adrian RoselliAlle bloederige details over hoe de specificatie voor het sectioning-algoritme is veranderd.
• “ARIA in HTML,” W3C Editor’s Draft (19 dec. 19)Regels om naar te leven als je merkt dat je ARIA-rollen en -attributen aan HTML toevoegt.
• The Practical Value Of Semantic HTML,” Bruce LawsonMijn eigen artikel, met een link naar details over hoe WatchOS HTML5 en microdata gebruikt.

(ra, il)