Wat is webtoegankelijkheid? WCAG en inclusief ontwerp uitgelegd

Webtoegankelijkheid betekent websites en apps zo bouwen dat mensen met een beperking ze kunnen gebruiken: of ze nu blind zijn en een schermlezer gebruiken, geen muis kunnen bedienen, een slechtziendheid of kleurenblindheid hebben, doof zijn, of een cognitieve of leerbeperking hebben. In de praktijk gaat het om zaken als tekstalternatieven voor afbeeldingen, voldoende kleurcontrast, formulieren met goede labels, en alles wat alleen met het toetsenbord werkt. De internationale standaard hiervoor is WCAG, de Web Content Accessibility Guidelines van het W3C.

Toegankelijkheid wordt vaak afgekort tot a11y, een afkorting van de Engelse term accessibility: de a, dan 11 letters, dan de y.

Waarom toegankelijkheid ertoe doet als je met AI bouwt

AI-builders zijn goed in apps die er goed uitzien. Toegankelijkheid gaat vooral over dingen die je niet in een screenshot ziet: of een knop echt een knop is, of een invoerveld een label heeft dat een schermlezer kan voorlezen, of je het menu met de Tab-toets kunt bereiken.

Daarom is het belangrijk om het te vragen:

• Het is makkelijk te missen. Een zelfgestylde dropdown kan perfect lijken en zonder muis onbruikbaar zijn. Je merkt het niet tenzij je ervoor test.
• Het is goedkoper om het vroeg goed te doen. Vragen om toegankelijke componenten vanaf de eerste prompt kost bijna niets. Een afgebouwde app achteraf aanpassen betekent elk scherm aanraken.
• Het helpt iedereen. Ondertiteling helpt mensen op luidruchtige plekken, goed contrast helpt mensen met een telefoon in de zon, en duidelijke labels helpen iedereen om formulieren sneller in te vullen.
• Het overlapt met SEO. Goede koppen, beschrijvende links en alt-tekst helpen zoekmachines ook je pagina's te begrijpen; zie SEO voor met AI gebouwde websites.
• Het kan verplicht zijn. Afhankelijk van waar je actief bent en wie je bedient, kan toegankelijkheid een wettelijke verplichting zijn.

Een alledaagse vergelijking

Denk aan de ingang van een gebouw.

Trappen werken prima voor veel mensen. Een hellingbaan werkt voor rolstoelgebruikers, en ook voor ouders met een kinderwagen, bezorgers met een steekwagen en reizigers met koffers. Automatische deuren, duidelijke borden, braille op liftknoppen en goede verlichting halen elk een drempel weg voor iemand.

Webtoegankelijkheid is hetzelfde idee voor digitale ruimtes: de hellingbanen, borden en leuningen van je app. En net als bij een gebouw is het veel makkelijker om een hellingbaan in de plannen op te nemen dan er één toe te voegen nadat het beton is uitgehard.

WCAG in het kort

WCAG wordt gepubliceerd door het Web Accessibility Initiative van het W3C. De huidige versie is WCAG 2.2, voor het eerst gepubliceerd in oktober 2023. Het is achterwaarts compatibel: inhoud die aan WCAG 2.2 voldoet, voldoet ook aan 2.1 en 2.0, en het W3C raadt aan de nieuwste versie te gebruiken. WCAG 2.2 is ook goedgekeurd als internationale standaard, ISO/IEC 40500:2025. Een heel andere WCAG 3 is in ontwikkeling als vroege concepttekst, nog geen afgeronde standaard.

WCAG is georganiseerd rond vier principes, vaak onthouden als POUR:

Elke richtlijn heeft toetsbare succescriteria op drie niveaus:

• Niveau A: het minimum. Als je hier niet aan voldoet, sluit je sommige mensen volledig uit.
• Niveau AA: de gangbare norm, en het niveau waarnaar de meeste wetten en beleidsregels verwijzen.
• Niveau AAA: het hoogste niveau. Het is op sommige plekken nuttig om na te streven, maar het W3C raadt niet aan om het voor hele sites te verplichten, omdat sommige inhoud er niet aan kan voldoen.

