这是indexloc提供的服务，不要输入任何密码
Skip to content

Listbox and tree: clarify requirements for selected and checked #1340

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.

Sign up for GitHub

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

Merged
merged 25 commits into from
Jan 22, 2021
Merged

Listbox and tree: clarify requirements for selected and checked #1340

Changes from all commits
Commits
Show all changes
25 commits
Select commit Hold shift + click to select a range
488e3d4
Resolves #700 and resolves #1052 with the following changes.
mcking65 Oct 11, 2020
2fb18bf
Apply typo fixes from Carolyn
mcking65 Oct 21, 2020
1a4bce3
recommend select in single-selects and checked in multi-selects
mcking65 Oct 21, 2020
05854a2
replicate option chanes in treeitem
mcking65 Oct 21, 2020
043b710
Revise definition and first para of treeitem for editorial consistenc…
mcking65 Oct 21, 2020
2ba9462
Editorial clarification of treeitem ownership requirement
mcking65 Oct 21, 2020
a2c1bdd
of > for
mcking65 Oct 21, 2020
fd1f29e
Remove obsolete language from aria-selected
mcking65 Oct 21, 2020
cd3382e
Add user agent restrictions to tab role
mcking65 Oct 21, 2020
1a306e3
Update index.html
carmacleod Nov 19, 2020
7537d56
Improve authoring guidance based on feedback
mcking65 Dec 3, 2020
2279833
Improve wording of normative authoring for groups owned by listbox
mcking65 Dec 4, 2020
4f96de0
Minor revision to wording of preamble to conditions list
mcking65 Dec 4, 2020
562bdc5
Simplify normative UA language for implicit values on options
mcking65 Dec 4, 2020
8621a1d
Duplicate option revisions in treeitem
mcking65 Dec 4, 2020
96462f3
Replicate revised UA requirements for implicit selection for tab role
mcking65 Dec 4, 2020
d9a23a1
Accept Carolyn's suggestion for a single sentence normative for the U…
mcking65 Dec 10, 2020
2cdcca9
Fix role reference tag
mcking65 Dec 10, 2020
ce8e890
Fix role reference tag
mcking65 Dec 10, 2020
e18f154
Revise wording of UA requirements related to implicit value calculation
mcking65 Dec 10, 2020
384b072
Simplify wording of authoring guidance regarding using both selected …
mcking65 Dec 10, 2020
c560f46
white space change
mcking65 Dec 11, 2020
0d6dfca
Make UA requirement for treeitem match option
mcking65 Dec 11, 2020
e518f31
Make UA requirement for tab match option
mcking65 Dec 11, 2020
c51f148
Make wording of authoring guidance for treeitem match option
mcking65 Dec 11, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 54 additions & 21 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5991,9 +5991,27 @@ <h5>Note regarding the ARIA 1.1 <code>none</code> role.</h5>
<div class="role" id="option">
<rdef>option</rdef>
<div class="role-description">
<p>A selectable item in a <rref>listbox</rref>.</p>
<p>Authors MUST ensure <a>elements</a> with <a>role</a> <code>option</code> are contained in, or <a>owned</a> by, an element with the <a>role</a> <rref>listbox</rref> or <rref>group</rref> within a <code>listbox</code>. Options not associated with a <rref>listbox</rref> might not be correctly mapped to an <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a>.</p>
<p>Elements with the role <code>option</code> have an implicit <sref>aria-selected</sref> value of <code>false</code>.</p>
<p>An item in a <rref>listbox</rref>.</p>
<p>Authors MUST ensure <a>elements</a> with <a>role</a> <code>option</code> are contained in, or <a>owned</a> by, an element with <a>role</a> <rref>listbox</rref> or an element with <a>role</a> <rref>group</rref> that is contained in, or <a>owned</a> by, an element with <a>role</a> <code>listbox</code>. Options not associated with a <rref>listbox</rref> might not be correctly mapped to an <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a>.</p>
<p>In certain conditions, a user agent MAY provide an implicit value for <sref>aria-selected</sref> for each <rref>option</rref> in a <rref>listbox</rref>, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:</p>
<ul>
<li>The value of <pref>aria-multiselectable</pref> on the <rref>listbox</rref> is <code>false</code> or <code>undefined</code>.</li>
Copy link
Contributor

Choose a reason for hiding this comment

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

So this includes when the author literally has the attribute aria-multiselectable="undefined"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is that a problem? Should we word it so it does not? That would be some real hair splitting.

