Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Label in name understanding doc update, large #614

Merged
merged 17 commits into from
Mar 8, 2019

Conversation

mbgower
Copy link
Contributor

@mbgower mbgower commented Feb 11, 2019

No description provided.

@awkawk
Copy link
Member

awkawk commented Feb 11, 2019

@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).

cognitive load for a speech input user to remember and say a speech command that is different from the visible label they see on a
control. It’s also an extra cognitive load for a text-to-speech user to absorb and understand speech output that does not
match the visible label.</p>
<p>The intent of this Success Criterion (SC) is to make text that is <em>visually</em> associated with a component also associated with the component <em>programmatically</em>. This helps ensure that people with disabilities can rely on visible labels as a means to interact with the components.</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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">(

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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”)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

@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
Copy link
Contributor Author

mbgower commented Feb 11, 2019

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.

Modified wording to soften message.
@awkawk
Copy link
Member

awkawk commented Feb 11, 2019

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
Copy link
Member

(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
Copy link
Contributor Author

mbgower commented Feb 11, 2019

@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
Copy link
Member

patrickhlauke commented Feb 11, 2019

@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
Copy link

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.

@alastc alastc changed the title Substantially modified Understanding doc and added image Label in name understanding doc update, large Feb 21, 2019
incorporating responses from survey
added in other suggestion
@mbgower
Copy link
Contributor Author

mbgower commented Feb 27, 2019

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 and others added 12 commits March 5, 2019 15:17
respond to feedback from call:
- rewrite of first sentence
- corrected 'criteria'
- addressed math

Plan to address icons and stacked labels in the general technique
rewrite of accessible name section to address concerns.
alterations to accessible name info
Added in a final line about using the proper operator symbol.
Final crack at a simpler intro sentence.
slight modification to sentenced to ensure no one thinks this only applies to words
one comma, one apostrophe
@awkawk awkawk mentioned this pull request Mar 6, 2019
Modified subheading to match AWK's langauge preference
@awkawk awkawk merged commit f844f13 into master Mar 8, 2019
@mbgower
Copy link
Contributor Author

mbgower commented Mar 8, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants