-
Notifications
You must be signed in to change notification settings - Fork 355
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
Guideline for labeling and describing #994
Conversation
draft-labelling-describing.md
Outdated
|
||
## Labels | ||
|
||
A label is used as the accessible name for an element. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we may not want to assume the term accessible name is meaningful to readers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Filed #996
draft-labelling-describing.md
Outdated
|
||
A label is used as the accessible name for an element. | ||
|
||
For elements with certain roles, the label is taken from the element’s contents by default. This can be overridden with a label from the author by using the aria-labelledby or aria-label attributes. If the label from the element’s contents is appropriate, then it should not be overridden with those attributes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
consider wording without "should" ... Only override the content if ... or something like that.
Describing what is appropriate or adequate as a label is out of scope, but if we are going to use the word, "appropriate", we should probably link to a w3c resource where that is covered. That might be part of the introductory paragraph.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. Is there something appropriate (ahem) we can link to?
draft-labelling-describing.md
Outdated
``` | ||
|
||
|
||
In some cases the combination of the element’s contents and another element would be appropriate as a label. In such situations, the aria-labelledby should be used and reference both the element itself and the other element. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Beautiful! Very complex concept made super simple!
One super nice thing about having the draft in markdown is that the view file link on the diff page actually renders the content ... no need for raw.githack. That makes reading wonderfully easy and efficient. |
Also remove sectionhead as it is an abstract role, and include an early draft of accessible name calculation.
- Use "explicit label" and "implicit label" instead of "name from author" and "name from content". - Expand on accessible name calculation.
@mcking65 the text here should be ready for review. |
draft-labelling-describing.md
Outdated
|
||
There are two different ways to get the label for an element, depending on the element’s role. | ||
|
||
* Implicit label by default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to say how this relates to "Name from content" in aria spec.
draft-labelling-describing.md
Outdated
## Labels | ||
|
||
There are two different ways to get the label for an element, depending on the element’s role. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While implicit/explicit depends on the role, I don't think that is enough info to help the user grasp the important concept here.
The important concept is that there are, broadly speaking, two kinds of labels. One kind of label labels the element and completely represents that element; essentially you could say the label is the element from the user's perspective, e.g., image, heading, link, button, checkbox, radio, menuitem, treeitem. Another kind of label labels another thing, e.g., the label is not the element, e.g., textbox, combobox, toolbar, grid, article, region, table.
One kind of label essentially represents the element and the other kind tells the user here is the purpose of all the junk in here, or here is the kind of junk in here. It labels a input, composite widget, or container.
While These two kinds roughly correspond to implicit (content) and explicit (author), this concept isn't explained well enough for the reader to get a sense of the difference between elements where the label overrides or the label augments.
I think it would be worthwhile if we could help users develop an intuitive understanding of these different kinds of labels/roles/elements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I've tried to address this, although possibly the new text is repeating things a bit.
Please see an alternative draft for labeling and describing. This draft does not use the work implicit and explicit, it just presents the labeling techniques and their relative priority in the ACCNAME computation. |
Thanks, Jon. I will review your draft. Did you intend to close this PR? I'll reopen. |
@zcorpan The important basic concept for me for labeling are:
These are the concepts that people need to understand, not implicit and explicit labeling. |
@zcorpan I think I pressed another wrong button "ready for review". |
I've moved away from "implicit" and "explicit" wording. |
@zcorpan I am not sure why you spending so much space discussing labels that come from content and labels that come from other markup. I think the introduction needs to help authors understand how screen reader use this information and how it is presented to the user, there is no mention of screen readers this information in your current draft. It is more important for authors to understand how labels change user experience for screen reader users than on the distinctions between labels that come from content and other methods. See Jon Gunderson's draft of labeling and describing on describing screen reader behavior with different types of labeling and descriptions. |
Also remove sectionhead as it is an abstract role, and include an early draft of accessible name calculation.
- Use "explicit label" and "implicit label" instead of "name from author" and "name from content". - Expand on accessible name calculation.
The ARIA Authoring Practices (APG) Task Force just discussed The full IRC log of that discussion<jemma> Topic: Naming and describing issues<zcorpan> GitHub: https://github.com//pull/994 <jemma> mck: I will post this to aria list and some other list to get feedback. I will also get feedback from engineers in facebook and some places. <jemma> https://raw.githack.com/w3c/aria-practices/zcorpan/labelling-describing/aria-practices.html#names_and_descriptions <zcorpan> 17 rows not finished <jongund> need to leave a little early <jemma> mck: the document will be stable by tomorrow. <zcorpan> https://raw.githack.com/w3c/aria-practices/zcorpan/labelling-describing/aria-practices.html#naming_with_aria-labelledby <zcorpan> search for "HTML hidden" <jemma> mck: I need feedback for above section <zcorpan> https://github.com//issues/26 <jemma> mck:we can ask about "math" role to Joannie <jemma> mck:I will work with Simon to finish the doc. <jemma> rrsagent, make minutes <RRSAgent> I have made the request to generate https://www.w3.org/2019/06/25-aria-apg-minutes.html jemma <jemma> s/warnign/warning <jemma> rrsagent, make minutes <RRSAgent> I have made the request to generate https://www.w3.org/2019/06/25-aria-apg-minutes.html jemma <jemma> s/particulary/particular <jemma> rrsagent, make minutes <RRSAgent> I have made the request to generate https://www.w3.org/2019/06/25-aria-apg-minutes.html jemma |
…eeitem and menuitem
PR #994 included changes to common/biblio.js that should not have been merged because that file is maintained outside the aria-practices repository. The change was addition of a reference to an external site. This commit removes the common/biblio.js changes and the reference to them.
PR #994 included changes to common/biblio.js that should not have been merged because that file is maintained outside the aria-practices repository. The change was addition of a reference to an external site. This commit removes the common/biblio.js changes and the reference to them.
Naming and describing section: Remove bibliography reference (pull#1059) PR #994 included changes to common/biblio.js that should not have been merged because that file is maintained outside the aria-practices repository. The change was addition of a reference to an external site. This commit removes the common/biblio.js changes and the reference to them.
Addresses issues #70 and #74.
Preview Link
See section 5 - providing accessible names and descriptions in the working branch
Preview | Diff