Success Criterion 2.5.3 - Label in Name - Level A

[JJdeGroot]

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#label-in-name

Share your thoughts for applying to mobile apps as a comment below.

[julianmka]

Based on previous task force conversation, this SC can be applied to native mobile apps and mobile web with minimal or no deviation from WCAG2ICT.

Proposal

In MATF's first draft of guidance, this SC's section will read as:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.3.

Please indicate your agreement with a thumbs up emoji 👍, or if you disagree, use the thumbs down emoji 👎 and elaborate in comments.

[detlevhfischer]

I think the meeting on 11. September 2024 brought a valuable hint that iOS has the accessibilityInputLabels() modifier that allows authors to define additional terms that speech control users will be able to speak to activate a control. So in cases where you have a longer label such as "Date (DD/MM/JJJJ)" or "E-Mail address (required)", speech input could just say "click date" or "click email". This might work anyway even without explicitly setting alternate labels, but whether or not these labels have been defined, using an abbreviated text as accname of a control with a label with longish visible label seems sufficient to meet the intent of 2.5.3 (provided that additional content, when important, is provided as accdescription.

The 2.5.3 Understanding text text allows the "Name (required)" and "Date (YYYY-MM-DD)" could accept "Name" and "Date" as the accessible names as long as the information is programmatically provided in addition, for example as accdescription such as accessibilityHint() in iOS, or presumably by inclusion as a label strign in the the value of accessibilityInputLabels(). I am not sure whether the contents of the latter would be programmatically exposed for SR reader users - are they it just available as a hook for speech input?

So my question is whether we want a Note pointing out that is is not necessarily the whole visible label that needs to be in the accname.

[julianmka]

I suppose we could have an iOS-specific note, although I do worry that it might be splitting hairs too much for people who are not already deeply familiar with native mobile accessibility.

For the sake of screen reader users with sight, I think it is still important that the acc name match the visible label to the greatest degree that is practical.

[julianmka]

As far as I know, accessibilityInputLabel is not exposed to screen reader users - which makes sense given that Voice Control cannot be operated with VoiceOver enabled.

[jha11y]

Notes from 11 September, 2024 Meeting:

Meeting Minutes 11 September

Joe_Humbert: the notes on closed functionality to be ignored for first draft [per other agreement in other meetings]

Detlev: would you consider the phrase-line is not included in the text for logos?

julianmka: iOS allows to apply alternate labels. You could set the accessible name with this method.

julianmka: Android does not have this capability

Jamie: leave as written in WCAG2ICT

Detlev: differences seem very minor, if any

Jamie: next one!

julianmka: next meeting we will vote on the SC that we think as a group can go into the draft as is

Joe_Humbert: to create separate section about user settings

julianmka: Spoiler alert! Settings as sufficient techniques has a Github issue we can start using: w3c/matf#67

AlainVagner: thanks julianmka

[JJdeGroot]

Closing this issue because the draft language has been accepted.