Een toegankelijke website kan iedereen gebruiken, ook mensen die slecht zien, geen muis gebruiken of moeite hebben met lezen. Je begint met een overzicht en een eerste eigen controle. Daarna laat je testen, maak je afspraken met je webbouwer en leveranciers, en houd je het elk jaar bij.
Een website is toegankelijk als iedereen hem kan gebruiken. Ook mensen die blind of doof zijn, geen muis kunnen gebruiken of moeite hebben met lezen. Sommigen gebruiken hulptechnologie: software of apparaten die helpen bij het gebruik van een computer. Denk aan een schermlezer die de pagina voorleest, een vergrootprogramma of spraakbesturing.
Wat een website toegankelijk maakt, staat in een internationale standaard: de Web Content Accessibility Guidelines (WCAG). Die rust op vier principes: waarneembaar, bedienbaar, begrijpelijk en robuust. Ken je WCAG nog niet? Lees dan eerst Wat is WCAG?
Het gaat om meer dan de pagina’s die je ziet als je je website opent. Ook je aanmeldformulier, pdf-folders, video’s, apps en het cliëntportaal horen erbij. De Europese norm voor digitale toegankelijkheid, EN 301 549, gaat dan ook niet alleen over websites, maar ook over apps en documenten.
In Nederland hebben 4,5 miljoen mensen een beperking of chronische ziekte. Daarnaast hebben 3 miljoen mensen van 16 tot en met 75 jaar moeite met lezen, schrijven of rekenen, en zij vinden een computer of smartphone vaak ook lastig. Een toegankelijke website helpt ook mensen met een tijdelijke beperking, zoals een gebroken arm.
Voor mensen met een beperking is zelf iets digitaal regelen nog vaak moeilijk of zelfs onmogelijk. Dat geldt voor overheidszaken, bankzaken, onderwijs en zorg, zo blijkt uit een monitor uit 2024. Iemand kan dan bijvoorbeeld online geen afspraak maken, omdat de patiëntenomgeving niet toegankelijk is.
Ook je organisatie heeft er baat bij, want als mensen meer zelf kunnen regelen, krijg je minder vragen. Het aantal vragen via loket, telefoon of chat kan tot 15% dalen.
En voor jou als hulpverlener verandert er iets in het contact met je cliënt. Kan een cliënt zelf een afspraak verzetten of een formulier invullen, dan hoeft dat niet meer via jou. Samen iets invullen blijft dan een keuze, en is geen noodzaak meer.
Maak iemand verantwoordelijk. Spreek af wie in je organisatie over toegankelijkheid gaat. Zorg dat de directie erachter staat, en vraag om vaste tijd en budget. Die persoon houdt het overzicht en de planning bij, en is het aanspreekpunt als iemand een probleem meldt.
Maak een overzicht van alles wat je online hebt. Denk aan je website, het aanmeldformulier, pdf-folders, video’s en apps. En aan het cliëntportaal: de beveiligde omgeving waar cliënten inloggen. Schrijf bij elk onderdeel op wie het beheert en wie het heeft gebouwd. Kijk meteen welke onderdelen je kunt opheffen of vervangen. Wat je weghaalt, hoef je niet meer toegankelijk te maken.
Kijk vooral kritisch naar pdf’s, want het is bijna nooit nodig om informatie in een pdf te zetten. Een gewone webpagina werkt meestal beter: hij past zich aan een klein scherm aan, en een formulier is op een webpagina makkelijker in te vullen.
Doe zelf een eerste controle. Daar heb je geen technische kennis voor nodig. Loop onze checklist toegankelijke website na. Probeer bijvoorbeeld je aanmeldformulier in te vullen met alleen de Tab-toets. Zoom daarna in tot 200% en kijk of alles nog werkt. Met de Contrastcheck zie je of je tekst genoeg afsteekt tegen de achtergrond. De Taalcheck wijst lange zinnen en moeilijke woorden aan.
Doe het met z’n tweeën: de een test, de ander noteert waar het misgaat. Die lijst heb je straks nodig voor je webbouwer.
Laat een volledig onderzoek doen. Een specialist toetst dan je hele website aan alle eisen van WCAG. Vraag of die de onderzoeksmethode WCAG-EM volgt. Die methode komt van het World Wide Web Consortium (W3C), de organisatie achter WCAG. Automatische testprogramma’s helpen daarbij, maar een mens moet de uitkomst altijd beoordelen. Voor overheidsorganisaties is het advies om zo’n onderzoek minstens eens in de drie jaar te doen.
Een volledig onderzoek kijkt naar de techniek, zoals de formuliervelden, het menu en de zoekfunctie, en naar de inhoud die je zelf plaatst: teksten, afbeeldingen, video’s en pdf’s. Alleen een onderzoek van de techniek, of alleen van de inhoud, is niet genoeg. Vraag ook of de onderzoeker hele taken test, zoals aanmelden van begin tot eind. Een taak die over meerdere pagina’s loopt, voldoet namelijk pas aan WCAG als álle pagina’s voldoen.
Test met de mensen voor wie het is. Vraag cliënten of ervaringsdeskundigen om iets te doen op je website, zoals een afspraak aanvragen. Kijk mee en vraag waar ze vastlopen. Zo leer je hoe mensen je website echt gebruiken. Zorgorganisaties kunnen daarvoor ook de Pharos-praktijkcheck aanvragen. Twee ervaringsdeskundigen en een adviseur van Pharos bezoeken dan de organisatie, en kijken onder meer naar de website en het patiëntenportaal. Lees ook Samen ontwerpen met cliënten.
Begin daar vroeg mee, niet pas als alles af is, want dat levert een betere website op en kost bij het bouwen minder moeite. Maar één persoon spreekt niet voor iedereen met een beperking. Nodig daarom mensen uit met verschillende beperkingen, en combineer wat zij zeggen met een onderzoek aan WCAG. Ga zorgvuldig om met hun tijd, en geef een passende vergoeding.
Begin bij wat mensen het meest nodig hebben. Maak een plan met een volgorde. Pak eerst de pagina’s aan waar mensen iets moeten regelen: aanmelden, contact en direct hulp. Je hoeft niet alles tegelijk te doen. Zorg wel dat je elk jaar verder komt.
Maak afspraken met je webbouwer. Spreek af dat nieuw werk voldoet aan WCAG 2.2 niveau AA. Vraag om bewijs, zoals een onderzoeksrapport. Of laat het werk door een ander controleren. Maak die afspraken vanaf het begin, want ongeveer 67% van de problemen ontstaat al in het ontwerp, en achteraf herstellen kan 4 tot 5 keer zoveel kosten als meteen toegankelijk bouwen. Maak ook afspraken met de leveranciers van andere systemen, zoals het cliëntportaal.
Stuurt een leverancier een algemeen onderzoek van zijn systeem mee? Kijk dan of het ook over jouw versie gaat. Zet je er je eigen logo en huisstijlkleuren in, dan moet je die apart laten onderzoeken. De teksten en afbeeldingen die je zelf plaatst, vallen er ook niet onder. Vragen die je aan een webbouwer of leverancier kunt stellen:
Leer je collega’s toegankelijk publiceren. Iedereen die teksten op de website zet, moet een paar dingen weten. Hoe je een alt-tekst schrijft: een korte beschrijving van een afbeelding voor wie hem niet ziet. Hoe je echte koppen gebruikt. En hoe je linkteksten maakt die zeggen waar ze heen gaan. Schrijf op taalniveau B1, zie Schrijven op B1.
Een goede alt-tekst zegt wat de afbeelding betekent, niet alleen hoe hij eruitziet. Bij een knop met een vergrootglas is “Zoeken” beter dan “vergrootglas”. Vraag je daarom af wat je over de afbeelding zou zeggen als je iemand helpt die de pagina niet kan zien. Met de Alt-tekst hulp schrijf je er een aan de hand van een paar vragen. Laat redacteuren ook een training volgen, of zich inlezen bij Digitoegankelijk.
Zet een toegankelijkheidsverklaring op je website. Daarin staat hoe toegankelijk je website is en wat je nog gaat verbeteren. Ook staat erin hoe bezoekers contact opnemen of een klacht indienen. Overheidsorganisaties moeten zo’n verklaring publiceren, en gebruiken daarvoor de invulassistent van Digitoegankelijk. Veel bedrijven die online iets verkopen, moeten ook een verklaring hebben. Voor andere organisaties is het een goede gewoonte. Met Toegankelijkheidsverklaring maken maak je in een paar stappen een verklaring.
Blijf controleren. Toegankelijkheid is nooit af, want elke nieuwe pagina en elke update kan nieuwe problemen geven. Controleer dus minstens één keer per jaar en werk dan ook je verklaring bij. Overheidsorganisaties moeten in die jaarlijkse update laten zien dat ze vooruitgang boeken, bijvoorbeeld doordat ze gevonden problemen hebben opgelost. Dat is een goede maat, ook als je geen overheid bent.
Een voorbeeld. Een welzijnsorganisatie heeft een wijkteam en een team voor ambulante begeleiding. Een begeleider merkt dat cliënten bellen over het aanmeldformulier op de website. Ze komen er zelf niet doorheen.
De teamleider neemt het op zich. Samen met een collega maakt ze een overzicht: de website, het aanmeldformulier, twaalf pdf-folders, twee uitlegvideo’s en een cliëntportaal van een leverancier. Zeven folders zijn verouderd, die halen ze weg. Van de belangrijkste folder maken ze een gewone webpagina.
Dan proberen ze het aanmeldformulier met alleen de Tab-toets. Bij de geboortedatum lopen ze vast, want die kies je in een kalender die alleen met de muis werkt. Een fout ingevuld veld krijgt alleen een rode rand, zonder uitleg. En bij 200% zoom schuift de chatknop over de knop om te versturen.
Twee cliënten doen mee aan een test. Een van hen ziet slecht en werkt met een vergrootprogramma. Hij mist de foutmelding, omdat die bovenaan de pagina staat en hij alleen een stukje van het scherm ziet. Met de checklist hadden ze dat niet gevonden.
Het aanmeldformulier komt bovenaan het plan. Met de webbouwer spreekt de teamleider af dat het nieuwe formulier voldoet aan WCAG 2.2 niveau AA, en dat een ander het nakijkt. De leverancier van het portaal stuurt een onderzoeksrapport. Maar daarin is het portaal onderzocht zonder de eigen kleuren en het logo van de organisatie, dus dat noteert ze als open punt. In de toegankelijkheidsverklaring staat wat al klaar is en wat nog komt.
Wat zeg je tegen een cliënt die meedoet aan zo’n test? Bijvoorbeeld: “Je test niet jezelf, je test onze website. Loop je vast, dan is dat precies wat we willen weten.” En tegen een collega die opziet tegen het werk: “We doen niet alles tegelijk. We beginnen met aanmelden, want daar lopen mensen nu vast.”
Moeten we voldoen aan WCAG 2.1 of aan WCAG 2.2? Het Besluit digitale toegankelijkheid overheid verwijst via de Europese norm EN 301 549 naar WCAG, en de versie van die norm uit 2021 verwijst naar WCAG 2.1. Op 2 september 2026 verscheen een nieuwe versie, met WCAG 2.2. Die telt mee vanaf het moment dat de Europese Commissie hem officieel aanwijst, en dat werd verwacht op 16 december 2026. Een website die voldoet aan WCAG 2.2, voldoet ook aan 2.1. Laat je iets bouwen, vraag dan dus om 2.2.
Moeten onze pdf-folders ook toegankelijk zijn? Voor overheidsorganisaties wel: alle pdf’s en andere documenten die ze na 23 september 2018 online hebben gezet. Oudere bestanden alleen als mensen ze nog nodig hebben om iets te regelen. Voor een pdf gelden dezelfde eisen als voor een webpagina. Heb je veel oude pdf’s? Ruim dan eerst op wat verouderd is, en maak daarna de belangrijkste bestanden toegankelijk. Voor de rest bied je een toegankelijke versie aan als iemand erom vraagt.
Hoe weet ik wat een onderzoeksrapport echt zegt? Kijk naar de reikwijdte: welke pagina’s, of welke versie van een app, de onderzoeker heeft bekeken. Bij de methode WCAG-EM is dat de eerste stap, dus het hoort in het rapport te staan. Staat jouw aanmeldformulier of jouw versie van het portaal er niet in, dan zegt het rapport daar niets over.
Generator
Zet op een rij wat je organisatie al heeft gedaan om de website toegankelijk te maken, en wat nog moet. Je krijgt een eenvoudige verklaring in gewone taal, als pdf. Voor overheden geldt een eigen, officieel model.
Kleurcheck
Check of je tekst goed te lezen is op de achtergrond. Kies twee kleuren en zie meteen of ze voldoen aan WCAG.
Tekstcheck
Check of je tekst makkelijk te lezen is. Je ziet lange zinnen en moeilijke woorden, met een makkelijker woord ernaast.
Schrijfhulp
Schrijf een goede alt-tekst bij een afbeelding. Beantwoord een paar vragen en je krijgt advies en een voorstel dat je kunt kopiëren.
In een toegankelijkheidsverklaring vertel je hoe goed je website of app werkt voor mensen met een beperking, wat nog niet goed gaat en wanneer je dat oplost. Overheidsorganisaties moeten er een publiceren, net als veel bedrijven die online iets verkopen. Voor andere organisaties is het een eerlijke en nuttige gewoonte.
Een brief, folder of pdf is toegankelijk als iedereen hem kan lezen: met een schermlezer, op een telefoon of met moeite met lezen. Het meeste regel je al in je tekstverwerker, met echte koppen, alt-teksten, genoeg contrast en duidelijke taal. Daarna controleer je het bestand, sla je het goed op als pdf en laat je het lezen door iemand voor wie het is.
Bedienbaar is het tweede principe van WCAG. Iedereen moet je website kunnen gebruiken, ook met alleen een toetsenbord, met spraak of met een trillende hand. Denk aan een zichtbare focus, genoeg tijd en knoppen die groot genoeg zijn. Met een voorbeeld van een cliënt die haar laptop met spraak bedient.
Heb je een idee, mis je iets, of wil je een hulpmiddel uitproberen met je team? Stuur ons een berichtje en vertel in een paar zinnen wat er speelt. We lezen alles en denken graag mee, en het verplicht je tot niets.
