# WCAG 2.2 AA-checklist voor SaaS-producten en webapps

<https://www.fixreports.com/nl/blog/wcag-2-2-checklist-saas-web-apps>

Bijgewerkt op 2026-10-26

Een SaaS-product heeft twee oppervlakken waar toegankelijkheid telt: de marketingsite die het verkoopt en de applicatie die mensen elke dag gebruiken. De marketingsite gaat op dezelfde punten mis als elke website, met te weinig contrast, ontbrekende alt-tekst en formulieren zonder labels. De applicatie voegt eigen problemen toe: inlogprocessen die wachtwoordmanagers blokkeren, dialogen die de toetsenbordfocus vasthouden, single-page-navigatie die schermlezers niet opmerken, datatabellen en grafieken zonder tekst, slepen zonder alternatief en sessies die zonder waarschuwing verlopen. Deze checklist loopt WCAG 2.2 niveau AA door aan de hand van de onderdelen van een typisch SaaS-product.

**De belangrijkste punten**

- WCAG 2.2 werd in oktober 2023 een W3C-aanbeveling en voegde negen succescriteria toe, waarvan zes op niveau A of AA ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- Accessible Authentication (3.3.8, AA) betekent dat inloggen niet mag afhangen van het onthouden of overtypen van een wachtwoord, tenzij mensen het kunnen plakken of een wachtwoordmanager kunnen gebruiken ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- Interactieve doelen moeten minstens 24 × 24 CSS-pixels zijn, of genoeg ruimte om zich heen hebben (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- Meldingen zoals “Opgeslagen” of “3 resultaten” moeten schermlezers bereiken zonder dat de focus verschuift (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- Zakelijke kopers en kopers uit de publieke sector vragen vaak om een Accessibility Conformance Report, meestal opgesteld op het VPAT-sjabloon van de Information Technology Industry Council ([ITI](https://www.itic.org/policy/accessibility/vpat)).

## Waarom is toegankelijkheid belangrijker voor SaaS dan voor een brochuresite?

Mensen gebruiken een SaaS-product urenlang, vaak omdat hun werkgever het heeft gekozen. Een drempel op een marketingpagina kost een bezoeker; een drempel in het product kan iemand verhinderen zijn werk te doen. Daarom vragen grotere klanten, universiteiten en overheidsinstanties steeds vaker naar toegankelijkheid voordat ze kopen, en daarom moet het antwoord over de applicatie gaan, niet alleen over de website.

Het is ook belangrijk omdat geautomatiseerde tests maar een deel van het probleem vangen. Tools zoals axe-core vinden fouten in de markup, zoals ontbrekende labels en te weinig contrast. Ze kunnen niet zien of een dialoog de focus naar de juiste plek teruggeeft, of de gegevens van een grafiek als tekst beschikbaar zijn, of dat een workflow met een toetsenbord kan worden afgerond. Een applicatie heeft zowel geautomatiseerde controles als handmatige tests nodig.

## Hoe maak je aanmelden en inloggen toegankelijk?

Bij authenticatie heeft WCAG 2.2 de belangrijkste nieuwe eis voor SaaS toegevoegd.

- **Sta plakken en wachtwoordmanagers toe (3.3.8, AA).** Blokkeer plakken in wachtwoord- of codevelden niet, en gebruik `autocomplete="username"`, `autocomplete="current-password"` en `autocomplete="one-time-code"`, zodat browsers en wachtwoordmanagers ze kunnen invullen.
- **Vermijd puzzels als enige toegang.** Een CAPTCHA die mensen vervormde tekst laat overtypen of een puzzel laat oplossen, is een test van cognitieve functies. Bied een alternatief aan, en kies bij voorkeur controles waarvoor de gebruiker niets hoeft te doen ([W3C](https://www.w3.org/TR/turingtest/)).
- **Geef elk veld een label (1.3.1 en 3.3.2, A).** Gebruik een zichtbaar `<label>` dat aan het invoerveld is gekoppeld; placeholdertekst verdwijnt zodra iemand typt en is geen label.
- **Benoem fouten in tekst (3.3.1, A) en stel oplossingen voor (3.3.3, AA).** “Het wachtwoord moet minstens 12 tekens hebben” helpt; alleen een rode rand helpt niet.
- **Vraag niet twee keer (3.3.7, A).** Als een aanmelding in meerdere stappen al om een bedrijfsnaam of adres heeft gevraagd, vul die dan in of laat mensen die selecteren in plaats van ze opnieuw te typen.
- **Houd hulp op dezelfde plek (3.2.6, A).** Als je chat, een hulplink of contactgegevens aanbiedt, zet ze dan op elke pagina van het proces op dezelfde relatieve plek.

## Welke formulier- en foutpatronen veroorzaken de meeste fouten?

In formulieren zitten de meeste fouten van applicaties. Het onderzoek van WebAIM uit 2026 naar een miljoen homepages vond ontbrekende formulierlabels op 51% daarvan ([WebAIM](https://webaim.org/projects/million/)), en applicaties hebben veel meer formulieren dan homepages.

- Geef elk invoerveld een programmatische naam, en groepeer bij elkaar horende bedieningselementen, zoals keuzerondjes, met `<fieldset>` en `<legend>`.
- Meld fouten waar mensen ze opmerken: verplaats de focus naar een foutoverzicht bovenaan het formulier of naar het eerste ongeldige veld, en link elk item in het overzicht aan het bijbehorende veld.
- Markeer verplichte velden in tekst, niet alleen met kleur (1.4.1, A).
- Verstuur niets en verander de context niet als iemand alleen een optie selecteert (3.2.2, A); wacht op een expliciete actie.

## Hoe moeten dialogen, menu’s en popovers zich gedragen?

Bij eigen componenten gaat de ondersteuning voor toetsenbord en schermlezer het vaakst mis. De WAI-ARIA Authoring Practices Guide beschrijft het verwachte gedrag voor elk patroon ([W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **Dialogen**: verplaats de focus naar de dialoog als die opent, houd Tab erin zolang hij open is, sluit hem met Escape en geef de focus terug aan het bedieningselement dat hem opende. Gebruik het native `<dialog>`-element of `role="dialog"` met `aria-modal="true"` en een naam.
- **Geen toetsenbordvallen (2.1.2, A)**: elk component moet met het toetsenbord te verlaten zijn.
- **Zichtbare focus (2.4.7, AA)** die niet verborgen zit achter vaste headers, cookiebanners of chatwidgets (2.4.11, AA, nieuw in 2.2).
- **Tooltips en popovers (1.4.13, AA)** die mensen met Escape kunnen sluiten, die niet verdwijnen als je er met de muis overheen gaat, en die blijven staan tot ze worden gesloten.
- **Sneltoetsen met één toets (2.1.4, A)**: als het indrukken van een lettertoets een actie start, laat mensen de sneltoetsen dan uitschakelen of opnieuw toewijzen, of maak ze alleen actief als het betreffende component de focus heeft.

## Hoe ga je om met navigatie in een single-page-app?

In een single-page-app verandert de URL zonder dat er een pagina wordt geladen, dus schermlezers melden misschien niet dat er iets is gebeurd.

- Werk bij elke routewijziging de documenttitel bij, zodat elke weergave een beschrijvende titel heeft (2.4.2, A).
- Verplaats de focus naar de hoofdkop van de nieuwe weergave, of meld de wijziging in een beleefde live-regio; frameworks zoals Next.js hebben hiervoor een route announcer.
- Houd een logische focusvolgorde aan (2.4.3, A): nadat een item is verwijderd, moet de focus naar een logisch buurelement gaan, niet terug naar het begin van de pagina.
- Bied een manier om herhaalde navigatie over te slaan (2.4.1, A), zoals een skiplink of landmarks.

## Hoe maak je dashboards, datatabellen en grafieken toegankelijk?

- **Tabellen**: gebruik echte `<table>`-markup met `<th>` en `scope` voor kopcellen, en een bijschrift (1.3.1, A). Rasters die uit `<div>`-elementen zijn opgebouwd, hebben het volledige ARIA-gridpatroon nodig, en dat is veel moeilijker goed te krijgen.
- **Grafieken**: geef elke grafiek een tekstalternatief dat de hoofdboodschap noemt, en bied de gegevens aan als tabel (1.1.1, A). Maak het verschil tussen reeksen niet alleen met kleur duidelijk (1.4.1, A); voeg labels of patronen toe.
- **Contrast**: tekst heeft 4.5:1 nodig (1.4.3, AA), en lijnen in grafieken, iconen en randen van invoervelden hebben 3:1 nodig tegenover hun achtergrond (1.4.11, AA). Controleer de donkere modus apart. Onze [kleurcontrastchecker](/nl/color-contrast-checker) test elk willekeurig kleurenpaar.
- **Statusmeldingen (4.1.3, AA)**: “Opgeslagen”, “Upload voltooid” en aantallen resultaten moeten `role="status"` of een live-regio gebruiken, zodat gebruikers van een schermlezer ze horen zonder hun plek kwijt te raken.

## Wat veranderen de nieuwe criteria van WCAG 2.2 voor webapps?

| Criterium | Niveau | Wat het in een app betekent |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Vaste werkbalken, banners en chatwidgets mogen het gefocuste element niet volledig bedekken |
| 2.5.7 Dragging Movements | AA | Alles wat je door te slepen doet, zoals het herordenen van een kanbanbord, heeft een alternatief met één aanwijzer nodig, bijvoorbeeld een menu of knoppen voor omhoog en omlaag |
| 2.5.8 Target Size (Minimum) | AA | Knoppen en links minstens 24 × 24 CSS-pixels, of zo ver uit elkaar dat een cirkel van 24 pixels rond elk doel geen ander doel overlapt |
| 3.2.6 Consistent Help | A | Hulplinks, chat en contactgegevens op elke pagina op dezelfde relatieve plek |
| 3.3.7 Redundant Entry | A | Informatie die al in hetzelfde proces is ingevoerd, wordt ingevuld of is selecteerbaar |
| 3.3.8 Accessible Authentication (Minimum) | AA | Inloggen zonder onthouden of overtypen, tenzij plakken, wachtwoordmanagers of een andere methode zijn toegestaan |

WCAG 2.2 heeft ook 4.1.1 Parsing geschrapt, dat geen praktisch effect meer heeft op toegankelijkheid ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

## Hoe zit het met time-outs, lay-out en zoomen?

- **Sessietime-outs (2.2.1, A)**: waarschuw mensen voordat een sessie verloopt en laat ze die met een eenvoudige actie verlengen, tenzij de tijdslimiet essentieel is of langer dan 20 uur. Wie lopend werk tussentijds opslaat, voorkomt het ergste.
- **Reflow (1.4.10, AA)**: content moet werken op een breedte van 320 CSS-pixels (gelijk aan inzoomen tot 400% op een scherm van 1280 pixels breed) zonder in twee richtingen te scrollen; datatabellen en vergelijkbare content zijn uitgezonderd.
- **Tekstafstand (1.4.12, AA)**: een grotere regelhoogte en letterafstand mogen geen tekst afsnijden, wat containers met een vaste hoogte vaak wel doen.
- **Oriëntatie (1.3.4, AA)**: zet de app niet vast in staande of liggende stand, tenzij dat essentieel is.

## Wat is een ACR, en heb je er een nodig?

Een Accessibility Conformance Report (ACR) documenteert hoe een product aan elk toegankelijkheidscriterium voldoet: ondersteund, gedeeltelijk ondersteund of niet ondersteund, met opmerkingen. De meeste worden opgesteld op het VPAT-sjabloon van de Information Technology Industry Council, dat edities heeft voor WCAG, de Amerikaanse Section 508-standaarden en de Europese norm EN 301 549 ([ITI](https://www.itic.org/policy/accessibility/vpat)).

Amerikaanse federale instanties moeten op grond van Section 508 toegankelijke technologie inkopen ([Section508.gov](https://www.section508.gov/)), en overheidsinstanties in de EU verwijzen naar EN 301 549, dus B2B-producten die aan die klanten verkopen, krijgen bij aanbestedingen vaak de vraag om een ACR. Een eerlijke ACR, met de bekende tekortkomingen erin, is nuttiger voor kopers dan een ACR die volledige ondersteuning claimt. Hij moet gebaseerd zijn op tests van het product, inclusief handmatige tests; een geautomatiseerde scan alleen kan hem niet invullen.

Als je in de EU aan consumenten verkoopt, kan de European Accessibility Act ook gelden voor de manier waarop je online verkoopt; onze [gids over de EAA](/nl/blog/european-accessibility-act-online-stores) legt de reikwijdte uit. Dit is geen juridisch advies.

## Hoe test een SaaS-team toegankelijkheid?

1. **Automatiseer de basis.** Draai axe-core of een vergelijkbare engine in je end-to-endtests en op de marketingsite, en laat builds falen bij nieuwe schendingen. Onze [gratis toegankelijkheidscheck](/nl/website-accessibility-checker) gebruikt dezelfde engine op elke openbare pagina.
2. **Test met een toetsenbord.** Doorloop je belangrijkste workflows, zoals aanmelden, een record aanmaken en instellingen wijzigen, met alleen Tab, Shift+Tab, Enter, spatie, Escape en de pijltjestoetsen.
3. **Test met een schermlezer.** NVDA op Windows en VoiceOver op macOS en iOS zijn gratis. Controleer of namen, rollen, toestanden en meldingen worden voorgelezen.
4. **Zoom in en verander de venstergrootte.** Controleer tekstzoom op 200% en een venster van 320 pixels breed.
5. **Los het op in het designsystem.** De meeste fouten komen uit gedeelde componenten; als je een knop of dialoog één keer oplost, is hij overal opgelost.

## Veelgestelde vragen

### Geldt WCAG voor de ingelogde delen van een webapp?

WCAG geldt voor alle webcontent, ook voor pagina’s achter een login. Of een wet vereist dat een specifiek product eraan voldoet, hangt af van het rechtsgebied en de klant, maar kopers die naar toegankelijkheid vragen, bedoelen meestal het hele product.

### Kan een overlay een SaaS-product toegankelijk maken?

Nee. Overlays veranderen de onderliggende code van eigen componenten niet, en daar zitten juist de fouten van applicaties. Onze gids over [toegankelijkheidsoverlays](/nl/blog/accessibility-overlays-ftc-order) behandelt het optreden van de FTC tegen een toonaangevende leverancier van overlays.

### Hoeveel van WCAG kunnen geautomatiseerde tools controleren?

Maar een deel. Geautomatiseerde regels vinden ontbrekende namen, labels en contrastfouten betrouwbaar, maar veel criteria, zoals een zinvolle focusvolgorde, bruikbare alt-tekst en begrijpelijke foutmeldingen, moet een mens beoordelen.

### Op welke WCAG-versie moeten we ons richten?

WCAG 2.2 niveau AA is de huidige versie. Veel wetten en aanbestedingsregels verwijzen nog naar WCAG 2.1 AA; wie aan 2.2 AA voldoet, voldoet ook aan 2.1 AA, afgezien van het geschrapte criterium Parsing.

### Moeten we aan niveau AAA voldoen?

Het W3C raadt niet aan om AAA voor hele producten te eisen, omdat sommige content niet aan elk AAA-criterium kan voldoen. Niveau AA is het gebruikelijke doel.

## Bronnen

- W3C: [What's New in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [Understanding 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [Understanding 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [Understanding 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: Dialog (Modal) Pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [Inaccessibility of CAPTCHA](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)