Issue 1151: updated document to use the terms owned and container for definitions #1224
Conversation
…related to aria-activedescendant
|
closes #1151 |
|
White space has been restored |
Co-Authored-By: Matt King <a11yThinker@Gmail.com>
Changes support latest combobox design pattern Co-Authored-By: Matt King <a11yThinker@Gmail.com>
Co-Authored-By: Matt King <a11yThinker@Gmail.com>
Co-Authored-By: Matt King <a11yThinker@Gmail.com>
Co-Authored-By: Matt King <a11yThinker@Gmail.com>
|
Accepted your suggested changes |
index.html
Outdated
| @@ -381,10 +381,10 @@ <h3>Information for User Agents</h3> | |||
| <li>Implement the host language method for keyboard navigation so that widgets that support <code>aria-activedescendant</code> may be included in the tab order.</li> | |||
| <li>For platforms that expose <a>desktop focus</a> or <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a> focus separately from <abbr title="Document Object Model">DOM</abbr> focus, do not expose the focused state in the accessibility <abbr title="application programming interface">API</abbr> for any element when it has <abbr title="Document Object Model">DOM</abbr> focus and also has <pref>aria-activedescendant</pref> which points to a valid <a href="#valuetype_idref">ID reference</a>.</li> | |||
| <li>When the <pref>aria-activedescendant</pref> attribute changes on an element that currently has <abbr title="Document Object Model">DOM</abbr> focus, remove the focused state from the previously focused object and fire an accessibility <abbr title="application programming interface">API</abbr> <a>desktop focus event</a> on the new element referenced by <code>aria-activedescendant</code>. If <pref>aria-activedescendant</pref> is cleared or does not point to an element in the current document, fire a desktop focus event for the <a>object</a> that had the attribute change.</li> | |||
| <li>For any element with an ID attribute, where the element is a descendant of an element with the <pref>aria-activedescendant</pref> attribute, apply the following accessibility <abbr title="Application Programming Interface">API</abbr> states to the target to ensure the object is accessible: | |||
| <li>Apply the following accessibility <abbr title="Application Programming Interface">API</abbr> states to any element with an ID attribute that can be referenced by an <pref>aria-activedescendant</pref> attribute. There are two ways an element can be referenced by the <pref>aria-activedescendant</pref> attribute. One way is when it is <a>owned</a> by an element with the <pref>aria-activedescendant</pref> and the other is when it is <a>owned</a> by an element that is controlled by an element with the <pref>aria-activedescendant</pref> attribute (e.g. see <ref>combobox</ref>): | |||
There was a problem hiding this comment.
One way is when it is owned by an element with the aria-activedescendant
From the definition of owned in terms:
An 'owned element' is any DOM descendant of the element, any element specified as a child via aria-owns, or any DOM descendant of the owned child.
Not currently part of this PR, but this PR is based on this definition, and its an incomplete definition. It insinuates a child could have more than one branch of owners. When an element gets a new owner via aria-owns, its old DOM parent owner is no longer its owner. IOW "any DOM descendant of the element" is only true, if that DOM descendant did not change ownership via another element's aria-owns. This is actually pretty important.
the other is when it is owned by an element that is controlled by an element with the aria-activedescendant attribute (e.g. see combobox)
- At least in Chrome, it's true that in this case the controlled by element needs to be one ancestor level up. Not sure if that's a bug or a useful optimization. It doesn't seem to make sense to overdo these checks, and look at every ancestor to see if there is an aria-controls pointing to it.
- Also, Chrome requires that the element with aria-controls by a text box. This only matters for the focusable state, not for focus events. For focus events, Chrome is not strict and will follow the aria-activedescendant from any focused element to any other element.
| <li>Focusable, if the element also has a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">role</a>, because the <pref>aria-activedescendant</pref> of the container can potentially point to it. It is not absolutely necessary to check this when there is no role, because elements that would be focusable would already have the focusable state.</li> | ||
| <li>Focused, whenever the container element sets <pref>aria-activedescendant</pref> to match the ID of this descendant and the container widget with <pref>aria-activedescendant</pref> has <abbr title="Document Object Model">DOM</abbr> focus.</li> | ||
| <li>Focusable, if the element also has a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">role</a>. The element needs to be focusable because it could be referenced by the <pref>aria-activedescendant</pref> attribute. Native elements that have no <a class="termref">role</a> attribute do not need to be checked, their native semantics determine the focusable state.</li> | ||
| <li>Focused, whenever the element is the target of the <pref>aria-activedescendant</pref> attribute and the element with the <pref>aria-activedescendant</pref> attribute has <abbr title="Document Object Model">DOM</abbr> focus.</li> |
There was a problem hiding this comment.
In reality it makes sense to apply the focused state to whatever gets actually focused. And since some browsers are not strict about firing activedescendant-based focus events, this line of the spec would not actually be used.
There was a problem hiding this comment.
@aleventhal
So the element with the aria-activedescendant attribute gets the focused state, the referenced element never does, right?
So the spec has been wrong for awhile?
There was a problem hiding this comment.
Or maybe what you are saying is that the element with the aria-activedescendant must have DOM focus for these states to be applied.
There was a problem hiding this comment.
Sorry it my comments go in contradiction to the previous conversations, just jumping in in the middle of the talk.
It feels complicated, I liked the simplicity of the old version. Leaving owned-controlled case out of the box for now, you could adjust the existing text to (changes are marked by bold):
"For any accessible element with an ID attribute, where the element is owned by an element with the aria-activedescendant attribute"
Then I would remove the role requirement. If element is accessible and has ID, that'd be a good justification to make it focusable. So:
- Focusable
- Focused when the owning element with aria-activedescendant attribute has DOM focus.
Having said that role requirement is not added in this PR, so it's totally fine to not tackle it.
Owned-controlled change looks valid but 1) it feels complicated (perhaps we need to introduce a new term for this owned-controlled case), 2) seems out of scope of this issue and thus deserves a separate issue.
There was a problem hiding this comment.
@asurkov wrote:
The controled case needs to be in scope. In ARIA 1.1, we changed the definition of activedescendant to include the case where a combobox input controlled a listbox, grid, or tree. However, this content about UA requirements was in core AAM, and we overlooked updating it for core AAM 1.1. As part of ARIA 1.2, we pulled this content out of core AAM and put it here, so it is now essential it be aligned with the definition of activedescendant.
index.html
Outdated
| <p class="note">The inability to set <abbr title="Document Object Model">DOM</abbr> focus to the containing element indicates an author error.</p> | ||
| </li> | ||
| <li>Otherwise, the user agent MAY attempt to set <abbr title="Document Object Model">DOM</abbr> focus to the child element itself.</li> | ||
| </ol> | ||
| </li> | ||
| <li>If the current element has an ID and an ancestor with the <code>aria-activedescendant</code> attribute present, the user agent MUST set the accessibility <abbr title="Application Programming Interface">API</abbr> focused state and fire an accessibility <abbr title="Application Programming Interface">API</abbr> focus <a>event</a> on the new active descendant.</li> | ||
| <li>If the current element has an ID and is <a>owned</a> by either a container element with the <code>aria-activedescendant</code> property or by a container element that is controlled by an element with the <pref>aria-activedescendant</pref> property, the user agent MUST set the accessibility <abbr title="Application Programming Interface">API</abbr> focused state and fire an accessibility <abbr title="Application Programming Interface">API</abbr> focus <a>event</a> on the element identified by the value of <code>aria-activedescendant</code>.</li> |
There was a problem hiding this comment.
Is I mentioned above, this is true only when the element with the aria-activedescendant gets DOM focused.
| <p>When multiple roles are specified as <em>required owned elements</em> for a role, at least one instance of one required owned element is expected. This specification does <em>not</em> require an instance of each of the listed owned roles. For example, a <code>menu</code> should have at least one instance of a <code>menuitem</code>, <code>menuitemcheckbox</code>, <em>or</em> <code>menuitemradio</code>. The <code>menu</code> role does not require one instance of each. </p> | ||
| <p>There may be times that required owned elements are missing, for example, while editing or while loading a data set. When a widget is missing <em>required owned elements</em> due to script execution or loading, authors MUST mark a containing element with <sref>aria-busy</sref> equal to <code>true</code>. For example, until a page is fully initialized and complete, an author could mark the document element as busy.</p> | ||
| <p>When multiple roles are specified as <em>required owned elements</em> for a role, at least one instance of one required <a>owned</a> element is expected. This specification does <em>not</em> require an instance of each of the listed owned roles. For example, a <code>menu</code> should have at least one instance of a <code>menuitem</code>, <code>menuitemcheckbox</code>, <em>or</em> <code>menuitemradio</code>. The <code>menu</code> role does not require one instance of each. </p> | ||
| <p>There may be times that required <a>owned</a> elements are missing, for example, while editing or while loading a data set. When a widget is missing <em>required owned elements</em> due to script execution or loading, authors MUST mark a containing element with <sref>aria-busy</sref> equal to <code>true</code>. For example, until a page is fully initialized and complete, an author could mark the document element as busy.</p> |
There was a problem hiding this comment.
I realize this is just adding owned as a linked definition, but this spec text may be wrong. You can have an empty listbox that is not "busy". See this example in ARIA practices:
https://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-rearrangeable.html
The empty listbox is the "Unimportant features" which the user has not filled in yet.
I don't believe aria-busy makes sense here. We should perhaps file a new issue for this, but required owned elements may need to be flexible and allow no children.
There was a problem hiding this comment.
I think updating this aria-busy language should be a separate 1.3 issue
Co-authored-by: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>
Co-authored-by: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>
Co-authored-by: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>
Co-authored-by: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>
|
@mcking65 I think we should limit the aria-activedescendant/aria-controls case to eminating from a focused textbox. This will reduce processing in the browser. |
There was a problem hiding this comment.
@mcking65 I think we should limit the aria-activedescendant/aria-controls case to eminating from a focused textbox. This will reduce processing in the browser.
I think we should also limit the scope of this aria-controls feature to what we have authoring practices for, which right now is combobox. The more specific we make the requirement, the less likely it will be abused and probably easier to implement and test.
| <li>Focusable, if the element also has a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">role</a>, because the <pref>aria-activedescendant</pref> of the container can potentially point to it. It is not absolutely necessary to check this when there is no role, because elements that would be focusable would already have the focusable state.</li> | ||
| <li>Focused, whenever the container element sets <pref>aria-activedescendant</pref> to match the ID of this descendant and the container widget with <pref>aria-activedescendant</pref> has <abbr title="Document Object Model">DOM</abbr> focus.</li> | ||
| <li>Focusable, if the element also has a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">role</a>. The element needs to be focusable because it could be referenced by the <pref>aria-activedescendant</pref> attribute. Native elements that have no <a class="termref">role</a> attribute do not need to be checked, their native semantics determine the focusable state.</li> | ||
| <li>Focused, whenever the element is the target of the <pref>aria-activedescendant</pref> attribute and the element with the <pref>aria-activedescendant</pref> attribute has <abbr title="Document Object Model">DOM</abbr> focus.</li> |
There was a problem hiding this comment.
@aleventhal
So the element with the aria-activedescendant attribute gets the focused state, the referenced element never does, right?
So the spec has been wrong for awhile?
| <li>Focusable, if the element also has a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">role</a>, because the <pref>aria-activedescendant</pref> of the container can potentially point to it. It is not absolutely necessary to check this when there is no role, because elements that would be focusable would already have the focusable state.</li> | ||
| <li>Focused, whenever the container element sets <pref>aria-activedescendant</pref> to match the ID of this descendant and the container widget with <pref>aria-activedescendant</pref> has <abbr title="Document Object Model">DOM</abbr> focus.</li> | ||
| <li>Focusable, if the element also has a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">role</a>. The element needs to be focusable because it could be referenced by the <pref>aria-activedescendant</pref> attribute. Native elements that have no <a class="termref">role</a> attribute do not need to be checked, their native semantics determine the focusable state.</li> | ||
| <li>Focused, whenever the element is the target of the <pref>aria-activedescendant</pref> attribute and the element with the <pref>aria-activedescendant</pref> attribute has <abbr title="Document Object Model">DOM</abbr> focus.</li> |
There was a problem hiding this comment.
Or maybe what you are saying is that the element with the aria-activedescendant must have DOM focus for these states to be applied.
|
@aleventhal wrote:
The aria-activedescendant definition limits it to a textbox, searchbox, or combobox. All 3 are necessary. |
…, searchbox, or combobox
|
@mcking65 @aleventhal |
| <li>Focusable, if the element also has a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">role</a>, because the <pref>aria-activedescendant</pref> of the container can potentially point to it. It is not absolutely necessary to check this when there is no role, because elements that would be focusable would already have the focusable state.</li> | ||
| <li>Focused, whenever the container element sets <pref>aria-activedescendant</pref> to match the ID of this descendant and the container widget with <pref>aria-activedescendant</pref> has <abbr title="Document Object Model">DOM</abbr> focus.</li> | ||
| <li>Focusable, if the element also has a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">role</a>. The element needs to be focusable because it could be referenced by the <pref>aria-activedescendant</pref> attribute. Native elements that have no <a class="termref">role</a> attribute do not need to be checked, their native semantics determine the focusable state.</li> | ||
| <li>Focused, whenever the element is the target of the <pref>aria-activedescendant</pref> attribute and the element with the <pref>aria-activedescendant</pref> attribute has <abbr title="Document Object Model">DOM</abbr> focus.</li> |
There was a problem hiding this comment.
Sorry it my comments go in contradiction to the previous conversations, just jumping in in the middle of the talk.
It feels complicated, I liked the simplicity of the old version. Leaving owned-controlled case out of the box for now, you could adjust the existing text to (changes are marked by bold):
"For any accessible element with an ID attribute, where the element is owned by an element with the aria-activedescendant attribute"
Then I would remove the role requirement. If element is accessible and has ID, that'd be a good justification to make it focusable. So:
- Focusable
- Focused when the owning element with aria-activedescendant attribute has DOM focus.
Having said that role requirement is not added in this PR, so it's totally fine to not tackle it.
Owned-controlled change looks valid but 1) it feels complicated (perhaps we need to introduce a new term for this owned-controlled case), 2) seems out of scope of this issue and thus deserves a separate issue.
| @@ -394,13 +394,14 @@ <h3>Information for User Agents</h3> | |||
| <li>Set the <abbr title="Document Object Model">DOM</abbr> focus: | |||
| <ol> | |||
| <li>If the <a class="termref">element</a> can take <abbr title="Document Object Model">DOM</abbr> focus, the <a class="termref">user agent</a> MUST set the <abbr title="Document Object Model">DOM</abbr> focus to it.</li> | |||
| <li>Otherwise, if the current element has an ID and an ancestor with the <pref>aria-activedescendant</pref> attribute present, and that ancestor is focusable, the user agent MUST set <abbr title="Document Object Model">DOM</abbr> focus to that ancestor. | |||
| <li>Otherwise, if the current element has an ID and the ID is referenced by the <pref>aria-activedescendant</pref> attribute of an element that is focusable, the user agent MUST set <abbr title="Document Object Model">DOM</abbr> focus to the element that has the <pref>aria-activedescendant</pref> attribute. | |||
| <p class="note">An element with an ID can be referenced when it is <a>owned</a> by a container element that has the <pref>aria-activedescendant</pref> attribute or by a container element that is controlled by an element that has the <pref>aria-activedescendant</pref> attribute (e.g. see <ref>combobox</ref>). Otherwise the <pref>aria-activedescendant</pref> attribute reference indicates an author error.</p> | |||
There was a problem hiding this comment.
mm, owned-controlled case goes into the note section, but it probably should stay in the main section. What about to add terms like aria-activedescendant referred element and referring aria-activedescendant element? then you could use the terms to keep phrases short and clear, and no notes required.
There was a problem hiding this comment.
I agree that we could make this easier to read with some new terms and editorial restructuring. However, at this point, if we agree on the meaning, I think we should just ship it and consider word smithing later.
I think we just need to define a term "valid aria-activedescendant reference" within the definition of aria-activedescendant and then use that here to reduce word count by a huge margin.
| <li>Focusable, if the element also has a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">role</a>, because the <pref>aria-activedescendant</pref> of the container can potentially point to it. It is not absolutely necessary to check this when there is no role, because elements that would be focusable would already have the focusable state.</li> | ||
| <li>Focused, whenever the container element sets <pref>aria-activedescendant</pref> to match the ID of this descendant and the container widget with <pref>aria-activedescendant</pref> has <abbr title="Document Object Model">DOM</abbr> focus.</li> | ||
| <li>Focusable, if the element also has a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">role</a>. The element needs to be focusable because it could be referenced by the <pref>aria-activedescendant</pref> attribute. Native elements that have no <a class="termref">role</a> attribute do not need to be checked, their native semantics determine the focusable state.</li> | ||
| <li>Focused, whenever the element is the target of the <pref>aria-activedescendant</pref> attribute and the element with the <pref>aria-activedescendant</pref> attribute has <abbr title="Document Object Model">DOM</abbr> focus.</li> |
There was a problem hiding this comment.
@asurkov wrote:
The controled case needs to be in scope. In ARIA 1.1, we changed the definition of activedescendant to include the case where a combobox input controlled a listbox, grid, or tree. However, this content about UA requirements was in core AAM, and we overlooked updating it for core AAM 1.1. As part of ARIA 1.2, we pulled this content out of core AAM and put it here, so it is now essential it be aligned with the definition of activedescendant.
| @@ -394,13 +394,14 @@ <h3>Information for User Agents</h3> | |||
| <li>Set the <abbr title="Document Object Model">DOM</abbr> focus: | |||
| <ol> | |||
| <li>If the <a class="termref">element</a> can take <abbr title="Document Object Model">DOM</abbr> focus, the <a class="termref">user agent</a> MUST set the <abbr title="Document Object Model">DOM</abbr> focus to it.</li> | |||
| <li>Otherwise, if the current element has an ID and an ancestor with the <pref>aria-activedescendant</pref> attribute present, and that ancestor is focusable, the user agent MUST set <abbr title="Document Object Model">DOM</abbr> focus to that ancestor. | |||
| <li>Otherwise, if the current element has an ID and the ID is referenced by the <pref>aria-activedescendant</pref> attribute of an element that is focusable, the user agent MUST set <abbr title="Document Object Model">DOM</abbr> focus to the element that has the <pref>aria-activedescendant</pref> attribute. | |||
| <p class="note">An element with an ID can be referenced when it is <a>owned</a> by a container element that has the <pref>aria-activedescendant</pref> attribute or by a container element that is controlled by an element that has the <pref>aria-activedescendant</pref> attribute (e.g. see <ref>combobox</ref>). Otherwise the <pref>aria-activedescendant</pref> attribute reference indicates an author error.</p> | |||
There was a problem hiding this comment.
I agree that we could make this easier to read with some new terms and editorial restructuring. However, at this point, if we agree on the meaning, I think we should just ship it and consider word smithing later.
I think we just need to define a term "valid aria-activedescendant reference" within the definition of aria-activedescendant and then use that here to reduce word count by a huge margin.
| <p>When multiple roles are specified as <em>required owned elements</em> for a role, at least one instance of one required owned element is expected. This specification does <em>not</em> require an instance of each of the listed owned roles. For example, a <code>menu</code> should have at least one instance of a <code>menuitem</code>, <code>menuitemcheckbox</code>, <em>or</em> <code>menuitemradio</code>. The <code>menu</code> role does not require one instance of each. </p> | ||
| <p>There may be times that required owned elements are missing, for example, while editing or while loading a data set. When a widget is missing <em>required owned elements</em> due to script execution or loading, authors MUST mark a containing element with <sref>aria-busy</sref> equal to <code>true</code>. For example, until a page is fully initialized and complete, an author could mark the document element as busy.</p> | ||
| <p>When multiple roles are specified as <em>required owned elements</em> for a role, at least one instance of one required <a>owned</a> element is expected. This specification does <em>not</em> require an instance of each of the listed owned roles. For example, a <code>menu</code> should have at least one instance of a <code>menuitem</code>, <code>menuitemcheckbox</code>, <em>or</em> <code>menuitemradio</code>. The <code>menu</code> role does not require one instance of each. </p> | ||
| <p>There may be times that required <a>owned</a> elements are missing, for example, while editing or while loading a data set. When a widget is missing <em>required owned elements</em> due to script execution or loading, authors MUST mark a containing element with <sref>aria-busy</sref> equal to <code>true</code>. For example, until a page is fully initialized and complete, an author could mark the document element as busy.</p> |
There was a problem hiding this comment.
I think updating this aria-busy language should be a separate 1.3 issue
|
Holding off on merging until we have the follow-up issues logged. Will merge as soon as that is done. |
… definitions (#1224) Co-Authored-By: Matt King <a11yThinker@Gmail.com> Co-Authored-By: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>
issue #1151
Updated definitions related to
aria-activedescendantto use the terms "owned" and "container", instead of just descendant elements.Here are some preview links:
Preview | Diff