This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26053 - Resolve comment from Mike Smith for ARIA 1.1
Summary: Resolve comment from Mike Smith for ARIA 1.1
Status: RESOLVED FIXED
Alias: None
Product: ARIA
Classification: Unclassified
Component: Spec (show other bugs)
Version: 1.1
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: James Craig
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-11 07:04 UTC by James Craig
Modified: 2018-05-14 16:56 UTC (History)
1 user (show)

See Also:


Attachments

Description James Craig 2014-06-11 07:04:20 UTC
Resolve comment from Mike Smith for ARIA 1.1
From tracker: https://www.w3.org/WAI/PF/Group/track/actions/1326

PF Working Group, please handle this as a formal comment on specification
requirements and implementation and testing of the Candidate Recommendation
of WAI-ARIA 1.0 at http://www.w3.org/TR/wai-aria/

Comment: 
Please make the WAI-ARIA precisely and unambiguously specify the complete
list of roles that role=option elements must be contained in or owned by
(that is, which roles can contain or own role=option elements).

I'm implementing and testing HTML+ARIA validation support in the W3C
validator, and I'm not able to implement and test the role=option
document-conformance requirements in the spec properly without the spec
being clear about what the requirements actually are.

Specifically, I suggest doing the following:

1. Include a single statement at http://www.w3.org/TR/wai-aria/roles#option
such as the following:

"Authors MUST ensure elements with role option are contained in or owned by an element
with any of the following roles: combobox, listbox, menu, radiogroup, or tree."

...with the "combobox, listbox, menu, radiogroup, or tree" part being an
exhaustive list of the container/owner roles where role=option is actually
allowed (I don't know myself whether that's actually the complete list
intended by the editors of the spec or not).

2. Remove any other statements in the spec that specify container/owner
requirements for role=option. For example, remove the current statement in 
in http://www.w3.org/TR/wai-aria/roles#select about container/owner
requirements for role=option.

Problem with current spec:
One part of the current CR (and ED at http://www.w3.org/WAI/PF/aria/roles#option
as well) first states this:

A. "Authors MUST ensure elements with role option are contained in, or
owned by, an element with the role listbox."
http://www.w3.org/TR/wai-aria/roles#option

So that would seem like a clear requirement that role=option elements must
only be used with role=listbox containers/owners.

But then another part of the the current CR and ED states this:

B. "Authors MUST ensure elements with role option are contained in an element
using one of the non-abstract child roles of select, such as combobox,
listbox, menu, radiogroup, or tree."
http://www.w3.org/TR/wai-aria/roles#select

Questions:

1. Does statement B above override statement A's requirement that role=option
elements must only be contained in or owned by an element with role=listbox?

2. Is the list of elements "such as combobox, listbox, menu, radiogroup, or
tree" in statement B an exhaustive list of the "non-abstract child roles of
select" which should allow role=option? It seems like it is, if instead of
"non-abstract child roles of select", what editors of the spec really meant
to write here instead is "the subclass roles of the select role". (But if
not, how do I find out from the spec what the complete list of
"non-abstract child roles of select" is?)

3. Can role=option elements also be owned by (not just contained in)
elements with the roles listed in statement B?

My comment at the beginning of this message is a request for the spec to
clarify the three questions just above.

--Mike
Comment 1 James Nurthen 2018-05-14 16:56:19 UTC
Looking at the current spec I believe this is resolved.