SC 2.5.3 Label in naam en select element

[gjccopinga]

Even een vraag over twee specifieke voorbeelden van het gebruik van een select element en hoe daar mee om te gaan bij SC 2.5.3.

1) Stel je hebt een select element zonder visueel label, maar met zelf-verklarende waardes. Bijvoorbeeld voor het sorteren:

<select> <option>Sorteer op datum</option> <option>Sorteer op Naam</option> </select>

In dit geval zou een los visueel label voor SC 3.3.2 niet nodig zijn, want er is geen onduidelijkheid over wat het select element doet. Voor SC 4.1.2 kan er een aria-label worden toegepast zodat het ook voldoet.

Ons uitgangspunt hier is dat SC 2.5.3 niet van toepassing is, omdat er geen visueel label gebruikt aanwezig is. Dit baseren we dan op basis van dit uitgangspunt bij SC 2.5.3:

"Note that where a visible text label does not exist for a component, this Success Criterion does not apply to that component."

2) Zo'n zelfde select element kan eventueel ook wel een visueel label hebben die als eerste optie binnen het select element staat. Bijvoorbeeld:

<select> <option>Sorteeropties</option> <option>Sorteer op datum</option> <option>Sorteer op Naam</option> </select>

In dit geval is er dus wel een zichtbaar label aanwezig. Een beetje vergelijkbaar met de situatie waar een placeholdertekst wordt gebruikt bij een tekstinvoerveld. Zodra er namelijk een keuze wordt gemaakt is het visuele label niet meer zichtbaar.

Ons uitgangspunt hier is dat als de tekst van zichtbare label ("Sorteeropties") terug komt in de toegankelijkheidsnaam (bijvoorbeeld door middel van een aria-label met diezelfde tekst) dat dit dan voldoende is om te voldoen aan SC 2.5.3. Nadeel hiervan is wel dat als er een waarde gekozen is dat iemand met spraakbediening dan het zichtbare label niet meer ziet en misschien het select element dan niet meer direct kan 'bedienen', maar dat is naar onze mening geen reden tot afkeur. Simpel gezegd is in die situatie het visuele label er niet meer (niet meer zichtbaar) en is SC 2.5.3 dan per definitie weer niet van toepassing.

3) Omdat beide voorbeelden wel problematisch zijn voor mensen die spraakbediening gebruiken en het wel zo geprogrammeerd kan worden dat het wel altijd toegankelijk is voor spraakbediening zouden we willen adviseren (!) om in beide gevallen toch een visueel tekstlabel toe te voegen buiten het select element die altijd zichtbaar blijft. Niet afkeuren dus, maar wel adviseren. Dit advies kan dan denk ik het beste bij SC 2.5.3 neergezet worden, maar zou ook bij SC 3.3.2 neergezet kunnen worden met een verwijzing dat het belangrijk is voor spraakbediening (en dan verwijzen naar SC 2.5.3).

Mijn vraag is of jullie het eens zijn met onze beoordeling van situatie 1) en situatie 2) en of jullie het eens zijn dat alleen een advies nodig is zoals beschreven bij 3).

[RenateRoke]

Ik denk dat de hamvraag dan vooral is of je de huidige zichtbare optie niet ook al kan zien als het visuele label van de select (ik ben van mening van wel). De WCAG omschrijft een label ook als tekst of een component met tekstalternatief, om een component op de webpagina te identificeren. Als de standaard geselecteerde optie binnen het select element informatie geeft over het doel (zoals in jouw voorbeeld), dan ís dat het visuele label. Niet zo'n goeie, maar toch.

[gjccopinga]

Renate, dank voor je inbreng. Ik weet niet of ik je uitleg helemaal kan volgen, omdat er niet een direct antwoord bij staat op mijn drie opties. Ik lees hierin dat je het eens bent met onze beoordeling van optie 2). Klopt dat?

