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

Conversation

@zcorpan
Copy link
Member

commented Feb 28, 2019

@mcking65 mcking65 self-assigned this Feb 28, 2019


## Labels

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

This comment has been minimized.

Copy link
@mcking65

mcking65 Feb 28, 2019

Contributor

we may not want to assume the term accessible name is meaningful to readers.

This comment has been minimized.

Copy link
@zcorpan

zcorpan Mar 4, 2019

Author Member

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.

This comment has been minimized.

Copy link
@mcking65

mcking65 Feb 28, 2019

Contributor

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.

This comment has been minimized.

Copy link
@zcorpan

zcorpan Mar 4, 2019

Author Member

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.

This comment has been minimized.

Copy link
@mcking65

mcking65 Feb 28, 2019

Contributor

Beautiful! Very complex concept made super simple!

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

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2019

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 some commits Mar 4, 2019

Write about roles that don't get name from content
Also remove sectionhead as it is an abstract role, and include an early draft of accessible name calculation.
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 draft-labelling-describing.md Outdated

zcorpan added some commits Mar 12, 2019

Rewrite and expand on labels
- Use "explicit label" and "implicit label" instead of "name from author" and "name from content".
- Expand on accessible name calculation.
@zcorpan

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
@zcorpan

zcorpan Mar 25, 2019

Author Member

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.

This comment has been minimized.

Copy link
@mcking65

mcking65 Apr 2, 2019

Contributor

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.

This comment has been minimized.

Copy link
@zcorpan

zcorpan Apr 25, 2019

Author Member

Thanks. I've tried to address this, although possibly the new text is repeating things a bit.

@jongund

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Contributor

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 Apr 16, 2019

@jongund

This comment has been minimized.

Copy link
Contributor

commented Apr 16, 2019

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

@zcorpan

This comment has been minimized.

Copy link
Member Author

commented Apr 25, 2019

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

@jongund

This comment has been minimized.

Copy link
Contributor

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 some commits Feb 28, 2019

Write about roles that don't get name from content
Also remove sectionhead as it is an abstract role, and include an early draft of accessible name calculation.
Rewrite and expand on labels
- Use "explicit label" and "implicit label" instead of "name from author" and "name from content".
- Expand on accessible name calculation.
@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Jun 25, 2019

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

2 checks passed

Travis CI - Branch Build Passed
Details
Travis CI - Pull Request Build Passed
Details

@mcking65 mcking65 deleted the zcorpan/labelling-describing branch Jun 28, 2019

michael-n-cooper added a commit that referenced this pull request Jun 28, 2019

Generated by TRAVIS-CI 37da361
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

Naming and describing section: Remove bibliography reference
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

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.

michael-n-cooper added a commit that referenced this pull request Jun 30, 2019

Generated by TRAVIS-CI bf22075
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
Projects
None yet
9 participants
You can’t perform that action at this time.