SC 3.3.1 foutmeldingen vs instructies

[gjccopinga]

Als er bij het invullen van een formulier fouten worden gemaakt, dan kunnen die op verschillende manieren aangegeven worden aan de bezoeker. Er zitten twee belangrijke aspecten aan dit succescriterium, namelijk:

1. the item that is in error is identified and
2. the error is described to the user in text.

Het moet dus duidelijk zijn bij welke invoervelden een fout is gemaakt ('identified') en de fout moet door middel van tekst duidelijk gemaakt worden. Over dit laatste gaat vooral mijn vraag. Er staat dat de fout omschreven moet zijn.
Waar wij altijd vrij strikt in zijn geweest is dat wij bij foutmeldingen een duidelijk onderscheid maken tussen een foutmelding en een instructie. Als er dus een fout wordt gemaakt door een verplicht veld niet in te vullen, vinden wij een melding als "Dit veld is verplicht" een instructie en geen goede foutmelding. Het geeft niet aan wat er fout is gegaan, maar het geeft meer een instructie. En waarschijnlijk is dit een tekstuele herhaling van een * symbool wat er waarschijnlijk al stond.
Als er staat "Het veld 'Voornaam' is verplicht" is dat al duidelijker wat betreft het identificeren van het invoerveld waar het probleem zit, maar zien wij dit nog steeds als instructies en niet als een echte foutmelding.
Maar, de vraag is of er voorwaarden zijn waarin je dit soort meldingen toch goed zou kunnen keuren als er op een andere manier duidelijk wordt gemaakt dat er iets is fout gegaan en dat je de melding dus moet lezen als een 'foutmelding.
Bijvoorbeeld als er een duidelijk (rood?) icoon van een waarschuwing voor de tekstuele melding staat die ook een goede alternatieve tekst heeft gekregen. Of als er naast de tekst ook een rode kleur voor de tekst is gebruikt en ook een rode rand om het invoerveld is gezet. Is die combinatie dan wel voldoende.
Ik snap dat er veel combinaties mogelijk zijn, maar ik zoek naar voorbeelden waarin we een tekstuele instructie (die vriendelijker overkomt) toch goed zouden kunnen keuren.

Of, zijn er organisaties die minder streng zijn en instructies ook goed keuren als foutmelding. Ik denk dan aan instructies als "Vul een geldig e-mailadres in", of "een telefoonnummer moet uit 10 cijfers bestaan" (dit laatste zie ik overigens zelf meer als een foutsuggestie).

Ik hoor graag hoe anderen hier naar kijken.

[Aircl0wn]

Volgens mij is deze vrij simpel en wordt er te veel gezocht in het vertalen van 'described'. Volgens mij is de vereiste hier dat de error in tekst beschikbaar is. Er wordt niets gezegd over de inhoud/formulering van de melding. In de basis zou die tekst melding en een aria-invalid al voldoende zijn om hier te voldoen. Je hebt dan namelijk ook al je programmatische en visuele identificatie.

Uiteraard moet je suggesties doen voor het verhelpen van de fout, afhankelijk van de validatie die gedaan wordt.

vinden wij een melding als "Dit veld is verplicht" een instructie en geen goede foutmelding
Waar komt dit onderscheidt vandaan?

"Het veld 'Voornaam' is verplicht" is dat al duidelijker wat betreft het identificeren van het invoerveld
Als het goed is, is de melding al gekoppeld aan het invoerveld en wordt het ook visueel nabij input weergeven. Daarmee is er op meerdere manier (visueel en programmatisch) al een relatie beschikbaar.

Je laatste deel begrijp ik niet helemaal waar je naar op zoek bent. Uiteraard kun je nog extra dingen toevoegen om het duidelijker te maken, als je maar aan die basisvereisten voldoet.

[julezrulez]

Describe als in "Could you describe your attacker?" is meer dan aangeven dat je aangevallen bent. Ik ben van mening dat je ook aangeeft dat een veld niet is ingevuld als je deze vergeten bent in te vullen. Ik ben daar zelf ook heel binair in. Vooral als er een placeholder in een veld staat ben ik al snel geneigd te zien dat het verplichte veld allang is ingevuld. Ik ga voor de drie-eenheid: instructie-foutmelding-verbetersuggestie. Dit mag in lossen zinnen of in een samengestelde zin, maar uit de tekst moet duidelijk op te maken zijn wat je fout hebt gedaan.

[FerJo]

@gjccopinga Zoals jij het beschrijft, heb ik het ook altijd uitgelegd, en zo heb ik het ook altijd aan websitebouwers verteld.
Al vraag ik me af of W3C er ook zo over denkt, gezien de voorbeelden die ze geven.

Ik vind: een goede foutmelding geeft minstens antwoord op de vraag: WAT heb ik fout gedaan? Zo interpreteer ik 'the error is described to the user in text'.

Dus 'Dit veld is verplicht' voldoet daar niet aan, omdat ik niet weet WAT ik fout heb gedaan.
'Vul een geldig e-mailadres in': hetzelfde. Ik weet dat ik een geldig e-mailadres moet invullen, maar wat heb ik fout gedaan?

Nog beter zou zijn om ook in tekst het veld te noemen WAAR de fout is opgetreden, want dan voldoe je ook aan: 'the item that is in error is identified' (schijnt erg prettig te zijn voor mensen die inzoomen, omdat de visuele relatie tussen de melding en het foute veld onduidelijk kan zijn, en dan is een specifieke melding wel zo prettig, wat ook in het criterium staat: The error message should be as specific as possible.)

Bijvoorbeeld: Het verplichte veld 'Voornaam' is niet ingevuld.

Dan sla je 2 vliegen in een klap.

Maar mijn interpretatie van dit SC is wellicht toch strenger dan de voorbeelden die W3C geeft.

Voorbeeld: https://www.w3.org/WAI/WCAG21/Techniques/client-side-script/SCR18

Example 2: Foutmelding:

• Name can only have letters and spaces.
• Telephone number can only have digits and separators.

Hier staat niet WAT ik fout heb gedaan, maar blijkbaar is dit volgens de W3C toch een valide foutmelding.

Ander W3C-voorbeeld:
https://www.w3.org/WAI/WCAG21/working-examples/script-form-validation-2/index.php

Foutmeldingen:

• Please enter your forename

• Please enter your age

• Please enter your email address

• Enter a suggestion

• Please rate this suggestion

Als deze voorbeelden die W3C geeft valide zijn, dan zou dus een foutmelding als 'Dit veld is verplicht' en 'Vul een geldig e-mailadres in' wel mogen, en moeten we die meldingen dus in een audit goedkeuren, maar als best practice er iets bij moeten zetten iets als ():

'In het kader van The error message should be as specific as possible. zou een betere aanpak zijn om aan te geven wat er fout is gegaan. Dus bijvoorbeeld: 'Het e-maladres is ongeldig. Vul een geldig e-mailadres in.'

Dus hoewel ik een voorstander ben van duidelijke foutmeldingen, weet ik niet of we dit SC op die manier mogen interpreteren en dus andersoortige meldingen fout mogen rekenen.

Je vraagt je ook af of extra visuele aanwijzingen de foutmelding verduidelijken:

(...) als er op een andere manier duidelijk wordt gemaakt dat er iets is fout gegaan en dat je de melding dus moet lezen als een foutmelding. Bijvoorbeeld als er een duidelijk (rood?) icoon van een waarschuwing voor de tekstuele melding staat die ook een goede alternatieve tekst heeft gekregen. Of als er naast de tekst ook een rode kleur voor de tekst is gebruikt en ook een rode rand om het invoerveld is gezet. Is die combinatie dan wel voldoende?

In het SC staat, onder Benefits:

This Success Criterion may help people with cognitive, language, and learning disabilities who have difficulty understanding the meaning represented by icons and other visual cues.

Dus visuele clues lijken mij niet voldoende. TEKST moet hier leidend zijn, ongeacht de extra visuele aanwijzingen die je geeft. Dus iets extra's aanbieden aan vormgeving (icoon, rode tekst) maakt een tekst niet extra 'fouter' - volgens het SC.
Uiteraard is het wel beter, denk ik, maar 'the bare minimum' is voldoende.

Nog even doorbordurend over het identificeren van een 'fout veld' ... Ik heb het idee dat de locatie van de foutmelding - dicht bij het veld dat fout is - al genoeg is om antwoord te geven op de vraag WAAR de fout is opgetreden. Ik concludeer dat uit de techniek : Providing text descriptions to identify required fields that were not completed

Ik heb de tekst nog even ontleed en dan kom ik dit tegen:

Another approach, using server-side validation, is to re-display the form (including any previously entered data), with either a text description at the location of the omitted mandatory field, or a text description that identifies the omitted mandatory fields.

'a text description at the location of the omitted mandatory field':
de locatie in de buurt van het veld is blijkbaar genoeg als antwoord op: 'the item that is in error is identified'

'a text description that identifies the omitted mandatory fields.':
als de foutmelding niet in de buurt staat van het veld - bovenaan het formulier bijvoorbeeld of in een alert - noem dan het veld dat fout is.

Dan zou dit dus voldoen aan SC 3.3.1:

Voornaam *: [ ]
Dit verplichte veld is niet ingevuld

De foutmelding staat in de buurt van het 'foute veld' dus het veld is 'identified'.

[gjccopinga]

Ik wil deze discussie toch nog even nieuw leven inblazen, omdat ik met het volgende zit.

Foutmeldingen worden ook gezien als statusberichten (Als er geen contextwijziging is in ieder geval).

Stel ik heb bij drie verplichte invoervelden niets ingevuld en bij elk veld staat er een foutmelding direct onder met de tekst "Dit is een verplicht veld". En, stel ik gebruik bij elk van deze meldingen een aria-live="polite" of role="status" (bij meerdere meldingen bij voorkeur geen role="alert" of aria-live="assertive", omdat screenreaders problemen hebben als dit meerdere keren voorkomt binnen één pagina en ze tegelijk verschijnen; vaak wordt er dan maar één van de drie voorgelezen), dan worden de drie foutmeldingen (buiten de context van het invoerveld) als volgt opgelezen: "Dit veld is verplicht. Dit veld is verplicht. Dit veld is verplicht". Leuk dat deze meldingen dus direct worden voorgelezen en dat ik dus weet dat er blijkbaar op drie plekken iets niet is ingevuld wat wel had gemoeten, maar ik weet dus nog steeds niet waar het probleem zich dan voordoet.

Dus, in combinatie met SC 4.1.3 zou een foutmelding zoals die bij 3.3.1 nodig is dan misschien minimaal toch het veld moeten identificeren waar het probleem zich voordoet. Dan is iets als "dit veld" niet afdoende. Dan moet het minimaal iets zijn als "Het veld voornaam is verplicht". Als je dan drie keer een melding krijgt over een verplicht veld, dan weet je in ieder geval om welke velden het gaat.

De vraag is echter of we dit dan bij 3.3.1 willen afkeuren, of alleen bij 4.1.3, omdat de statusberichten niet duidelijk genoeg zijn. Of, keuren we dit helemaal nergens af?

[Aircl0wn]

Voor 3.3.1: Als je een foutmelding hebt, welke gekoppeld is aan een input met een aria-invalid state dan is die relatie gemaakt. Je hebt dan aan beide eisen voldaan

Vor 4.1.3 zit je op eenzelfde vlak dat hier normatief enkel gesteld wordt dat je die status message goed opmaakt dat deze bijvoorbeeld voorgelezen kan worden (aria-live) hier wordt niets meer gesteld over de inhoud van het bericht.

Het kan aanzienlijk beter, maar ik vraag me dus af of je het wel kunt afkeuren.

Ik ben persoonlijk een groot voorstander van samenvattingen aan het begin van het formulier, waar de gebruiker alle informatie in een keer kan vinden. Je hoeft dan ook niet moeilijk meet concurrerende aria=live of alert zettingen te werken, maar kan de gebruiker direct naar deze samenvatting geleiden. Die samenvatting dan wel als status message opmaken uiteraard.

[BartCardan]

Ik wil deze toch nog een keer aanwakkeren. Vooral omdat ik verschillen zie tussen de understanding van WCAG 2.1 en 2.2 die mij niet eerder zijn opgevallen.

Op https://www.w3.org/WAI/WCAG21/Understanding/error-identification.html wordt bij "Benefits" gezegd:

This Success Criterion may help people with cognitive, language, and learning disabilities who have difficulty understanding the meaning represented by icons and other visual cues.

In de WCAG 2.2 versie hiervan op https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html wordt nergens meer verwezen naar icoontjes en is deze "benefit" aangepast in:

This success criterion may help people with cognitive, language, and learning disabilities who have difficulty understanding the specific reason why a form submission failed (in cases where this is not already made obvious by the nature of the form).

Er staat verder wel dat de fout duidelijk gemaakt moet worden in tekst, maar de volgende zin geeft misschien toch wat vrijheid om een icoon toe te voegen:

It is perfectly acceptable to indicate the error in other ways such as through the use of an image, color, or other visual indicator, in addition to the text description.

Vlak voor de "benefits" staat een note en die zegt het volgende:

This criterion does not cover which of these methods should be used - the only requirement is for errors to be presented to users in text or a text alternative.

Vooral het laatste stukje vind ik interessant, namelijk "or a text alternative". Dit doet vermoeden dat een icoontje met een tekstalternatief of een aria-invalid="true" toch zou mogen en gezien kan worden als "as text".

Gekeken naar deze atomic rule (proposed) dan geeft Expectation 3 misschien wat ruimte, maar ik hoor graag ook andere meningen: https://www.w3.org/WAI/standards-guidelines/act/rules/36b590/proposed/
Hierin staat:

Each test target either has no form field error indicators or at least one of the form field error indicators describes: the cause of the error, or how to resolve it, in text that is included in the accessibility tree or included in the accessible name or accessible description of the test target.

Ik lees dit als volgt:
Als een invoerveld een fout heeft en dit is visueel duidelijk (form field error indicator) dan moet deze de fout omschrijven in tekst die beschikbaar is in de accessibility tree, in de accessible name of in de description van het invoerveld. Oftewel: een gekoppelde instructie met een andere indicator (bijv. icoon) gekoppeld met aria-describedby zou dus mogen.

Lees ik dit goed?

Met deze nieuwe input, kunnen we dan misschien een conclusie trekken?
Ik denk dat er zeker ruimte is voor icoontjes met de aanpassing van de understanding van WCAG 2.2, mits dat ook programmatisch duidelijk is dat het een fout is

[sander-nl]

Een icoon met een goed tekstalternatief in combinatie met een instructie vind ik voldoende voor 3.3.1. Natuurlijk kan het altijd beter, maar we moeten kijken naar wat minimaal nodig is volgens het succescriterium.

[rianrietveld]

Bij het toevoegen van alleen een icoontje, en niet de tekst fout (of vergelijkbaar), ga je uit van voorkennis van de gebruiker, dat die het icoontje snapt. Een icoontje alleen (ook met alt tekst) is mijns inziens onvoldoende.