Ga naar hoofdinhoud
Formulieren & Validatie

Formulieren en validatie binnen Accessibility & Design Systems

Formulieren zijn het hart van digitale dienstverlening. Hier vragen overheden informatie, nemen besluiten processen hun start en worden rechten en plichten vastgelegd. Als formulieren niet toegankelijk zijn, is digitale inclusie onmogelijk.

Deze pagina laat zien hoe ontwerp- en validatiekeuzes direct bepalen of mensen een proces zelfstandig kunnen afronden, welke eisen volgen uit WCAG 2.2 en EN 301 549, en hoe je formulieren toegankelijk én robuust inricht in ontwerp, componenten en delivery.

Waarom formulieren cruciaal zijn voor toegankelijkheid

In overheidsprocessen zijn formulieren zelden optioneel:

Aanvragen van toeslagen of subsidies
Inschrijvingen
Bezwaar- en meldformulieren
Identificatie- en verificatieprocessen

Veel gebruikers ervaren hier:

  • Stress
  • Taalbarrières
  • Tijdsdruk
  • Onzekerheid over gevolgen

Als formulieren dan ook nog slecht ontworpen zijn, ontstaat directe uitsluiting.

Toegankelijke formulieren leiden aantoonbaar tot:

  • Minder uitval
  • Minder fouten
  • Minder herstelverzoeken
  • Minder belasting op helpdesks

Relevante WCAG-criteria

Formulieren raken een groot deel van de WCAG:

1.3.1
Info and Relationships – labels, groepen en structuur
1.3.5
Identify Input Purpose – herkenbare invoervelden
2.4.3
Focus Order – logische tabvolgorde
3.3.1
Error Identification – fouten moeten herkenbaar zijn
3.3.2
Labels or Instructions – duidelijke uitleg vooraf
3.3.3
Error Suggestion – help bij herstel
3.3.4
Error Prevention – bevestigen vóór definitieve acties

Deze eisen zijn juridisch verplicht via EN 301 549.

Labels: de basis die nog vaak misgaat

Veelvoorkomende fouten
  • Alleen placeholders gebruiken
  • Labels die verdwijnen bij focus
  • Visuele labels die niet gekoppeld zijn in code

Gevolg: screenreaders kondigen velden niet correct aan, gebruikers weten niet meer wat ze invullen, fouten nemen toe.

Best practice
  • Elk veld heeft een zichtbaar label
  • Label blijft altijd zichtbaar
  • Label is programmatisch gekoppeld aan het veld

Placeholders mogen ondersteunend zijn, maar nooit het label vervangen.

Instructies en context: vóórdat het misgaat

Gebruikers moeten vooraf weten:

  • Wat wordt gevraagd
  • In welk formaat
  • Waarom dit nodig is

Wat vaak misgaat

  • Instructies pas na foutmelding
  • Vage veldnamen
  • Juridische taal in plaats van taakgerichte uitleg
Toegankelijke aanpak
  • Korte uitleg boven het formulier
  • Veldspecifieke hints waar nodig
  • Duidelijke voorbeeldformats

Goede instructies voorkomen fouten in plaats van ze achteraf te corrigeren.

Groeperen van velden: fieldsets en structuur

Bij samenhangende vragen (bijvoorbeeld adres, gezinssamenstelling, bankgegevens) moeten velden logisch gegroepeerd zijn én moet die relatie ook in de code bestaan.

Waarom dit belangrijk is

Screenreadergebruikers horen in welke sectie zij zich bevinden en welke vragen bij elkaar horen.

Best practice
  • Gebruik fieldset en legend voor groepen
  • Geef secties duidelijke koppen
  • Verdeel lange formulieren in overzichtelijke stappen

Zo blijft het proces behapbaar.

Verplichte velden: niet alleen met kleur

Veelgemaakte fout

Alleen rode rand of sterretje. Voor gebruikers met kleurenblindheid of screenreaders is dit onvoldoende.

Toegankelijke aanpak
  • Tekstuele aanduiding (bijv. "verplicht")
  • Consistente markering
  • Uitleg aan begin van formulier

Kleur mag ondersteunen, maar nooit de enige indicator zijn.

