Een toegankelijke website voor iedereen

“Ieder mens heeft het recht om te leven als ieder ander en mee te doen in de maatschappij. Gebruikmaken van de mogelijkheden die het internet, computers en smartphones ons bieden hoort daar natuurlijk bij. Juist daarom is het belangrijk dat digitale dienstverlening toegankelijk is voor iedereen.”

Miljoenen Nederlanders hebben één of meerdere beperkingen. Denk daarbij aan mensen die blind (78.000 mensen) of slechtziend (238.000), kleurenblind (700.000), doof of slechthorend (1.300.000), motorisch beperkt of lichamelijk gehandicapt (1.500.000), zwakbegaafd, dyslectisch (825.000), autistisch of laaggeletterd (1.500.000) zijn. Maar ook tijdelijke beperkingen vallen hieronder, zoals mensen die een gebroken arm hebben, vermoeid zijn of mensen die buiten in de zon lopen en het scherm niet goed kunnen zien.  

De groep mensen die een toegankelijke website of app nodig hebben is waarschijnlijk een stuk groter dan je denkt. Daarom heeft de Nederlandse overheid in een wet opgenomen dat iedereen in staat moet zijn om jouw digitale product te gebruiken. Die verplichte digitale toegankelijkheid geldt al een tijd voor nieuwe websites en applicaties van overheidsinstanties, publiekrechtelijke instellingen en samenwerkingsverbanden waar de overheid aan deelneemt. Sinds 23 september 2020 geldt deze wet ook voor alle bestaande sites en voor mobiele applicaties sinds 23 juni 2021. Per 2025 wordt dit uitgebreid naar andere sectoren. Dit staat omschreven als "elektronischecommunicatiediensten, met uitzondering van transmissiediensten die voor de levering van machine-to-machinediensten worden gebruikt; diensten die toegang verlenen tot audiovisuele mediadiensten;" en "bankdiensten voor consumenten; e-handelsdiensten". Bekijk hier het volledige overzicht.

Het voldoen aan de verplichte digitale toegankelijkheid levert je ook nog extra voordelen op. Zo verbetert het de vindbaarheid van je website omdat zoekmachines de site gemakkelijker kunnen indexeren waardoor meer bezoekers je site zullen vinden. En je maakt de website ook voor bezoekers zonder beperking gebruiksvriendelijker, zodat je meer engagement creëert bij deze doelgroep. Twee factoren die flink zullen bijdragen aan het succes van je website. 

We zien dus dat de toegankelijkheidseisen voor steeds meer producten en diensten gaan gelden. Maar niet iedereen in de commerciële sector wordt verplicht om aanpassingen te doen. Echter, het recht op gelijke behandeling van mensen met een beperking of chronische ziekte stelt ook eisen aan commerciële instellingen, op basis van ‘redelijkheid’. Welke inspanning redelijk wordt geacht om jouw site of app toegankelijk te maken, verschilt per bedrijf. 

Is digitale toegankelijkheid voor jouw organisatie verplicht, of wil je sowieso zoveel mogelijk voldoen aan de toegankelijkheidseisen? Dan wil je natuurlijk weten in hoeverre jouw huidige site of app binnen de toegankelijkheidsregels past. Misschien is die al een paar jaar oud en weet je niet zeker of deze voldoet aan de nieuwe eisen. De nieuwe eisen hebben betrekking op afbeeldingen, geluid en video, animatie, formulieren, geo-informatie, navigatie, tabellen, techniek en code, tekst en vormgeving. Maar we kunnen zeggen dat de eisen grofweg in twee categorieën vallen: Vormgeving (hoe onderdelen worden weergegeven) en Techniek (hoe onderdelen worden gecodeerd). Een overzicht van de eisen met bijbehorende uitleg vind je hier.

De Nederlandse toegankelijkheidseisen zijn gebaseerd op de Web Content Accessibility Guidelines (WCAG) van het World Wide Web Consortium (W3C). Hierin documenteren zij alle adviezen, aandachtspunten en mogelijke implementaties als het gaat om toegankelijkheid op het web.

Voldoet je site niet aan de toegankelijkheidseisen? Om dat op te lossen, zijn er verschillende opties:

1. Nieuwe look & feel

Hebben de punten waarop je slecht scoort vooral betrekking op de vormgeving? Bijvoorbeeld teksten op afbeeldingen, kleurcontrasten die te laag zijn of lettertypes te klein? Dan kom je waarschijnlijk al een heel eind met aanpassingen aan de vormgeving. Dit is de minst ingrijpende optie.

2. (Gedeeltelijk) redesign

Zijn er bepaalde onderdelen die structurele problemen hebben? Dan zou je die delen van de site kunnen vernieuwen. Je kunt dan nadenken over hoe de content daar het beste gepresenteerd wordt zodat het toegankelijk is voor zoveel mogelijk mensen.

3. Nieuwe website

Komen de aanpassingen qua tijd en kosten in de buurt van het volledig herbouwen van de website, dan kan het interessant zijn om voor een volledig nieuwe website te kiezen. Zo kun je van begin af aan, bij iedere beslissing die je neemt, rekening houden met toegankelijkheid. Zowel in de vormgeving, als de techniek. En natuurlijk neem je dan ook meteen andere wensen mee in het nieuwe design.

Door je website of app toegankelijk te maken kunnen meer mensen er gebruik van maken. Het aantal bezoekers zou dus wel eens kunnen gaan toenemen! Maar misschien maak je je wel zorgen of je jouw huisstijl nog wel op dezelfde manier kunt blijven gebruiken. Omdat de toegankelijkheidseisen gevolgen hebben voor de vormgeving van je site of app, kan het zijn dat elementen van je huisstijl anders zullen moeten worden toegepast. Dat komt doordat toegankelijke websites leesbaar moeten zijn, genoeg contrast moeten hebben en alle betekenis overgebracht moet worden door middel van tekst, en niet alleen door kleuren en afbeeldingen. Toch betekent het zeker niet dat je jouw huisstijl moet laten varen. Wel is het zaak er bewust mee om te gaan, zodat zoveel mogelijk mensen gebruik kunnen maken van jouw digitale dienst of product.

Leesbaarheid

Om ervoor te zorgen dat je boodschap door zoveel mogelijk gebruikers gelezen kan worden, is de leesbaarheid van de teksten op je site het allerbelangrijkste. Er wordt naar een combinatie van twee eigenschappen gekeken: de grootte van de tekst en het contrast van de tekst ten opzichte van de achtergrond. Het kan zijn dat kleuren die gedefinieerd zijn in de huisstijlgids niet voldoende contrast hebben en het contrast moet worden verhoogd. Of dat er moet worden gekeken naar andere combinaties van de huidige kleuren. En wanneer de huidige site relatief kleine teksten bevat (minder dan 16px), dan zijn de eisen nog iets strenger dan wanneer de teksten groter zijn.

Veel huisstijlen maken ook gebruik van teksten op afbeeldingen. Helaas is dat op dit moment niet toegestaan volgens de toegankelijkheidseisen, zelfs niet met een overlay over de afbeelding of schaduwen onder de tekst. Dit komt omdat je niet kunt garanderen dat de tekst in alle omstandigheden en met elke afbeelding voldoende contrast heeft. Om dat op te lossen worden teksten dus vaak boven of onder afbeeldingen geplaatst of in kaders met een achtergrondkleur.

Contrast

Naast de tekst op de site is het aan te raden om ook voldoende contrast te geven aan andere elementen waarmee de gebruiker moet interacteren. Denk hierbij aan iconen, buttons, invoervelden van formulieren en scheidingen tussen secties. 

Niet alleen met kleuren communiceren 

Ook is het verstandig om niet alleen op kleuren te vertrouwen om een betekenis over te brengen. Doe je dat wel, dan kunnen mensen die kleurenblind zijn de betekenis verkeerd begrijpen. Daarnaast kunnen kleuren in verschillende culturen andere betekenissen hebben. Het is daarom aan te raden om ook tekstuele uitleg toe te voegen. Bovendien is tekst makkelijker om te zetten in bijvoorbeeld braille of spraak.

