Hoe u uw formulieren toegankelijk maakt: labels, fouten en validatie

Volgens WebAIM heeft 48.6% van de homepage’s van websites ontbrekende formulierinvoerveldenlabels — waardoor niet-gelabelde invoervelden een van de meest voorkomende toegankelijkheidsproblemen op het web zijn. Denk na over wat dat in de praktijk betekent: een schermlezergebruiker komt op je contactformulier, drukt op Tab om door de velden te gaan en hoort niets anders dan steeds opnieuw "edit text". Schermlezers kondigen formulierlabelvelden aan — zonder labels horen gebruikers "edit text" zonder context en weten ze niet welke informatie ze moeten invoeren. Formulieren zijn vaak het meest bedrijfskritische onderdeel van een website — checkoutflows, aanmeldschermen, contactpagina’s, ondersteuningsverzoeken — en toch behoren ze tot de meest consequent kapotte ervaringen voor mensen die gebruikmaken van ondersteunende technologie.

Waarom formulier­toegankelijkheid belangrijker is dan je denkt

Aangezien 1 op de 4 volwassenen in de VS leeft met een beperking, is toegankelijke formulier­validatie niet optioneel; het is essentieel. Tot die groep behoren mensen die blind zijn of een beperkt gezichtsvermogen hebben, mensen met motorische beperkingen die afhankelijk zijn van toetsenbordnavigatie, mensen met cognitieve beperkingen die duidelijke instructies nodig hebben, en mensen die spraakbesturingssoftware gebruiken om formulieren in te vullen. Elk veld zonder label, elke vage foutmelding en elk validatiepatroon dat uitsluitend op kleur vertrouwt, is een deur die stilletjes wordt gesloten voor een aanzienlijk deel van je publiek.

De meeste gebruikers met een beperking lopen tegen fouten aan bij het verzenden van informatie en krijgen geen duidelijke instructies over hoe ze die moeten oplossen — waardoor ze twee opties overhouden: de poging opgeven en op zoek gaan naar een toegankelijker formulier, of de hulp van iemand anders inschakelen; geen van beide zijn ideale ervaringen. Vanuit zakelijk perspectief verbeteren toegankelijke formulieren de gebruikerservaring, verlagen ze de uitvalpercentages en voldoen ze aan wettelijke vereisten. Vanuit complianceperspectief zijn WCAG 1.3.1 (Info and Relationships) en 4.1.2 (Name, Role, Value) Level A-vereisten die al bestaan sinds WCAG 2.0 in 2008 werd gelanceerd. Dit zijn geen randgevallen of geavanceerde technieken — het zijn de fundamentele verwachtingen van de standaard.

Volgens het WebAIM Million-rapport behoren ontbrekende formulierlabels consequent tot de belangrijkste toegankelijkheidsfouten op het web, en onderzoek naar implementatiefouten laat zien waarom: organisaties richten zich op complexe oplossingen terwijl ze basispatronen negeren die mensen met een beperking in staat zouden stellen hun diensten daadwerkelijk te gebruiken. Het goede nieuws is dat het oplossen van de meeste van deze problemen niets exotisch vereist — alleen bewust, goed geïnformeerd HTML.

De WCAG-succescriteria die formulieren aansturen

Voordat je in de implementatie duikt, is het handig om te weten welke specifieke WCAG-succescriteria van toepassing zijn op formulieren. De Web Content Accessibility Guidelines (WCAG) beschrijven vier kernprincipes — Waarneembaar, Bedienbaar, Begrijpelijk en Robuust (POUR) — die de ruggengraat vormen van inclusieve validatiesystemen. Binnen dat kader zijn er verschillende succescriteria die rechtstreeks betrekking hebben op formulierontwerp.

