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

Guideline for labeling and describing #994

Merged
merged 137 commits into from
Jun 28, 2019
Merged

Conversation

zcorpan
Copy link
Member

@zcorpan zcorpan commented Feb 28, 2019

@mcking65 mcking65 self-assigned this Feb 28, 2019

## Labels

A label is used as the accessible name for an element.
Copy link
Contributor

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point. Filed #996


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.
Copy link
Contributor

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.

Copy link
Member Author

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?

```


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.
Copy link
Contributor

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!

draft-labelling-describing.md Outdated Show resolved Hide resolved
@mcking65
Copy link
Contributor

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.

zcorpan added 2 commits March 4, 2019 16:29
Also remove sectionhead as it is an abstract role, and include an early draft of accessible name calculation.
draft-labelling-describing.md Outdated Show resolved Hide resolved
draft-labelling-describing.md Outdated Show resolved Hide resolved
draft-labelling-describing.md Outdated Show resolved Hide resolved
draft-labelling-describing.md Outdated Show resolved Hide resolved
zcorpan added 3 commits March 12, 2019 17:06
- Use "explicit label" and "implicit label" instead of "name from author" and "name from content".
- Expand on accessible name calculation.
@zcorpan
Copy link
Member Author

zcorpan commented Mar 13, 2019

@mcking65 the text here should be ready for review.


There are two different ways to get the label for an element, depending on the element’s role.

* Implicit label by default
Copy link
Member Author

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.

## Labels

There are two different ways to get the label for an element, depending on the element’s role.

Copy link
Contributor

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.

Copy link
Member Author

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.

@jongund
Copy link
Contributor

jongund commented Apr 16, 2019

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.

@jongund jongund closed this Apr 16, 2019
@zcorpan
Copy link
Member Author

zcorpan commented Apr 16, 2019

Thanks, Jon. I will review your draft.

Did you intend to close this PR? I'll reopen.

@zcorpan zcorpan reopened this Apr 16, 2019
@jongund
Copy link
Contributor

jongund commented Apr 16, 2019

@zcorpan
I did not intend to close the pull request, so please reopen.
I think the practices should be more these are the ways and here is an example.

The important basic concept for me for labeling are:

  1. Accessible name
  2. Grouping label
  3. Accessible description

These are the concepts that people need to understand, not implicit and explicit labeling.

@jongund jongund marked this pull request as ready for review April 16, 2019 19:27
@jongund
Copy link
Contributor

jongund commented Apr 16, 2019

@zcorpan I think I pressed another wrong button "ready for review".

@zcorpan
Copy link
Member Author

zcorpan commented Apr 25, 2019

I've moved away from "implicit" and "explicit" wording.

@jongund
Copy link
Contributor

jongund commented Apr 25, 2019

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

zcorpan added 7 commits April 29, 2019 17:43
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.
@css-meeting-bot
Copy link
Member

The ARIA Authoring Practices (APG) Task Force just discussed Naming and describing issues.

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

@mcking65 mcking65 merged commit 37da361 into master Jun 28, 2019
@mcking65 mcking65 deleted the zcorpan/labelling-describing branch June 28, 2019 16:49
michael-n-cooper pushed a commit that referenced this pull request Jun 28, 2019
Add section on accessible names and descriptions (pull #994)

Addresses issues #70 and #74 by adding section 5: - providing accessible names and descriptions.
mcking65 added a commit that referenced this pull request Jun 28, 2019
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.
mcking65 added a commit that referenced this pull request Jun 29, 2019
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.
michael-n-cooper pushed a commit that referenced this pull request Jun 30, 2019
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.
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.

9 participants