Onjuist gedrag: een praktijkgids voor formulierfouten

Er is een zin die op meer websites voorkomt dan zou moeten:

“Ongeldige invoer.”

Ongeldig in welke zin? De gebruiker moet het maar raden, en de meesten zullen daar geen moeite voor doen. Ze zullen het formulier verlaten, en jij zult nooit weten waarom.

Foutmeldingen in formulieren zijn het punt waarop UX, toegankelijkheid en elementaire duidelijkheid vaak tegelijkertijd in het gedrang komen; en de kosten zijn reëel. Afgebroken aanvragen, gefrustreerde klanten, gebruikers van schermlezers die worden uitgesloten van diensten waar ze wettelijk recht op hebben. Beschouw dit als een praktijkgids: een lijst met veelvoorkomende foutmeldingen die je op de meeste websites tegenkomt, waarom ze schadelijk zijn en wat je in plaats daarvan kunt schrijven.

Foutmeldingen die je vast wel eens hebt gezien

Als je ooit online een formulier hebt ingevuld, ben je deze meldingen waarschijnlijk allemaal wel eens tegengekomen.

• “Voer een geldig e-mailadres in.” De gebruiker typte joe@gmail en vergat de .com. Je validator weet wat er ontbreekt. De foutmelding zou dat ook kunnen weten, maar zegt het niet.

• “Dit veld is verplicht.” Op een formulier met zeventien velden is dit bericht functioneel nutteloos. Welk veld? De gebruiker moet het hele formulier doorlopen om erachter te komen.

• “Er is een fout opgetreden.” Dit is een status, geen bericht. Het vertelt de gebruiker dat er iets is gebeurd, zonder te zeggen wat, waar of wat hij nu moet doen.

• “Het wachtwoord moet ten minste één hoofdletter, één kleine letter, één cijfer en één speciaal teken bevatten (maar niet deze specifieke speciale tekens), minimaal 12 en maximaal 16 tekens lang zijn, mag uw gebruikersnaam niet bevatten en mag niet overeenkomen met een van uw laatste 24 wachtwoorden.” Erger nog: dit bericht verschijnt vaak pas nadat de gebruiker het formulier heeft verzonden, nooit van tevoren als richtlijn.

• “Er is iets misgegaan.” De meest voorkomende foutmelding op het internet. Ook een van de minst nuttige. Het vertelt de gebruiker niets over het probleem en biedt geen oplossing.

• Een rood sterretje en stilte. Het formulier blijft staan. De verzendknop doet niets. De gebruiker klikt opnieuw, laadt de pagina opnieuw, raakt alles kwijt wat hij heeft getypt en vertrekt. Vanuit het perspectief van de gebruiker is de site kapot.

Waarom dit ook buiten de UX van belang is

Voor een ziende toetsenbordgebruiker is een vaag foutbericht frustrerend. Voor een gebruiker van een schermlezer kan het ertoe leiden dat een formulier daadwerkelijk onmogelijk in te vullen is. Er zijn vier veelvoorkomende manieren waarop dit misgaat:

• De foutmelding verschijnt wel, maar de schermlezer leest deze nooit voor. Boven het veld wordt een rood bericht weergegeven. Visueel is het duidelijk. Voor een gebruiker van een schermlezer die al voorbij die plek is getabd, bestaat de foutmelding niet. Zonder aria-live of role=“alert” blijft de foutmelding onopgemerkt.

• De foutmelding wordt wel voorgelezen, maar is niet gekoppeld aan het veld. De schermlezer leest ergens op de pagina “E-mailadres is ongeldig” voor. Wanneer de gebruiker teruggaat naar het e-mailveld, geeft het veld zelf geen enkele indicatie dat er een fout is opgetreden. De gebruiker moet onthouden welk veld de fout bevatte en wat er mis mee was. De oplossing is het gebruik van aria-describedby om het veld aan de fouttekst te koppelen.

• Fouten worden na het verzenden als een muur van tekst aangekondigd. “Corrigeer de volgende fouten: E-mailadres is ongeldig. Telefoonnummer is ongeldig. Postcode is ongeldig. Provincie is verplicht.” Dit is technisch gezien WCAG-conform. Functioneel gezien biedt het de gebruiker geen mogelijkheid om naar een specifieke fout te navigeren en dwingt het hen om de hele lijst te onthouden terwijl ze terugscrollen door het formulier.

• Kleur doet al het werk. De rand van het veld wordt rood. Het label wordt rood. Het sterretje krijgt een opvallendere rode tint. Dit is allemaal niet waarneembaar voor gebruikers met slecht zicht, kleurenblindheid of die afhankelijk zijn van een schermlezer. Een visuele indicator zonder programmatische indicator is geen toegankelijkheidsfunctie, maar decoratie.

Dit is geen theorie. Fouten in formulieren behoren steevast tot de meest genoemde problemen bij WCAG 2.1 AA-audits en klachten bij de EAA. Ook in de beoordelingen van DigiToegankelijk worden ze voortdurend gesignaleerd. In onderzoeken op grond van Titel II wordt ernaar verwezen. Als uw formulier fouten niet duidelijk aan elke gebruiker kenbaar maakt, sluit u mensen uit van de dienst die dat formulier biedt; dit is in toenemende mate zowel een kwestie van naleving als van gebruiksvriendelijkheid.

Kenmerken van een correcte foutmelding

Als je deze volgorde goed aanhoudt, schrijven de meeste foutmeldingen zichzelf.

Wat is er misgegaan?

Dit is het deel dat de meeste foutmeldingen overslaan. Ze vertellen de gebruiker dat er iets mis is gegaan, zonder te zeggen wat. “Ongeldig.” “Mislukt.” “Fout.” Dit zijn statuslabels, geen uitleg.

Om het probleem te benoemen, moet je weten wat het probleem eigenlijk is. Dat klinkt voor de hand liggend, maar een verrassend aantal foutmeldingen wordt geschreven door ontwikkelaars die de validatieregel wel zien, maar deze nooit terugvertalen naar gewone taal. Als je validator weet dat er een domein ontbreekt in het e-mailadres, moet de foutmelding dat aangeven. Als het veld precies 10 cijfers vereist, zeg dat dan. Als het wachtwoord is afgewezen omdat het overeenkomt met een eerder wachtwoord, benoem dat dan specifiek in plaats van het hele wachtwoordbeleid eruit te gooien.

De test: kan de gebruiker, door alleen de foutmelding te lezen, in zijn eigen woorden uitleggen wat er mis is gegaan? Zo niet, dan heb je vraag één niet beantwoord.

Waar is het misgegaan?

De foutmelding moet gemakkelijk te vinden zijn. Op een formulier met twee velden is dat eenvoudig. Op een formulier met twintig velden dwingt de melding „dit veld is verplicht“ de gebruiker om het hele formulier af te speuren op zoek naar de fout. Tegen de tijd dat hij het gevonden heeft, is hij vergeten wat hij aan het doen was.

De locatie werkt op twee niveaus. Visueel moet de foutmelding naast of direct onder het veld verschijnen waar het betrekking op heeft — niet bovenaan het formulier, niet in een pop-up, niet in een toast die na drie seconden verdwijnt. Programmatisch moet de foutmelding aan het veld worden gekoppeld met aria-describedby, zodat schermlezers het als onderdeel van het veld aankondigen, niet als een losstaande zin die ergens op de pagina zweeft.

Wanneer de gebruiker de fout tegenkomt, mag hij nooit hoeven te vragen “welke?”.

Wat moet de gebruiker hieraan doen?

Dit is waar de meeste foutmeldingen net tekortschieten om echt nuttig te zijn. Ze wijzen het probleem aan en geven aan waar het zit, maar laten het aan de gebruiker over om zelf uit te zoeken hoe hij het moet oplossen.

Iemand vertellen dat “je wachtwoord te kort is” is beter dan “ongeldig wachtwoord”, maar “je wachtwoord bestaat uit 8 tekens – het moet er minstens 12 zijn” is nog beter. De eerste versie geeft een feit weer. De tweede versie geeft de gebruiker een doel. Ze weten precies hoeveel tekens ze nog nodig hebben en kunnen daarop reageren zonder het wachtwoordbeleid opnieuw te hoeven lezen.

Soms is de oplossing duidelijk uit het probleem af te leiden (“het telefoonnummer mist het netnummer” impliceert “voeg het netnummer toe”). Soms is dat niet het geval (“deze kaart is verlopen” zou gepaard moeten gaan met “probeer een andere kaart of werk de vervaldatum bij”). Bij twijfel: leg het duidelijk uit.

Voor-en-na-voorbeelden

Het patroon is consistent: specifiek, concreet en bruikbaar. Elke melding leest alsof ze door een mens voor een ander is geschreven, en niet als een statuscode die in gewone taal is vertaald.

De technische checklist

De bovenstaande principes zijn gemakkelijker toe te passen in combinatie met de implementatiedetails. Hieronder volgt een beknopte samenvatting van wat elk toegankelijk formulier nodig heeft.

• Geef fouten aan met tekst, niet alleen met kleur. Rode randen zijn acceptabel als aanvulling. Ze zijn geen vervanging. Elke fout moet een tekstlabel hebben waarin het probleem in woorden wordt benoemd.

• Koppel de fout programmatisch aan het veld. Gebruik aria-describedby op het invoerveld, verwijzend naar de ID van het foutbericht. Wanneer een gebruiker van een schermlezer de focus op het veld legt, moet hij de veldnaam, eventuele instructies en de fout horen.

• Markeer ongeldige velden als ongeldig. Gebruik aria-invalid=“true” op het invoerveld wanneer het zich in een foutstatus bevindt. Dit geeft aan ondersteunende technologie door dat dit specifieke veld een probleem heeft.

• Geef fouten aan wanneer ze verschijnen. Gebruik voor fouten die na het verzenden of asynchrone validatie aan het licht komen role="alert" of aria-live=“polite”, zodat schermlezers ze aankondigen zodra ze verschijnen, zonder dat de gebruiker ernaar hoeft te zoeken.

• Stuur bij het verzenden de focus naar de eerste fout. Een samenvatting bovenaan het formulier is nuttig, maar niet voldoende. Verplaats de toetsenbordfocus naar het eerste ongeldige veld, of naar een focusbare foutensamenvatting die naar elk ongeldig veld linkt. Dit is vaak het verschil tussen een formulier dat 30 seconden kost om te corrigeren en een formulier dat vijf minuten kost.

• Valideer op het juiste moment. Inline validatie werkt goed voor zaken die je in realtime kunt controleren, zoals de sterkte van een wachtwoord of het e-mailformaat. Het werkt slecht voor zaken die je niet kunt controleren, zoals controles aan de serverzijde of validatie tussen verschillende velden. Vertel iemand niet dat zijn e-mail ongeldig is op het moment dat hij het eerste teken typt. Laat hem eerst uit typen.

• Bewaar wat ze hebben ingevoerd. Een formulier waarvan de velden bij een fout worden gewist, wordt niet nog een keer ingevuld. Dit geldt met name voor lange tekstvelden, zoals feedback of sollicitatiebrieven.

Een kleine mentaliteitsverandering

De meeste foutmeldingen zijn geschreven vanuit het perspectief van het systeem. Ongeldig. Verplicht. Mislukt. Dit zijn statuscodes die als zinnen worden gepresenteerd.

Betere foutmeldingen zijn geschreven vanuit het perspectief van de gebruiker. Ze gaan ervan uit dat de gebruiker iemand is die zijn best doet, die ergens vastloopt en graag weer verder wil. Ze wijzen niemand de schuld toe en geven de gebruiker niet het gevoel dat hij voor een test is gezakt.

Het verschil is klein, maar het verandert de ervaring volledig:

• “U heeft een ongeldige datum ingevoerd” → “We hebben de datum nodig in de indeling DD-MM-JJJJ”

• “Telefoonnummer is ongeldig” → “Voeg alstublieft het netnummer toe”

• “Deze actie kan niet worden voltooid” → “Deze kaart is verlopen. Wilt u een andere proberen?”

• “Verboden” → “U moet opnieuw inloggen, uw sessie is verlopen”

Het formulier is geen quiz waar de gebruiker voor zakt. Het is een hulpmiddel dat u aanbiedt, en de foutmeldingen maken deel uit van het gesprek.

De test met twee vragen

Voordat je een foutmelding implementeert, lees deze dan hardop voor en vraag jezelf af: zou ik dit tegen iemand zeggen die recht voor me staat? En als ik dat zou doen, zou diegene dan weten wat hij of zij vervolgens moet doen?

Als het antwoord op een van beide vragen ‘nee’ is, herschrijf de melding dan. Als het antwoord op beide vragen ‘ja’ is, doet de melding waarschijnlijk goed wat ze moet doen.

De volgende keer dat je een formulier controleert, van jezelf of van iemand anders, begin dan met de foutmeldingen. Daar zitten de problemen meestal verstopt.