Een voorbeeld: op de linkerafbeelding zie je weinig contrast tussen elementen, geen omschrijvende labels bij de invoervelden en geen tekst op de knop.

Aan de basis van de meeste toegankelijkheidsimplementaties ligt een van de basispijlers van het web: Hypertext Markup Language (HTML). Deze opmaaktaal is dé manier om een document te structureren zodat een webbrowser deze als een pagina kan weergeven. Naast webbrowsers gebruiken ook crawlers van zoekmachines en toegankelijkheidssoftware (zoals screenreaders) dit formaat om de inhoud uit te kunnen lezen en te gebruiken voor indexatie of het voorlezen ervan.

Het is daarom essentieel om de HTML-structuur op orde te hebben om het voor deze software zo gemakkelijk mogelijk te maken hun werk te doen en in de behoefte en doelen van de eindgebruiker te voorzien. Het juist structureren levert al direct zonder verdere inspanningen voordelen op als het gaat om toegankelijkheid.

Structuur

HTML bestaat uit tientallen elementen waarmee informatie op de pagina kan worden gestructureerd, zoals lijsten, paragrafen en knoppen. Veel van deze elementen hebben een specifiek doel, gedrag - zie verderop in dit artikel - en een bepaalde semantiek, kortom betekenis. Door de juiste elementen te gebruiken kan dit, en soms ook de context en belangrijkheid van de inhoud, beter begrepen worden door toegankelijkheidssoftware.

Het gebruik van juiste elementen puur voor de semantiek verbetert de toegankelijkheid van een website nog niet direct. Het biedt echter wel de mogelijkheden om meer functionaliteit te bieden aan de gebruikers. Zo bestaan er bijvoorbeeld elementen om onder andere de hoofdinhoud van de pagina en belangrijke navigatieblokken, zoals het hoofdmenu, te structureren. Hierdoor worden ze voorzien van context en betekenis en kan functionaliteit aangeboden worden zoals het snel navigeren naar het eerste navigatieblok of de hoofdinhoud.

Onder water maken deze elementen gebruik van de Accessible Rich Internet Applications-standaard (ARIA). Hierin wordt de implementatie voor het delen van extra informatie met betrekking tot HTML-elementen, -structuur en -interactie gedocumenteerd met betrekking tot toegankelijkheid. Het kan gezien worden als een extra laag structuur bovenop de HTML-structuur, maar dan puur voor toegankelijkheid. Zoals je verderop in dit artikel leest, speelt deze standaard bij bijna iedere technische implementatie een rol.

Gedrag

Het juiste gebruik van elementen puur voor de semantiek levert dus enkel indirecte verbeteringen qua toegankelijkheid op. Er zijn daarentegen wel directe resultaten zichtbaar als het gaat om het standaardgedrag in browsers en toegankelijkheidssoftware.

Zo is er voor elk element een standaard gedocumenteerd voor onder andere gedrag, functionaliteit, vormgeving en toegankelijkheid. Een goed voorbeeld hiervan is een ‘button’-element, waar het volgende standaardgedrag aan hangt: gedraagt zich als een klikbaar element, is via het toetsenbord navigeerbaar, zal door screenreaders als “klik + naam van de knop” worden voorgelezen en wordt er standaardvormgeving toegevoegd zodra naar de knop wordt genavigeerd, zoals een blauwe rand of stippellijn. Bovendien is het vanuit semantisch oogpunt duidelijk dat wanneer er op het element geklikt wordt, er een actie zal worden uitgevoerd. Deze en nog meer voordelen verkrijgen we enkel door het juiste gebruik van elementen.

Een ander voorbeeld: lijsten. Het is mogelijk om een lijst visueel als zodanig weer te geven door middel van een hyphen (‘-’) of een nummer voor elk item in de lijst. Als echter het juiste lijstelement wordt toegepast, krijgen we naast standaardvormgeving met opsommingstekens ook standaardgedrag met betrekking tot toegankelijkheid. Zo zullen screenreaders voorlezen hoeveel elementen de lijst bevat en welk item er momenteel wordt voorgelezen: “Lijst 5 items. Item 1 van 5. Het eerste item van de tekst. Item 2 van 5. Het tweede item van de tekst.”

Met het gebruik van een juiste structuur zetten we de eerste stap voor een goede basis voor een toegankelijke website, zonder hiervoor extra werk te hoeven verrichten. Daarnaast zijn er verschillende implementaties die ingebouwd moeten worden bovenop de bestaande structuur met betrekking tot toelichtingen en navigatie.

Veel van de adviezen met betrekking tot toegankelijkheid hebben te maken met het toelichten van een webpagina. Denk daarbij aan visuele elementen zoals afbeeldingen, of interacties die plaats kunnen vinden op de pagina. De vuistregel hiervoor is dat naast een visuele weergave er ook een tekstueel alternatief moet zijn, dat gebruikt kan worden door software zoals screenreaders.

Interactie

Een goede HTML-structuur voorziet toegankelijkheidssoftware van informatie over bepaalde elementen en zorgt voor standaardvormgeving. Maar wat niet achterhaald kan worden, is hoe bepaalde elementen onderling met elkaar communiceren, verbintenis hebben of dat er interactie op de pagina plaatsvindt of kan plaatsvinden. Om dit te communiceren gebruiken we de eerder vermelde ARIA-standaard. Hiermee kan extra toelichting richting toegankelijkheidssoftware worden verstuurd als alternatief voor de visuele weergave.

Een voorbeeld is `role="alert"`. Wanneer dit attribuut wordt toegevoegd op een element, zal de content ervan direct worden voorgelezen door een screenreader. Dit wordt bijvoorbeeld toegepast voor foutmeldingen in formulieren. Vaak wordt door middel van rode randen om het invoerveld en een roodgekleurde tekstuele uitleg visueel gecommuniceerd dat er iets fout is gegaan. Voor bijvoorbeeld blinde personen werken deze visuele elementen niet en het is maar de vraag of de screenreader de foutmelding voorleest. Het kan namelijk zijn dat de gebruiker al naar het volgende invoerveld is genavigeerd en dus voorbij de foutmelding is gesprongen. De bezoeker komt er dan pas aan het einde van het formulier achter dat er ergens iets fout is gegaan, omdat het verzenden van het formulier niet lukt.

Vervolgens moet de gebruiker het hele formulier door navigeren om het invoerveld met de foutmelding te vinden; een tijdrovende en frustrerende ervaring. Als oplossing daarvoor kan de foutmelding van `role="alert"` worden voorzien, waardoor deze direct wordt voorgelezen door de screenreader zodra deze verschijnt. Bijvoorbeeld: “Dit is een verplicht veld en mag niet leeg zijn.” Hiermee krijgen gebruikers van screenreaders ook directe feedback net als in de visuele weergave. Een ander behulpzaam attribuut met betrekking tot foutmeldingen in formulieren is `aria-invalid`; hiermee wordt het veel gemakkelijker om te identificeren welk invoerveld een foutmelding teruggeeft.

Daarnaast zijn er ARIA-attributen om een bepaalde interactie en status mee te identificeren. Zoals bij een uitklapper; als de pagina opent is deze ingeklapt, met een mogelijkheid om deze uit te klappen. Visueel wordt dit vaak met een ‘plus/min’-icoon of een ‘pijl’-icoon weergegeven, maar ook voor niet-visuele navigatie zoals een screenreader moet duidelijk gemaakt worden dat er iets opengeklapt kan worden en in welke status het momenteel verkeert (open of gesloten). Deze informatie sturen we richting de software met behulp van de ARIA-attributen `aria-controls` (toegevoegd op de knop en bevat een verwijzing naar het openklappende element), `aria-expanded` (toegevoegd op de knop en geeft de huidige status aan) en `aria-hidden` (toegevoegd aan het openklappende element met de content en geeft aan of de content zichtbaar is). Een toepassing zie je in onderstaand voorbeeld.

Naast de hiervoor genoemde attributen bevat de ARIA-standaard nog tientallen andere attributen waarmee een bepaalde status van een element of juist de mogelijkheden qua interactie duidelijk kunnen worden gemaakt.

Visuele elementen

