Placeholder tekst en toegankelijkheidsnaam

[gjccopinga]

Ik ben benieuwd hoe anderen omgaan met de placeholder tekst in relatie tot de toegankelijkheidsnaam. Een placeholdertekst is om vele redenen niet toegankelijk en zou ook niet als enige als tekstlabel gebruikt moeten worden. Maar stel dat het wel het geval is. Hoe gaan jullie hier dan mee om in relatie tot SC 2.5.3 en SC 4.1.2. Oftewel, nemen jullie deze wel mee in de toegankelijkheidsnaam (wat in praktijk door verschillende browsers wel wordt gedaan), of juist niet. Ik merk dat hier bij verschillende mailinglijsten ook verschillende meningen over zijn, dus ik wil graag peilen hoe dat in Nederland (en België) zit en of we hier met elkaar op dezelfde manier naar kunnen kijken.

[Aircl0wn]

Placeholders zijn lastig, niemand vindt ze (logisch) goed genoeg maar veel houvast heb je niet om ze af te keuren.

Ik behandel ze als volgt:

Binnen 2.5.3 wordt de term label losser gebruikt en valt alles binnen een (ongedefinieerde) afstand waarvan je visueel zou kunnen herleiden dat het om de naam van de input gaat in de scope. De waarde wordt binnen de specificaties meegenomen in de berekening en daarmee wordt dus voldaan aan het SC.

Hetzelfde geldt voor 4.1.2, doordat het meegenomen wordt in de berekening wordt de input van een name voorzien als er geen label is toegewezen.

[Veyfeyken]

Failure op 3.3.2 Labels or Instructions volgens Patrick H. Lauke en Jonathan Avila in deze thread: https://github.com/w3c/wcag/issues/864

[Aircl0wn]

Naast dat dat geen officiële bepaling is, zie ik nog enkele problemen met die redenatie.

Het gaat bij 3.3.2 om labels of instructies. Een placeholder is hier een instructie en daarmee voldoe je in de initiële staat wel aan het SC. De UD stelt ook dat het toegestaan is die instructies alleen te tonen als de input focus heeft, wat impliceert dat het andersom ook mag?

Je kunt zelfs een introductie paragraaf schrijven met "vul hieronder je gegevens in" en dan heb je in principe instructies gegeven en dus voldaan aan het SC...

[DennisVanZanten]

Waar je ook aan kan denken is,

Dat wanneer de placeholder als de toegankelijke dient en het bijbehorende invoerveld wordt geselecteerd door de gebruiker, de placeholder visueel kan verdwijnen.

In dat geval, voor hen met een niet-motorische beperking, zien zij niet (altijd) meer wat het woord is dat zij dienen te gebruiken.

[gjccopinga]

Omdat we in de reacties gaan afwijken van mijn initiële vraag toch even mijn vraag kort herhalen. De vraag is of de tekst van een placeholder attribuut wel of niet meegenomen moet worden bij het bepalen van de toegankelijkheidsnaam van een invoerveld. Dit is van belang om duidelijkheid over te hebben, omdat dit een probleem kan veroorzaken voor succescriterium 2.5.3 en 4.1.2. En dan vooral in de situatie dat er geen andere tekst/content is die deel uitmaakt van de toegankelijkheidsnaam. De placeholder tekst is dan de enige tekst die eventueel in de toegankelijkheidsnaam kan komen te staan.

Graag een apart issue opzetten als er over placeholderteksten gesproken moet worden ten aanzien van succescriterium 3.3.2.

[DennisVanZanten]

Gekeken naar het W3 artikel over 2.5.3 zou een placeholder niet gebruikt moeten worden om een label te vertonen, maar indien er geen andere aanwijzers aanwezig zijn, kan de gebruiker toch gebruik maken van de visuele (en door hulpsoftware bepaalde) tekst om het invoerveld te kunnen benaderen.

Het lijkt mij handig dat, wanneer de placeholder het laatste reddingsmiddel is voor het bepalen van een toegankelijkheidsnaam, deze onderdeel dient te zijn van de toegankelijkheidsnaam. Maar het dient wel te worden gezien als een no-go om het te accepteren als enige oplossing, aangezien deze in strijd gaat met teksten zoals: "UI controls which include a visible label have a matching full (or partial) accessible name". Een placeholder verdwijnt namelijk bij het invullen van het bijbehorende veld.

[JuliaZjochova]

Dag Gerard, ik ben nu bezig met de voorbereiding op het WAS-examen van de IAAP. In de studiemateriaal staat resoluut: 'Placeholder text MUST NOT be used as the only method of providing a label for a text input."

[rvantonisse]

Hoi,

Het placeholder attribuut gebruiken voor de name; tldr: nee

In acc name computation https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te, onder D, staat het volgende voor de berekening van een name:

Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").

