Je klikt op ‘Versturen’ en het formulier blijft staan. Naast het e-mailadres verschijnt een rode rand. Wat is er mis: ontbreekt het adres, is het formaat verkeerd, of heeft de server het verzoek geweigerd? Voor de ontwikkelaar is validatie misschien een boolean. Voor de bezoeker is het een moment waarop de hele taak kan vastlopen.
Een toegankelijke foutmelding doet meer dan een ongeldige waarde markeren. Ze benoemt het probleem, maakt duidelijk waar het zit en helpt de bezoeker verder. Dat begint bij begrijpelijke tekst, maar vraagt ook om de juiste relatie tussen een invoerveld, zijn foutmelding en de focus in de interface.
Begin niet met JavaScript, maar met de boodschap
‘Ongeldige invoer’ is technisch correct maar weinig behulpzaam. Bij een leeg e-mailveld kun je schrijven: ‘Vul je e-mailadres in.’ Bij een verkeerd formaat: ‘Vul een geldig e-mailadres in, bijvoorbeeld naam@bedrijf.nl.’ Het eerste zegt wat ontbreekt, het tweede hoe de invoer kan worden hersteld.
WCAG 2.2-succescriterium 3.3.1 vraagt dat een automatisch gedetecteerde invoerfout wordt geïdentificeerd en in tekst beschreven. Succescriterium 3.3.3 vraagt waar mogelijk een correctiesuggestie. Een rode rand alleen volstaat dus niet. Deze uitleg is geen claim dat een compleet formulier daarmee al WCAG-conform is.
Geef het veld een naam en verbind de foutmelding
Neem één e-mailveld als klein demonstratief voorbeeld. Het label blijft zichtbaar wanneer iemand begint te typen; de melding heeft een eigen element en wordt aan het veld gekoppeld via aria-describedby.
<form id="contact" novalidate>
<label for="email">E-mailadres (verplicht)</label>
<input id="email" name="email" type="email"
required aria-describedby="email-error">
<p id="email-error"></p>
<button type="submit">Versturen</button>
</form>Het required-attribuut legt de verplichting vast. type="email" biedt ingebouwde controle op het invoerformaat. Met novalidate schakelen we de standaard browsermelding bij verzenden uit, zodat het voorbeeld een eigen foutafhandeling kan demonstreren. In productie moet die afhandeling dan ook daadwerkelijk beschikbaar en toegankelijk zijn.
Laat zien wat de browser al weet
De Constraint Validation API geeft onder meer aan of een veld leeg is terwijl het verplicht is (valueMissing) of niet voldoet aan het verwachte e-mailformaat (typeMismatch). Daarmee hoeft een developer niet voor ieder veld zelf een reguliere expressie te verzinnen.
const form = document.querySelector('#contact');
const email = document.querySelector('#email');
const error = document.querySelector('#email-error');
function validateEmail() {
const message = email.validity.valueMissing
? 'Vul je e-mailadres in.'
: email.validity.typeMismatch
? 'Vul een geldig e-mailadres in, bijvoorbeeld naam@bedrijf.nl.'
: '';
error.textContent = message;
if (message) email.setAttribute('aria-invalid', 'true');
else email.removeAttribute('aria-invalid');
return message === '';
}
form.addEventListener('submit', (event) => {
event.preventDefault();
if (!validateEmail()) {
email.focus();
return;
}
// Voorbeeld stopt hier: implementeer en controleer
// serververwerking voordat je succes meldt.
});
email.addEventListener('input', () => {
if (email.getAttribute('aria-invalid') === 'true') {
validateEmail();
}
});De code toont het mechanisme maar verzendt geen bericht. Ze is tegen de genoemde API-documentatie gecontroleerd, niet als volledige implementatie in browsers of met schermlezers getest. Het is belangrijk dat het voorbeeld geen schijnsucces toont: een geslaagde client-side-check betekent nog niet dat de server een inzending heeft ontvangen.
Waarom de timing van een melding uitmaakt
Fouten tonen bij iedere toetsaanslag kan hinderlijk zijn. Iemand die net aan een e-mailadres begint, krijgt dan al een waarschuwing voordat het adres af is. In het voorbeeld verschijnen fouten bij verzenden en wordt een bestaande fout tijdens het corrigeren bijgewerkt. Dat is één bruikbare aanpak, geen universele regel. Test wat voor jouw formulier en gebruikers werkt.
Bij langere formulieren is alleen de eerste fout focussen mogelijk onvoldoende. Een foutoverzicht bovenaan, met links naar de betrokken velden, kan helpen. Zorg ook dat dynamisch veranderende meldingen voor hulptechnologie waarneembaar zijn; de precieze aanpak hangt af van de interactie en vereist handmatige toetsing.
De browser is niet de beveiligingsgrens
Een gebruiker kan client-side-validatie omzeilen door verzoeken rechtstreeks naar de server te sturen. Controleer verplichte gegevens en toegestane waarden daarom ook op de server. Verschijnt daar een fout, laat dan de eerder ingevoerde geldige informatie staan en geef opnieuw een herstelbare melding.
Ook de uitkomst van de verwerking moet helder zijn. Een knop die ophoudt met draaien is geen ontvangstbewijs. Toon pas een succesmelding wanneer de server de inzending daadwerkelijk heeft geaccepteerd. Het W3C maakt onderscheid tussen feedback bij individuele velden en feedback over het formulier als geheel.
Zo controleer je of bezoekers verder kunnen
Begin met een leeg formulier en druk op Verzenden. Is duidelijk welk veld ontbreekt? Vul daarna een verkeerd adres in, corrigeer het en controleer of de melding verdwijnt. Loop alles zonder muis door. Herhaal de taak bij vergroting, op een smal scherm en met een schermlezer. Simuleer tot slot een serverfout: blijven ingevulde waarden behouden en krijgt de bezoeker een bruikbare uitleg?
Documenteer met welke browser, apparaten en ondersteunende technologie is getest. Een codevoorbeeld of automatische scan bewijst niet dat de gehele interactie toegankelijk is.
Voor een bredere controle van labels, verzending en het volledige contactproces, zie Dogteams zeven controles voor een toegankelijk contactformulier. Onze sponsor BlazeForce beschrijft daarnaast de verwerking van formulierinzendingen met BlazeForce Forms. Beoordeel iedere gekozen plugin op dezelfde principes.
Een foutmelding is pas goed als ze de taak herstelt
Technisch gezien gaat validatie over de vraag of invoer aan regels voldoet. Voor de bezoeker gaat het over iets anders: kan ik begrijpen wat er mis is en mijn taak alsnog afronden? Koppel daarom duidelijke tekst aan semantische velden, gebruik browsermogelijkheden waar dat helpt en test ook de uitzonderingen. Toegankelijke validatie is geen losse rode rand, maar onderdeel van de volledige gebruikersroute.
Bronnen
- W3C WAI — Validating Input
- W3C WAI — User Notifications
- WCAG 2.2 — Error Identification
- WCAG 2.2 — Error Suggestion
- MDN — Constraint Validation API
Neem contact met ons op
Vertel ons waarmee we kunnen helpen; we reageren binnen twee werkdagen.
