Voldoet jouw website al aan de nieuwe wet?

Maar hoe zit de wetgeving in elkaar? Hoe wordt een website of applicatie toegankelijk gemaakt? En hoe kun je zien of een website aan de gestelde eisen voldoet? Allemaal vragen die in deze blog worden beantwoord. Daarnaast wordt er verder uitleg gegeven over diverse principes en nemen we een duik in de techniek die erachter schuilgaat. Ook worden er voorbeelden gegeven over hoe wij dit alles hebben geïmplementeerd op deze website.

De meeste mensen ondervinden geen problemen tijdens het dagelijks gebruik op het web. Daarmee is de kans groot dat jij, de lezer, je in de volgende situatie herkent:

Je bent op zoek naar een antwoord op een vrij specifieke vraag, hierdoor pak je jouw telefoon en surft naar Google. Via Google typ je trefwoorden of de gehele vraag in. Binnen een oogopslag heb je een aantal sites gezien waar je het antwoord op meent te vinden. Je klikt het eerste resultaat aan, en na deze site een aantal seconden gescand te hebben, weet je al dat je het antwoord op je vraag hier niet zal vinden. Daarom navigeer je terug en selecteer je het tweede resultaat, en zoek je op deze pagina naar je antwoord. Dit zet zich voort totdat je antwoord op je vraag hebt. Hier ben je een minuut, hooguit twee, mee bezig.

Hetgeen hierboven staat beschreven is echter niet voor iedereen het geval. Mensen met een beperking hebben hier meer moeite mee. Hoewel Google zich altijd sterk inzet om voor iedereen toegankelijk te zijn, is dat voor de websites aan het andere eind, de websites die jouw antwoord bevatten, niet zo vanzelfsprekend.

De websites zijn goed geoptimaliseerd omtrent Search Engine Optimization (SEO), waardoor ze bovenaan de resultaten in Google terecht zijn gekomen, maar dat is geen hint dat ze goed in gebruik zijn per se. Het kan zijn dat de inhoud van de website niet te bereiken is zonder de muis te gebruiken, dat de tekst te klein is en niet door de gebruiker is aan te passen, of dat afbeeldingen op de site geen onderschrift bevatten. Dit resulteert in het feit dat mensen met een visuele, motorische of andere beperking de site niet kunnen gebruiken zoals is bedoeld, en daarmee niet de inhoud tot zich kunnen nemen.

Om ervoor te zorgen dat de online producten en diensten van de overheid en overheidsinstanties wel door iedereen te gebruiken is, bestaat er wetgeving.

Op 14 juli 2016 trad het VN-verdrag Handicap in werking in ons land. Dit verdrag bevordert, beschermt en waarborgt de rechten van mensen met een lichamelijke of verstandelijke beperking. Het beschrijft waaraan onze overheid dient te voldoen om ervoor te zorgen dat het de positie van individuen met een handicap verbetert. Naast het feit dat deze groep het recht heeft zelfstandig te wonen, naar school te gaan en het openbaar vervoer te gebruiken, beschrijft het verdrag dat zij zelfstandig besluiten moeten kunnen nemen, en dat zij ondersteund dienen te worden indien zij daar niet zelf toe in staat zijn. Alle stemlokalen zijn hierdoor dermate gelegen en ingericht om ieder persoon in staat te stellen hun stem uit te brengen; om even de context te schetsen.

De wetgeving in Nederland heeft zich in de loop der jaren verder ontwikkeld. Vanaf 1 januari 2017 moeten alle openbare gebouwen verplicht toegankelijk zijn. Denk hierbij aan supermarkten met paden die breed genoeg zijn voor rolstoelgebruikers, toegankelijke toiletten en hellingen in plaats van opstapjes in de horeca, maar ook brailletekst in liften voor blinden en slechtzienden. Echter dienen niet alleen gebouwen toegankelijk te zijn vanaf deze datum. Toegankelijkheid is tevens digitaal de algemene norm geworden voor bedrijven en organisaties van de overheid; zij dienen hierdoor hun producten en diensten toegankelijk aan te bieden.

De algemene norm omtrent toegankelijkheid is vanaf 23 september 2019 verplicht voor alle nieuwe interne en externe websites en webapplicaties van overheidsinstanties, of partijen in dienst van de overheid. Externe digitale producten zijn openbaar en door iedereen te bezoeken, en interne omgevingen zijn enkel te gebruiken door een selectieve groep, bijvoorbeeld het personeel van een bedrijf. Deze verplichting geldt voor de voornoemde type websites die na 23 september 2018 zijn gepubliceerd, vanaf 23 september 2020 dienen ook de omgevingen die vòòr 23 september 2018 zijn gemaakt aan de gestelde richtlijnen te voldoen.

In totaal bestaan er vier hoofdrichtlijnen in digitale toegankelijkheid. Websites en applicaties hebben te maken met de Web Content Accessibility Guidelines (WCAG), waar in 2018 de versie 2.1 van is gepubliceerd. Deze term is overkoepelend voor alle richtlijnen waar ontwerpers en ontwikkelaars rekening mee dienen te houden voor een toegankelijke digitale omgeving. Enkele voorbeelden zijn:

In nieuwste versie van WCAG zijn ook mobiele toestellen meegenomen en wordt er extra aandacht gegeven aan content voor gebruikers met visuele achterstand.

Ruim de helft van de gebruikers wereldwijd maakt gebruik van een mobiele telefoon als zij het web betreden. De overige helft is gevuld met gebruikers van desktops, tablets en minder conventionele apparaten. Meer dan de helft van de mensen maakt dus geen gebruik van een muis als zij een website bezoeken. In plaats daarvan interacteren zij met hun vinger of een stylus, en dat op een scherm kleiner dan dat van een PC.

Knoppen, invoervelden en dergelijke dienen groot genoeg te zijn om met gemak aan te kunnen raken. De norm die hiervoor wordt aangehouden is een minimum van 48 pixels, in de breedte en hoogte. Gemiddeld genomen is dit de grootte van het gedeelte van je vinger wat in aanraking komt met het scherm.

Blinden en slechtzienden moeten ook gebruik kunnen maken van de online wereld. Voor deze groep bestaat diverse hard- en software. Zo vertalen braille terminals de inhoud van een website naar fysieke brailletekens, zodat deze waar te nemen zijn door met de vingers te voelen. Daarnaast zijn er softwareoplossingen die de website voorlezen, schermlezers genaamd. Net zoals de navigatie in je auto, is hetgeen uitgesproken wordt allemaal gegenereerd. Dit resulteert in een ‘computerstem’, wat voor sommige gebruikers misschien even wennen is. Maar het voordeel hiervan is dat het tempo van de stem in te stellen is. Er zijn zelfs schermlezers die meerdere, zowel mannelijke als vrouwelijke stemmen aanbieden.

Apple maakt gebruik van VoiceOver voor hun producten, en Google kent TalkBack voor Android en ChromeVox voor hun Chrome browser. Ook zijn er schermlezers te verkrijgen van andere software bedrijven. Ze lossen hetzelfde probleem op, maar het verschil tussen de schermlezers ligt in de stem die spreekt en de instellingen.

Ondanks het feit dat een groot deel van de wereld gebruik maakt van een desktop, betekent dit niet dat iedereen gebruik maakt van een computermuis. Mensen die in het gips zitten na een botbreuk zullen niet altijd in staat zijn een muis te gebruiken. Ook mensen die lijden aan de ziekte van Parkinson, of een andere aanleiding voor een tremor hebben, kunnen moeite ervaren bij de bediening van een muis.

Het indrukken van een knop vereist minder inspanning en precisie is niet van essentie. Om deze redenen navigeren zij een website of applicatie aan de hand van het toetsenbord. De Tab-toets speelt daar een heel belangrijke rol. Door op deze knop te drukken, verschuift de focus binnen het document naar voren. Met de combinatie Shift + Tab verschuift de focus naar achter. De pijltjestoetsen regelen de scroll positie op de pagina, en met de Enter-toets en spatiebalk worden interacties uitgevoerd. Het is erg belangrijk dat de volgorde van de navigatie aan de hand van het toetsenbord op een logische manier verloopt, anders stoort de gebruiker zich aan de chaotische structuur.

Ook bestaan er apparaten voor mensen met een zwaar lichamelijk handicap, bijvoorbeeld mensen die vrijwel volledig verlamd zijn. Het betreft speciale hardware waar maar een enkele knop aanwezig is. Ook zijn er varianten waar meer knoppen aanwezig zijn. Hiermee kunnen zij met hun hoofd, of ander werkend lichaamsdeel, de knop indrukken, en zo door de digitale omgeving navigeren. Deze apparaten worden switches genoemd. Software gekoppeld aan switches helpt redelijk met navigeren, maar — net als bij de toetsenbordnavigatie — is ook hier de structuur van de code om te navigeren van groot belang.