Dit heeft betrekking op elementen die puur op een visuele manier informatie overbrengen. Een voor de hand liggend voorbeeld zijn afbeeldingen. Essentiële informatie kan worden misgelopen doordat men deze niet of slecht kan zien, denk aan infographics. Het is daarom belangrijk om een tekstueel alternatief aan te bieden om alsnog de informatie over te brengen, bijvoorbeeld met een attribuut (het verplichte `alt`-attribuut) op de afbeelding of een bijschrift onder de afbeelding. Voor video's zijn er nog meer oplossingen om rekening mee te houden, zoals een uitgeschreven versie van het gesproken woord en/of ondertiteling.

Andere visuele elementen op een pagina zijn iconen, met of zonder interactieve context. Ook hiervoor dienen we een tekstueel alternatief toe te voegen. Dit kan gedaan worden door middel van de ARIA-attributen `aria-label` of `aria-labelledby` of een tekstelement dat visueel niet zichtbaar is, maar wel door toegankelijkheidssoftware wordt gebruikt.

Een voorbeeld hiervan is een overzicht van artikelen met daarbij informatie over het aantal reacties. Om de weergave compact te houden is er gekozen om enkel een 'spreekwolkje'-icoon met daarachter een cijfer te tonen. Een screenreader leest dit voor als “Icoon spreekwolkje, 10” en maakt niet duidelijk waar dit cijfer voor staat. Door een toelichtende tekst toe te voegen aan het icoon (“Aantal reacties op dit artikel:”) is dit wel duidelijk.

Nog schrijnender zijn knoppen met enkel een icoon, zoals in de afbeelding hieronder van een ‘vind ik leuk’-knop. Visueel gezien maakt de context de functie van de knop duidelijk. Maar voor bezoekers met screenreader is dit een stuk lastiger te doorgronden: wat doet een knop met omschrijving ‘icon-heart’? De afbeelding hieronder illustreert hoe de structuur kan worden aangepast om de knop toegankelijker te maken.

Met de toevoeging van de tekst vertolkt het icoon in de afbeelding hierboven enkel nog een decoratieve functie. Om te voorkomen dat dit soort elementen, die onnodig en afleidend zijn ten opzichte van de echte inhoud, worden voorgelezen door screenreaders is het mogelijk om deze te verbergen voor toegankelijkheidssoftware via het `aria-hidden`-attribuut. Zo blijft de toegankelijke versie van de pagina beknopt, gefocust op de inhoud en zonder onnodige afleiding.

Samengevat is het essentieel dat iedere gebruiker alle content op een pagina tot zich kan nemen en kan begrijpen. Hier zijn designoplossingen voor, zoals een juist contrast en lettergrootte, maar er ligt ook zeker een verantwoordelijkheid bij de technische implementatie om naast de standaard visuele weergave ook alternatieve (tekstuele) vormen aan te bieden.

Een muis of andere ‘point-and-click’-devices (zoals touchpads) zijn niet de enige manier om te navigeren door een pagina. Veel mensen gebruiken enkel het toetsenbord. Bij toetsenbordnavigatie wordt er tussen ‘focusable’ elementen gesprongen (knoppen, links, formulierelementen of elementen waar dit specifiek voor is aangezet). Aangezien het mogelijk is om hierdoor flinke stukken van de pagina over te slaan is het essentieel om visueel aan te geven waar men zich bevindt, om niet te verdwalen. Vanuit de browser krijgen deze 'focusable' elementen al een standaard focus vormgeving mee, maar het is ook mogelijk om zelf vormgeving die wellicht beter past binnen de huisstijl toe te passen.

Enkele voorbeelden van het verschil in vormgeving tussen de standaardweergave en ‘hover/focus’-weergave van 'focusable' elementen.

Naast het visueel duidelijk maken waar de bezoeker zich op de pagina bevindt, is het belangrijk om rekening te houden met de volgorde van elementen op de pagina. Denk aan een pop-up met een sluitknop. Vaak staat de sluitknop rechts bovenaan. Het is een optie om het element in de structuur als eerste te plaatsen om zo het toepassen van de vormgeving te versimpelen. Dat is niet logisch voor gebruikers van screenreaders. Deze krijgen kort na het openen van de pop-up direct de optie te horen om het weer te sluiten. Je zou echter verwachten eerst de inhoud van de pop-up te horen om vervolgens actie te moeten ondernemen, zoals sluiten. Door alle acties onderin te plaatsen, biedt je ook de mogelijkheid voor éénrichtingsnavigatie. Daarmee ga je alleen vooruit in de tabstructuur in plaats van steeds vooruit (‘tab’) en weer achteruit (‘shift + tab’).