<li>None of the <rref>option</rref> elements in the <rref>listbox</rref> have an explicitly declared value for <sref>aria-selected</sref> or <sref>aria-checked</sref>.</li>
Copy link
Contributor

Choose a reason for hiding this comment

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

If there are 300 options, do you want us to go through each one and check? Or can the UA optimize a bit here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good question.

I think we've figured out that if UA never provides implicit values, nothing will break in a way that harms users. So, one approach could be to limit conditions where implicit values are provided if you want a UA to provide them at all.

When building the AX tree, isn't it necessary to process every option and at the same time set its states and props? So, you might be doing this anyway just to create the tree.

Copy link
Contributor

Choose a reason for hiding this comment

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

The main problem occurs when there are updates. We try to only process changed nodes, because as a page changes due to interactions, users expect things to be responsive. However, if we optimize so that once an implicit value is used, that it can be used going forward, then we should be ok on the browser performance front. I don't think the optimization needs any verbiage here, but we should clarify that it's a good approach.

</ul>
<p>
If a user agent provides an implicit <sref>aria-selected</sref> value for an <rref>option</rref>, the value SHOULD be <code>true</code> if the <rref>option</rref> has DOM focus or the <rref>listbox</rref> has DOM focus and the <rref>option</rref> is referenced by <pref>aria-activedescendant</pref>.
Otherwise, if a user agent provides an implicit <sref>aria-selected</sref> value for an <rref>option</rref>, the value SHOULD be <code>false</code>.
</p>
<p>
Authors MAY indicate selection for <rref>option</rref> elements using either <sref>aria-selected</sref> or <sref>aria-checked</sref>.
Some user interfaces indicate selection with <sref>aria-selected</sref> in single-select list boxes and with <sref>aria-checked</sref> in multi-select list boxes.
Authors SHOULD NOT specify both <sref>aria-selected</sref> and <sref>aria-checked</sref> on <rref>option</rref> elements contained by the same <rref>listbox</rref> except in the extremely rare circumstances where all the following conditions are met:
Copy link
Contributor

Choose a reason for hiding this comment

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

My one suggestion would be to tweak the "except when" wording, since (colloquially) it currently implies that authors should use both selected and checked when they think those three conditions are met.

Could we split up this line into two sentences, something like "Authors SHOULD NOT specify both aria-selected and aria-checked on option elements contained by the same listbox. However, authors MAY use both in the extremely rare circumstances where all the following conditions are met: [...]" (though probably with some more wording tweaks)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed with 03732dc

</p>
<ul>
<li>The meaning and purpose of <sref>aria-selected</sref> is different from the meaning and purpose of <sref>aria-checked</sref> in the user interface.</li>
<li>The user interface makes the meaning and purpose of each state apparent.</li>
<li>The user interface provides a separate method for controlling each state.</li>
</ul>
</div>
<table class="role-features">
<caption>Characteristics:</caption>
Expand Down Expand Up @@ -6041,18 +6059,15 @@ <h5>Note regarding the ARIA 1.1 <code>none</code> role.</h5>
</tr>
<tr>
<th class="role-required-properties-head">Required States and Properties:</th>
<td class="role-required-properties">
<ul>
<li><sref>aria-selected</sref></li>
</ul>
</td>
<td class="role-required-properties"></td>
</tr>
<tr>
<th class="role-properties-head" scope="row">Supported States and Properties:</th>
<td class="role-properties">
<ul>
<li><sref>aria-checked</sref></li>
<li><pref>aria-posinset</pref></li>
<li><sref>aria-selected</sref></li>
<li><pref>aria-setsize</pref></li>
</ul>
</td>
Expand Down Expand Up @@ -6088,7 +6103,7 @@ <h5>Note regarding the ARIA 1.1 <code>none</code> role.</h5>
</tr>
<tr>
<th class="implicit-values-head" scope="row">Implicit Value for Role:</th>
<td class="implicit-values">Default for <sref>aria-selected</sref> is <code class="default">false</code>.</td>
<td class="implicit-values"></td>
</tr>
</tbody>
</table>
Expand Down Expand Up @@ -8694,11 +8709,14 @@ <h5>Presentational Roles Conflict Resolution</h5>
<p>If a <rref>tabpanel</rref> or item in a <rref>tabpanel</rref> has focus, the associated <code>tab</code> is the currently active tab in the <rref>tablist</rref>, as defined in <a href="#managingfocus">Managing Focus</a>. <rref>tablist</rref> elements, which contain a set of associated <rref>tab</rref> elements, are typically placed near a series of <rref>tabpanel</rref> elements, usually preceding it. See the <cite><a href="" class="practices"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Authoring Practices</a></cite> for details on implementing a tab set design pattern.</p>
<p>Authors MUST ensure <a>elements</a> with <a>role</a> <rref>tab</rref> are contained in, or <a>owned</a> by, an element with the role <rref>tablist</rref>.</p>
<p>Authors SHOULD ensure the <rref>tabpanel</rref> associated with the currently active tab is <a>perceivable</a> to the user.</p>