Maar in de html spec, https://html.spec.whatwg.org/#the-placeholder-attribute, staat duidelijk geschreven:

The placeholder attribute should not be used as an alternative to a label. For a longer hint or other advisory text, the title attribute is more appropriate.

Dus nee placeholder als name is een fail ook op 4.1.2. En een title attribuut (tooltip) wordt als last resort gebruikt voor een acc name. Wel als description.

[gjccopinga]

Dank Roel,

dat is ook in lijn met hoe wij er naar kijken, maar we konden het nooit heel goed onderbouwen. Dank dus voor deze verwijzingen. Die van de accessible name computation had ik al wel gevonden en daar lijkt dan wat ruimte te zijn. Ruimte voor interpretatie. Maar met de HTML 5 spec er naast denk ik dat de conclusie wel duidelijk is. Een placeholder zou dus eventueel als een 'description' nog kunnen, maar niet als 'accessible name' (toegankelijkheidsnaam). Duidelijk!

[Aircl0wn]

De vraag is of de tekst van een placeholder attribuut wel of niet meegenomen moet worden bij het bepalen van de toegankelijkheidsnaam van een invoerveld

Per de specs wordt dit meegenomen in de naamberekening, dus dat lijkt me het antwoord al. De rest gaat over interpretaties en discussies die (helaas) niet strak zijn vastgelegd.

@JuliaZjochova hebben ze een directe (normatieve) bron die ze daar vermelden?

@rvantonisse Het stuk wat je aanhaalt over de berekening gaat over de rangorde, daar lees ik niets over dat het niet meegenomen zou moeten worden, wel wanneer in de volgorde het bepalend is voor het eindresultaat. Zoals in evergreen browsers gebeurd. Daarmee kan ik me dus ook niet vinden in een placeholder als fail voor 4.1.2 want het zorgt wel degelijk voor een accessible name als dat het enige attribuut is..

'Should not' is geen 'must not' en dus ook maar een advies.

Terug naar 2.5.3, het gaat er hier dat, wanneer er een tekst label is, deze overeenkomt met de accessible name. De norm stelt niet dat dit tekst label aanwezig moet zijn. Anders zouden we alle knoppen met alleen icoontje ook moeten gaan afkeuren. Is het een probleem voor de gebruiker? Jazeker, maar wel voor elke gebruiker en meer dan een accessibility probleem.

The UD geeft duidelijk aan dat hun definitie van label bij 2.5.3 breder is dan de HTML tag label en stelt:

As such, in the absence of any other nearby text string (as described in the preceding list), if an input contains placeholder text, such text may be a candidate for Label in Name.

[rvantonisse]

'Should not' is geen 'must not' en dus ook maar een advies.

Goed punt @Aircl0wn.

Daaraan toevoegend, als blijkt dat elke browser een placeholder als name goed ondersteund icm voorleessoftware, dan zie ik weer geen reden voor afkeuring op 4.1.2.

[gjccopinga]

Kan ik het volgende uit bovenstaande concluderen?

1) Als een placeholder attribuut als enige kandidaat aanwezig is voor het bepalen van de toegankelijkheidsnaam (er is dus geen label element, geen title attribuut, geen aria-lebel, enz), dan wordt de tekst van het placeholder attribuut gebruikt voor de toegankelijkheidsnaam en is dit geen 'fail' voor SC 4.1.2 en ook niet voor SC 2.5.3. 2) Als wel andere kandidaten aanwezig zijn, zullen één of meerdere van die kandidaten deel uit maken van de toegankelijkheidsnaam en zal de tekst van het placeholder attribuut niet meegenomen worden in de toegankelijkheidsnaam.

En bovenstaande is dan op basis van punt D van de Accessible Name Computation in combinatie met de praktijk waarbij de gangbare User Agents de placeholder in die gevallen ook opnemen in de toegankelijkheidsnaam.

[MarjonBakker]

@gjccopinga Ja, dat lijkt me een juiste conclusie.

[rianrietveld]

Ik kan me technisch vinden in de conclusie van @gjccopinga maar praktisch is het niet. Als een veld alleen een placeholder heeft en automatisch wordt gevuld door de browser, dan moet de ziende gebruiker toch de invoer verwijderen om te zien of de juiste waarde bij het juiste veld is ingevuld. Of de ziende gebruiker kan een fout antwoord geven als deze niet begrijpt dat de waarde eigenlijk anders moet zijn. In het geval van een autocomplete geeft de placeholder geen instrustructie hoe het veld in te vullen.

[Aircl0wn]

de vraag ging over de accessible name berekening. daarin wordt de placeholder meegenomen.

Het alleen hebben van een placeholder failed mogelijk wel onder 3.3.2. Als iets is ingevuld, heeft je invoerveld geen zichtbaar label meer. Als er dus ook geen andere instructies zijn waaruit duidelijk blijkt wat een gebruiker waar moet invullen failed het 3.3.2