Toegankelijkheid en WCAG op je website

De Europese Accessibility Act zet webtoegankelijkheid hoog op de agenda van Belgische en Nederlandse ondernemers. Waar toegankelijkheid volgens de WCAG-richtlijnen (Web Content Accessibility Guidelines) vroeger vaak werd gezien als een optionele extra voor overheidsinstanties, vraagt de wetgeving nu ook van commerciële platformen en webshops dat ze voor iedereen bruikbaar zijn. Voor kmo's betekent dit dat blind vertrouwen op een mooi ontwerp niet langer volstaat.

Veel bedrijven proberen de wetgeving snel af te vinken door een losse plugin of een toegankelijkheidswidget over hun bestaande site te leggen. Zulke tools beloven met een simpel script directe naleving van de regels, maar in de praktijk veroorzaken ze vaak meer problemen dan ze oplossen. Ze vertragen het platform met zware JavaScript-bestanden en lossen de fouten in de feitelijke broncode niet op.

Echte toegankelijkheid begint in de basis van je platform. Door te bouwen met schone code, logische HTML-structuren en een doordacht ontwerp voldoe je niet alleen aan de wettelijke verplichtingen, maar bouw je ook een snellere, beter bruikbare en beter vindbare website. In dit artikel bekijken we wat de wetgeving vraagt en hoe een voor-en-na-transformatie er in de praktijk uitziet.

Wat de wetgeving concreet van ondernemers vraagt

De wetgeving rond digitale toegankelijkheid is gebaseerd op de internationale WCAG-standaarden. In Europa stelt de European Accessibility Act duidelijke eisen aan e-commerce, digitale dienstverlening en publiek toegankelijke applicaties. De kern van deze regelgeving is dat digitale informatie voor iedereen toegankelijk moet zijn, ongeacht visuele, auditieve, motorische of cognitieve beperkingen.

De richtlijnen van WCAG zijn opgebouwd rond vier vaste principes:

• Waarneembaar: Informatie en interface-elementen moeten toonbaar zijn op manieren die gebruikers kunnen waarnemen. Denk aan voldoende kleurcontrast en tekstalternatieven voor afbeeldingen.
• Bedienbaar: De gebruikersinterface en navigatie moeten met verschillende invoerapparaten te bedienen zijn, zoals een toetsenbord of een schermlezer.
• Begrijpelijk: De informatie en de bediening van de interface moeten logisch en voorspelbaar zijn.
• Robuust: De inhoud moet betrouwbaar geïnterpreteerd kunnen worden door een breed scala aan browsers en hulptechnologieën.

Voor de meeste commerciële platformen geldt niveau AA van WCAG als de wettelijke norm. Dit betekent dat niet alleen de hoofdpagina's, maar het volledige traject van navigatie tot afrekenen of contact opnemen aan de standaarden moet voldoen.

Waarom snelle overlays en zware plugins niet werken

Wanneer een ondernemer geconfronteerd wordt met nieuwe wetgeving, is de neiging groot om te zoeken naar een snelle software-oplossing. Op de markt verschijnen veel zogeheten toegankelijkheidswidgets. Dit zijn externe scripts die een knop aan de zijkant van het scherm toevoegen waarmee de bezoeker tekstgrootte of contrast kan aanpassen.

Het probleem met deze overlays is dat ze de onderliggende code van het platform ongemoeid laten. Een schermlezer die door een blinde bezoeker wordt gebruikt, kijkt rechtstreeks naar de HTML-structuur van de pagina. Als een knop is gebouwd als een generieke <div> zonder de juiste functionaliteit, zal een overlay dat niet corrigeren. Bovendien voegt een externe widget vaak honderden kilobytes aan complexe scripts toe, wat de laadtijd van de site negatief beïnvloedt.

Net zoals het toevoegen van zware bibliotheken voor kleine visuele elementen de code vervuilt, zorgt een overlay-plugin voor technische ballast. Een toegankelijke site vereist geen extra laag bovenop de interface, maar een strakke, lichte broncode waarin elke bouwsteen vanaf de basis correct is opgezet.

Een voor-en-na-scenario: van quick fix naar echte toegankelijkheid

Om te begrijpen hoe toegankelijkheid in de praktijk werkt, bekijken we de transformatie van een digitaal platform. In dit scenario vergelijken we de oude situatie met de aanpak en het uiteindelijke resultaat.

De situatie voor de herziening

Het oorspronkelijke platform vertoonde de typische kenmerken van een site die door de jaren heen is dichtgetimmerd met losse modules en kant-en-klare thema-onderdelen:

• Navigatie: Menu's waren enkel bedienbaar met een muis. Bezoekers die met de Tab-toets navigeerden, raakten de focus kwijt omdat er geen visuele indicator was die aangaf welk element geselecteerd was.
• Formulieren: Invoervelden in de checkout en op de contactpagina misten gekoppelde <label>-elementen. Een schermlezer kon niet voorlezen wat er in een specifiek veld ingevoerd moest worden.
• Visuele keuzes: De merkkleuren werden gebruikt zonder rekening te houden met contrastverhoudingen. Lichte grijze tekst op een witte achtergrond zorgde voor een slechte leesbaarheid.
• Noodgreep: Om aan de regels te voldoen was een externe overlay-plugin geïnstalleerd. Dit vertraagde de laadtijd aanzienlijk en leidde tot foutmeldingen bij de verwerking van formulieren.

De aanpak

In plaats van de overlay te behouden, werd gekozen voor een grondige sanering van de broncode. De externe plugin werd volledig verwijderd en de interface-onderdelen werden opnieuw opgebouwd op basis van semantische HTML en maatwerk-componenten met React en Tailwind CSS.

Eerst werd de HTML-structuur hersteld. Klikbare elementen die als <div> of <span> geprogrammeerd waren, werden vervangen door echte <button>- en <a>-tags. Dit geeft de browser direct de juiste instructies voor toetsenbordbediening en schermlezers.

Daarna werd het kleurenpalet aangepast. Binnen de Tailwind-configuratie werden kleurvariabelen vastgelegd die gegarandeerd voldoen aan de minimale contrastverhouding van 4,5:1 voor normale tekst. Tot slot werden alle interactieve elementen voorzien van duidelijke, aanpasbare focus-states via CSS, zodat het altijd helder is welk onderdeel actief is tijdens het navigeren met het toetsenbord.

De situatie na de herziening

Het resultaat na deze aanpak laat een duidelijk verschil zien:

• Volledige toetsenbordbediening: Het hele platform, inclusief complexe formulieren en pop-ups, is vlot te doorlopen zonder muis.
• Schone broncode: Door het schrappen van de externe widget en het opschonen van overbodige scripts laadt de pagina aanzienlijk sneller.
• Automatische naleving: Het platform voldoet op broncodeniveau aan de WCAG AA-eisen, zonder afhankelijk te zijn van externe leveranciers of maandelijkse software-abonnementen voor widgets.
• Beter voor zoekmachines: De semantische structuur die nodig is voor toegankelijkheid stelt ook de zoekmachines van Google in staat om de inhoud van de pagina beter te begrijpen en te indexeren.

De praktische checklist voor je eigen platform

Als je wilt controleren of jouw website of applicatie klaar is voor de wettelijke eisen, zijn er enkele belangrijke punten waar je direct op kunt letten.

Semantische HTML

Gebruik HTML-elementen waarvoor ze bedoeld zijn. Een kop is een <h1>, <h2> of <h3>, een navigatiemenu staat in een <nav>, en een actieknop is altijd een <button>. Vermijd het gebruik van generieke elementen met JavaScript-events voor interactieve onderdelen.

Contrast en leesbaarheid

Zorg ervoor dat de tekstkleur voldoende contrasteert met de achtergrond. Test niet alleen de standaardtekst, maar ook de status van knoppen bij een hover- of focus-actie. Gebruik een schreefloos en voldoende groot lettertype voor de lopende tekst.

Toetsenbordnavigatie en focus

Druk op je eigen website een paar keer op de Tab-toets. Kun je zien waar je bent? Kun je het menu openen en door de formulieren navigeren? Als de blauwe of zwarte rand rond actieve elementen is uitgeschakeld in de CSS zonder dat er een alternatief voor is gebouwd, is de site niet toegankelijk voor toetsenbordgebruikers.

Formulieren en foutmeldingen

Ieder invoerveld heeft een bijbehorend label dat via het for-attribuut is gekoppeld aan het id van het veld. Wanneer een gebruiker een fout maakt bij het invullen van een formulier, moet de foutmelding niet alleen met kleur worden aangegeven, maar ook met duidelijke tekst.

Toegankelijkheid inbouwen vanaf het eerste ontwerp

Het achteraf toegankelijk maken van een bestaande, verouderde website is vaak duurder en tijdrovender dan het correct opzetten van een nieuw platform. Wanneer je bouwt met maatwerk op basis van moderne technologieën zoals React, TypeScript en Tailwind CSS, kun je toegankelijkheid direct meenemen in de architectuur.

Door componenten modulair op te bouwen en te voorzien van de juiste ARIA-attributen waar nodig, blijft het platform ook bij toekomstige uitbreidingen voldoen aan de WCAG-normen. Schone code en toegankelijkheid gaan hand in hand: ze zorgen voor betere prestaties, minder technisch onderhoud en een optimale ervaring voor elke bezoeker.

Wil je weten hoe jouw huidige website of platform scoort op het gebied van toegankelijkheid en structuur? Neem contact op voor een gratis gesprek van dertig minuten waarin we de technische staat van je platform bespreken.