Kijk daarom goed naar welke rol de structuur voor zijn rekening neemt, en welke rol de vormgeving heeft. Er zijn de afgelopen jaren steeds meer manieren toegevoegd in Cascading Style Sheets (CSS) om de volgorde van elementen op een pagina aan te passen. Zo is het redelijk simpel geworden om de volgorde volledig om te keren in vergelijking tot de structuur. Hier moet wel zorgvuldig mee worden omgegaan. Een gebruiker heeft een bepaalde verwachting van de navigatie. Vooral wanneer er genavigeerd wordt via het toetsenbord, is de verwachting dat dit gebeurt van boven naar beneden en van links naar rechts. Mocht door een verschil in structuur en vormgeving plots een ‘tab’ (dus navigeren naar beneden of naar rechts) resulteren in een verspringing terug naar boven of naar links, dan kan dit voor verwarring en onduidelijkheid zorgen.

Skiplinks

Naast het juist structureren van navigatie, is het aan te raden om extra opties toe te voegen om het navigeren zelf gemakkelijker en aangenamer te maken. Zo zullen screenreaders na iedere paginanavigatie (dus van de ene naar de andere pagina) continu bovenaan de pagina beginnen met voorlezen. Bij het eerste paginabezoek kan het nog gewenst zijn om te ontdekken welke navigatiemogelijkheden er zijn, maar na een aantal verdiepende paginabezoeken wordt het vervelend om steeds het volledige hoofdmenu link voor link aan te horen of over te slaan.

Je kunt dit voorkomen door het gebruik van zogeheten 'skiplinks', die (zoals de naam al doet vermoeden) als doel hebben om delen van de pagina over te slaan. Deze links staan helemaal bovenaan de pagina en zijn standaard alleen zichtbaar voor screenreaders en wanneer deze door navigeren via het toetsenbord gefocust zijn. De meest voorkomende implementatie is het doorspringen naar de daadwerkelijke content waardoor de hoofdnavigatie kan worden overgeslagen.

Kortom: vergeet nooit dat de muis niet de enige manier is om te navigeren en dat altijd duidelijk moet zijn waar de bezoeker zich op de pagina bevindt. En om het navigeren voor je bezoeker aangenamer en efficiënter te maken, geef je de mogelijkheid om (vooral herhalende) stukken te kunnen overslaan.

Het is belangrijk om jouw digitale dienst of product toegankelijk te maken voor zoveel mogelijk mensen. In sommige gevallen is dit zelfs verplicht. En wij verwachten dat deze verplichtingen in de toekomst alleen maar uitgebreider zullen worden en voor meer sites en apps zullen gaan gelden. Vooral op het gebied van het ondersteunen van mentale beperkingen zien wij nog grote stappen voorwaarts.

De Nederlandse inzet om mensen met een beperking te ondersteunen komt voort uit de Europese toegankelijkheidsrichtlijn. Deze richtlijn gaat verder dan alleen websites en apps. Ook bijvoorbeeld geldautomaten, smartphones, tv’s en streaming devices, diensten voor vervoer, bankdiensten, e-boeken en e-commerce moeten voor iedereen toegankelijk worden. We zien echter een convergentie van technologieën. Websites en apps worden steeds meer gebruikt om meerdere van deze functies te vervullen, denk aan tv-kijken op je telefoon of betalen met een app. Ook vanuit dit perspectief zal er waarschijnlijk meer regelgeving ontstaan om ook deze digitale diensten toegankelijk te laten zijn.

Voor het bedrijfsleven is het momenteel nog een keuze om digitale producten wel of niet toegankelijk te maken. Wij adviseren een toegankelijke website of app, zodat jouw digitale dienst of product door zoveel mogelijk mensen te gebruiken is!