HTML5: de toekomst van toegankelijke websites

Ik krijg steeds vaker de vraag hoe toegankelijkheid zich verhoudt tot het gebruik van nieuwe technieken als HTML5 en CSS3, of werkwijzes als adaptive design en responsive design. Omdat de webrichtlijnen dateren van 2004, en niet meer zijn uitgebreid met de technologieën die in de tussenliggende jaren zijn ontwikkeld, betekent dat simpelweg dat onder die webrichtlijnen HTML5 en CSS3 niet zijn toegestaan. Echter, met Webrichtlijnen versie 2 (WR2) ‐ welke is goedgekeurd als overheidsstandaard in juni 2011 ‐ behoort HTML5 en CSS3 wel tot de mogelijkheden. WR2 is alleen tot op heden nog niet toetsbaar, omdat niet alle toetsmechanismen geaccordeerd zijn. Belangrijkste is echter; HTML5 draagt bij aan de toegankelijkheid van websites, dus het wordt tijd dat we de kansen die voor het grijpen liggen ook hanteren.

De toekomst is dichterbij dan je denkt

HTML5 draagt bij aan de toegankelijkheid van websites

Dat WR2 in combinatie met HTML5 en CSS3 voor uitdagingen kan zorgen merkte ik toen ik eind 2011 zijdelings betrokken was bij de bouw en toetsing van de website voor het Koninklijk Huis. Deze is getoetst op basis van WR2, ondanks dat nog niet voor alle ijkpunten duidelijk was hoe dit volledig toetsbaar was. We kregen in de toetsing daarom terug dat het gebruik van CSS3 wel toegestaan was, maar het gebruik van vendor prefixes (zoals -webkit-, -moz- en -o-) niet. Daarmee valideerde de stylesheet namelijk niet. Logisch, want dergelijke ijkpunten gaan uit van de standaard (Webrichtlijnen 2, principe Universeel, richtlijn U9), en voor zaken zoals border-radius, text-shadow en alle andere nieuwe attributen zijn nog geen definitieve keuzes gemaakt door het W3C, dus is er een tussenoplossing met vendor-prefixes. De webrichtlijnen zeggen hier het volgende over:

Het gebruik van nog niet formeel vastgestelde open specificaties kan een risico inhouden. De grootte van het risico houdt rechtstreeks verband met de ondersteuning door software waarmee webcontent wordt opgevraagd. Complicerende factor is overigens dat lang niet iedereen beschikt – of kan beschikken – over de laatste versies van softwareprodukten. Bij het gebruik van nog niet formeel vastgestelde open specificaties moet daarom terdege rekening worden gehouden met het feit dat ook oudere versies van software in gebruik zijn.

Uiteindelijk was het argument dat het niet ten koste van de gebruikerservaring wordt toegepast, voldoende om over dit punt heen te stappen en te gedogen. Toch geeft dat in ieder geval wel aan dat ondanks de flexibele houding ten opzichte van moderne technieken in WCAG2 de mogelijkheden niet ineens onbegrensd zijn. Het staat in ieder geval open voor discussie en pragmatisme. maar leidt vooralsnog wel af van de belangrijke verbeteringen op het gebied van toegankelijkheid, die met name met de komst van HTML5 zijn ontstaan. In het kort biedt HTML5 meer structuur en logica aan de browser en de gebruikers, waarmee je relatief ten opzichte van XHTML1.0 Strict en haar voorgangers eenvoudiger een moderne, dynamische én toegankelijke site kunt bouwen.

Betekenisvolle elementen

De belangrijkste verbetering op het gebied van toegankelijkheid op basis van HTML5 is de toevoeging van elementen zoals <header>, <article> en <aside>, die contextuele en semantische betekenis geven aan de inhoud van elementen. Voorheen zou je deze elementen opmaken met een <div>-element met een classname of id, en we weten allemaal dat in 50% van de gekozen classnames en id’s onvoldoende rekening is gehouden met betekenisvolle en semantisch-correcte naamgeving. Denk bijvoorbeeld aan de id’s die .NET voorheen standaard genereerde voor elementen, zoals id="ctl00_ctl10_publishingContext1". Volgens de webrichtlijnen moeten elementen betekenisvolle id’s of classes hebben, en daar voldoet deze naamgeving in ieder geval niet aan. Maar ook het gebruik van grid frameworks zoals het 960 Grid System helpt niet met opmaak als <h1 class="grid_4 push_4">. Het geeft geen duidelijke handvat voor de gebruiker, en bovendien is de betekenis verloren als je middels CSS de boel op de schop neemt. Ergo; HTML5 helpt developers een handje bij deze verbeterslag.

Paginastructuur