WCAG 2.2 voegde negen succescriteria toe aan 2.1, waaronder Target Size (Minimum) op niveau AA: klikbare doelen moeten over het algemeen minimaal 24 bij 24 CSS-pixels zijn, met uitzonderingen, en Accessible Authentication (Minimum), dat inlogstappen beperkt die afhankelijk zijn van geheugen of puzzels, zoals een wachtwoord opnieuw moeten typen terwijl plakken niet is toegestaan. Het verwijderde ook het oude criterium "Parsing" omdat het verouderd was.

Een uitgewerkt voorbeeld: een aanmeldformulier

Hier is een aanmeldformulier zoals een AI het zou kunnen maken, en wat een toegankelijkheidscontrole vindt:

Geen van deze oplossingen verandert veel aan hoe het formulier eruitziet. Allemaal veranderen ze of sommige mensen het überhaupt kunnen gebruiken.

Belangrijke termen

Veelvoorkomende misverstanden

• "Toegankelijkheid is alleen belangrijk voor blinde gebruikers." Het omvat visuele, motorische, gehoor-, spraak- en cognitieve beperkingen, plus tijdelijke situaties zoals een gebroken arm.
• "Toegankelijke sites zien er saai uit." Toegankelijkheid beperkt een paar zaken, zoals contrast, focusstijlen en tekstgrootte, maar mooie toegankelijke sites zijn de norm, niet de uitzondering.
• "Een automatische checker geeft een 100, dus we zijn klaar." Geautomatiseerde tools vangen maar een deel van de problemen. Of alt-tekst echt betekenisvol is, of een stroom logisch is met een schermlezer, moet een mens controleren.
• "Een overlaywidget maakt ons compliant." Werkbalken die erbovenop worden geplakt, kunnen ontbrekende labels of kapotte toetsenbordtoegang in je code niet oplossen. Los de bron op.
• "We hebben geen gebruikers met een beperking." Misschien weet je het gewoon niet. Veel beperkingen zijn niet zichtbaar, en mensen die tegen een drempel aanlopen, vertrekken meestal gewoon.

Wat je aan je AI-builder kunt vragen

• "Bouw dit zodat het voldoet aan WCAG 2.2 niveau AA."
• "Gebruik semantische HTML: echte knoppen, links, koppen in de juiste volgorde, en labels voor elk formulierveld."
• "Zorg dat elk interactief element alleen met het toetsenbord werkt en een zichtbare focusstijl heeft."
• "Controleer alle tekst- en iconenkleuren op contrast: 4,5:1 voor normale tekst, 3:1 voor grote tekst en iconen."
• "Voeg betekenisvolle alt-tekst toe aan informatieve afbeeldingen en lege alt-tekst aan decoratieve."
• "Toon formulierfouten als tekst, gekoppeld aan het veld, niet alleen met kleur."
• "Respecteer de instelling voor verminderde beweging van de gebruiker bij animaties."
• "Draai een geautomatiseerde toegankelijkheidscontrole en noem wat die niet kan testen, zodat ik dat handmatig kan controleren."

Test het daarna zelf: leg de muis weg en probeer je belangrijkste stroom alleen met Tab, Shift+Tab, Enter en de spatiebalk af te ronden. Probeer de ingebouwde schermlezer van je telefoon op de hoofdpagina. Zoom de browser in tot 200% en kijk of er iets kapotgaat.

Toegankelijkheid in Mythex

Mythex bevat geen speciale toegankelijkheidscontrole, dus behandel toegankelijkheid als onderdeel van je prompts en je tests. Vraag vanaf de eerste prompt om WCAG 2.2 AA, controleer het resultaat in de Preview met het toetsenbord, en gebruik /test zodat de agent je belangrijkste stromen doorloopt voordat je publiceert; zie App-testen. Het SEO-recept vraagt ook om semantische koppen en betekenisvolle alt-tekst, wat beide doelen dient.

Voor een praktische checklist, zie hoe je je website toegankelijk maakt. Lees voor ontwerp hoe je met AI een mooie app ontwerpt, en test vóór de lancering hoe je je app test voordat je live gaat. De eigen WCAG-samenvatting van het W3C is de gezaghebbende bron.

Veelgestelde vragen