Foutmeldingen: waar het vaak echt misgaat

Veelvoorkomende problemen

  • Foutmelding bovenaan zonder focus
  • Melding alleen bij het veld maar niet aangekondigd
  • Onduidelijke teksten ("ongeldige invoer")

Gevolg: gebruikers weten niet wat er misging, toetsenbordgebruikers vinden de fout niet.

Toegankelijke foutafhandeling
  • Foutmelding bij het veld
  • Samenvatting bovenaan bij meerdere fouten
  • Focus verplaatsen naar eerste fout
  • Duidelijke uitleg wat er moet worden aangepast

Niet alleen aangeven dát iets fout is, maar hoe het opgelost kan worden.

Inline validatie: helpend of juist verwarrend?

Realtime validatie kan helpen, maar ook verstoren.

Risico's

  • Screenreaders die continu nieuwe meldingen krijgen
  • Focus die verspringt
  • Gebruikers die niet begrijpen wanneer iets definitief is
Richtlijn
  • Valideer bij verlaten van het veld of bij submit
  • Kondig wijzigingen toegankelijk aan
  • Houd feedback voorspelbaar

Rust en voorspelbaarheid zijn essentieel voor cognitieve toegankelijkheid.

Focusmanagement na acties

Na belangrijke acties moet focus logisch worden geplaatst:

  • Na submit naar foutmelding of bevestiging
  • Bij modals naar de titel van de dialoog

Wat vaak misgaat

  • Focus blijft op submitknop
  • Scherm verandert maar screenreader merkt niets

Dit leidt tot desoriëntatie en gemiste feedback. Focusmanagement is dus een essentieel onderdeel van validatie.

Bevestiging bij juridisch of financieel gevoelige acties

WCAG vereist extra bescherming bij:

Indienen van aanvragen Versturen van bezwaar Financiële transacties
Vereisten (WCAG 3.3.4)
  • Mogelijkheid tot controleren
  • Mogelijkheid tot corrigeren
  • Expliciete bevestiging

Niet alleen technisch, maar ook begrijpelijk gepresenteerd.

Meerstapsformulieren en voortgang

Bij langere processen:

  • Moeten stappen duidelijk zijn
  • Moet voortgang herkenbaar zijn
  • Moet teruggaan mogelijk blijven
Toegankelijke voortgangsindicatie
  • Niet alleen via kleur
  • Tekstueel aangeven waar men is
  • Duidelijke koppen per stap

Zo behouden gebruikers overzicht en controle.

Formulieren in design systems

Veel formulieren worden opgebouwd uit herbruikbare componenten: inputvelden, foutmeldingen, knoppen, meldingsbalken. Als deze niet toegankelijk zijn, worden fouten massaal herhaald en kost herstel extreem veel tijd.

Wat hoort standaard in componenten

Correcte label-koppeling
Foutmelding-patronen
Focusgedrag
Contrast in alle states

Zo wordt toegankelijkheid schaalbaar.

Wat dit betekent voor overheidsorganisaties

Voor de overheid geldt:

  • Iedereen moet zelfstandig digitale zaken kunnen regelen
  • Formulieren zijn vaak de enige toegang tot rechten
  • Fouten hebben directe gevolgen voor burgers

Daarom moeten formulieren:

Onderdeel zijn van UX-ontwerp
Expliciet getest worden
Vaste kwaliteitscriteria krijgen

Van losse checks naar structurele borging

Sterke organisaties:

  • Toetsen ontwerpen vóór bouw
  • Hebben vaste formulierrichtlijnen
  • Testen met keyboard en screenreaders
  • Verwerken WCAG in acceptatiecriteria

Zo wordt toegankelijkheid onderdeel van reguliere kwaliteitszorg.

Hulp nodig bij formulieren in jullie portalen of ketens?

Formulieren raken ontwerp, techniek, beleid en uitvoering tegelijk. Ik help overheidsorganisaties zodat iedereen zelfstandig digitale zaken kan regelen — zonder extra drempels.

  • UX-review van formulieren
  • Vertaling van WCAG naar concrete ontwerpregels
  • Toetsing van componentbibliotheken
  • Ondersteuning van productteams in delivery