Er bestaan dus meerdere technieken en hulpmiddelen om mensen te voorzien van een goede online ervaring. Helaas werken deze middelen niet vanzelf. De ontwerper van een digitaal product dient rekening te houden met deze gebruikersgroep, en de ontwikkelaar zal datgene op een correcte manier moeten programmeren.

De structuur van een website of webapplicatie wordt aangebracht door middel van HyperText Markup Language (HTML). In deze computertaal geeft een ontwikkelaar aan of een onderdeel van de website, element genoemd, een paragraaf, een knop, of een ander type is. De meest recente versie van de taal, HTML5, heeft meer van deze elementen toegevoegd. Deze elementen krijgen standaard meer semantische waarde, waardoor de ontwikkelaar deze niet later hoeft toe te voegen.

Hieronder een voorbeeld van de verschillende versies van HTML. In allebei de code blokken staat aangegeven hoe een artikel in de betreffende computertaal wordt aangemaakt. Alle tekst en code wat ingesprongen is, bevindt zich binnen het element wat een enkele stap minder is ingesprongen.

In HTML4, nu verouderd, is het overkoepelende ‘parent’ element een ‘division’ element; <div>. Dit element kent geen semantische waarde, in tegenstelling tot het specifieke artikel element; <article>:

Voordeel van HTML5, boven voorgaande versies, is dat webbrowsers, zoekmachines, en hulpmiddelen voor mensen met een beperking, vanzelf waarde kunnen geven aan deze semantisch correcte elementen. Een zoekmachine weet hiermee direct dat een artikel zich op de pagina bevindt. Schermlezers en andere hulpmiddelen geven aan de gebruiker door dat hetgeen in het <article> element staat onderdeel uitmaakt van een artikel.

In het eerste kwartaal van 2014 publiceerde het World Wide Web Consortium (W3C), de organisatie achter het wereldwijde web, het “Web Accessibility Initiative - Accessible Rich Internet Applications” als een nieuwe webstandaard. Een hele mondvol; daarom is dit verkort tot het acroniem WAI-ARIA. Het beschrijft aan ontwikkelaars van websites en webapplicaties hoe semantiek en metadata aan HTML-elementen toegevoegd kan worden, bovenop de standaard waardes die de voornoemde HTML-elementen bieden. Hierdoor kan een ontwikkelaar een digitaal product van hogere toegankelijkheid voorzien dan de browser initieel aanbiedt.

Het Web Accessibility Initiative bestaat echter wat langer. In de herfst van 1996, vijf jaar na de lancering van het wereldwijde web, schreef Tim Berners-Lee, de uitvinder van het web, het volgende: “The emergence of the World Wide Web has made it possible for individuals with appropriate computer and telecommunications equipment to interact as never before. It presents new challenges and new hopes to people with disabilities.” Niet veel later werd het initiatief officieel gelanceerd. Hier werden toegankelijkheid standaarden voorgoed naar HTML gebracht. Over de jaren zijn deze standaarden, zoals eerder genoemd, alleen maar verbeterd, inclusief de meest recente versie: HTML5.

Een voorbeeld van een WAI-ARIA techniek, is een groep van HTML-attributen die de naam ‘aria-’ bevatten. Hiermee wordt extra informatie gegeven over de rol, functionaliteit of status van een specifiek element. Een nietszeggend <div> element kan daarmee door schermlezers ineens als een knop geïnterpreteerd worden. Dat ziet er als volgt uit:

Dit voorbeeld is zeer gesimplificeerd, maar het biedt een duidelijke indicatie over het gebruik van de ARIA attributen. Het is aan te raden om standaard HTML5 te kiezen boven het gebruik van ARIA attributen. Maar lang niet alle elementen uit de selectie van HTML5-elementen zijn per definitie volledig toegankelijk. Een navigatie dient voorzien te zijn van een label, om aan te geven of het de hoofdnavigatie betreft, of een andere vorm van navigatie. In de praktijk ziet dat er zo uit:

Het <nav> element staat voor navigatie, en het ‘aria-label’ attribuut beschrijft om wat voor navigatie het gaat. Dit wordt ook door de schermlezer voorgelezen aan de gebruiker.

Er bestaat een hele lijst aan attributen om toegankelijkheid te verbeteren. Deze lijst, en meer over het onderwerp, is te vinden via de landingspagina van de ARIA rubriek van de MDN Web Docs: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA

Nu een meer technische blik op het hoofdonderwerp. Browsers ‘lezen’ de pagina van een website, die is opgebouwd uit HTML-elementen, van boven naar beneden; eigenlijk zoals wij mensen dat ook doen. Hieruit wordt een Document Object Modal (DOM) boomstructuur opgezet. In deze DOM structuur worden alle relaties tussen de diverse HTML-elementen in kaart gebracht: Waar ieder element zich bevindt, en wat de bovenliggende elementen zijn.

Er is nog een structuur die de browser genereert: De Accessibility Tree. Net als de DOM is deze structuur een overzicht van alle relaties die tussen elementen bestaat, echter geheel gericht op de toegankelijkheid van de website of applicatie. Dit is hetgeen browsers beschikbaar stellen voor schermlezers en andere hulpmiddelen voor toegankelijkheid. Aan de hand van deze structuur kan de browser afleiden naar welk element de focus dient te gaan, wanneer de Tab-toets wordt ingedrukt, of welke tekst er in een knop staat aangegeven. Ook staat er beschreven aan welk webadres een link gekoppeld is, en of een selectievakje actief staat. Het is een belangrijk principe die het web voor een zo groot mogelijk publiek toegankelijk maakt.

Om softwareontwikkelaars bij te staan in dit ingewikkelde onderwerp, heeft een ontwikkelaar uit de Verenigde Staten, Dave Rupert, begin 2013 een initiatief gelanceerd; het “Accessibility Project” genaamd. Deze naam wordt afgekort tot het “A11Y Project”. Het nummer elf tussen de letters ‘A’ en ‘Y’ staat voor het aantal letters tussen de ‘A’ en ‘Y’ van “Accessibility”. Het initiatief is uitgegroeid tot een organisatie met drie hoofdprincipes:

Er zijn meerdere partijen die zich actief inzetten voor toegankelijkheid, met de principes van het A11Y Project in gedachten. Een van deze partijen is Google. In hun YouTube video’s over het onderwerp, vertelt Rob Dodson in korte video’s wat de beste manieren zijn om toegankelijkheid aan een project toe te voegen. Bekijk de introductie van Google's A11Ycasts via de onderstaande ingesloten YouTube video:

Ook wij streven ernaar de inhoud van onze website aan een zo’n groot mogelijk publiek te bieden. Tijdens de ontwikkeling van de website heeft de algemene toegankelijkheid daarom een grote rol gespeeld. Ieder onderdeel van de website dient op een logische positie te staan en op de correcte manier opgebouwd te worden, zodat er geen problemen ontstaan waar de gebruiker uiteindelijk last van heeft.

De website is volledig te besturen met een toetsenbord en speciale switch hardware, bovenop de ondersteuning van een muis en andere aanwijzers. Alle informatie die wij bieden, zijn door het indrukken van de verschillende navigatietoetsen te bereiken. Alle interactieve elementen op de website geven feedback aan de gebruiker als het focus heeft, dit gebeurt wanneer de Tab-toets positie zich op dat specifieke element bevindt. Alles wat gefocust kan worden, is interactief. Dat wil zeggen dat de gebruiker actie kan ondernemen op hetgeen gefocust is met de Enter-toets of spatiebalk. Wij hebben tevens een aantal gebruiksvriendelijk oplossingen doorgevoerd omtrent toetsenbordnavigatie. Als er bijvoorbeeld een overliggend venster wordt geopend, dan verschuift de focus automatisch naar de knop om dit venster weer te sluiten, zo kan de gebruiker terug naar de inhoud van de website met een enkele druk op de knop, in het geval hij per ongeluk het overliggende venster heeft geopend.

Alle inhoud wat buiten het scherm valt, wordt wel gelezen door de browser, omdat de elementen gewoon aanwezig zijn in de HTML-structuur. Wij hebben echter instructies meegegeven dat deze niet te bereiken zijn, totdat deze worden aangevraagd. Een voorbeeld hiervan is het menu van de website instellingen. Dit uitschuifbare menu is te vinden aan de uiterst rechtse kant van de hoofdnavigatie, het bevat een icoon van een tandwiel.