Met de nieuwe elementen kun je de structuur van de pagina veel logischer opbouwen, maar er is ook een veel groter gevaar om dit juist teniet te doen, zoals Roger Johansson heel goed heeft uitgelicht. Ik heb overwogen dit opnieuw op de doeken te doen, maar zijn artikel dekt de lading volledig, dus lees dat vooral! Waar het om gaat is dat de nieuwe elementen niet allemaal gelijkwaardig worden behandeld door het DOM. Zo zijn de elementen <section>, <nav>, <article> en <aside> sectioning elements, wat betekent dat zij worden herkend als logische elementen op een pagina. <header> en <footer> zijn geen als zodanig herkende onderdelen op een pagina, wat voor vreemde situatie kan zorgen in de logische structuur voor zoekmachines en screenreaders, zoals het artikel van Roger Johansson ook duidelijk maakt. Het lastige is dat voor deze situatie voorals geen bekende oplossing is, en de alternatieven ofwel zoekmachineonvriendelijk ofwel ontoegankelijk zijn. Desalniettemin biedt het developer wel veel meer houvast bij het ontwikkelen van templates en ondersteund het mensen met een beperking doorgaans meer dan met de oude syntax, en inmiddels ook enkele screenreaders de HTML5 document outlines ondersteunen (update: Readspeaker bevestigt dit, en geeft ook aan dat Readspeaker los van de document outline informatie ophaalt uit de pagina (inclusief callbacks) en presenteert). Ik gebruik zelf deze HTML5 document outline chrome plugin om die outlines te toetsen.

Kopregelstructuur

Een van de meest gehoorde — overigens vaak erg enthousiaste maar toch foutieve — uitspraken over HTML5 is dat je meerdere H1’s mag toepassen op een pagina. Het klopt dat dit is toegestaan, maar wel bijna-altijd-foutief is de praktische uitwerking. Dit heeft grotendeels te maken met de eerder genoemde document outline problematiek. In theorie zou je met de nieuwe elementen steeds nieuwe secties kunnen opzetten, en dan zou iedere heading een <H1>-element kunnen zijn. Feitelijk zouden de browser, de screenreader en de zoekmachine dan zelf de logica moeten herleiden, maar in de praktijk interpreteren de meeste screenreaders en alle zoekmachines op Google na (voor zover ik weet?) zulke documenten als zeer plat, door het gebrek aan hiërarchie. Natuurlijk zal dit op termijn betere ondersteuning krijgen, maar ik denk dat het hoe dan ook logischer is de ‘oude’ structuurbeginselen aan te houden bij het gebruik van kopregels. Het is sowieso beter in combinatie met CSS (je hoeft namelijk niet voor iedere sectie de <h1> alsnog anders op te maken), maar het is ook logischer qua algehele structuur. De <h3> in een <aside> in een <article> is tenslotte herkenbaar minder relevant/belangrijk dan een <h1> op diezelfde plek. Het blijft een context-onafhankelijk element op deze manier. Maar het belangrijkste argument om die structuur aan te houden is volgens mij de onafhankelijkheid van browsers, zoekmachines en screenreaders; het werkt nu, en het zal straks werken als HTML5 echt goed wordt ondersteund.

Logische afbeeldingen

Een andere semantische verbetering in HTML5 is de toevoeging van het <figure>-element. <Figure> mag worden gebruikt voor de opmaak van afbeeldingen, is dus niet verplicht maar kan wel helpen bij het toegankelijker maken van dit stukje content.

Voorheen maakten we afbeeldingen met een onderschrift als volgt op:

<div>
<img src="afbeelding.jpg" alt="Omschrijving van de afbeelding" />
</div>
<p>Omschrijving van de afbeelding (of afbeeldingen), niet persé gelijk aan de alt-tekst</p>

Met het HTML5 <figure>-element kun je de elementen als het ware bij elkaar plaatsen:

<figure>
<img src="afbeelding.jpg" alt="Omschrijving van de afbeelding" />
<figcaption>Omschrijving van de afbeelding (of afbeeldingen), niet persé gelijk aan de alt-tekst<figcaption>
</figure>

Je ziet hierbij meer contextuele logica ontstaan tussen de afbeelding en het bijbehorende onderschrift. Verwacht wordt dat zoekmachines en screenreaders dit ook als zodanig zullen interpreteren, wat uiteraard de toegankelijkheid ten goede komt ten opzichte van de oude situatie.

Reïncarnatie van oude elementen