De meest relevante criteria zijn onder andere: 1.3.1 Info and Relationships (Level A), dat vereist dat informatie, structuur en relaties die via presentatie worden overgebracht programmatisch kunnen worden bepaald; 2.4.6 Headings and Labels (Level AA), dat stelt dat koppen en labels onderwerp of doel beschrijven; 3.3.2 Labels or Instructions (Level A), dat vereist dat labels of instructies worden gegeven wanneer inhoud gebruikersinvoer vereist; en 4.1.2 Name, Role, Value (Level A), dat vereist dat voor alle gebruikersinterfacecomponenten de naam en rol programmatisch kunnen worden bepaald.

Door je te houden aan WCAG-richtlijnen 3.3.1 tot en met 3.3.4, die foutidentificatie, instructies, suggesties en preventie behandelen, maak je formulieren die voor alle gebruikers eenvoudiger en intuïtiever zijn. Dit zijn geen willekeurige hoepels — elk criterium weerspiegelt een echte gebruikersbehoefte. Als je het "waarom" achter elke regel begrijpt, wordt het veel eenvoudiger om correct te implementeren en om in randgevallen goede afwegingen te maken.

Labels goed krijgen: de basis van toegankelijke formulieren

Een label is niet alleen een visuele hint. Het is de programmatische verbinding tussen een tekstbeschrijving en een formuliercontrole, en het is het primaire mechanisme waarmee ondersteunende technologieën identificeren waar een veld voor is. De meest robuuste manier om deze verbinding te maken is met het HTML-element <label> en het for-attribuut, dat verwijst naar de id van de bijbehorende input.

<!-- Fout: alleen placeholder is geen toegankelijk label -->
<input type='email' placeholder='Email address'>

<!-- Goed: Expliciet label gekoppeld via for/id -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email'>

Labels moeten altijd zichtbaar zijn — niet alleen placeholders. Placeholders verdwijnen wanneer gebruikers typen, waardoor er geen context overblijft. Dit is een cruciaal belangrijk onderscheid. Placeholdertekst is nooit ontworpen om als label te dienen; ze verdwijnt zodra een gebruiker begint te typen, heeft vaak onvoldoende kleurcontrast en veel schermlezers geven deze tekst niet betrouwbaar weer als de toegankelijke naam van het veld. Alleen op placeholders vertrouwen faalt voor alle gebruikers — niet alleen voor degenen die ondersteunende technologie gebruiken.

Wanneer je groepen gerelateerde velden hebt — zoals een set keuzerondjes of een blok selectievakjes — is het juiste patroon <fieldset> en <legend>. Groepeer gerelateerde opties zoals selectievakjes en keuzerondjes met fieldsets en legends om complexe formulieren makkelijker te begrijpen te maken.

<fieldset>
  <legend>Preferred contact method</legend>

  <input type='radio' id='contact-email' name='contact' value='email'>
  <label for='contact-email'>Email</label>

  <input type='radio' id='contact-phone' name='contact' value='phone'>
  <label for='contact-phone'>Phone</label>
</fieldset>

In situaties waarin een zichtbaar label visueel overbodig zou zijn — bijvoorbeeld een los zoekveld naast een duidelijk gelabelde Search-knop — kun je aria-label of aria-labelledby gebruiken om een toegankelijke naam te bieden zonder zichtbare tekst weer te geven. Gebruik dit echter spaarzaam. Mensen die schermlezers gebruiken kunnen formuliercontroles makkelijker identificeren en begrijpen omdat ze zijn gekoppeld aan labels, fieldsets en andere structurele elementen — en zichtbare labels zijn voor iedereen nuttig, inclusief ziende gebruikers met cognitieve beperkingen, gebruikers die tot 400% inzoomen en iedereen die even de draad kwijt is in een lang formulier.

Ook moeten verplichte velden zowel visueel als programmatisch worden aangegeven, met behulp van het attribuut required of aria-required. Een rood sterretje alleen is niet voldoende — voeg bovenaan het formulier een korte notitie toe zoals "Velden gemarkeerd met * zijn verplicht" en zorg dat het attribuut required in de markup staat, zodat ondersteunende technologieën kunnen aankondigen dat het veld verplicht is wanneer een gebruiker de focus erop plaatst.

Foutmeldingen schrijven die echt helpen

Foutmeldingen zijn waar de meeste formulieren gebruikers op een tweede, versterkende manier in de steek laten. Nadat een gebruiker een formulier heeft verzonden dat validatiefouten oplevert, moet die drie dingen weten: dat er een fout is opgetreden, welk veld de fout veroorzaakte en wat er moet worden gedaan om die te herstellen. De meeste formulierfouten beantwoorden slechts de eerste van deze vragen — en zelfs dat nog slecht.

Vage foutmeldingen zoals "Invalid input" of "Error" vertellen gebruikers niet wat er misging of hoe ze het kunnen corrigeren. Elke foutmelding moet het specifieke probleem benoemen en een concrete oplossing voorstellen.

Om compatibiliteit met schermlezers te garanderen, moeten foutmeldingen in de DOM worden geïntegreerd met ARIA-attributen zoals aria-invalid="true" en aria-describedby, die foutmeldingen direct koppelen aan hun bijbehorende formuliervelden. Zo ziet een correct gemarkeerde foutstatus eruit:

<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
>
<span id='email-error' role='alert'>
  Please enter a valid email address, for example: [email protected]
</span>

Het attribuut aria-invalid="true" vertelt een schermlezer dat het veld momenteel een ongeldige waarde heeft. Het attribuut aria-describedby verwijst naar het element dat de foutmelding bevat, die de schermlezer voorleest wanneer de gebruiker de focus op die input plaatst. De role="alert" op de foutspan zorgt ervoor dat deze onmiddellijk wordt aangekondigd wanneer hij in de DOM wordt geplaatst, zonder dat de gebruiker ernaartoe hoeft te navigeren.

In een minimalistisch ontwerp is het verleidelijk om alleen een rode kleur te gebruiken om aan te geven dat een veld ongeldig is — maar alleen kleur gebruiken is niet voldoende, zoals onderbouwd door WCAG 1.4.1 Use of Color, omdat mensen kleur op verschillende manieren waarnemen en die rode kleur niet door iedereen wordt opgemerkt. De oplossing is om de kleurrijke foutstatus aan te vullen met een extra visueel element — dat kan een pictogram zijn, maar zelfs dat is mogelijk niet genoeg om te begrijpen waarom het veld ongeldig is, dus de meest inclusieve oplossing is om expliciet een tekstbericht te tonen.

Specifieke foutmeldingen zijn vooral nuttig voor gebruikers met cognitieve uitdagingen, verminderde aandacht of gebruikers van schermlezers — omdat slecht geschreven feedback tot frustratie kan leiden en er zelfs toe kan leiden dat gebruikers het formulier helemaal verlaten. Schrijf foutmeldingen vanuit het perspectief van de gebruiker: wat moesten ze invoeren en hoe kunnen ze dat nu meteen corrigeren?

Validatietiming en focusbeheer

Wanneer je valideert is net zo belangrijk als hoe je valideert. Fouten te vroeg triggeren — bijvoorbeeld terwijl de gebruiker nog aan het typen is — betekent dat je hun flow onderbreekt met voortijdige klachten. Fouten alleen bij verzending triggeren kan ertoe leiden dat de gebruiker door een lang formulier moet scrollen op zoek naar de velden die aandacht nodig hebben. Het juiste antwoord is een gelaagde aanpak.

Combineer realtime feedback voor kritieke velden, on-blur-controles voor geformatteerde invoer en validatie bij verzending voor een volledige foutcontrole. In de praktijk betekent dit: valideer complexe formaten zoals wachtwoorden of e-mailadressen wanneer de gebruiker het veld verlaat (on blur); vermijd onderbrekende inlinevalidatie die bij elke toetsaanslag wordt geactiveerd; en voer bij het verzenden van het formulier een volledige controle uit en communiceer alle fouten in één keer duidelijk.

Leid na verzending de focus automatisch naar de eerste fout om gebruikers efficiënt te begeleiden. Als er meerdere fouten zijn, is het meest toegankelijke patroon om de focus te verplaatsen naar een samenvatting bovenaan het formulier met alle fouten als links die naar de relevante velden springen. Dit betekent dat de gebruiker de foutsamenvatting hoort zodra hij of zij verzendt, de volledige omvang van wat moet worden opgelost kan begrijpen en direct naar elk probleem kan navigeren.

<!-- Foutsamenvatting bovenaan het formulier, programmatisch gefocust -->
<div id='error-summary' role='alert' tabindex='-1'>
  <h2>2 errors found. Please correct the following:</h2>
  <ul>
    <li><a href='#email'>Email address: Please enter a valid email</a></li>
    <li><a href='#phone'>Phone number: Please use the format (555) 555-5555</a></li>
  </ul>
</div>

Zorg dat gebruikers formulieren kunnen doorlopen zonder muis, met een logische tabvolgorde en zichtbare focusindicatoren. De standaard focusring van de browser is een wettelijke en functionele basis — maar veel ontwerpteams onderdrukken die met outline: none in hun CSS zonder een vervanging te bieden. Dit maakt het formulier in de praktijk onbruikbaar voor gebruikers die alleen een toetsenbord gebruiken. Een duidelijke, contrastrijke focusindicator is vereist onder WCAG 2.4.7 (Level AA) en de strengere 2.4.11 in WCAG 2.2. Als je merkrichtlijnen botsen met de standaard focusring, vervang die dan — verwijder hem niet.

Instructies en hints geven vóórdat fouten optreden

De beste formulierfout is de fout die nooit hoeft te verschijnen. Goed geplaatste instructies en hints voorkomen fouten in de eerste plaats, wat beter is voor elke gebruiker. Verplichte invoervelden of invoervelden die een specifiek formaat, een specifieke waarde of lengte vereisen, moeten deze informatie opnemen in het label van het element of in de programmatisch gekoppelde instructies.

Het veldlabel is de eerste visuele instructie over wat er moet worden ingevuld, gevolgd door een beschrijving indien nodig. Net zoals ziende gebruikers een beschrijving kunnen zien, moeten schermlezergebruikers zich daar ook van bewust zijn — en je kunt de beschrijving aan de input koppelen met het attribuut aria-describedby, dat een id accepteert die verwijst naar het beschrijvingselement, waardoor de schermlezer de beschrijving automatisch voorleest wanneer de gebruiker de focus op het veld plaatst.

<label for='phone'>Phone number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-describedby='phone-hint'
>
<span id='phone-hint'>Format: (555) 555-5555</span>

Geef waar mogelijk voorbeelden om verwachtingen te verduidelijken — als een datumveld bijvoorbeeld het formaat MM/DD/YYYY vereist, voeg dan een voorbeeld toe zoals "Enter date as 12/25/2024." Geef voor wachtwoordvelden de vereisten vooraf aan in plaats van ze één voor één te onthullen wanneer de gebruiker elke regel overtreedt. Als het mogelijk is, moeten formulieren niet aan een tijdslimiet zijn gebonden, zodat gebruikers het formulier in hun eigen tempo kunnen invullen — en als er een tijdslimiet nodig is, moet de gebruiker de mogelijkheid hebben om die uit te zetten of te verlengen.

Het attribuut autocomplete is een ander vaak over het hoofd gezien toegankelijkheidsmechanisme. Waarden instellen zoals autocomplete="email", autocomplete="given-name" of autocomplete="street-address" stelt browsers en wachtwoordmanagers in staat velden correct automatisch in te vullen, waardoor de belasting voor gebruikers met motorische beperkingen, cognitieve beperkingen of iedereen voor wie herhaald typen moeilijk is, drastisch wordt verminderd. WCAG 1.3.5 (Identify Input Purpose, Level AA) vereist dit voor velden die persoonlijke informatie verzamelen.

Je formulieren testen op toegankelijkheid

De regels kennen is één ding; weten of je formulieren ze daadwerkelijk volgen is iets anders. Een gecombineerde teststrategie is de meest betrouwbare aanpak. Hoewel tools zoals Lighthouse en WAVE kunnen helpen om problemen automatisch te detecteren, is handmatig testen met alleen toetsenbordnavigatie en schermlezers essentieel om problemen met bruikbaarheid in de echte wereld op te sporen.

Voor toetsenbordtesten hoef je alleen je muis los te koppelen en te proberen het formulier in te vullen. Je moet elk veld kunnen bereiken, elke knop kunnen activeren en elke foutmelding kunnen ontvangen met alleen Tab, Shift+Tab, pijltjestoetsen en Enter/Spatie. Als je vastloopt, is dat een mislukking. Voor schermlezertesten gebruik je NVDA met Firefox op Windows of VoiceOver met Safari op macOS. Schermlezers gedragen zich net iets anders dan elkaar — andere sneltoetsen, andere semantische aankondigingen en andere ondersteuning voor functies; zo werkt NVDA beter met Firefox, terwijl VoiceOver het best werkt met Safari. Testen met ten minste twee combinaties zal het breedste scala aan problemen aan het licht brengen.

Tools zoals WAVE en Axe zijn uitstekend om formulieren te scannen op ontbrekende labels, onjuiste ARIA-attributen en slecht kleurcontrast. Deze geautomatiseerde tools kunnen rechtstreeks in je CI/CD-pijplijn worden geïntegreerd om regressies te detecteren voordat ze in productie komen. Omdat toegankelijkheidsrichtlijnen genuanceerd zijn, kunnen geautomatiseerde tools echter slechts ongeveer 30% van de WCAG-problemen detecteren — daarom moet de geautomatiseerde laag worden aangevuld met handmatige beoordeling en idealiter testen met echte gebruikers die afhankelijk zijn van ondersteunende technologie.

Wanneer je je markup handmatig beoordeelt, stel jezelf de volgende vragen voor elk formulierveld: Heeft het een zichtbaar label? Is dat label programmatisch gekoppeld via for/id of ARIA? Is eventuele hinttekst gekoppeld met aria-describedby? Stelt elke foutstatus aria-invalid="true" in en verwijst deze naar de foutmelding via aria-describedby? Is het attribuut required aanwezig op verplichte velden? Kun je elk interactief element uitsluitend met een toetsenbord bereiken en bedienen?

Belangrijkste punten

• Elke input heeft een programmatisch label nodig. Gebruik <label for='...'> voor alle formuliervelden — vertrouw nooit alleen op placeholdertekst. Elk formulierveld heeft een programmatisch label nodig, zonder uitzonderingen — placeholdertekst is geen label.
• Foutmeldingen moeten het probleem benoemen en een oplossing voorstellen. Foutmeldingen moeten het probleem identificeren en aangeven hoe het kan worden opgelost, en moeten met hun velden worden gekoppeld via aria-describedby.
• Vertrouw nooit alleen op kleur. Vertrouw niet alleen op kleur voor welke statusindicatie dan ook — gebruik tekst, pictogrammen en andere niet-kleurindicatoren naast kleurcodes.
• Beheer de focus na verzending. De fout moet duidelijk worden geïdentificeerd, snelle toegang tot het problematische element moet worden geboden en de gebruiker moet de fout eenvoudig kunnen herstellen en het formulier opnieuw kunnen verzenden. De focus verplaatsen naar een foutsamenvatting na een mislukte verzending is de gouden standaard.
• Test met echte tools, niet alleen aannames. Formulieren toegankelijk houden is geen eenmalige taak — het vereist regelmatige tests en updates om ervoor te zorgen dat ze compliant en gebruiksvriendelijk blijven. Combineer geautomatiseerde scans met navigatie met alleen toetsenbord en schermlezertests bij elke belangrijke formulierupdate.