Je website toegankelijk maken: een startgids voor WCAG 2.2

Om een website toegankelijk te maken, bouw je hem zo dat mensen hem kunnen gebruiken met een toetsenbord, een schermlezer, zoom of een schakelapparaat, net zo goed als met een muis. Gebruik echte HTML-elementen voor knoppen, links, koppen en formulierlabels, geef afbeeldingen betekenisvolle alt-tekst, houd het tekstcontrast hoog en zorg dat de focus zichtbaar is. De norm om naar te streven is WCAG 2.2 niveau AA. Geautomatiseerde checkers vangen een deel van het probleem; een test van tien minuten met toetsenbord en schermlezer vangt veel van de rest.

Wat ‘toegankelijk’ in de praktijk betekent

Toegankelijkheid gaat over mensen: iemand die blind is en een schermlezer gebruikt, iemand met een trillende hand die met het toetsenbord navigeert, iemand met een visuele beperking die tot 200% inzoomt, iemand die in fel zonlicht leest, iemand met een tijdelijk gebroken pols. Goede toegankelijkheid maakt een site meestal beter voor iedereen: duidelijkere structuur, leesbare tekst, formulieren die hun fouten uitleggen.

De referentienorm is de Web Content Accessibility Guidelines (WCAG) van het W3C. Vanaf september 2026 is de huidige versie WCAG 2.2 (gepubliceerd oktober 2023, bijgewerkt december 2024); WCAG 3 is een vroege conceptversie. WCAG is opgebouwd rond vier principes: content moet waarneembaar, bedienbaar, begrijpelijk en robuust zijn. Er zijn drie conformiteitsniveaus:

Wetten in verschillende landen verwijzen naar WCAG, bijvoorbeeld de Europese Toegankelijkheidswet, die sinds juni 2025 van toepassing is op veel consumentgerichte digitale diensten in de EU. Welke regels voor jou gelden, hangt af van waar je actief bent en wat je verkoopt. Vraag bij twijfel een adviseur. Deze gids behandelt het praktische werk.

Opties: hoe je er komt

Voor de meeste kleine sites zijn de eerste twee genoeg: vraag de AI om vanaf het begin toegankelijk te bouwen en audit daarna voor de lancering.

De reparaties die het meest tellen

Gebruik de juiste HTML-elementen

Het meeste van de toegankelijkheid komt gratis mee met correcte HTML. Een <button> is focusbaar, werkt met Enter en spatie, en wordt als knop aangekondigd. Een <div> met een klikhandler is niets van dat alles. AI-gegenereerde code gebruikt soms opgemaakte div’s voor alles; vraag om semantische elementen:

• <button> voor acties, <a href> voor navigatie
• Eén <h1> per pagina, daarna <h2> en <h3> in volgorde: schermlezergebruikers springen tussen koppen
• Landmarks: <header>, <nav>, <main>, <footer>
• Een <label> gekoppeld aan elk formulierveld
• De taal van de pagina in <html lang="nl">

Gebruik ARIA-attributen alleen als geen native element past, bijvoorbeeld voor een aangepaste tabset of combobox. Verkeerde ARIA is erger dan geen ARIA.

Toetsenbordtoegang en zichtbare focus

Alles wat je met de muis kunt doen, moet ook met alleen het toetsenbord kunnen (WCAG 2.1.1). Druk Tab door de pagina: elke link, knop en elk veld moet in logische volgorde bereikbaar zijn, en je moet altijd zien waar de focus staat (2.4.7 Focus zichtbaar). WCAG 2.2 voegde toe dat het gefocuste element niet volledig verborgen mag zijn achter vaste koppen of cookiebanners (2.4.11, niveau AA).

Veelvoorkomende fouten: menu’s die alleen bij hover openen, modale vensters die de focus niet vasthouden of niet met Escape te sluiten zijn, en outline: none in de CSS zonder vervanging.

Tekstalternatieven

Elke betekenisvolle afbeelding heeft alt-tekst nodig die zegt wat ze in context toont (“Chef die het proeverijmenu opmaakt”, niet “afbeelding1.jpg”). Decoratieve afbeeldingen krijgen een lege alt="", zodat schermlezers ze overslaan. Knoppen met alleen een icoon hebben een toegankelijke naam nodig (“Sluiten”, “Zoeken”). Video’s hebben ondertiteling nodig; audio heeft een transcript nodig.

Kleur en contrast

WCAG 2.2 AA vereist een contrastverhouding van minimaal 4,5:1 voor normale tekst en 3:1 voor grote tekst (1.4.3), en 3:1 voor onderdelen van de interface zoals invoerranden en betekenisvolle iconen (1.4.11). Lichtgrijze placeholdertekst en bleke knoppen zijn de gebruikelijke fouten. Gebruik ook nooit alleen kleur om betekenis over te brengen: een rode rand op een ongeldig veld heeft ook een foutmelding nodig.

Schalen en reflow

Tekst moet bruikbaar blijven bij 200% zoom (1.4.4), en content moet werken bij een breedte van 320 CSS-pixels zonder zijdelings te scrollen (1.4.10). Een goed responsive ontwerp lost het meeste hiervan op.

Doelgroottes, formulieren en fouten

