Een foutmelding die een schermlezer mist

Bij een foutmelding moeten drie dingen kloppen: de bezoeker moet merken dát er iets fout is, weten in welk veld, en begrijpen hoe hij het herstelt. Een rode rand levert hooguit het eerste, en alleen voor wie kleur waarneemt. Een schermlezer leest de tekst en de rol van elementen voor, niet hun kleur.

De W3C-tutorials over webtoegankelijkheid (https://www.w3.org/WAI/tutorials/) bundelen praktische richtlijnen voor veelvoorkomende onderdelen van webpagina's en combineren WCAG-succescriteria en -technieken. De overzichtspagina beschrijft niet specifiek hoe je foutmeldingen in formulieren koppelt; zoek daarvoor de relevante tutorialpagina op. Die tutorials zijn een goed vertrekpunt, maar ze vervangen je eigen test niet: hoe jouw formulier zich gedraagt hangt af van je code, je plug-ins en je schermlezer.

Typische symptomen die je kunt herkennen:

• De fout staat alleen in een melding bovenaan, zonder verwijzing naar het veld.
• De foutmelding verschijnt visueel onder het veld, maar staat niet in dezelfde volgorde of is niet aan het veld gekoppeld.
• De status 'ongeldig' bestaat alleen als kleur of icoontje zonder tekstalternatief.
• Na verzenden springt de focus nergens naartoe, dus de bezoeker blijft op de verzendknop staan.

Doe de diagnose op een kopie of testomgeving van het formulier, en bij voorkeur met een echte schermlezer. Welke je gebruikt (een ingebouwde of een losse) en welke combinatie met je browser, is jouw keuze; resultaten kunnen per combinatie verschillen.

1. Verstuur het formulier leeg of met bewust foute invoer. Noteer wat je ziet en wat je hoort. Gebeurt er auditief iets, of blijft het stil?
2. Navigeer met enkel het toetsenbord. Waar staat de focus na het verzenden? Kun je met Tab bij elk foutief veld komen?
3. Laat per foutief veld voorlezen. Hoort je naast de veldnaam ook dat het ongeldig is en wat de foutmelding zegt?
4. Schakel de kleuren uit of bekijk in grijstinten. Is nog steeds duidelijk welk veld fout is? Zo niet, leunt de uitleg te veel op kleur.

Schrijf per stap één regel op: verwacht, gezien, gehoord. Dat is je nulmeting. Zonder nulmeting kun je na de aanpassing niet aantonen dat er iets verbeterd is.

Gebruik de onderstaande tabel als beslisblad. Welke technische middelen jouw formulierbouwer toelaat, controleer je bij de beheerder of in de documentatie van je tool; ik verzin hier geen menunamen.

Kies per situatie één oplossing en pas die overal in hetzelfde formulier consistent toe. Mengvormen maken het voor gebruikers en voor jezelf moeilijker om te testen.

Herhaal na elke aanpassing dezelfde vier diagnosestappen en vergelijk met je nulmeting. Gebruik deze controlelijst:

• Elk invoerveld heeft een zichtbaar en programmatisch gekoppeld label.
• Elke foutmelding is gekoppeld aan het veld waarop ze slaat.
• De status 'ongeldig' is niet enkel via kleur herkenbaar.
• De foutmelding legt uit wat er fout is en hoe je het herstelt.
• Na verzenden met fouten gaat de focus naar een samenvatting of naar het eerste foutieve veld.
• Na het herstellen van een veld verdwijnt de foutmelding, ook voor de schermlezer.
• Het formulier is volledig met toetsenbord te bedienen.
• Je hebt dit getest in minstens één schermlezer en één browser, en genoteerd welke.

Test ook op mobiel als een deel van je bezoekers daar formulieren invult. Dat gedrag kan afwijken van de desktop, dus noteer de uitkomst apart. Een geslaagde controle bewijst dat de geteste combinatie werkt, niet dat elke combinatie werkt, en ook geen volledige WCAG-conformiteit van het formulier.

Stel: een marketeer draagt een offerteformulier met vier velden over aan een ontwikkelaar. Dit is een fictief voorbeeld met alleen invoer en verwachte controles, zonder gemeten uitkomst.

Invoer: het veld 'E-mailadres' bevat de tekst 'jan@' en het veld 'Telefoon' is leeg maar verplicht.

Beschreven wensen in de overdracht:

1. Na verzenden verschijnt een samenvatting met twee items: 'E-mailadres: vul een volledig adres in, bijvoorbeeld naam@domein.be' en 'Telefoon: dit veld is verplicht'.
2. Elk item is een link naar het bijbehorende veld.
3. Onder elk foutief veld staat dezelfde tekst, gekoppeld aan het veld.
4. Het veld krijgt naast de rode rand ook de tekst 'Fout:' vóór de melding.

Verwachte controles: met schermlezer hoor je bij het veld 'E-mailadres' de naam, dat het ongeldig is en de foutmelding. Met alleen Tab bereik je beide velden. In grijstinten is nog te zien welke velden fout zijn. Wat de schermlezer precies uitspreekt, noteer je zelf; ik formuleer daar geen verwachte uitslag voor.

Toegankelijke foutafhandeling staat niet los van laadgedrag. MDN beschrijft webprestaties als de combinatie van objectieve metingen en de ervaren gebruikerservaring van laad- en runtime, waaronder of knoppen reageren (https://developer.mozilla.org/en-US/docs/Web/Performance). MDN geeft geen advies over foutmeldingen voor schermlezers. Als eigen redactioneel voorstel kun je ook controleren of de foutmelding binnen een voor jou aanvaardbare tijd verschijnt en wordt aangekondigd, want wachten zonder hoorbare terugkoppeling kan verwarrend zijn.

Maak van deze procedure een vaste stap bij elke nieuwe of gewijzigde formulierpagina: nulmeting, aanpassing, hercontrole, korte notitie met datum, schermlezer en browser. Zo kan een collega het later overnemen zonder alles opnieuw uit te zoeken.

Wil je daarnaast zien welke zichtbare signalen je website publiek afgeeft, bekijk die dan via Marketing Scan. Een publieke scan meet zichtbare signalen en kan een toetsenbord- of schermlezertest van je formulier niet vervangen.