Afbeeldingen die worden weergegeven op onze site, zijn tevens voorzien van een zogeheten ‘alt-tekst’, kort voor alternatieve tekst; dit is een omschrijvende tekst, specifiek voor de afbeelding in kwestie. In het geval de afbeelding niet kan worden geladen, dan wordt deze tekst weergegeven, naast een icoontje dat aangeeft dat het een afbeelding betreft. Deze tekst wordt tevens door schermlezers gebruikt om de blinde of slechtziende gebruiker te informeren over de afbeelding op de pagina.

Alle afbeeldingen die door onze content manager te uploaden en beheren zijn, hebben een invoerveld waar de alternatieve tekst kan worden ingevuld.

Toegankelijkheid voor mensen met een visuele beperking is meer dan het begrip schermlezer. Alle tekstuele inhoud dient groot genoeg te zijn, en er dient rekening gehouden te worden met mensen met een vorm van kleurenblindheid. In Nederland is ongeveer 1 op de 12 mannen kleurenblind. Bij vrouwen is dit 1 op de 200. Het grote verschil tussen man en vrouw heeft te maken met het feit dat mannen, per cel, een X en Y chromosoom hebben, en vrouwen twee X chromosomen.

Er zijn meerdere soorten kleurenblindheid, voor iedere additieve kleur (rood, groen, blauw) bestaat er een vorm van kleurenblindheid waar een van deze kleuren minder of niet wordt waargenomen. De wetenschappelijke naamgeving voor deze vormen zijn:

Buiten het gebruik van kleur in afbeeldingen, maken wij voornamelijk gebruik van zwart/donkergrijs, wit en de kleur oranje uit onze huisstijl. Het is van belang dat deze kleuren op zichzelf, maar ook naast elkaar, goed te onderscheiden blijven, zodat de inhoud van de website goed leesbaar blijft.

Wij hebben goed gekeken naar de leesbaarheid van onze website. De website maakt gebruik van leesbare lettertypes en een tekstgrootte die iets hoger ligt dan bij de gemiddelde website. In het geval dat de lettergrootte de gebruiker niet bevalt, heeft hij de mogelijkheid dit te wijzigen. Op apparaten met een aanraakscherm, maar ook op desktops en laptops, kunnen gebruikers inzoomen. Door respectievelijk met twee vingers de pagina te vergroten, of de toetscombinatie ‘Ctrl +’ (‘Cmd +’ op MacOS) te gebruiken. Dit vergroot de tekst door de gehele website in te zoomen, maar wat als de gebruiker enkel het lettertype groter of kleiner wil maken? Voor hen hebben wij een lettergrootte selectie aangemaakt in de website instellingen, te vinden onder het tandwieltje aan de rechterkant van de hoofdnavigatie.

Het volgende is minder relevant aangaande de toegankelijkheid van de website: Wij hebben een donker thema geïmplementeerd voor gebruikers die hier een voorkeur voor hebben. Sommigen vinden het prettiger om witte tekst op een donkere achtergrond te hebben, vooral als zij zich bevinden in een donkere ruimte; bijvoorbeeld als zij in bed liggen en nog even met hun telefoon internetten. Door de donkere achtergrond wordt de gebruiker niet overladen door een zee van wit licht. Daarnaast draagt het donkere thema bij aan een langere batterijduur.

Het donkere thema is, net als de lettergrootte, te activeren in de website instellingen.

Dit is niet het enige waar wij rekening mee hebben gehouden. De volgende lijst aan toegankelijkheidsverbeteringen zijn overigens geïmplementeerd.

Naast dit alles hebben wij een zekere hoeveelheid aan kleinere implementaties doorgevoerd in de code van de website. Deze zijn echter te technisch om beknopt in detail te omschrijven.

Hoe kom je erachter of een digitale omgeving voldoet aan richtlijnen omtrent toegankelijkheid? Het is moeilijk om je voor te doen als een gebruiker met een (visuele) beperking als je hier zelf niet dagelijks mee te maken hebt. Om deze reden zijn er meerdere online tools beschikbaar die je hierin kunnen assisteren. Deze voeren een analyse uit door te kijken naar de code waar de website of applicatie op draait, en of deze voldoet aan de gestelde eisen van WCAG 2.0 of andere versies van deze richtlijn.