• Doelgrootte: WCAG 2.2 AA vraagt om aanwijsdoelen van minimaal 24 bij 24 CSS-pixels, of genoeg ruimte rond kleinere (2.5.8). Groter is vriendelijker op telefoons.
• Formulieren: zichtbare labels (niet alleen placeholder), duidelijke instructies, en foutmeldingen die zeggen wat er mis is en hoe je het oplost, naast het veld.
• Inloggen: laat mensen geen puzzel oplossen of een code overtypen zonder alternatief; sta wachtwoordmanagers en plakken toe (3.3.8 Toegankelijke authenticatie).

Prompts die werken

Bouw deze site zodat hij voldoet aan WCAG 2.2 niveau AA: semantische HTML-landmarks, één h1 per pagina met koppen in volgorde, echte knop- en linkelementen, labels bij elk formulierveld, zichtbare focusstijlen, tekstcontrast van minimaal 4,5:1, alt-tekst bij betekenisvolle afbeeldingen en alt="" bij decoratieve, en html lang ingesteld.

Audit de pagina’s /signup en /checkout op toegankelijkheid. Controleer gebruik met alleen het toetsenbord, de focusvolgorde, zichtbare focus, labels, foutmeldingen, contrast en schermlezernamen voor knoppen met alleen een icoon. Geef elk probleem met het WCAG-criterium, en repareer ze daarna zonder het visuele ontwerp meer dan nodig te veranderen.

Het mobiele menu kan niet met het toetsenbord worden gebruikt. Maak er een knop met aria-expanded van, verplaats de focus naar het menu wanneer het opent, sluit het met Escape en zet de focus terug op de knop.

Stap voor stap

1. Voer een geautomatiseerde controle uit. Het gedeelte Toegankelijkheid van Lighthouse in Chrome DevTools, of de axe-browserextensie, op elke belangrijke pagina. Repareer alles wat wordt gemeld.
2. Haal de muis weg. Tab door elke pagina en voltooi elke belangrijke taak: aanmelden, zoeken, afrekenen. Noteer alles wat je niet kunt bereiken, waar je de focus niet ziet, of waar je niet uit kunt komen.
3. Zoom in tot 200% en verklein het venster tot telefoonbreedte. Niets mag worden afgesneden of zijdelings scrollen.
4. Probeer tien minuten een schermlezer: VoiceOver op Mac en iPhone, TalkBack op Android, of NVDA op Windows (gratis). Luister naar koppen, links en formuliervelden. “Knop” zonder naam, of “link, klik hier”, betekent werk.
5. Controleer het contrast van tekst, knoppen en invoervelden met een contrastchecker.
6. Repareer en test opnieuw dezelfde taken.
7. Publiceer een toegankelijkheidsverklaring met de norm die je nastreeft en hoe problemen gemeld kunnen worden, en beantwoord die meldingen.

Veelgemaakte fouten

• Vertrouwen op een overlay-widget in plaats van de code te repareren.
• Focusranden verwijderen omdat ze er rommelig uitzien, zonder vervanging.
• Placeholdertekst als enige label. Die verdwijnt zodra iemand begint te typen en is vaak laag in contrast.
• “Klik hier” en “Lees meer” als links. Buiten context horen schermlezergebruikers een lijst met identieke links.
• Alt-tekst volgepropt met zoekwoorden. Alt-tekst is voor mensen; beschrijf de afbeelding.
• Eenmaal testen. Elke nieuwe functie kan de toetsenbordtoegang breken. Voeg een toetsenbordronde toe aan je controle voor de lancering.

Toegankelijkheidschecklist

• Geautomatiseerde controle (Lighthouse of axe) is schoon op de belangrijkste pagina’s
• Elke taak is met alleen het toetsenbord te voltooien
• Focus is altijd zichtbaar en nooit verborgen achter vaste elementen
• Semantische koppen, landmarks, knoppen en links; lang ingesteld
• Betekenisvolle alt-tekst; decoratieve afbeeldingen alt=""; ondertiteling bij video
• Tekstcontrast ≥ 4,5:1 (grote tekst ≥ 3:1); interfaceonderdelen ≥ 3:1
• Werkt bij 200% zoom en 320 px breedte
• Elk formulierveld heeft een zichtbaar label en duidelijke foutmeldingen
• Toegankelijkheidsverklaring met een manier om problemen te melden

Voor de concepten achter dit alles, lees wat is webtoegankelijkheid. Toegankelijk ontwerp en goed ontwerp overlappen veel; hoe je met AI een mooi ogende app ontwerpt behandelt de visuele kant.

Toegankelijkheid op Mythex

Mythex bouwt met de norm die je vraagt, dus zet “WCAG 2.2 AA” in je eerste prompt en in vervolgvragen. Je kunt de telefoonformaat-weergave van Preview gebruiken om kleine schermen te controleren (Preview en Code). Tests met toetsenbord, zoom en schermlezer werken het best op de gepubliceerde URL of een preview in een eigen tabblad. Vraag de agent om een pagina te auditen, de bevindingen te repareren en de reparaties daarna zelf te testen; een geautomatiseerde ronde is een begin, geen eindoordeel.

Veelgestelde vragen