Label in name understanding doc update, large

[mbgower]

No description provided.

[awkawk]

@mbgower The only thing that I find to be a problem is the "close proximity" bit - this is too subjective and I think will be seen as an attempt to redefine "label". The Label in Name SC speaks to "User Interface components with labels" and there is nothing in 2.0 or 2.1 that specifies distance from the control for a label to "count". I think that the group should not make this clarification without a full understanding of the implications. (lines 18-27 the the lines in question).

[patrickhlauke]

To be picky, the first sentence makes it sound to me like it has to be the same piece of text in the markup that is associated. However, it can be duplicated as well (i.e. the visual text itself, and then an alternative that duplicates that particular text, e.g. First name <input ... aria-label="First name">(

[mbgower]

If you have a wording suggestion that solves that, I'll be happy, but I find trying to be clear about text vs text string, etc., has resulted in it being more confusing (or at least a lot harder to parse). Yes, one could just recreate the visible string in an aria-label; however at some point automated rules are going to start failing the multiple variations which would probably be okay with speech recognition -- e.g., "First Name:" and "firstname" -- and it is just so much easier for everyone if aria-label is left out where possible.

[patrickhlauke]

I would tend not to handwave away the ways in which it's perfectly valid to pass this SC (e.g. using aria-label). So starting with something like

The intent of this Success Criterion (SC) is to make sure that text that is <em>visually</em> associated with a component also forms part of the component's accessible name.

and then adding more explanations, references, examples could be better?

Examples could be along the lines of (grabbing something I threw together not so long ago for an unofficial explainer):

<a href="..." aria-label="Please read more about WCAG 2.1">Read more</a> would pass, as the “Read more” string (disregarding capitalization) is present in the aria-label

<a href="..." aria-label="Read about WCAG 2.1">Read more</a> would fail, as the string is not present

<a href="..." aria-label="Read some more about WCAG 2.1">Read more</a> would fail, as the aria-label does not contain the actual string “read more” (the word “some” is between “Read” and “more”)

[awkawk]

How about:
The intent of this Success Criterion (SC) is to make the accessible name include (or match) the text used for the visual label for a component. This helps ensure that people with disabilities can rely on visible labels as a means to interact with the components.

[patrickhlauke]

@mbgower The only thing that I find to be a problem is the "close proximity" bit - this is too subjective and I think will be seen as an attempt to redefine "label". The Label in Name SC speaks to "User Interface components with labels" and there is nothing in 2.0 or 2.1 that specifies distance from the control for a label to "count". I think that the group should not make this clarification without a full understanding of the implications. (lines 18-27 the the lines in question).

having just proposed removing some "close proximity" wording from 3.3.2 here #612 i agree that it's not a concept that's specific enough, nor is it defined anywhere.

[mbgower]

The notion of close proximity already exists:

Field labels located in close proximity to the associated field assist users of screen magnifiers because the field and label are more likely to visible within the magnified area of the page.

(https://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html)

Labels for most fields are positioned immediately before the field, that is, for left-to-right languages, either to the left of the field or above it, and for right-to-left languages, to the right of the field or above it. Labels for radio buttons and checkboxes are positioned after the field.

(https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/G162)

I have concerns -- I don't think it is too much to describe them as grave concerns -- that if we do not restrict the guidance to "near proximity", this SC is going to be interpreted in a way that is going to worsen the experience for both speech input users and screen reader users. I anticipate a lot of well-meaning people adding instructions, group labels, headings, input mask information, etc., to the accessible name which will increase both accidental triggering for speech input users and verbosity for screen reader users.

I'd rather deal with the very few exceptions in a separate technique (as was done with http://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/H65 for Labels or Instructions.) If you feel we can work in such qualifications into the Understanding doc, I'm happy to review the language.

I'm going to try putting in some qualifiers into the section to see if I can make you happy.

[awkawk]

Field labels located in close proximity to the associated field assist users of screen magnifiers because the field and label are more likely to visible within the magnified area of the page.

This is just an example - it isn't saying that this is the only way.

(https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/G162)

This is a technique that is saying to use the commonly expected locations, which are close to the control. It is just saying that this is an acceptable way, not that it is THE way.

I have concerns -- I don't think it is too much to describe them as grave concerns -- that if we do not restrict the guidance to "near proximity", this SC is going to be interpreted in a way that is going to worsen the experience for both speech input users and screen reader users. I anticipate a lot of well-meaning people adding instructions, group labels, headings, input mask information, etc., to the accessible name which will increase both accidental triggering for speech input users and verbosity for screen reader users.

In the example that we've discussed, I think that is exactly what you are doing as a result of your close proximity language!

I'll read it again and make some suggestions/pull request.

[patrickhlauke]

(for info, i searched through the rest of understanding, and found another use of "proximity" in https://www.w3.org/WAI/WCAG21/Understanding/status-messages - apart from that there's some old Silverlight techniques that use the term)

[mbgower]

@patrickhlauke The language about proximity has been in place for a decade. I'm not sure that referring to your newly suggested edit to remove it is how citing precedence would work :)

[patrickhlauke]

@patrickhlauke The language about proximity has been in place for a decade. I'm not sure that referring to your newly suggested edit to remove it is how citing precedence would work :)

i wasn't claiming any kind of authority. just pointing out that IF the group doesn't mind removal of the proximity language in my proposed edits since it's not clearly defined anywhere, it may not be the best time to reintroduce that somewhere else instead. by all means, let's keep it... shrug

[mraccess77]

Proximity is very important for users with low vision. We are considering an SC for WCAG 2.2 to attempt to address these needs. Based on the response here it sounds like a clear SC would be better than a technique that is not rooted in any WCAG 2.0 requirement.

[mbgower]

okay, I"ve made changes to this PR that incorporate much of the feedback from yesterday's survey and @awkawk PR version. They show up in the commits further up this thread.

[mbgower]

@michael-n-cooper I have now resolved all of the outstanding comments, and we approved this for adoption in our last call. Can you please merge? Note that I will be updating techniques, but I think it is good to get this new material in front of people. I will make a separate PR which will cover changes to the cross-referenced techniques.