Success Criterion 3.3.2 - Labels or Instructions - Level A

[JJdeGroot]

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#labels-or-instructions

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

[Keanem6]

I don't see any variation on this one.

[JJdeGroot]

We might want to clarify "label" in mobile context. But the definition as is seems pretty clear.

label:

text or other component with a text alternative that is presented to a user to identify a component within Web content

Note 1 A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.

Note 2 The term label is not limited to the label element in HTML.

The note 2 already makes it clear that it's not limited to the <label> HTML element.

And note 1 makes it clear that the label should be visible (whether text, or component with alt-text)

I would keep it as is for our first draft.

[JJdeGroot]

Discussed in today’s meeting.

23 October 2024

[Source](https://www.w3.org/2024/10/23-matf-minutes.html#c9b0) ~~~text We could probably add a note that labels should not disappear when input focus is given to the labelled element (i.e. hint) Hey all, sorry for being late - construction workers started making noise at the office so headed home, but missed the meeting notification because I was away from my laptop. Thanks for taking over Joe_Humbert! Could we just add a relates link? Joe_Humbert it seems that mobile developers do miss this julianmka said there is a mention of this somewhere else Jamie if we scope it to mobile apps, agrees Yes, note can help to clarify best-practices in mobile (app) context Just add a contact in iPhone - the name field is an example of this error julianmka there isn't a mention in 3.2.2 in the understanding docs Joe_Humbert do we need to modify the definition of label? Android would be "text" element, "UILabel" in IOS (or "TextView" if you're a dinosaur Android dev) +1 as is +1 as is +1 as is +1 +1 as is +1 ACTION: Suggest to accept 3.3.2 for the wider group ~~~

ACTION: Suggest to accept 3.3.2 for the wider group

[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 3.3.2.

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

[dotjay]

One aspect that may need more exploration here when it comes to supporting documents (particularly in Understanding documents are translated for mobile) is to what degree visible labels must or should/could be applied for certain UI patterns that exist on mobile (and possibly other software) but perhaps do not on Web.

One example I'm thinking of is user entry using wheel-style Pickers often found on iOS that often don't have visible labels:

In the screenshot above, an example shows an editable time is a button that reveals a popup with two wheel-style Pickers for hour and minute respectively. The button has a visible label of "Time" setting the user's expectation and meeting the criterion. But is that considered enough of a visible label to pass for the two Pickers that are not explicitly labelled with "Hour" and "Minute" (but do have accessible names).

[JJdeGroot]

Hi @dotjay , thanks for contributing! As discussed in our meeting just now, we will be closing issues that reached consensus for our draft note. I'm going to close this issue now, but in a future stage we will get back to the points you mentioned.

Closing this issue because the draft language has been accepted.

Edit: wait... we are still in the voting stage for this one. We will consider your points in next meeting!

[detlevhfischer]

I think there are similar cases where requirements are exempt when elements are employed without change that are defined by the user agent (or OS). See target size exeptions for UA controls. The argument in favour of exempting custom controls like this would be that users know these elements from other apps and the OS itself, and authors can therefore expect them to be understood. It also avoids forcing authors to craft some custom stuff because of issues with OS or UA level controls, stuff that may be harder to maintain (and that may also deviate from user expectations).

So even where issues can be found in OS or UA-supplied date pickers like input type="date" in the web context (as is the case with some browsers) I think it would be bad to fail them and implicity force authors wanting or needing to conform to build a complex custom datepicker.

[JJdeGroot]

Discussed in today’s meeting.

13 November 2024

[Source](https://www.w3.org/2024/11/13-matf-minutes.html#603b) ~~~text Illai Are we refering to the entire component or the spinner alone for this SC? JJ Google and Apple need to make more efforts to make the native components accessibile Joe_Humbert the example looks like just a pop-up and that should be fine. However, the spinner is overlaid on calendar, which could be a problem for some users. +1 JJ +1 JJ JJ this needs to be updated by Apple Do we agree to keep the original proposal text for 3.3.2 by Julian? +1 +1 +1 +1 +1 ~~~

Conclusion: we considered the concerns of @dotjay and @detlevhfischer ; however at this moment we don't think an exception is needed for the case that Jon presented. The time picker has a visible label, the time spinner itself is a pop-up. There might be more situations where we don't want to force authors to create their own components. If we identify situations where that's needed, we can add an exception in a future version of our guidance.

For now, we are going to accept the text proposed by Julian for our first draft.