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

Issue 876: add draft specification for role label #886

Closed
wants to merge 26 commits into from

Conversation

Projects
None yet
7 participants
@jongund
Copy link
Contributor

jongund commented Jan 14, 2019

@jongund jongund changed the title added draft description for role label Issue 867: add description for role label Jan 14, 2019

@jongund jongund changed the title Issue 867: add description for role label Issue 867: add draft specification for role label Jan 14, 2019

@jnurthen jnurthen added the Agenda label Jan 15, 2019

@jnurthen jnurthen removed the Agenda label Feb 5, 2019

@jnurthen jnurthen added the Agenda label Feb 12, 2019

@jnurthen jnurthen changed the title Issue 867: add draft specification for role label Issue 876: add draft specification for role label Feb 14, 2019

@jnurthen

This comment has been minimized.

Copy link
Contributor

jnurthen commented Feb 14, 2019

@jongund

This comment has been minimized.

Copy link
Contributor Author

jongund commented Feb 21, 2019

@jnurthen
Updated the list of roles that can have name generated by label encapsulation based on discussions on the aria 2/21/2019 teleconference.
I also added "label encapsulation" to the list of "name from" for the included roles.

@carmacleod
Copy link
Contributor

carmacleod left a comment

Please note typo of "acccessible" with 3 c's.

index.html Outdated
<div class="role" id="label">
<rdef>label</rdef>
<div class="role-description">
<p>The <rref>label</rref> role can be used to identify the visible caption (e.g. acccessible name) of a user interface component. A user interface component can be associated with a label using the <code>aria-labelledby</code> attribute or by encapsulating the component inside the element with <code>role=label</code>. Not all roles that support name from author can use the encapsualtion method, the following list are the roles that are supported: </p>

This comment has been minimized.

Copy link
@carmacleod

carmacleod Feb 25, 2019

Contributor

typo: acccessible with 3 c's

This comment has been minimized.

Copy link
@jnurthen

jnurthen Feb 25, 2019

Contributor

accccccessible can never have enough c's

@css-meeting-bot

This comment has been minimized.

Copy link
Member

css-meeting-bot commented Mar 7, 2019

The ARIA Working Group just discussed Label role.

The full IRC log of that discussion <jamesn> topic: Label role
<jamesn> https://github.com//pull/886
<irfan_ali> jn: JG made some updates to this issue
<jongund> https://raw.githack.com/jongund/aria/issue876-role-label/index.html#label
<irfan_ali> jg: nly the roles checkbox, listbox, meter, >radio, searchbox, spinbutton, switch and textbox support name from encapsulation method.
<irfan_ali> mk: there should not be any implementation complication to check the name calculation.
<irfan_ali> jn: looking at reference e.x list box
<irfan_ali> jn: author override the order
<jamesn> https://raw.githack.com/jongund/aria/issue876-role-label/index.html#namecalculation
<irfan_ali> jn: do we need to come up with a term other than two words
<irfan_ali> mk: there is a complication here. the way author is define right now, it includes the encapsulation.
<MarkMcCarthy> s/nly/Only
<irfan_ali> mk: aria encapsulation would have to be different than authors.
<MarkMcCarthy> s/>radio/radio
<jamesn> GitHub: https://github.com//pull/886
<irfan_ali> jn: I see everything that supports encapsulation, also supports author
<irfan_ali> mk: role label doesn't have any affect on a11y tree. right now author includes encapsulation which is fine.
<irfan_ali> jn: its fine what JG done.
<jamesn> need to add to https://raw.githack.com/jongund/aria/issue876-role-label/index.html#namecalculation
<irfan_ali> mk: its not adding but its rewording
<irfan_ali> jn: it may requires changing to some other stuff as well.
<irfan_ali> jg: we have content and authors name from, do you want third thing that talks about encapsulation?
<irfan_ali> jg: 5.2.7, we need to add a definition of encapsulation
<irfan_ali> mk: i wish it would have been attribute
<irfan_ali> mk: content comes from author so its okay
<irfan_ali> jn: more comments?
<irfan_ali> jn: we will come back to this if anything else to be discussed
<irfan_ali> zakim, next item
<Zakim> agendum 5. "No mention of aria-placeholder in name/description calculation algorithm" taken up [from jamesn]
<Stefan> q+
@devarshipant

This comment has been minimized.

Copy link

devarshipant commented Mar 8, 2019

@jongund - I don't think using role label provides the semantic equivalence of matching for / id attributes in native html. In that case, should there be instructions to warn authors not to rely on role label to set keyboard focus on form control by clicking the label?

jongund added some commits Mar 21, 2019

@jongund

This comment has been minimized.

Copy link
Contributor Author

jongund commented Mar 21, 2019

@jnurthen
I made some edits to fix spelling problem and improved the definition text that is used in Section 5.4 Definition of Roles. So it should be ready to merge.

@mcking65
Copy link
Contributor

mcking65 left a comment

I suggested some revisions below. I believe some of the revisions are critical as some aspects of the normative statements are ambiguous as currently worded.

@@ -530,6 +530,7 @@ <h3>Accessible Name Calculation</h3>
<ol>
<li>author: name comes from values provided by the author in explicit markup features such as the <pref>aria-label</pref> attribute, the <pref>aria-labelledby</pref> attribute, or the host language labeling mechanism, such as the <code>alt</code> or <code>title</code> attributes in <abbr title="Hypertext Markup Language">HTML</abbr>, with HTML <code>title</code> attribute having the lowest precedence for specifying a text alternative.</li>
<li>contents: name comes from the text value of the <a>element</a> node. Although this may be allowed in addition to "author" in some <a>roles</a>, this is used in content only if higher priority "author" features are not provided. Priority is defined by the <a href="https://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_te">accessible name and description computation</a> algorithm. [[ACCNAME-1.1]]</li>
<li>encapsulation: name comes from the text value of the <a>element</a> node with role <cod>label</cod> that is the closest ancestor. Although this may be allowed in addition to "author" and "contents" in some <a>roles</a>, encapsulation is used only if higher priority "author" features are not provided. Priority is defined by the <a href="https://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_te">accessible name and description computation</a> algorithm. [[ACCNAME-1.1]]</li>

This comment has been minimized.

Copy link
@mcking65

mcking65 Mar 21, 2019

Contributor

Note that the first code tags in the text are missing an 'e'.

For the first sentence, I suggest:

name comes from the text value of the nearest ancestor element having the <code>label</code> role.

This comment has been minimized.

Copy link
@jnurthen

jnurthen Mar 27, 2019

Contributor

@jongund I think this comment still needs to be resolved before I can merge.

index.html Outdated
<div class="role" id="label">
<rdef>label</rdef>
<div class="role-description">
<p>Identifies the visible caption (e.g. acccessible name) of a user interface component. </p>

This comment has been minimized.

Copy link
@mcking65

mcking65 Mar 21, 2019

Contributor

Recommend:

A visible name or caption for a user interface component.

Why:

  1. "Identifies" is the language we use for properties not roles. Roles are a thing or representation of a thing. Spo, I removed the word "identifies."
  2. If it is a name, it is not just an accessible name. We don't want readers to think that it is something different from the name that is presented to all users as opposed to users of AT.
index.html Outdated
<rdef>label</rdef>
<div class="role-description">
<p>Identifies the visible caption (e.g. acccessible name) of a user interface component. </p>
<p>A user interface component can be associated with a label using the <code>aria-labelledby</code> attribute or by encapsulating the component inside the element with <code>role=label</code>. Only the roles <code>checkbox</code>, <code>listbox</code>, <code>meter</code>, <code>radio</code>, <code>searchbox</code>, <code>spinbutton</code>, <code>switch</code> and <code>textbox</code> support name from encapsulation method. Authors SHOULD ensure that at least one component references each label. Authors SHOULD move focus to the associated user interface component when a label is activated with a pointer or by touch. If more than one component is associated with the label the first component SHOULD receive keyboard focus.

This comment has been minimized.

Copy link
@mcking65

mcking65 Mar 21, 2019

Contributor

I recommend the following structure and wording:

A label element can provide an accessible name for a user interface component if it is programatically associated with the component. Authors MAY associate a label element with another element by using one of two methods:

  • Encapsulation: The label element contains the element it names.
  • Reference: The label element is referenced by the element it names via the aria-labelledby attribute.

The encapsulation method of naming is supported only if the element being named has one of the following roles:

  • checkbox
  • listbox
  • meter
  • radio
  • searchbox
  • spinbutton
  • switch
  • textbox

Authors SHOULD ensure that:

  • All label elements are associated with one or more other elements.
  • When a label is activated by touch or a pointer and its associated element is focusable, focus moves to the associated element. If more than one focusable element is associated with the same label, focus moves to the first component.
index.html Outdated
<rdef>label</rdef>
<div class="role-description">
<p>Identifies the visible caption (e.g. acccessible name) of a user interface component. </p>
<p>A user interface component can be associated with a label using the <rref>aria-labelledby</rref> attribute or by encapsulating the component inside the element with role <code>label</code>. Only the roles <rref>checkbox</rref>, <rref>listbox</rref>, <rref>meter</rref>, <rref>radio</rref>, <rref>searchbox</rref>, <rref>spinbutton</rref>, <rref>switch</rref> and <rref>textbox</rref> support name from encapsulation method. Authors SHOULD ensure that at least one component references each label. Authors SHOULD move focus to the associated user interface component when a label is activated with a pointer or by touch. If more than one component is associated with the label the first component SHOULD receive keyboard focus.

This comment has been minimized.

Copy link
@mcking65

mcking65 Mar 21, 2019

Contributor

I recommend the following structure and wording:

A label element can provide an accessible name for a user interface component if it is programatically associated with the component. Authors MAY associate a label element with another element by using one of two methods:

  • Encapsulation: The label element contains the element it names.
  • Reference: The label element is referenced by the element it names via the aria-labelledby attribute.

The encapsulation method of naming is supported only if the element being named has one of the following roles:

  • checkbox
  • listbox
  • meter
  • radio
  • searchbox
  • spinbutton
  • switch
  • textbox

Authors SHOULD ensure that:

  • All label elements are associated with one or more other elements.
  • When a label is activated by touch or a pointer and its associated element is focusable, focus moves to the associated element. If more than one focusable element is associated with the same label, focus moves to the first component.
@jongund

This comment has been minimized.

Copy link
Contributor Author

jongund commented Mar 22, 2019

@jongund - I don't think using role label provides the semantic equivalence of matching for / id attributes in native html. In that case, should there be instructions to warn authors not to rely on role label to set keyboard focus on form control by clicking the label?

@devarshipant
There is an author directive to add this behavior when then are using the label role

@jongund

This comment has been minimized.

Copy link
Contributor Author

jongund commented Mar 22, 2019

@jnurthen @mcking65
I made updates to the pull request based on your comments.

<rdef>label</rdef>
<div class="role-description">
<p>A visible name or caption for a user interface component.</p>
<p>A label element can provide an accessible name for a user interface component if it is programatically associated with the element. Authors MAY associate a label element with the element by using one of two methods:</p>

This comment has been minimized.

Copy link
@melanierichards

melanierichards Mar 28, 2019

Contributor

Wordsmithing: instead of "a label element", perhaps "An element with role label" (that said, we do seem to do both).

jongund added some commits Apr 4, 2019

@jongund

This comment has been minimized.

Copy link
Contributor Author

jongund commented Apr 4, 2019

This pull request can be discarded, see new pull request

@jnurthen jnurthen closed this Apr 10, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.