<!-- keep following para synced with its counterpart in #tablist -->
<p>For a single-selectable <rref>tablist</rref>, authors SHOULD hide other <code>tabpanel</code> <a>elements</a> from the user until the user selects the tab associated with that tabpanel. For a multi-selectable <rref>tablist</rref>, authors SHOULD ensure that the <rref>tab</rref> for each visible <rref>tabpanel</rref> has the <sref>aria-expanded</sref> <a>attribute</a> set to <code>true</code>, and that the <code>tabs</code> associated with the remaining hidden <code>tabpanel</code> elements have their <sref>aria-expanded</sref> attributes set to <code>false</code>.</p>

<p>In either case, authors SHOULD ensure that a selected tab has its <sref>aria-selected</sref> attribute set to <code>true</code>, that inactive tab elements have their <sref>aria-selected</sref> attribute set to <code>false</code>, and that the currently selected tab provides a visual indication that it is selected. In the absence of an <sref>aria-selected</sref> attribute on the current tab, <a>user agents</a> SHOULD indicate to <a>assistive technologies</a> through the platform <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a> that the currently focused tab is selected.</p>
<p>Authors SHOULD ensure that a selected tab has its <sref>aria-selected</sref> attribute set to <code>true</code>, that inactive tab elements have their <sref>aria-selected</sref> attribute set to <code>false</code>, and that the currently selected tab provides a visual indication that it is selected.</p>
<p>In certain conditions, a user agent MAY provide an implicit value for <sref>aria-selected</sref> for each <rref>tab</rref> in a <rref>tablist</rref>, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:</p>
<ul>
<li>The value of <pref>aria-multiselectable</pref> on the <rref>tablist</rref> is <code>false</code> or <code>undefined</code>.</li>
<li>None of the <rref>tab</rref> elements in the <rref>tablist</rref> have an explicitly declared value for <sref>aria-selected</sref> or <sref>aria-expanded</sref>.</li>
Copy link

Choose a reason for hiding this comment

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

It's probably silly to use aria-expanded in a single-select tablist. However, I think this sentence means that if aria-expanded is set in a single-select tablist, there is no implicit aria-selected. Why does aria-expanded have this effect in this case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same as the argument for aria-checked similarly effecting a listbox.

If the author is using aria-expanded, we assume it is in lieu of aria-selected. If it is not, then it is up to the author to explicitly declare both. We don't want the user agent to assume the author wants both.

</ul>
</div>
<table class="role-features">
<caption>Characteristics:</caption>
Expand Down Expand Up @@ -9891,9 +9909,28 @@ <h5>Presentational Roles Conflict Resolution</h5>
<div class="role" id="treeitem">
<rdef>treeitem</rdef>
<div class="role-description">
<p>An option item of a <rref>tree</rref>. This is an <a>element</a> within a tree that may be expanded or collapsed if it contains a sub-level group of tree item elements.</p>
<p>A collection of <code>treeitem</code> elements to be expanded and collapsed are enclosed in an element with the <rref>group</rref> <a>role</a>.</p>
<p>Authors MUST ensure <a>elements</a> with <a>role</a> <code>treeitem</code> are contained in, or <a>owned</a> by, an element with the role <rref>group</rref> or <rref>tree</rref>.</p>
<p>An item in a <rref>tree</rref>.</p>
<p>A <rref>treeitem</rref> <a>element</a> may contain a sub-level group of elements that can be expanded or collapsed. An expandable collection of <code>treeitem</code> elements are enclosed in an element with the <rref>group</rref> <a>role</a>.</p>
<p>Authors MUST ensure <a>elements</a> with <a>role</a> <code>treeitem</code> are contained in, or <a>owned</a> by, an element with role <rref>tree</rref> or an element with role <rref>group</rref> that is contained in, or owned by, an element with role <rref>treeitem</rref>.</p>
<p>In certain conditions, a user agent MAY provide an implicit value for <sref>aria-selected</sref> for each <rref>treeitem</rref> in a <rref>tree</rref>, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:</p>
<ul>
<li>The value of <pref>aria-multiselectable</pref> on the <rref>tree</rref> is <code>false</code> or <code>undefined</code>.</li>
<li>None of the <rref>treeitem</rref> elements in the <rref>tree</rref> have an explicitly declared value for <sref>aria-selected</sref> or <sref>aria-checked</sref>.</li>
Copy link
Contributor

Choose a reason for hiding this comment

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

Since is is basically the same text as for option, does it make sense to create a separate section for Multiselectable Container Widgets Supporting Checked or Selected, and then redirect the reader to there? That way we don't have to wonder if it's exactly the same.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, that will make it easier to provide the same functionality in the future, e.g. if we ever add a listgrid role.

Finally, why are we only doing this for tree and listbox? What about treegrid? Can't rows be checked or selected there? Imagine a threaded email interface.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think it would simplify the wording to consolidate; it would still have to explicitly mention the option, listbox, tree, and treeitem roles.

In grid and treegrid, aria-checked is not supported on rows. In those widgets, if you were crazy enough to use both checked and selected states, you can just put a checkbox in a cell. That is not possible in listbox and tree; you can't put a checkbox inside an option or treeitem.

</ul>
<p>
If a user agent provides an implicit <sref>aria-selected</sref> value for a <rref>treeitem</rref>, the value SHOULD be <code>true</code> if the <rref>treeitem</rref> has DOM focus or the <rref>tree</rref> has DOM focus and the <rref>treeitem</rref> is referenced by <pref>aria-activedescendant</pref>.
Otherwise, if a user agent provides an implicit <sref>aria-selected</sref> value for a <rref>treeitem</rref>, the value SHOULD be <code>false</code>.
</p>
<p>
Authors MAY indicate selection for <rref>treeitem</rref> elements using either <sref>aria-selected</sref> or <sref>aria-checked</sref>.
Some user interfaces indicate selection with <sref>aria-selected</sref> in single-select trees and with <sref>aria-checked</sref> in multi-select trees.
Authors SHOULD NOT specify both <sref>aria-selected</sref> and <sref>aria-checked</sref> on <rref>treeitem</rref> elements contained by the same <rref>tree</rref> except in the extremely rare circumstances where all the following conditions are met:
</p>
<ul>
<li>The meaning and purpose of <sref>aria-selected</sref> is different from the meaning and purpose of <sref>aria-checked</sref> in the user interface.</li>
<li>The user interface makes the meaning and purpose of each state apparent.</li>
<li>The user interface provides a separate method for controlling each state.</li>
</ul>
</div>
<table class="role-features">
<caption>Characteristics:</caption>
Expand Down Expand Up @@ -12939,12 +12976,8 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
<sdef>aria-selected</sdef>
<div class="state-description">
<p>Indicates the current "selected" <a>state</a> of various <a>widgets</a>. See related <sref>aria-checked</sref> and <sref>aria-pressed</sref>.</p>
<p>This <a>attribute</a> is used with single-selection and multiple-selection widgets:</p>
<ol>
<li>Single-selection containers where the currently focused item is not selected. The selection normally follows the focus, and is managed by the <a>user agent</a>.</li>
<li>Multiple-selection containers. Authors SHOULD ensure that any selectable descendant of a container in which the <pref>aria-multiselectable</pref> attribute is <code>true</code> specifies a value of either <code>true</code> or <code>false</code> for the <sref>aria-selected</sref> attribute.</li>
</ol>
<p>Any explicit assignment of <sref>aria-selected</sref> takes precedence over the implicit selection based on focus. If no <abbr title="Document Object Model">DOM</abbr> element in the widget is explicitly marked as selected, assistive technologies MAY convey implicit selection which follows the keyboard focus of the <a href="#managingfocus">managed focus</a> widget. If any <abbr title="Document Object Model">DOM</abbr> element in the widget is explicitly marked as selected, the user agent MUST NOT convey implicit selection for the widget.</p>
<p>This <a>attribute</a> is used to indicate which elements within single-selection and multiple-selection <rref>composite</rref> widgets are selected.</p>
<p>The <rref>option</rref>, <rref>tab</rref>, and <rref>treeitem</rref> roles permit user agents to provide an implicit value for <sref>aria-selected</sref> when specified conditions are met. User agents MUST NOT provide an implicit value for aria-selected in any other circumstance.</p>
</div>
<table class="state-features">
<caption>Characteristics:</caption>
Expand Down