Asterisk afkeuren 1.1.1 op basis dat het niet door alle screenreaders (TalkBack) goed wordt voorgelezen

[RenateRoke]

Hoi allemaal, ik zag al een discussie die hier een beetje op lijkt maar me net niet het antwoord geeft waar wij naar op zoek zijn:

Vooralsnog keuren wij het alléén gebruiken van een asterisk (*) om aan te geven dat een veld verplicht is af, omdat TalkBack deze niet voorleest (als er geen spatie tussen het woord en de asterisk zit). Dit is nog steeds een openstaand known issue: https://issuetracker.google.com/issues/271387526. Ons advies als oplossing is dan altijd om aria-required op het invoerelement toe te voegen.

Voor mij klinkt het logisch dat dit afkeurbaar is als we testen voor 'gangbare browsers en hulpsoftware', maar de meningen zijn nogal verdeeld. Hoe gaan andere bureaus/testers hier mee om en (vooral benieuwd naar) waarom?

Edit: en op 1.1.1 omdat we een asterisk in z'n eentje interpreteren als non-text (en daar waren de meningen ook al over verdeeld zag ik haha).

Related: #40

[bramd]

Bij Firm Ground keurden we het niet af, maar ik sta ervoor open om dat te herzien. Ik ben benieuwd naar andere reacties.

[Veyfeyken]

Ik denk niet dat een bug in een bepaald hulpmiddel een doorslaggevend argument mag zijn in het beoordelen van een succes criterium. Als de betekenis van de asterisk verklaard wordt, bij voorkeur boven het formulier, keur ik het niet af.

1.1.1 Non-text content is in mijn mening niet van toepassing. Het is een karakter/leesteken, geen afbeelding maar ik begrijp wel dat daar de meningen verdeeld zijn.

3.3.2: Labels or Instructions
Labels or instructions are provided when content requires user input.

Wanneer de asterisk verklaard wordt, vind ik dat aan bovenstaande is voldaan.
Ik vermeld wel altijd dat het gebruik van een asterisk geen goed patroon is, tekstuele labels zijn de best practice.

[erikkroes]

Het lastige is denk ik dat de asterisk gebruikt wordt als een representatie; een soort pictogram. Door de toepassing wordt het eigenlijk een afbeelding. Het staat er niet in de functie als leesteken. Net zoals ASCII-art kan ook falen op 1.1.1, terwijl dat ook karakters/leestekens zijn.

Daarnaast denk ik ook dat een bug in een hulpmiddel geen reden van af/goedkeuring is. De R in WCAG staat voor Robust. Je bouwt voor de lange termijn, en je bouwt iets wat een solide basis is voor tools. Dat die tools er vervolgens een zooitje van maken...

[Aircl0wn]

Zoals de andere discussie al liet zien zijn de meningen hier nogal verdeeld vooralsnog.

Net als @Veyfeyken zie ik een * niet als non-text. Naast dat het een eigen ASCII symbool is, is het onderdeel van de sequence of characters die het label opmaken en die iets in menselijke taal probeert duidelijk te maken. 1.1.1 valt voor mij dan dus af.

Ik deel ook de mening dat een bug in een tool geen reden is tot afkeuren als het elders wel werkt.

Wat andere SC langlopend:

• 2.4.6: Als het sterretje niet verklaard wordt, is het label niet duidelijk genoeg.
• 3.3.2: Er een label aanwezig, maar of die duidelijk genoeg is, wordt in dit SC niets over gezegd. Er staat geen label AND instructions (helaas).
• 1.3.1: de bedoeling van het sterretje is een verplicht veld, dus moet je dit ook programmatische duidelijk maken. Dat kan natuurlijk op verschillende manieren, maar ik vind een sterretjes, zelfs uitgelegd, geen programmatische bepaling of vallen onder 'available in text' als dit niet letterlijk in het label verwerkt is.

[rvantonisse]

Ter referentie: #40, waarin uitgebreid over dit teken gediscussieerd wordt wanneer een uitleg voor * bij een invoerveld ontbreekt.

[rvantonisse]

1.3.1: de bedoeling van het sterretje is een verplicht veld, dus moet je dit ook programmatische duidelijk maken. Dat kan natuurlijk op verschillende manieren, maar ik vind een sterretjes, zelfs uitgelegd, geen programmatische bepaling of vallen onder 'available in text' als dit niet letterlijk in het label verwerkt is.- @Aircl0wn

Volgens mij geldt dit onder 4.1.2 voor invoervelden. Bij 1.3.1 is een tekstuele verwijzing (voor mij) voldoende wat wordt gedaan met de referentie / voetnoot stijl.

Met een situatie als deze:

<label for="name">Name*</label>
<input type="text" id="name">

<p>...content...</p>

<p>*: Required</p>

Vervelend dat het niet voorgelezen wordt, want dan is het ook onduidelijk. Ik zou er een opmerking over plaatsen aangezien het om 1 toepassing gaat, Talkback. Tenzij natuurlijk essentieel voor de doelgroep van de website en ondersteuning voor Talkback nodig is.

Terugkomend op 4.1.2, moet deze informatie technisch aanwezig zijn voor interface componenten. En dat zou ik met html required attribuut aangeven. Talkback lijkt op dit gebied het slechtst te scoren (https://a11ysupport.io/?featuresearch=required), dus des te belangrijker dat deze missende spaties eruit worden gewerkt voor de gebruikers van Talkback.

[Aircl0wn]

Ik blijf toch bij 1.3.1 want het is een visuele relatie (sterretje) die je programmatisch moet onderscheiden. Ik ben het eens dat een duidelijk label ook voldoende zou zijn. De vraag is of een sterretje, dat zelf weer elders wordt verklaard, duidelijk genoeg is. ik zelf zou zeggen van niet. je vraagt wel veel van iemand die die verklaring niet direct kan zien. Als het sterretje lokaal een verborgen tekst variant heeft, zou ik er geen probleem mee hebben, want dan heb je inderdaad die lokale verklaring.

Qua 4.1.2:
required is een state.
de name en role' moeten programmatisch aanwezig zijn. De state` moet programmatisch 'instelbaar' zijn (gezet kunnen worden) als de gebruiker dit kan instellen/aanpassen. Dat laatste is niet van toepassing hier want je bepaald het als auteur dat een veld verplicht is. dus mijns inziens gaat deze niet op hier.

Dit in tegenstelling tot een uitklapelement met een aria-expanded state bijvoorbeeld waarbij je de state bijhoudt als de gebruiker de interactie aangaat. Datzelfde attribuut is dus voor 1.3.1 ook belangrijk, want dit communiceert ook de mogelijke interactie.

Het gebruik van required moet je wel je validatie uit zetten, anders zit je met ontoegankelijke validatie meldingen.
a11ysupport is vaak erg out-of-date helaas, dus daar kun je ook niet 1-2-3 van uit gaan.

[JJdeGroot]

Als de required state niet duidelijk is bij gebruik van een * zou ik het op 1.3.1 of 2.4.6 afkeuren.

Als de asterisk uitgelegd wordt voordat de formulier velden beginnen, is het wat mij betreft duidelijk.
En een asterisk in combinatie met aria-required of vergelijkbaar is naar mijn idee ook duidelijk.

Dat een bepaalde hulpsoftware zoals TalkBack niet goed om gaat met bepaalde karakters is naar mijn idee geen afkeurpunt.

[RenateRoke]

Aangezien in het understanding document van 1.3.1 specifiek wordt benoemd dat het uitleggen van een asterisk als aanduiding van een verplicht veld voldoende is, gaan we er bij dezen niet meer vanuit dat het dan nog afkeurbaar is onder 1.1.1 maar we blijven het meenemen als advies :) dank allemaal!

[erikkroes]

Dus zonder uitleg afkeuren, en met uitleg meenemen als advies?

https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html#examples

[rianrietveld]

Is de conclusie en de concensus dat een asterisk alleen, als visuele aanduiding voor een foutmelding:

• wordt beschouwd als non-text content (SC 1.1.1 Niet-tekstuele content)
• onvoldoende uitleg is (SC 3.3.2 Labels of instructies), er moet een uitleg van wat de asterisk betekent boven het formulier staan.

Geef een 👍 voor mee eens.
Geef een 👎 voor niet mee eens en vertel waarom.

Het besluit in dit issue geldt ook voor #40 (Is een asterisk zonder verklaring bij verplichte velden een failure? )

[janitatop]

Het lijkt mij niet toepasselijk onder 1.1.1 omdat ik het wel zie als tekst.
Ik ben het er wel mee eens dat het teken verklaard moet worden bovenaan het formulier (punt 2).
En voor hulpsoftware zou ik adviseren om aria-required toe te voegen voor als de asteriks niet goed wordt voorgelezen.

[cstrobbe]

Volledig oneens met afkeuren onder SC.1.1.1. Het TalkBack-probleem leidt tot een onvoldoende duidelijk label, wat onder SC 3.3.2 2.4.6 valt.
(Een verklaring voor de asterisk boven het formulier is geen voorbeeld van SC 1.1.1 omdat die verklaring niet aan de definitie van text alternative voldoet. Een "text alternative" is "programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content".)

[Aircl0wn]

Ik delel de mening om het niet af te keuren onder SC 1.1.1.

Het niet ondersteunen door TalkBack zou ik alleen niet aanduiden als een failure voor SC 3.3.2.
Als we dit voor alle 'bugs' in software moeten gaan doen is het einde zoek. Als de implementatie goed is en het zou in principe moeten werken keur ik het niet af.

[rianrietveld]

We laten afkeuren voor SC 1.1.1 vallen. Blijft 3.3.2 staan.

Is de conclusie en de concensus dat een asterisk alleen onvoldoende uitleg is (SC 3.3.2 Labels of instructies), er moet een uitleg van wat de asterisk betekent boven het formulier staan.

Geef een 👍 voor mee eens.
Geef een 👎 voor niet mee eens en vertel waarom.

Het besluit in dit issue geldt ook voor #40 (Is een asterisk zonder verklaring bij verplichte velden een failure? )

[Veyfeyken]

Aan 3.3.2 Labels of instructies is voldaan want er is een label. Het gaat om 2.4.6 Koppen en labels.

Headings and labels describe topic or purpose.

Je kan argumenteren dat hier niet aan is voldaan als de asterisk niet is verklaard. Persoonlijk vind ik het geen failure. De asterisk verklaren lijkt me een best practice. Het niet verklaren vormt geen specifiek probleem voor mensen met een beperking, het is eerder een algemeen issue.

[Aircl0wn]

@Veyfeyken Klopt Gijs, is was in de war! (niet de eerste keer bij deze twee...)