Hier nog even een aanvulling op mijn eigen verhaal om duidelijk(er) te maken wat ik vooral ook niet zie als visueel label.

Je zou inderdaad kunnen stellen dat de zichtbare optie het visuele label is. Maar je wilt niet dat elke mogelijke 'waarde' terugkomt in de toegankelijkheidsnaam; en eigenlijk ook niet de eerste waarde (als dat echt een waarde is en geen omschrijving). Ik zou waardes (die je kunt kiezen bij een select) dus ook echt zien als waardes en niet als labels, tenzij de eerste 'waarde' wel misbruikt (?) is om een soort visueel label te maken. Als de eerste waarde geen visueel tekstlabel is, maar echt een waarde die je kunt kiezen zou ik dus minder snel geneigd zijn om dit ook als 'label' te zien. Want, wederom, dan moet die 'waarde' dus terugkomen in de toegankelijkheidsnaam en dat voelt voor mij niet goed. Daarmee maak je de toegankelijkheidsnaam onduidelijk(er). Zelfs al zou het een combinatie zijn van een goede toegankelijkheidsnaam aangevuld met de eerste waarde. Dat voelt niet goed of logisch.

[gjccopinga]

Een vergelijkbare discussie op de Github omgeving van het W3C is hier te vinden. Ik vond hier echter niet echt een duidelijk antwoord uit naar voren komen. Er wordt doorgelinkt naar andere discussies, maar nergens nog een duidelijk antwoorden kunnen vinden. Iemand anders wel? Zie ik iets over het hoofd?

Zie: https://github.com/w3c/wcag/issues/2484

[Aircl0wn]

1. "Sorteer (op)" is voor deze waarden hetzelfde en zou ik als label beschouwen, want je hebt een zichtbare tekst die het doel en de betekenis overbrengt. Ik zou dit dus ook in de name willen terugzien. 2.5.3 is mijns inziens dus wél van toepassing. Ik zou het dus ook goedkeuren als de name klopt.

2. Dat lijkt me geen wenselijke oplossing. Je zit met een waarde die niets doet (meer mogelijkheid om iets fout te submitten) en het is niet persistent. Dus iemand kan het een keer gebruiken en als ze daarna niet meer weten wat de default waarde was of als ze via stem het veld opnieuw moeten activeren hebben ze geen label meer.

Faalt dan naar mijn mening 3.3.2 (om dezelfde reden keur ik placeholders alleen ook af). 2.5.3 blijft ook van toepassing want je heb nog steeds een waarde die dan de betekenis weergeeft (label), maar die niet meer overeenkomt met de name ter referentie mijn mentale beeld hierbij

• Sorteeropties
• oplopend
• aflopend

een andere optie (iets wat meer in een formulier past en niet ene losse functie is zoals hierboven)

• vervoersmiddel
• fiets
• boot
• auto
• vliegtuig (Je kunt hier dus per ongeluk ook "vervoersmiddel" als waarden insturen..)

Advies zeker geven. Naast een text label kan het ook een icoon zijn uiteraard.

[gjccopinga]

Ik zie nu pas dat in mijn originele post mijn code voorbeelden niet goed zijn weergegeven. Nu staat het er met de juiste code. Hopelijk zijn mijn voorbeelden dan nog wat duidelijker.

[gjccopinga]

Misschien nog even een derde voorbeeld die we in praktijk vaak zien en die wel deel uitmaakt van een groter formulier. Bijvoorbeeld als je een geboortedatum moet invullen en er zijn losse velden voor dag, maand en jaar en waarbij voor de maand een select wordt gebruikt met de namen van de maanden. Deze heeft dan geen visueel label (Behalve "Geboortedatum" als legend bij de fieldset). Er is dus ook geen eerste optie die een label aangeeft, maar alleen de 12 maanden van het jaar in het select. Deze zouden we bij 3.3.2 niet altijd afkeuren, omdat de waardes zelfverklarend zijn. Iedereen weet dat "Januari", "Februari", enz. maanden zijn. Een extra label of een instructie die aangeeft dat er een maand gekozen moet worden is dan overbodig (of niet? En zo niet, waarom niet?). Hoe beoordeel je in dit geval 2.5.3? Wij zouden dan zeggen dat er geen visueel label is en dan is 2.5.3 dus niet van toepassing. Maar ergens wringt dat toch ook wel. Het is hier dus de combinatie dat we voor 3.3.2 niet echt willen eisen dat er een visueel label moet zijn. Maar dan heb je wel een probleem met 2.5.3. Zou je in dat geval dan wel een visueel label moeten eisen?

[Aircl0wn]

3.3.2 stelt dat als er user input nodig is dat je dan een label of instructies geeft. De definitie geeft aan dat een label voor iedereen waarneembaar moet zijn.

Dat kan natuurlijk op verschillende manieren. met een label of via omliggende tekst oid. Het is me niet helemaal duidelijk of de andere velden wel een zichtbaar label hebben (dag/maand)

Geboortedatum (fieldset legend) zegt hier alleen iets over de inhoud van de fieldset, en is geen label voor een individueel veld. De waardes van een select zijn labels voor de individuele option, maar staat niet gelijk aan het label voor de select zelf.

2.5.3 gaat niet om de aanwezigheid van een label (dat er hoort te zijn per 3.3.2), maar of het label tekst of een afbeelding van tekst bevat. zo ja, dan moet die waarde in de name zitten. Dit SC is dus niet van toepassing voor een icoontje, maar zegt zeker niet dat een label er niet hoeft te zijn.

Daarnaast zou dit dan stellen dat bij elke wijziging in de select die nieuwe zichtbare waarde ook als name gebruikt moet worden. Naast dat dit problemen geeft voor het gebruik in z'n algemeenheid, zou ik het dan markeren on 2.4.6 omdat alleen de (wisselende) maand in mijn ogen geen goede aanwijzing is voor onderwerp of doel.

[rianrietveld]

Wat spraakbediening betreft: Als er geen zichtbaar label is, kan in Apple Voice Controle de gebruiker show numbers zeggen, en dan worden alle focusable elementen van een nummer voorzien. De gebruiker kan dan click nummer zeggen om het te activeren. Practisch hoeft een aankjlikbaar element geen accessible name of label te hebben voor spraakbediening.

Ik vind dat de HTML moet kloppen. Dus altijd een zichtbaar label, sr-only verborgen label of aria-label aan de select toevoegen. Als door middel van de zichtbare optie begrijpbaar is wat er te kiezen valt, lijkt het me voldoen aan WCAG.

[rvantonisse]

Volgens naamberekening hoort de select zonder label, wel een naam te krijgen van de geselecteerde option.

Ik ben voor slagen / voldoende op 2.5.3 bij het ontbreken van een expliciet label, zoals beschreven in situatie 1 EN 2, omdat het gebruiken van geselecteerde waarde goed ondersteund is. Alleen het wijzigen van de waarde wordt misschien niet overal direct voorgelezen (Talkback? https://a11ysupport.io/tech/html/select_element)

Situatie 2 faalt, omdat zowel label als keuzes bij elkaar zijn opgenomen en genoemde redenen voor 3.3.2 door @Aircl0wn .

Geteste Codepen situatie 1 + label alternatief: https://codepen.io/rvantonisse/pen/ZEZpJGq

N.B.: Ik zie dat naam berekening recent (27-2-2024) is geupdate! https://www.w3.org/TR/accname-1.2/#computation-steps; Zie Stap 2 C "Embedded Control", voorheen stap 2 E.

[gjccopinga]

Zo, ik zie dat de naam berekening flink verandert en uitgebreid is. Dat wordt even een leuke puzzel om een keer goed te bestuderen. Dank voor de tip in ieder geval. Ik ga kijken of hier een duidelijk antwoord uit gehaald kan worden.