Tijdens de ontwikkeling van de Create website, maakten wij gebruik van Lighthouse. Dit is een ingebouwd hulpmiddel in de ontwikkelingsomgeving van de Google Chrome browser. Met Lighthouse kan een ontwikkelaar de prestaties, SEO en toegankelijkheid van een webomgeving meten. Van de resultaten wordt netjes een rapport gegenereerd.

Zoals hiervoor genoemd, zijn er ook online oplossingen te vinden om de toegankelijkheid te meten. Op de Accessibility Checker website (https://achecker.ca/ ) hoef je enkel het webadres uit de adresbalk van de webomgeving te kopieëren en in hun invoerveld te plakken. Vervolgens leveren zij gratis een rapport aan de hand van de WCAG richtlijnen. Daarnaast biedt het W3C een lijst met verschillende tools die je kunnen ondersteunen, deze vind je op https://www.w3.org/WAI/ER/tools/ Ook deze zijn allemaal gratis te gebruiken.

Nu heerst misschien de vraag: Wat gaat dit alles kosten? Ondanks het feit dat ieder individu gebruik moet kunnen maken van je website of applicatie, is het een realistische vraag. Er kan namelijk een groot percentage van de ontwikkeling in het toegankelijk maken van een product zitten, waardoor de kosten omhoog kunnen schieten.

Digitale producten van overheidsinstanties en partijen die samenwerken met de overheid, en daarmee een grote gebruikersgroep hebben, zijn per wet verplicht toegankelijk te zijn vanaf 23 september 2019. Er is dus sprake van een vereiste, en niet iets dat van een offerte geschrapt mag worden. Het is aan de ontwikkelaars hier goed mee om te gaan, en tijdens het programmeren al rekening met toegankelijkheid te houden. Als dit niet wordt gedaan, dan moet er in een later stadium tijd voor worden vrijgemaakt. Het aantal extra uren die besteed wordt aan het toegankelijk maken van bestaande code is veel groter dan wanneer het ingecalculeerd is en direct wordt uitgevoerd.

Bij Create houden wij rekening met toegankelijkheid vanaf de eerste regel code die wordt geschreven. Wij maken gebruik van de toegankelijke voordelen van HTML en ARIA, en bouwen de architectuur van een applicatie, van zowel de pagina’s als de inhoud daarvan, op een begrijpbare manier op. Zo zorgen wij ervoor dat mensen met muis, toetsenbord, schermlezer of andere hard- of software alle geboden informatie tot zich kunnen nemen. Hiermee houden we de kosten aangaande toegankelijkheid miniem, zonder dat dit ten nadele van gaat van de algemene toegankelijkheid.

De invoering van de wetgeving betreffende de toegankelijkheid kan even slikken zijn voor ondernemingen die hier rekening mee dienen te houden. Met name als hier niet eerder over na is gedacht. In de eerste instantie lijkt het maar om een kleine groep mensen te gaan, maar dit blijkt dus niet het geval. Er zijn talloze verschillende beperkingen die het dagelijks online leven van deze groep heel moeilijk kunnen maken; van kleurenblindheid en een tijdelijke botbreuk, tot aan volledige blindheid of verlamming.

Het gaat iedere onderneming aan dat hun digitale product door iedereen, of in ieder geval zoveel mogelijk mensen, te gebruiken is. Zo wordt eventuele frustratie bij de gebruiker voorkomen, en kan iedereen de gegeven informatie tot zich nemen. Bovendien kan dit leiden tot een hogere conversieratio.

College voor de rechten van de Mens https://www.mensenrechten.nl/nl/vn-verdrag-handicap Rijksoverheid https://www.rijksoverheid.nl/onderwerpen/rechten-van-mensen-met-een-handicap/gelijke-behandeling-mensen-met-beperking-of-chronische-ziekte https://www.communicatierijk.nl/vakkennis/r/rijkswebsites/verplichte-richtlijnen/digitale-toegankelijkheid https://www.digitoegankelijk.nl/beleid/wet-en-regelgeving/tijdlijn-wet--en-regelgeving Statcounter - Global stats https://gs.statcounter.com/platform-market-share/desktop-mobile-table Wikipedia https://en.wikipedia.org/wiki/Web_Accessibility_Initiative https://en.wikipedia.org/wiki/WAI-ARIA W3C https://www.w3.org/WAI/history The A11Y Project https://a11yproject.com/ Accessibility.nl - Expertisecentrum voor toegankelijke ICT https://www.accessibility.nl/kennisbank/artikelen/kleuren/kleurenblind