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

Should aria-selected be listed as required for option role? #700

Closed
mcking65 opened this issue Feb 5, 2018 · 3 comments · Fixed by #1340
Closed

Should aria-selected be listed as required for option role? #700

mcking65 opened this issue Feb 5, 2018 · 3 comments · Fixed by #1340
Assignees
Labels
has PR PR exists that will close this issue
Milestone

Comments

@mcking65
Copy link
Contributor

mcking65 commented Feb 5, 2018

Originally posted by @kbae00 in w3c/aria-practices#594.

Currently aria-selected is listed in the Characteristics table as a required attribute for the option role: https://www.w3.org/TR/wai-aria-1.1/#option. But the description says "Elements with the role option have an implicit aria-selected value of false." Should aria-selected be listed as a supported attribute instead of required?

@mcking65
Copy link
Contributor Author

mcking65 commented Feb 5, 2018

This is a good question. Section 5.2.2 Required States and Properties says:

Content authors MUST provide a non-empty value for required states and properties. Content authors MUST NOT use the value undefined for required states and properties, unless undefined is an explicitly-supported value of that state or property.

And, it also says:

NOTE: A host language attribute with the appropriate implicit WAI-ARIA semantic fulfills this requirement.

Interesting that native attributes meet the requirement but the implied semantics associated with an ARIA role do not.
If the ARIA role has a default implied value, why would authors have to duplicate that implied value explicitly if the implied value is the correct value for the element?

We have this same type of requirement on other roles, aria-checked for example.

I think we should leave the role definitions the same but change the authoring requirement in section 5.2.2. Instead it should say:

Content authors MUST provide a non-empty value for required states and properties except in conditions where the role that requires the state or property provides the appropriate value by default. Content authors MUST NOT use the value undefined for required states and properties, unless undefined is an explicitly-supported value of that state or property.

@mcking65 mcking65 added this to the ARIA 1.2 milestone Aug 15, 2018
@mcking65 mcking65 self-assigned this Aug 15, 2018
@mcking65
Copy link
Contributor Author

I have changed my view on how to fix this. I now think that we need to change aria-selected to a supported property for option.

There are two reasons. First, aria-selected includes language that saves authors from having to declare aria-selected=false on selectable elements in single-select widgets. The following from the aria-selected spec is baked into user agents:

This attribute is used with single-selection and multiple-selection widgets:

  1. Single-selection containers where the currently focused item is not selected. The selection normally follows the focus, and is managed by the user agent.
  2. Multiple-selection containers. Authors SHOULD ensure that any selectable descendant of a container in which the aria-multiselectable attribute is true specifies a value of either true or false for the aria-selected attribute.

Any explicit assignment of aria-selected takes precedence over the implicit selection based on focus. If no DOM element in the widget is explicitly marked as selected, assistive technologies MAY convey implicit selection which follows the keyboard focus of the managed focus widget. If any DOM element in the widget is explicitly marked as selected, the user agent MUST NOT convey implicit selection for the widget.

Second, both option and treeitem also support aria-checked. I don't know why option supports aria-checked, but at least for treeitem, aria-checked can be used instead of aria-selected in multi-select trees. Then, it is possible to set aria-checked to mixed on a parent treeitem where some but not all descendant treeitem elements are selected (checked).

So, aria-selected should be supported, not required on option.

Further, aria-selected should not have an implied default value if not set. This is particularly important if aria-checked is being used instead of aria-selected.

mcking65 added a commit that referenced this issue Aug 15, 2018
…ve implicit value

For issue #700, made the following changes to the option role section in index.html:

1. Remove sentence from description that states there is an default value of false fore aria-selected on option elements.
2. Remove aria-selected from required states and properties row of attributes table.
3. Add aria-selected to supported row of attributes table.
4. Remove default value for aria-selected from implicit values row of attributes table.

Note: This cascades to treeitem so that aria-selected is not required on treeitem.
@jnurthen jnurthen added the has PR PR exists that will close this issue label Oct 2, 2019
@jnurthen jnurthen modified the milestones: ARIA 1.2, ARIA 1.3 Nov 19, 2019
mcking65 added a commit that referenced this issue Oct 11, 2020
Removes "selectable" from the definition of option to support cases where either an item is checkable instead of selectable or an item is neither selectable nor checkable (i.e., similar to disabled). The definition of option is then:

>An item in a listbox.

Replaces the statement:

>Elements with the role option have an implicit aria-selected value of false.

with a list of conditions that must be met before a user agent can provide an implicit value for aria-selected. This enables authors to:
1. Use aria-checked instead of aria-selected in any listbox.
2. Indicate that an option is not selectable or checkable by omitting the declaration of checked or selected in a listbox where either checked or selected is explicitly declared on some of the options.

Adds authoring guidance that:
1. Weakly suggests use of checked instead of selected in multi-selects.
2. Strongly discourages use of both checked and selected in the same listbox.

In the characteristics table for option:
1. Removes aria-selected from required properties and adds to supported properties.
2. Removes the implicit value for aria-selected.
@mcking65
Copy link
Contributor Author

working on a solution in pull request #1340, which replaces PR #799.

mcking65 added a commit that referenced this issue Dec 4, 2020
Removes "selectable" from the definition of option to support cases where either an item is checkable instead of selectable or an item is neither selectable nor checkable (i.e., similar to disabled). The definition of option is then:

>An item in a listbox.

Replaces the statement:

>Elements with the role option have an implicit aria-selected value of false.

with a list of conditions that must be met before a user agent can provide an implicit value for aria-selected. This enables authors to:
1. Use aria-checked instead of aria-selected in any listbox.
2. Indicate that an option is not selectable or checkable by omitting the declaration of checked or selected in a listbox where either checked or selected is explicitly declared on some of the options.

Adds authoring guidance that:
1. Weakly suggests use of checked instead of selected in multi-selects.
2. Strongly discourages use of both checked and selected in the same listbox.

In the characteristics table for option:
1. Removes aria-selected from required properties and adds to supported properties.
2. Removes the implicit value for aria-selected.
mcking65 added a commit that referenced this issue Dec 10, 2020
Removes "selectable" from the definition of option to support cases where either an item is checkable instead of selectable or an item is neither selectable nor checkable (i.e., similar to disabled). The definition of option is then:

>An item in a listbox.

Replaces the statement:

>Elements with the role option have an implicit aria-selected value of false.

with a list of conditions that must be met before a user agent can provide an implicit value for aria-selected. This enables authors to:
1. Use aria-checked instead of aria-selected in any listbox.
2. Indicate that an option is not selectable or checkable by omitting the declaration of checked or selected in a listbox where either checked or selected is explicitly declared on some of the options.

Adds authoring guidance that:
1. Weakly suggests use of checked instead of selected in multi-selects.
2. Strongly discourages use of both checked and selected in the same listbox.

In the characteristics table for option:
1. Removes aria-selected from required properties and adds to supported properties.
2. Removes the implicit value for aria-selected.
jnurthen pushed a commit that referenced this issue Jan 22, 2021
* Resolves #700 and resolves #1052 with the following changes.

Removes "selectable" from the definition of option to support cases where either an item is checkable instead of selectable or an item is neither selectable nor checkable (i.e., similar to disabled). The definition of option is then:

>An item in a listbox.

Replaces the statement:

>Elements with the role option have an implicit aria-selected value of false.
with a list of conditions that must be met before a user agent can provide an implicit value for aria-selected. This enables authors to:

1. Use aria-checked instead of aria-selected in any listbox.
2. Indicate that an option is not selectable or checkable by omitting the declaration of checked or selected in a listbox where either checked or selected is explicitly declared on some of the options.

Adds authoring guidance that:
1. Weakly suggests use of checked instead of selected in multi-selects.
2. Strongly discourages use of both checked and selected in the same listbox.

In the characteristics table for option:
1. Removes aria-selected from required properties and adds to supported properties.
2. Removes the implicit value for aria-selected.

Co-authored-by: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>
Co-authored-by: James Teh <jamie@jantrid.net>

* Duplicate option revisions in treeitem
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has PR PR exists that will close this issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants