Iedereen die mijn artikelen kent weet dat ik toegankelijkheid van websites belangrijk vind. Er is echter een trend om headings (kopopmaakprofielen) te misbruiken met als argument een betere toegankelijkheid, bijvoorbeeld headings voor het menu. Headings zijn echter bedoeld voor het structureren van de primaire content van een pagina. En nergens anders voor. Dat is goed voor toegankelijkheid, goed voor vindbaarheid en past in het principe van zelfstandige content. En daarmee is het uiteindelijk goed voor de gebruiker.
Primaire, secundaire en metacontent
Wat is content? Content is in principe alle informatie die op een website is te vinden. In dit artikel gaan we uit van 3 soorten content: primaire-, secundaire- en metacontent. In het screenshot hieronder (gemeente Deventer, overigens een van de betere gemeentewebsites) zijn de primaire en secundaire content aangegeven.
Primaire en secundaire content op www.deventer.nl
Primaire content
Als we uitgaan van een artikel – bijvoorbeeld het bovenstaande over het paspoort -, dan draait de webpagina primair om het onderwerp van dit artikel, het paspoort. Dit noem ik de primaire content van de pagina.
Voor de vindbaarheid van het artikel is deze content het belangrijkst. Mensen zoeken immers naar een bepaald onderwerp, in dit geval informatie over een paspoort aanvragen. Pas als de informatie interessant blijkt, kijkt men verder, bijvoorbeeld naar gerelateerde informatie of naar de afzender om een idee te krijgen van de betrouwbaarheid van de informatie.
Secundaire content
Op een webpagina is meer informatie dan alleen de primaire content van het artikel. Er is bijvoorbeeld ook nog:
- een header: de bovenkant van de pagina met bijna altijd het logo, soms een slogan van de organisatie, de zoekfunctie, de taalkeuze en soms de mogelijkheid tot inloggen;
- een menu: links, rechts en/of boven;
- een nieuwsblok;
- een blok met ‘Direct naar’ (of een variant daarop);
- een footer: de onderkant van de pagina, vaak met enkele menuknoppen, zoals sitemap en contact.
Deze informatie is de secundaire content van de pagina. In het voorbeeld hierboven van de gemeente Deventer is dat links het menu met ‘Producten en Diensten’ en rechts de blokken ‘Zie ook’ en ‘Digitaal loket’.
Metacontent
Naast alle zichtbare informatie kent een pagina ook nog informatie die we niet direct kunnen zien. Deze informatie is wel zichtbaar in de broncode van de pagina. Het gaat het om de informatie die in de metatags staan. Dit zijn bijvoorbeeld de metatag keywords, metatag description en de Dublin Core Metadata. Het belang van deze metatags was ooit groot, maar is tegenwoordig minimaal. We bespreken deze metacontent verder niet in dit artikel.
Structureren van primaire content
Een artikel heeft een bepaalde structuur, net zoals een rapport of een boek dat heeft. Voor het aanbrengen van de structuur gebruik je koppen en tussenkoppen. Vanuit het oogpunt van usability, vindbaarheid en toegankelijkheid is het belangrijk dat deze kopteksten de juiste HTML-code meekrijgen. Zo is de titel bovenaan de pagina omsloten door een heading1-tag (h1-tag):
<h1>Paspoort</h1>
De paragraafkoppen hebben vervolgens een heading2-opmaak (h2). Subkoppen binnen een paragraaf krijgen een h3 enzovoort. Bijvoorbeeld:
<h2>Omschrijving</h2>
<p>Stukje tekst</p>
<h3>Aanvragen</h3>
Door content met deze headings te structureren is de content optimaal toegankelijk voor mensen met braille- en spraakuitvoer. Zij gebruiken voor het snel scannen van een pagina namelijk een zogenaamde headingslist (zie afbeelding hieronder). Via hun software vragen zij deze lijst op. In deze lijst staan alle headings en zo krijgen ze snel een overzicht van de pagina.
Headingslist website gemeente Deventer (software: JAWS)
Ook voor de vindbaarheid in zoekmachines zijn deze headings belangrijk. Zoekmachines zoals Google gaan ervan uit dat teksten in headings belangrijk zijn en geven ze daarom extra gewicht mee bij de indexering. Ze dragen daarmee bij aan een betere vindbaarheid van het artikel.
Tot slot zijn headings ook goed voor de uniforme opmaak van een pagina. Als een webredactie consequent de koppen meegeeft, dan hebben alle pagina’s een vergelijkbare opmaak. En dat is goed voor de usability van de site.
Gebruik geen headings voor secundaire content
Omdat de headings de structuur van een artikel weergeven, moeten deze alleen gebruikt worden voor de structurering van de primaire content. Ook hier duiken de laatste tijd weer allerlei vreemde implementaties op: de headings 2 worden dan gebruikt om de secundaire content te ontsluiten. Dus het menu links heeft een h2, het nieuwsblok rechts en de zoekfunctie hebben een h2 enzovoort.
Dit is ook te zien op de website van de gemeente Deventer (zie screenshot hieronder). De h1 is wel goed geplaatst, namelijk op ‘Paspoort’, want dat is de titel van de pagina. In de primaire content zelf is alleen ‘In het kort’ een heading 2 gegeven. Alle andere h2′s worden gebruikt voor secundaire content, zoals ‘Producten en diensten’, ‘De vraag is’, ‘Gemeente en Openingstijden’.
Gebruik van headings (www.deventer.nl)
Het argument voor deze wijze van implementeren is enkel omdat het beter zou zijn voor de toegankelijkheid. Door deze blokken een h2 mee te geven, komen ze terug in de headingslist en kunnen ze zo makkelijk bereikt worden. Dit is een vreemde redenering: omdat spraak- en brailleuitvoer makkelijk headingslisten weergeven gaan we de structuur van pagina’s helemaal omgooien? Zodanig dat ze minder goed vindbaar zijn in zoekmachines? Want die krijgen allemaal minder relevante en niet-betekenisvolle informatie in h2-tags in hun database. Ook vanuit het idee van herbruikbare content (bijvoorbeeld vanuit een XML-formaat) is dit niet logisch.
Het gebruik van headings voor het ontsluiten van secundaire content, zoals een menu, is niet juist. Hoe kun je deze blokken wel goed ontsluiten voor mensen die afhankelijk zijn van spraak-/brailleuitvoer?
Een alternatief is te zien op de website van de gemeente Leusden (hoewel ze verder de headings volledig verkeerd gebruiken). Onzichtbaar bij een gewone weergave maar wel aanwezig in de broncode staan bovenaan enkele snellinks naar het menu en dergelijke. Via CSS wordt deze informatie in de gewone weergave verborgen. Bij het weglaten van de CSS wordt het wel zichtbaar. Daarmee worden de blokken direct toegankelijk en zijn ze voor gebruikers van braille- en spraakuitvoer direct bereikbaar.
Weergave www.leusden.nl zonder css
Gewone weergave www.leusden.nl
Een ander alternatief vinden we in HTML 5. In HTML 5 wordt het mogelijk veel meer semantiek aan te brengen in de HTML-code (zie Semantics in HTML 5). Met het attribuut ‘role’ kun je uitstekend de verschillende blokken aangeven. Het menu krijgt dan bijvoorbeeld: role=’navigation’. We zullen echter nog even moeten wachten totdat HTML 5 in alle browsers is geïmplementeerd.
heading 1 is voor de titel van de pagina en nergens anders voor
De heading 1 (h1) is de hoogste in de hiërarchie van headings. De titel van een artikel staat ook bovenaan de hiërarchische structuur van een pagina. Daarom heeft een titel een h1-opmaak. Ook zoekmachines geven h1 het meeste gewicht.
Helaas zijn sommige webbouwers en webeigenaren de laatste tijd de verkeerde kant opgegaan. Ze zijn de h1 gaan gebruiken voor de afzender van de site. Vanuit de optiek van de bezoeker en de zoekmachine is dat een vreemde en onjuiste keuze. Mensen zoeken eerst op inhoud en pas als deze is gevonden zijn ze geïnteresseerd in de afzender, bijvoorbeeld, of de informatie uit een betrouwbare bron komt.
Een voorbeeld waarin dit mis gaat is de website van het waterschap Hunze & Aa’s, www.hunzeenaas.nl (zie afbeelding hieronder). Elke pagina heeft als heading1-tekst “Logo Waterschap Hunze & Aa’s”. De eigenlijke titel van de pagina heeft een h2 (zelfs nog een dubbele).
h1 voor logo op www.hunzeenaas.nl
Ik heb nog eens nagekeken hoe dit oorspronkelijk bedoeld is door de ‘uitvinder’ van het World Wide Web, Tim Berners Lee. In zijn boek ‘Weaving the Web’ (ik zal de pagina nog eens opzoeken) geeft hij aan dat de heading 1 bedoeld is voor de titel van de pagina. Sommige mensen zullen volhouden dat hij wellicht bedoeld heeft dat de titel gelijk is aan de afzender. Dat snijdt geen hout: dan zouden alle artikelen van een website dezelfde titel hebben. Dat zal nooit de bedoeling zijn geweest.
Elke pagina heeft één h1
Een artikel heeft één titel. Er kan natuurlijk wel een sub of supertitel (chapeau) zijn, maar een artikel heeft één titel. Een webpagina heeft één h1.
Ook deze richtlijn wordt vaak niet goed geïmplementeerd. Zo gebruikt de gemeente Leusden maar liefst 9 h1-tags voor de structuur van een pagina (zie hieronder).
9 h1-tags op één pagina op www.leusden.nl
Sla geen niveaus over
Na een h2 kan nog een h2 komen of een h3. En geen h4. Zo geldt dat voor alle niveaus. Dit is ook een eis in Webrichtlijnen 1. Vergelijk dit met hoe je een gewoon rapport opmaakt. Daar start je ook direct na de titel van een hoofdstuk met een paragraaf en niet met een subparagraaf.
Een voorbeeld waar dit goed gaat is de overzichtspagina van WCAG 2 op de site van het W3C, Web Content Accessibility Guidelines (WCAG) 2.0.
Voorbeeld goede headingsstructuur (www.w3.org/tr/wcag20)
Headings op de homepage
Een bijzondere pagina is de homepage. Wat is nu de titel van de homepage, want de pagina heeft niet echt één onderwerp? In dit geval ontsluit de pagina de rest van de site. Gebruikelijk is dat deze pagina ‘home’ heet. Omdat ‘home’ voor een bezoeker van buiten de site geen inhoud weergeeft, is het goed om hier – naast home – ook het onderwerp van de site te noemen. Dat kan de naam van de afzender zijn, maar dat hoeft niet.
Een homepage bevat vaak blokken met informatie, bijvoorbeeld een blok met nieuws of een blok met snellinks. Gebruik voor blokken die op elke pagina worden getoond ook geen headings. Gebruik daarvoor bijvoorbeeld snellinks die via CSS onzichtbaar zijn gemaakt. Geef de blokken in het primaire contentvlak h2-tags mee. Het nieuwsblok krijgt dan bijvoorbeeld een h2 en de nieuwsberichten een h3.
Headings bij een zoekresultatenpagina
Een andere bijzondere pagina is de zoekresultatenpagina (Search Engine Results Page of SERP). Google gebruik voor haar resultaten ook headings. Geef elk zoekresultaat een h2. Dat is ideaal voor mensen met spraak- en brailleuitvoer, want ze kunnen makkelijk van resultaat naar resultaat springen. De titel van deze pagina is ‘Zoekresultaten’, eventueel aangevuld met het aantal resultaten, en heeft deze een h1-opmaak.
Conclusie
Het lijkt alsof webbouwers en webeigenaren de laatste tijd verder verwijderd zijn geraakt van een goede implementatie van headings, dit alles met als argument toegankelijkheid. Het gaat hierbij met name om het gebruik van headings voor secundaire content en het gebruik van de h1 voor de afzender van de site. Het gebruik van headings voor secundaire content is echter helemaal niet nodig voor een betere toegankelijkheid. Er kunnen beter enkele links worden toegevoegd, die via CSS onzichtbaar worden gemaakt. Op termijn kan daar het role-attribuut in HTML 5 voor gebruikt worden.
Het gebruik van de h1 voor de afzender van de site is helemaal nergens goed voor. Gebruik gewoon de h1 voor de titel van de primaire content, de content waar de bezoeker voor komt.
Dit is zacht gezegd een nogal afwijkende mening. Er is geen enkele spec, html 3.2, html 4, XHTML en zéker niet HTML5 die beweert dat heading alleen bedoeld zijn voor primaire content. Headings zijn op zich bedoeld om de structuur van een pagina weer te geven, de gehele pagina, dus ook ‘secundaire’ content. In tegenstelling tot wat de schrijver beweert is secundaire content namelijk ook content die gewoon toegankelijk moet zijn en dús ook via headings benaderbaar moeten zijn.
Het stuk was al wat slecht geïnformeerd en gebaseerd op verkeerde aannames maar zodra HTML5 er bij gehaald wordt gaat het helemaal mis: HTML5 propageert juist het gebruik van meerdere H1′s op een pagina: elk item (article in HTML5 termen) wat zelfstandig, dus buiten de context van deze pagina, prima tot z’n recht komt heeft een H1 nodig. Een H1 is dus bedoeld als heading van elk artikel, hoe klein ook, dus ook voor secundaire content. En nee, dat is niet slecht voor SEO, google vindt dit prima.
De heading-outline die getoond wordt gaat dus op voor elk artikel op een pagina, niet alleen voor de zogenaamde ‘primaire content’ en kan dus meerdere malen voorkomen.
Het is lovenswaardig dat er eens een artikel verschijnt over toegankelijkheid. Het is alleen erg jammer dat dit artikel de plank volledig mis slaat en slechte adviezen geeft.
Haha wat een onzin. Ga een nieuwe baan zoeken, iedereen is fout maar ikke is goed!
Ik moet me aansluiten bij Vasilis. Vooral het deel over headings in secundaire content slaat de plank volledig mis.
“Door content met deze headings te structureren is de content optimaal toegankelijk voor mensen met braille- en spraakuitvoer.” De secundaire content hoeft dus niet toegankelijk te zijn voor deze bezoekers. Lekker is dat als ze, zoals in het voorbeeld, iets als “producten en diensten” zoeken. Dat lijkt me alleszins essentiële content voor een site als deze die gewoon ontsloten moet worden door een duidelijke structuur aan te geven. Dat doen we o.a. door het gebruik van de juiste headings, ook hier.
Ook over het gebruik van meerdere H1 spreekt de auteur zichzelf tegen: “Een artikel heeft één titel. (…) Een webpagina heeft één h1.” En wat als je, zoals Vasilis al aangaf, meerdere artikelen op één pagina hebt? Juist: meerdere H1′s (in HTML5 iig).
Interessante en ongetwijfeld spraakmakende blogpost! Een afwijkende mening is het zeker, ook ten opzichte van de huidige toegankelijkheids specificatie(s). Laten we eerst eens kijken naar de stelling dat secundaire content niet van headings voorzien moet worden. WCAG 2.0:
WCAG 2.0 Techniques (H42):
“In this example, the main content of the page is in the middle column of a 3-column page. The title of the main content matches the title of the page, and is marked as h1, even though it is not the first thing on the page. The content in the first and third columns is less important, and marked with h2.”
Zie: http://www.w3.org/TR/WCAG-TECHS/H42.html
De Nederlandse webrichtlijnen (v2) verwijzen vanuit hun richtlijn over Kopregelhierarchie (U.1.3.) naar het volgende WCAG 2 document:
“To facilitate navigation and understanding of overall document structure, authors should use headings that are properly nested (e.g., h1 followed by h2, h2 followed by h2 or h3, h3 followed by h3 or h4, etc.).”
Zie: http://versie2.webrichtlijnen.nl/draft/20101201/sc/u.1.3/ en http://www.w3.org/TR/WCAG20-TECHS/G141.html.
Dan kunnen we zeggen: “Dat is maar het WCAG, zo kan ik het ook!”. We nemen een kijkje op het (oude) WAC (Web Access Centre) blog:
“Heading structure should be consistent throughout the site.”
Zie: http://webarchive.nationalarchives.gov.uk/20100418065544/http://www.rnib.org.uk/wacblog/headings/quick-tips-for-accessible-headings/
Genoeg hierover. Dan het gebruik van één element. Laten we de nieuwste HTML (HTML5) specificatie er eens bij pakken:
“Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.”
HTML5 introduceert sectioning content. Binnen deze elementen (bijvoorbeeld het section- en het article-element) wordt aangeraden om te starten met een element en de outline binnen die sectie verder invulling te geven.
Zie ook: http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#sectioning-content en http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#headings-and-sections.
Dat wil overigens niet zeggen dat alle huidige screenreaders deze specificatie op de juiste manier geïmplementeerd hebben.
Dan nog even kort over wat je noemt de tag ‘role’. Ten eerste: role is geen tag, maar een attribuut. Zie ook: http://csswizardry.com/eta.
Ten tweede: dit is de in HTML5 opgenomen WAI-ARIA specificatie. Deze specificatie kan al door bouwers van het web gebruikt worden om meer semantiek in de DOM te leggen, door bijvoorbeeld het gebruik van landmark roles (zie: http://www.w3.org/TR/wai-aria/roles#landmark_roles). Elke browser kan prima overweg met het toevoegen van attributen, ook als de parser geen enkele semantische waarde aan het attribuut toekent.
Verder kan ik me vinden in de reactie van Vasilis. Gaaf dat er eens een artikel over toegankelijkheid geplaatst wordt. Ik ben trouwens benieuwd naar verdere onderbouwing van Jaap z’n artikel!
@Vasilis: dat HTML5 toestaat dat er meerdere h1′s worden gebruikt staat helemaal los van het feit dat HTML5 het role-attribuut kent waarmee je dus goed secundaire content kunt ontsluiten. En dat er geen specs zijn die dit voorschrijven is ook mijns inziens niet een argument dat het niet zou kloppen. Mee eens, het maakt het zeker sterker als de specs hetzelfde zeggen. HTML5 houdt zich niet bezig met dergelijke semantiek; die keuze is aan de auteur.
Mag ik verder weten in hoeverre het “stuk slecht geïnformeerd is” en “gebasserd op verkeerde aannames”?
@Roy: MIjn betoog is dat ook voor mensen met spraakuitvoer het in eerste instantie gaat om de primaire content. Mensen zijn op zoek naar informatie en zijn dus in eerste instantie gericht op de primaire content. Door via bijvoorbeeld een snelmenu het menu (met bijvoorbeeld Producten en diensten) te ontsluiten kunnen zij ook eenvoudig deze content bereiken. Het menu is zeker essentiële content, maar niet waar de bezoeker (in de meeste gevallen) in eerste instantie voor komt. En ik spreek mijzelf niet tegen als ik aangeef dat er slechts één h1 hoort te zijn. Als het goed is bevat een pagina slechts één artikel. Bij een overzichtspagina met meerdere artikelen heeft elk artikel een h2 en is de titel van de pagina (met een h1) “Recente artikelen” of iets dergelijks. Dat HTML5 het mogelijk maakt betekent niet dat dit goed is.
@Peter: dank voor je uitgebreide reactie. Ja, spraakmakend is het zeker. Mijn reactie:
- WCAG 2.0 Techniques (H42): tja, daar staat zonder meer dat h2 wel voor secundaire content gebruikt mag worden.
- Webrichtlijnen 1, Kopregelhierarchie (U.1.3.): hier staat niets over het wel of niet gebruik van headings voor secundaire content. Sterker nog: veel sites komen daarmee in de problemen omdat ze voor het menu of nieuws een headings gebruiken en deze in de code niet onder de primaire content zetten.
- “Heading structure should be consistent throughout the site.â€: ook hier zie ik niet de strijdigheid met mijn verhaal (?)
- “Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.â€:
En hier ben ik het dus inderdaad deels niet mee eens als zij bedoelen dat er op een pagina meerdere sections kunnen zijn die dan een h1 moeten krijgen. In de 2e helft staat “or to use elements of the appropriate rank for the section’s nesting level” en daarmee kun je het wel weer goed doen, want je moet dan voor elke sectie (volgens mij sterk vergelijkbaar met de paragraaf) een heading gebruiken. Dat is precies wat ik zeg.
- role is inderdaad geen tag, maar een attribuut. Ik zal dat nog aanpassen.
@Jaap: Ik kan me echt nog niet in je standpunt vinden.
Je hebt het hier over een document outline. Lees daar meer over op https://developer.mozilla.org/en/Sections_and_Outlines_of_an_HTML5_document. Wat quotes.
“The structure of a document, i.e., the semantic struture of what is between body and /body, is fundamental to presenting the page to the user.”
“All content lying inside the element is part of a section. Sections in HTML5 can be nested. Beside the main section, defined by the element, sections limits are defined either explicitly or implicitly. Explicitly-defined sections are the content within , , , , , , and tags.”
Zie op die pagina ook de voorbeelden die gegeven worden van code met bijbehorende outline. Dan zul je zien dat het ineens logisch is geworden om binnen sectioning content opnieuw te starten met een reeks h1-h6.
Het punt van alle voorbeelden die ik gaf, was het feit dat in vrijwel alle richtlijnen doorklinkt dat de outline (of: de heading-structuur) geldt voor de gehele pagina, niet een gedeelte ervan.
Ook de aanname dat een gebruiker gericht is op de primaire content kan ik niet direct met je delen. Het zou geweldig zijn als elke gebruiker op je website komt en direct de juiste pagina en inhoud voorgeschoteld krijgt. De bounces zouden naar het nul-punt dalen. Helaas is dat niet zo. Zoals diverse mensen al eens hebben aangestipt, zou elke pagina op het web moeten fungeren als een home-page: bezoekers komen op willekeurige pagina’s binnen (via bv. zoekmachines) en verlaten de pagina als ze niet kunnen vinden wat ze zoeken. Des te belangrijker wordt de structuur van de pagina als geheel.
Bovendien is mijn visie dat elke gebruiker dezelfde ervaring hoort te krijgen. Zoals jij het stelt gaan webbouwers terug naar de jaren negentig en zetten andere elementen dan heading-elementen in om titels boven een sectie te emuleren. Voor de bezoeker met goed zicht ziet de tekst er uit als titel, voor de blinde bezoeker niet. Waarom zou je deze discriminatie toepassen en zelfs aanbevelen?
Daarnaast:
- Het ‘role’-attribuut van ARIA is _niet_ bedoeld om de outline van een document mee te definiëren. ARIA heeft veel doeleinden en biedt veel kansen, maar dit is er niet een van.
- De HTML5 spec is juist wel gericht op de semantiek van een document. Daarmee dus ook de toegankelijkheid. Denk hierbij aan het invoeren van sectioning content, een nieuw outlining algoritme, het toestaan van ARIA, nieuwe sectioning elementen, diverse JS API’s (ik weet het, die horen niet bij de HTML5 specificatie an sich).
Als laatst nog even een quote vanuit bovenstaand MDC artikel:
“The new sections and headings elements introduced in HTML5 bring the ability to describe the structure and the outline of a web document in a standard way. They bring a big advantage for people having HTML5 browsers and needing the structure to help them understanding the page, for instance people needing the help of some assistive technology.”.
Eens!
Jaap, je noemt nogal vaak dat iets ‘goed’ of ‘fout’ is zoals over meerdere H1 elementen in HTML5: “Dat HTML5 het mogelijk maakt betekent niet dat dit goed is.” en in je laatste reactie “use only H1 […] appropriate rank […] daarmee kun je het wel weer goed doen…”
Verdiep je eens in de HTML5 specificatie (v.w.b. headings en sectioning) op pagina’s zoals http://vlst.nl/x/84 en http://vlst.nl/x/85 wordt daar meer over geschreven.
Kort door de bocht: In HTML5 bestaat het concept van de Document Outline en die werkt anders dan in b.v. HTML4. Elke opvolgende heading (b.v. H2 na een H1) impliceert een nieuwe sectie. Maar niet alleen het nummertje achter de heading tag (b.v. H1 of H2) bepaalt waar deze heading in de outline hoort, maar ook de ‘context’ en dan met name de ‘Sectioning Content’ waar Peter het al over heeft.
Je kunt de outline van een HTML5 document checken met b.v. http://gsnedders.html5.org/outliner/
Het eerste heading element in een (nieuwe) sectie wordt de heading voor die sectie. Dat betekent dat die heading een H3 _kan_ zijn, maar net zo goed een H1. Bekijk een visueel voorbeeldje van Bruce Lawson: http://www.brucelawson.co.uk/tests/html5-sections.html
Bovenstaande is de reden dat de spec spreekt over “Sections _may_ contain headings of any rank, but authors are strongly encouraged to either use only h1 elements […]“. Omdat een nieuwe sectie context (door b.v. een
sectionofarticleelement te gebruiken) de heading hierarchy ‘reset’ _kan_ je een H6 gebruiken als eerste heading (dat is dan semantisch een H1), maar _beter_ is het om gewoon een H1 te gebruiken.Lang verhaal maar ik hoop dat je begrijpt dat HTML5 in dit opzicht afwijkt van HTML4 en dat er dus niet makkelijk meer te spreken is over ‘goed’ en ‘fout’ met betrekking tot H1. Je kunt niet meer zeggen dat er maar 1 H1 op de pagina ‘moet’: juist gebruik is helemaal afhankelijk van de context.
Misschien moet de auteur zich eens gaan verdiepen in wat HTML5 echt is en hoe het in de praktijk werkt.
Tip: http://html5-showcase.com
Ik heb niet veel toe te voegen aan bovenstaande reacties, behalve dan dit: als je het role attribuut gaat gebruiken voor een navigatiemenu (wat op zich een prima idee is), moet je natuurlijk wel ‘navigation’ gebruiken als role, en niet ‘menu’. Misschien een idee voor de auteur om zich eens te verdiepen in de WAI ARIA specificatie: http://www.w3.org/TR/wai-aria/roles.
@Peter en de anderen: Ik moet na het lezen van jullie reacties erkennen dat mijn aannames niet juist zijn. Met name de quotes van Peter over HTML 5 geven mij nu echt een ander inzicht dan dat er nu verwoord staat in mijn artikel. Voldoende reden voor mij om de content nog eens goed te bezien en andere conclusies te trekken.
Ik wil het toch nog even uiteenrafelen en doe toch nog een poging, vooral over de dingen die voor mij onduidelijk blijven:
- Ik zie een verschil tussen een artikelpagina (zoals deze pagina) en “ontsluitende” pagina’s, zoals een homepage. Mijn artikel gaat in principe over een artikelpagina. Een blinde help je mijns inziens meer met een headingslist die de inhoud van het artikel weergeeft, dan allerlei omliggende content. Ik denk nu wel – na het lezen van met name de citaten over HTML5 – dat je die content ook van headings kunt voorzien. Die staan dan wel bij voorkeur ná de primaire content.
- Verder begrijp ik niet dat er HTML5 wordt uitgegaan van meerdere h1′s. In mijn optiek gaat een artikelpagina over 1 onderwerp en heeft deze pagina ook 1 titel. Je kunt dit volgens mij niet anders coderen dan met een h1. En daarmee heeft alle andere content een lagere heading. HTML5 geeft ook niet aan dat je meerdere moet gebruiken. Wellicht moet je dit toch zo lezen dat meerdere h1′s gebruikt moeten worden als een pagina ook meerdere onderwerpen heeft, dus als het meer een ontsluitende pagina is.
- Ik vergelijk een artikelpagina met een artikel zoals dat ook op papier kan staan. Het heeft een titel en vervolgens koppen (of hoofdstukken in een boek). Vervolgens weer subkoppen (of paragrafen). Het bijzondere aan HTML is dat de h1 in feite de titel is. Dat is bijzonder, want het zou eigenlijk semantisch ook “title” moeten zijn. Maar die wordt gebruikt voor de browsertitel. Als je nu een inhoudsopgave zou maken van een artikelpagina, dan staat h1 niet daarin, maar begint deze met de h2′s. als een pagina een intern menu heeft, wordt die ook zo gestructureerd, dus de eerste h2 heet “1″. Ik zal de HTML 5 specs nog goed gaan bestuderen, maar dat punt begrijp ik nu in ieder geval helemaal niet. Zij gaan uit van een outline waarin de h1 de “1″ krijgt. Gaan zij uit van een nieuwe titel-tag om de titel van de pagina weer te geven? Of krijg je per artikel-pagina verschillende outlines?
- In hoeverre maakt secundaire content deel uit van de semantiek van een artikel, de kern van de pagina? Het feit dat er een nieuwsblok staat is dat een onderdeel van de semantiek van de pagina? Het lijkt mij meer iets van de morfologie van de pagina, namelijk van de vorm van de pagina. Er is toch geen semantische relatie tussen een inhoudelijk artikel en een menu of nieuwsblok?
@Maaike: menu moet inderdaad navigation zijn. Is aangepast in het artikel.
@Jaap misschien kan je de inleiding even aanpassen en aangeven dat je gedachtes over heading wellicht niet helemaal kloppen? Mensen die de reacties niet lezen worden nu nog steeds verkeerd geïnformeerd en dat zou jammer zijn.
Je kan het artikel natuurlijk ook terugtrekken en een nieuw artikel over dit onderwerp publiceren zodra je het begrijpt.
@Vasilis: ik ga het artikel aanpassen. Intussen heb ik het idee dat ik het redelijk begrijp en blijf ik in essentie dezelfde vragen houden. Maar zonder meer moet ik daarvoor het artikel anders gaan opstellen.
@Jaap: Je geeft aan dat je geen H2′s moet gebruiken voor secundaire content, maar kun je dan ook aangeven met welk element dit dan wel zou moeten, rekeninghoudende met het feit dat oudere browsers geen HTML5 ondersteunen: deventer.nl is nu bijv. IE6 compatible.
P.S.: De link naar de website van de gemeente Leusden klopt trouwens niet; het is nu een relatief pad ipv een absoluut pad.
@Jaap: Ik ben blij dat je het artikel gaat aanpassen. Voor niet-ingewijden zal het lezen van dit artikel zowel verwarrend als misleidend kunnen werken. Met name je uitspraken over “goed” en “fout” verbazen mij; een standpunt mag je natuurlijk hebben, maar het zou heel duidelijk moeten zijn voor de lezer dat het om jouw eigen mening gaat, met name omdat die mening tegen bijna tegen zoveel specificaties in gaat.
De volgorde van broncode is wellicht ook interessant in deze discussie (voor HTML4 dan) aangezien een lineaire “weergave” zoals een outline vaak hierop is gebaseerd.
Wat betreft je openstaande vragen omtrent HTML5 en headings:
- http://www.w3.org/TR/html5/sections.html#the-h1-h2-h3-h4-h5-and-h6-elements
Hopelijk hebben de lezers (en/of jijzelf) hier ook wat aan:
- http://html5doctor.com/the-header-element/
- http://html5doctor.com/nav-element/
- http://html5doctor.com/the-section-element/
- http://html5doctor.com/the-hgroup-element/
- http://html5doctor.com/the-article-element/
Zie ook:
- http://diveintohtml5.org/
- http://books.alistapart.com/products/html5-for-web-designers
- http://introducinghtml5.com/
http://www.youtube.com/watch?v=GIn5qJKU8VM
Matt Cutts, “chef H1 & more” van Google:
“If there is a logical reason to have multiple sections, it’s not so bad to have multiple H1′s. I would pay attention to overdoing it. (…) I would use it where it makes sense”
Meerdere H1′s gebruiken is geen enkel probleem als er een zekere logica achter zit. Je pagina volplempen met H1′s werkt averechts.
Vergeten we in deze discussie nu niet de digitale toegankelijkheid waar het allemaal mee begon?
Want al is Jaaps oplossing misschien niet de beste, hij heeft wel een punt over het inperken van het aantal headers op een pagina. Ik heb geen verstand van HTML, maar weet inmiddels wel hoe mensen die een voorleesfunctie gebruiken daar over het algemeen mee omgaan.
die voorleesfunctie staat bijvoorbeeld razendsnel, omdat de meeste websites heel veel voor te lezen hebben. Begin maar eens in de linkerbovenhoek en bekijk wat je allemaal tegenkomt voordat je bij de inhoud komt. Reken dan eens uit hoeveel pagina’s je op een interessante website bekijkt en je weet hoe vaak je dat zelfde menu hoort als je doorklikt. Vandaar dat, naast wat verschillende manieren van inbreuk op de tabvolgorde, een (onzichtbare, maar wel hoorbare) knop bovenin de pagina met ‘spring naar inhoud’ erg gewaardeerd wordt.
Daarnaast wordt er, weer vanwege de enorme hoeveelheid rotzooi per website dat serieel in plaats van globaal doorlopen moet worden, vaak gebruik gemaakt van koppenlijsten en linklijsten.
In koppenlijsten wil je gelijk doorklikken naar een artikel waar je al naar op zoek was en wil je dus niet weer een enorm menu-item doorgraven (wat Jaap secundaire content noemt) voordat je bij de werkelijke koppen van de pagina komt, vandaar dat over die volgorde goed nagedacht moet worden.
Linklijsten zijn hetzelfde verhaal, naast dat ze qua naam vaak problemen opleveren. Als je in deze lijst alleen ‘lees verder’ en ‘klik hier’ kunt lezen, dan is het te hopen dat de alt-tekst je meer vertelt zodat je kunt vinden wat je zoekt.
Naar aanleiding van de ontwikkeling van onze bedrijfswebsite hebben we overigens met een aantal cliënten van Bartimeus (instituut voor blinden en slechtzienden) gekeken of een pagina met veel of juist weinig links goed beviel. Daaruit bleek dat een pagina met helemaal geen links het gevoel gaf dat ze vast waren gelopen, maar dat een pagina met zes of meer links (een gewone inhoudspagina)zorgen voor een lichte information overload.
Heel interessant wordt het als je pagina’s ook echt gaat laten voorlezen door gratis voorleesprogramma’s (ogen dicht!). Dan zijn de technische eisen helemaal niet meer zo relevant, dan hoor je ineens wat eraan schort.
@Stephen Hay: Bedankt voor de links.
Dit artikel is meer van toepassing op de huidige situatie die we met HTML4 kennen. HTML brengt echt structuur en relaties aan.
Door het gebruik van sections en articles worden het op zich zelf staande onderdelen in een pagina. En die kunnen een eigen headings hebben die los staan van de hele pagina.
En dit is ook gelijk de reden waarom HTML5 is zo belangrijk is voor een toegankelijk internet!
(RANT: Maar aangezien IE8 GEEN HTML5 ondersteuning heeft en IE9 niet meer op XP draait krijgen we weer de zelfde situaties als met IE6)….
@Sebastiaan Ik kan me voorstellen dat (de auteur van) dit artikel meer uitgaat van HTML4. Daarom is b.v. ook de opmerking van Stephen over de volgorde van de broncode belangrijk.
Toegankelijke webpagina’s kunnen prima ontwikkelt worden in zowel HTML4 als HTML5.
Ik ben, net als jij, enthousiast over HTML5 maar, zoals Stephen en ik al eerder aangaven, denk ik dat het belangrijk is om voorzichtig te zijn met al te grove generalisaties.
Voorzichtig niet alleen met opmerken dat bepaalde zaken “goed” of “fout” zijn, maar helemaal met ongefundeerde uitspraken m.b.t. b.v. HTML5: die zijn er namelijk al veel te veel gedaan
Je zegt dat “IE8 GEEN HTML5 ondersteuning heeft”. Dit is simpelweg niet waar!
Je doelt waarschijnlijk op het feit dat IE bepaalde (semantische) elementen, zoals
section enarticleniet correct interpreteert en rendered. Dat is inderdaad een probleem waarvoor op het moment Javascript de enige praktische oplossing is.Maar je kunt gerust HTML5 gebruiken zonder van deze elementen gebruik te maken.
Uiteraard zijn er meer aspecten van HTML5 die nog geen (volledige) ondersteuning hebben, maar er is weinig reden om niet nu al gebruik te maken van het HTML5 Doctype. Daarmee kan je al gerust de kortere Meta Charset definitie gebruiken en bepaalde attributen weglaten (zoals type op script elementen) of juist toevoegen (placeholder, verschillende input types, etc).
Opmerkingen (‘rants’) zoals jouw “IE8 HEEFT GEEN HTML5 ondersteuning” en “We krijgen weer dezelfde situaties als met IE6″ zijn te generiek, onjuist, en ‘hold back the Web’ in mijn optiek.