Naast de echt nieuwe elementen zijn sommige oudere elementen afgestoft en opnieuw voorzien van een functie. Denk hierbij aan de <i> en <b> die met XHTML1.0 Strict uit den boze waren. <i> staat nu voor een alternatieve stem in de vorm van bijvoorbeeld een voice-over of voor taxonomie (de olifant is een ‘<i>zoogdier</i>), wat dus wezenlijk anders is dan het benadrukken van stukken tekst met het <em> element. Voor het <b> vind ik het persoonlijk iets schimmerig, omdat dit als een visuele oplossing wordt gebruikt voor het uitlichten van een stuk tekst. Misschien begrijp ik het simpelweg niet goed, maar in mijn beleving kunnen we dit element beter alsnog vermijden.

<hr />

Een ander element dat een flinke verduidelijking heeft gekregen is de horizontal rule. Hoewel dit in het verleden vrij veel is gebruikt voor visuele doeleinden (Foei!), is nu vrij duidelijk omschreven waar het <hr />-element voor dient, namelijk thematische overgangen in tekst (op paragraaf-niveau), en feitelijk hetzelfde is als </section><section>. Het is dus bovenal een logisch element en niet langer een grafisch element, hoewel het nog steeds zo kan en mag worden gebruikt mits onderdeel van tekst. Het onderstrepen van titels is daarmee gelukkig eindelijk voorbij (hoop ik!).

Tot slot

HTML5 is dus echt een verbeterslag, en dat was al langer bekend vanuit ontwikkelingsoogpunt. Dat het ook qua usability en toegankelijkheid een flinke slag maakt is voor zover mij bekend minder doorgedrongen in de gelederen. Zelfs ondanks de vooralsnog gebrekkige ondersteuning van screenreaders en zoekmachines, is er simpelweg veel winst in met name de houvast die het biedt voor zowel ontwikkelaars als gebruikers.

Het is dan ook zaak voor de commissies rondom de webrichtlijnen vaart te maken met de toetsingsmogelijkheden. We kunnen dan eindelijk zonder achteruitkijkspiegel toegankelijke websites en applicaties ontwikkelen, en simpelweg de zeer handige gereedschappen gebruiken die inmiddels al enkele jaren voor het oprapen liggen. Go go go!

Aanvulling 29 september 2012

Zoals Gerrit Berkouwer terecht opmerkt is er ook veel kritiek op de nieuwe elementen. Aanleiding hiervoor is de onvolledigheid van de nieuwe elementen, wat voor verwarring kan zorgen. Het zal altijd een hybride model van HTML5 en div’s moeten blijven, omdat de HTML5 elementen nooit de volledige semantische waarde kunnen dekken. Het blijft dus altijd belangrijk om niet te leunen om de HTML5-elementen, maar logisch nadenken als leidraad te behouden.

11 gedachten over “HTML5: de toekomst van toegankelijke websites”

    1. Hee Gerrit, dank voor je reactie! Ik kende dat artikel niet, de discussies over of er voldoende nieuwe elementen zijn of niet kende ik al wel. Uiteraard dekt het de lading niet, dus het zal een hybride vorm blijven. Dat is iets wat ik nog even in het artikel zal toevoegen overigens, dus dank daarvoor.

      Als je echter kijkt naar de semantische waarde van de elementen, en de verhouding tot de heading structuur is dat op een bepaalde manier heel waardevol. Maar zoals met alle nieuwe technologie; blijf nadenken wat je gebruikt en waarom. Dat blijft altijd de uitdaging voor iedereen.

      Het is wel even food for thought, ik zal het dit weekend verwerken in het artikel, stuur je nog even een update dan! Thanks :)

  1. Hoi Jeroen, goed stuk! Als bij tijd en wijle cynische ouwe l*l kan ik bij tijd en wijle een lachbui niet onderdrukken als ik zie hoe sommige ontwikkelaars zich enthousiast maar effectief de hoek in schilderen met al die mooie nieuwe semantische elementen, zeker als er gewerkt wordt met een gecompliceerde templating structuur, zoals in mijn huidige project.
    Men begint heel voortvarend met (kijk mij nou toch een hip zijn :P) en gaat daarna qua structuur en toegankelijkheid gierend de mist in. Dat kon onder de vorige versies ook al prima, maar html5 biedt nieuwe kansen! :)
    Een hele fijne (nou…) is de mogelijkheid om een link helemaal vol te plempen met blok- en andere elementen (davidwalsh.name/html5-elements-links). Screenreader heaven (NOT).
    Daarom ben ik blij te lezen dat jij net als ik voorlopig gaat voor de hybride vorm. We hebben er een mooie schatkist van gave en waardevolle elementen bij gekregen, maar gezond verstand is onontbeerlijk. Dank voor deze bijdrage aan dat gezonde verstand. Gerrit, ook bedankt voor de link; goed leesvoer.

    1. Dat ziet er inderdaad erg interessant uit, thanks voor de link Iacobien! Genoten van Fronteers? Welke sessie vond jij het hoogtepunt?

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *