Is een asterisk zonder verklaring bij verplichte velden een failure?

[Veyfeyken]

<label>Naam *</label>
<input...>

De betekenis van de asterisk (*) wordt nergens op de pagina verklaard.
Failure op 2.4.6 Headings and Labels of 3.3.2 Labels or Instructions?
Of valt dit niet onder de success criteria?

Note Rian:
Dit issue wordt verder afgehandeld in issue #55 Asterisk afkeuren 1.1.1 op basis dat het niet door alle screenreaders zoals TalkBack goed wordt voorgelezen.

[RenateRoke]

Ik keur dit altijd af onder 3.3.2 in ieder geval :)

[julezrulez]

Hoe moet iemand die voor het eerst van zijn leven een formulier invult anders weten wat een sterretje betekent? En voor iedereen geldt dat er een eerste keer was dat je tegen het sterretje aanliep al zullen velen van ons niet meer weten wanneer dat was.

[Aircl0wn]

• 3.3.2: is er een label? ja, dus geen issue. Of het inhoudelijk juist is, daar gaat dit SC niet om en er staat geen label AND instructions (helaas).
• 2.4.6: Is het label duidelijk genoeg? nee, sterretje is niet verklaard.
• 1.3.1: potentieel - Is het veld als required opgemaakt?

Vervolgens kun je nog een hele discussie hebben over hoe je dan het sterretje toont of niet. Zou hem verbergen voor screenreaders want het veld wordt door de juiste opmaak al als verplicht doorgegeven.

[JuliaRietveld]

Ik ben het met Renate en Jules eens mede omdat het onnodige foutmeldingen kan genereren als verplichte velden niet worden ingevuld. Maar ik weet dat er ook andere meningen zijn. Sommige onderzoekers gaan er vanuit dat alle velden verplicht zijn en het sterretje niet toe doet. Ik ben benieuwd naar jullie reacties.

[cstrobbe]

Hoe moet iemand die voor het eerst van zijn leven een formulier invult anders weten wat een sterretje betekent? En voor iedereen geldt dat er een eerste keer was dat je tegen het sterretje aanliep al zullen velen van ons niet meer weten wanneer dat was.

Wat hier geformuleerd wordt betreft alle gebruikers, los van functiebeperking. Wanneer de asterisk niet uitgelegd wordt, worden personen met een functiebeperking niet sterker benadeeld dan andere gebruikers. WCAG, daarentegen, gaat over problemen die personen met een functiebeperking benadelen tegenover andere personen (zonder aanspraak te maken op volledigheid).

Een ietwat vergelijkbare vraag werd ook reeds in de WCAG-issues op GitHub gesteld: Clarification on 3.3.2: Labels or Instructions with regard to required fields and Sufficient Techniques en de conclusie was dat het ontbreken van een uitleg over verplichte velden niet automatisch een fout tegen SC 3.3.2 is.

[rvantonisse]

Een sterretje / arterisk / * in dit geval kun je zien als non-text content. Of je het attribuut required op de input als alternatief rekent is discutabel, maar anderszijds is dit af te keuren onder 1.1.1 bij het ontbreken van een visueel alternatief ala: "*, een verplicht veld"

[rvantonisse]

Anderen rekenen het alternatief ala een foutmelding na versturen als voldoende. E.g. "dit veld is verplicht, maar niet ingevuld"

[cstrobbe]

Een sterretje / arterisk / * in dit geval kun je zien als non-text content.

De asterisk staat op elk Westers toetsenbord en werd decennia geleden al in ASCII opgenomen. Natuurlijk is de asterisk tekst.

[sophieschoice]

• 3.3.2: is er een label? ja, dus geen issue. Of het inhoudelijk juist is, daar gaat dit SC niet om en er staat geen label AND instructions (helaas).
• 2.4.6: Is het label duidelijk genoeg? nee, sterretje is niet verklaard.
• 1.3.1: potentieel - Is het veld als required opgemaakt?

Vervolgens kun je nog een hele discussie hebben over hoe je dan het sterretje toont of niet. Zou hem verbergen voor screenreaders want het veld wordt door de juiste opmaak al als verplicht doorgegeven.

Huh, 2.4.6 is wel een goede inderdaad. Daar heb ik niet aan gedacht.

Een sterretje / arterisk / * in dit geval kun je zien als non-text content. Of je het attribuut required op de input als alternatief rekent is discutabel, maar anderszijds is dit af te keuren onder 1.1.1 bij het ontbreken van een visueel alternatief ala: "*, een verplicht veld"

Het is enkel een violation van SC 1.1.1 als er een afbeelding wordt gebruikt voor de asterisk, ipv van het leesteken.

[cstrobbe]

Iemand moet bij de WCAG issues eens een common failure voor SC 2.4.6 voorstellen die het ontbreken van een uitleg voor de asterisk afkeurt. (Niet vragen of het een failure is maar direct een gedetailleerde failure indienen.)
Want dit komt zo dikwijls voor (ook al voor 2008) dat ik niet begrijp waarom deze failure niet bestaat als het ontbreken van een uitleg voor de asterisk vanuit het standpunt van WCAG effectief een failure is.

[rvantonisse]

Een sterretje / arterisk / * in dit geval kun je zien als non-text content.

De asterisk staat op elk Westers toetsenbord en werd decennia geleden al in ASCII opgenomen. Natuurlijk is de askterisk tekst.

Karakters kunnen ook gebruikt worden als icoon of in dit geval als aanduiding "Hier is iets mee". Zie het laatste gedeelte in de definitie van "non-text content" https://www.w3.org/TR/WCAG21/#dfn-non-text-content.

Zo worden streepjes (min-teken - ) gebruikt als opsommingsteken in platte tekst om een lijst te starten. Maar ook als kunst zoals ze beschrijven in de opvolgende note over "ASCII-Art". Het gemixed gebruik van karakters alszijnde text en non-text in een zin komt in ook voor, met bijvoorbeeld ASCII-emojis ¯\_(ツ)_/¯. Dit is een duidelijk voorbeeld van tekst als niet-tekst inzetten.

Anderen in deze thread noemen ook dat de arterisk zonder context ook niet duidelijk is. Vandaar dat een tekstalternatief hiervoor duidelijk nodig is; e.g. "* een verplicht veld". En is af te rekenen onder 1.1.1.

Betreft 2.4.6: helpt een arterisk niet met het verduidelijken van het doel, zonder is e.g. "naam" ook duidelijk. In de context van het formulier zal de gebruiker wel doorhebben dat er iets mee moet, maar wat is niet meteen duidelijk.
Betreft 1.3.1: eens met @Aircl0wn
Betreft 3.3.2: een met @Aircl0wn

[Veyfeyken]

Ik volg de redenering "crappy UI for all, not a failure". Het verklaren van de asterisk lijkt me een aanbeveling onder 2.4.6: Headings and Labels.

[cstrobbe]

De asterisk voor verplichte velden vergelijken met ASCII-art is een vergelijking tussen appels en peren. Dit wordt eigenlijk al gesuggereerd door de parallel die getrokken wordt met het liggend streepje (het minteken is geen leesteken) en het opsommingsteken: wanneer men namelijk het liggend streepje als opsommingsteken gebruikt in plaats van echte lijstelementen, is dit een overtreding van 1.3.1, niet van 1.1.1.

[RaphDeRooij]

<label>Naam *</label>
<input...>

De betekenis van de asterisk (*) wordt nergens op de pagina verklaard. Failure op 2.4.6 Headings and Labels of 3.3.2 Labels or Instructions? Of valt dit niet onder de success criteria?

Ik volg de redenering van @Veyfeyken en @cstrobbe: A crappy UI for all is not a WCAG failure. Het valt dus niet onder de succescriteria.

Wat niet wegneemt dat het een goed gebruik is om altijd duidelijk aan te geven wat de betekenis is van iets. Dus ook van een asterisk in de context van formuliervelden. Dat is, letterlijk, voor iedereen duidelijker.

[rvantonisse]

Zojuist nog even rond gekeken binnen de WCAG en de issues. In het eerder gerelateerde issue https://github.com/w3c/wcag/issues/2357 wordt ook verwezen naar een ander issue: https://github.com/w3c/wcag/issues/1698. Deze lijkt meer relevant. Daar wordt ook verwezen naar techniek H90, welke exact het voorbeeld beschrijft wanneer een asterisk wordt gebruikt voor de aanduiding van een verplicht veld.

Dit komt voor als techniek om te voldoen aan 3.3.2. Dat betekent alleen nog steeds niet dat het niet toepassen hiervan leidt tot een failure voor 3.3.2. Maar zou dus, wat ik probeer te beargumenteren, wel kunnen voor 1.1.1. Als de asterisk als figuur geïntepreteerd wordt.

Wat is visueel immers het verschil tussen of er een tekstteken of jpeg wordt gebruikt voor het asterisk? Nog steeds niet duidelijk voor de gebruiker wat de betekenis is. In het voorbeeld van H90 noemen ze:

It is important that the asterisk meaning is defined at the start of the form.

Alleen leggen ze dus niet uit waarom dat belangrijk is... wellicht is succes criterium 1.1.1 de reden.

[rvantonisse]

Ik deel de redenering "A crappy UI for all is not a WCAG failure" niet. Slechte, niet bruikbare, gebruikersinterface is naar mijn beleving juist een 100% toegankelijkheidsissue.

[sophieschoice]

Ik deel de redenering "A crappy UI for all is not a WCAG failure" niet. Slechte gebruikersinterface is naar mijn beleving juist een 100% toegankelijkheidsissue.

WCAG is er om websites toegankelijker te maken voor mensen met een beperking. Niet voor mensen zonder een beperking (al profiteren die daar wel van). Als er zaken zijn die voor iedereen impact (dus ook voor mensen zonder een beperking) hebben, dan is het een usability issue.

[Aircl0wn]

2.4.6 is hier heel kort en bondig volgens mij

Headings and labels describe topic or purpose.

Een onverklaard sterretje voldoet hier bij mij niet aan.

Ik deel de redenering "A crappy UI for all is not a WCAG failure" overigens ook niet en weet ook niet zo goed waarop deze stelling gebaseerd wordt? De enige melding hierover in WCAG heeft alleen betrekking op link teksten voor zover ik weet.

Het zal geen perfect voorbeeld zijn maargoed :)
Als ik een afbeelding plaats die je iets wil vertellen, maar niemand snapt 'm en er is ook geen tekst alternatief, is dat dan ook crappy UI en moeten we dat dan door de vingers zien? Er is nog steeds de intentie om je iets duidelijk te maken.
Ik vermoed dat, ook al snap je tijdens de audit een afbeelding niet, als je het idee hebt dat er een betekenis aan hangt en de alt tekst ontbreekt dan markeer je het waarschijnlijk als fail?

[rvantonisse]

en weet ook niet zo goed waarop deze stelling gebaseerd wordt?

Wat ik vond staat in de eerste paragraaf van de "Abstract":

Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities. These guidelines address accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines will also often make Web content more usable to users in general.

Maar hieruit concluderen dat als het een probleem voor ieder is, dat het dan geen toegankelijkheidsprobleem betreft gaat mij te ver.

Ook uitspraken als "wcag is alleen om mensen met een handicap / beperking te helpen" veroorzaakt juist een tegenovergestelde exclusieve benadering.

Hier staat juist dat het toegankelijk maken van web content het effect kan hebben dat deze voor zo veel mogelijk gebruikers, met in het bijzonder mensen met een handicap, bruikbaarder wordt.

De enige melding hierover in WCAG heeft alleen betrekking op link teksten voor zover ik weet.

Deze definitie is inderdaad expliciet gericht op linkdoelen: https://www.w3.org/TR/WCAG21/#dfn-ambiguous-to-users-in-general

Verder heb ik de conformance sectie meerdere malen proberen uit te pluizen om op dit punt iets te ontdekken, maar tot nu toe niets kunnen vinden.

In 2.4.6 hebben ze het over "topic OR purpose" (onderwerp OF doel). "Verplicht" klinkt eerder als een instructie, waardoor het beter zou passen bij 3.3.2. Maar daar stond wat jij @Aircl0wn al zij ook een OF tussen.

Daarom ben ik nog steeds benieuwd naar mijn interpretatie / fail case voor de asterisk (of elk ander gebruik van teksticonen / symbolen gebruikt als visuele verwijzing of status indicatie) onder 1.1.1. Daar zie ik hem dus graag afgekeurd.

[Aircl0wn]

Maar hieruit concluderen dat als het een probleem voor ieder is, dat het dan geen toegankelijkheidsprobleem betreft gaat mij te ver.

Ook uitspraken als "wcag is alleen om mensen met een handicap / beperking te helpen" veroorzaakt juist een tegenovergestelde exclusieve benadering.

Hier staat juist dat het toegankelijk maken van web content het effect kan hebben dat deze voor zo veel mogelijk gebruikers, met in het bijzonder mensen met een handicap, bruikbaarder wordt.

Eens

Daarom ben ik nog steeds benieuwd naar mijn interpretatie / fail case voor de asterisk (of elk ander gebruik van teksticonen / symbolen gebruikt als visuele verwijzing of status indicatie) onder 1.1.1. Daar zie ik hem dus graag afgekeurd.

Dit zou ik zeker niet standaard zo willen zien. Dat zou volgens mij een legio aan andere discussie cases gaan opleveren. Allen als de opmaak geschikt is, kun je het als non-text beschouwen. Terug naar je ASCII voorbeeld zou ik daar zoiets verwachten als een figure met figcaption en de ASCII content verborgen voor screenreaders.

Bij een label zou je dan het sterretje moeten verbergen en een alt tekst "verplicht" moeten toevoegen. Maar je krijgt dan als nog weer dubbele informatie (label + required state).

[cstrobbe]

Maar hieruit concluderen dat als het een probleem voor ieder is, dat het dan geen toegankelijkheidsprobleem betreft gaat mij te ver.
Ook uitspraken als "wcag is alleen om mensen met een handicap / beperking te helpen" veroorzaakt juist een tegenovergestelde exclusieve benadering.

Het doel van WCAG is het formuleren van criteria voor content die toegankelijk is voor personen met een functiebeperking en niet het formuleren van usability-criteria die content beter bruikaar maken voor het geheel van de bevolking.

Dat was de teneur van de discussies in de WCAG-werkgroep toen ik er zelf actief lid van was en dit is bij mijn weten niet veranderd.

Hier staat juist dat het toegankelijk maken van web content het effect kan hebben dat deze voor zo veel mogelijk gebruikers, met in het bijzonder mensen met een handicap, bruikbaarder wordt.

In het citaat uit de Abstract staat heel duidelijk dat het hoofddoel toegankelijkheid voor personen met een functiebeperking is en dat een betere usability voor de rest van de bevolking een "neveneffect" is. De algemene usability is dus ondergeschikt aan de toegankelijkheid.

Wanneer het over conformiteit gaat (en daar gaat deze discussie over), dient men zich strikt aan de succescriteria te houden in plaats van ze te verdraaien met het argument "maar zo is het beter voor de algmene bevolking".

Zie ook de Working Group Charters, b.v. het Web Content Accessibility Guidelines Working Group (WCAG WG) Charter van 2004:

The mission of the Web Content Accessibility Guidelines Working Group (WCAG WG) is to develop guidelines to make Web content accessible for people with disabilities.

Voor zover van usability sprake is, gaat het over de usability van WCAG (als document) en de ondersteunende documenten (How to Meet, Understanding ...), niet over de usability van andere websites.

Het huidige charter van 2019 heeft het ook enkel over toegankelijkheid, niet over usability.

---

Daarom ben ik nog steeds benieuwd naar mijn interpretatie / fail case voor de asterisk (of elk ander gebruik van teksticonen / symbolen gebruikt als visuele verwijzing of status indicatie) onder 1.1.1. Daar zie ik hem dus graag afgekeurd.

Dit kan alleen onder SC 1.1.1 vallen indien men een afbeelding van een asterisk als img-element zonder alternatieftekst (of een verkeerde alternatieftekst) gebruikt. De asterisk als ASCII-teken voor het identificeren van een verplicht veld valt vanzelfsprekend niet onder SC 1.1.1, aangezien het tekst is. (Een enkele asterisk is noch ASCII art, noch leetspeak, noch een emoticon, noch iets anders dat onder "non-text content" valt.)

[MarjonBakker]

Failure op 2.4.6 Headings and Labels.

Even teruggrijpen op de discussie over tekst en alternatieven:

Dit kan alleen onder SC 1.1.1 vallen indien men een afbeelding van een asterisk als img-element zonder alternatieftekst (of een verkeerde alternatieftekst) gebruikt.

Dat klopt niet. Dit is de definitie van tekst:

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language

Dat een teken op je toetsenbord zit, wil nog niet zeggen dat het menselijke taal is. 'Non-text' lijkt mij met opzet ontkennend geformuleerd, zodat je geen opsomming hoeft te geven van alle mogelijke soorten niet-tekstuele content, zoals hierboven: "ASCII art, noch leetspeak, noch een emoticon, noch iets anders dat onder "non-text content" valt".

Een asterisk drukt niets uit in menselijke taal. Net als bijvoorbeeld aleen een x-teken (een letter 'x', of een kruisje voor vermenigvuldiging) als enige content van een sluitknop nog geen goede accessible name voor de knop oplevert (wat ik afkeur onder 1.1.1, omdat het kruisje niet als menselijke taal wordt gebruikt).

Een asterisk wordt van oudsher gebruikt om een noot te plaatsen bij een tekst. Die noot moet er dan wel zijn.

De bedoeling van 2.4.6 is dat iemand in een keer een formulier correct kan invullen aan de hand van goede labels. Het label is niet duidelijk als de asterisk niet wordt uitgelegd. Als je de asterisk wel uitlegt, is er meteen ook een tekstalternatief (waardoor afkeuren onder 1.1.1 niet nodig is).

De reden dat ik dit niet afkeur onder 3.3.2 is deze tekst uit de understanding van 3.3.2: "While this Success Criterion requires that controls and inputs for data entry and submission have labels, whether or not these labels are sufficiently clear or descriptive is covered separately by 2.4.6: Headings and Labels."

[rianrietveld]

Dit issue wordt verder afgehandeld in issue #55 Asterisk afkeuren 1.1.1 op basis dat het niet door alle screenreaders zoals TalkBack goed wordt voorgelezen.