Response to your comments on Accessible Rich Internet Applications (WAI-ARIA) 1.0

Dear Michael[tm] Smith:

Thank you for your comments on the 18 January 2011 Candidate Recommendation
of Accessible Rich Internet Applications (WAI-ARIA) 1.0
(http://www.w3.org/TR/2011/CR-wai-aria-20110118/). The Protocols and
Formats Working Group has reviewed all comments received on the draft. We
would like to know whether we have understood your comments correctly and
whether you are satisfied with our resolutions.

Please review our resolutions for the following comments, and reply to us
as soon as possible to say whether you accept them or to discuss additional
concerns you have with our response. If we do not hear from you by that
date, we will mark your comment as "no response" and close it. If you need
more time to consider your acknowledgement, please let us know. You can
respond by email to public-pfwg-comments@w3.org (be sure to reference our
comment ID so we can track your response). Note that this list is publicly
archived.

Please see below for the text of comments that you submitted and our
resolutions to your comments. Each comment includes a link to the archived
copy of your original comment on
http://lists.w3.org/Archives/Public/public-pfwg-comments/.

Note that if you still strongly disagree with our resolution on an issue,
you have the opportunity to file a formal objection (according to 3.3.2 of
the W3C Process, at
http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
to public-pfwg-comments@w3.org. Formal objections will be reviewed during
the candidate recommendation transition meeting with the W3C Director,
unless we can come to agreement with you on a resolution in advance of the
meeting.

Thank you for your time reviewing and sending comments. Though we cannot
always do exactly what each commenter requests, all of the comments are
valuable to the development of Accessible Rich Internet Applications
(WAI-ARIA) 1.0.

Regards,

Janina Sajka, PFWG Chair
Michael Cooper, PFWG Staff Contact


Comment 424: Please clearly specify what role=option must be contained in or owned by
Date: 2013-08-13
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2013JulSep/0005.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - option (role) <http://www.w3.org/TR/2011/CR-wai-aria-20110118/#option>
Status: Accepted proposal

-------------
Your comment:
-------------
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.

--------------------------------
Response from the Working Group:
--------------------------------
We have removed the statement from the "select" role that conflicted with
the statement in the "option" role. The questions about how Statement B
overrides Statement A no longer relate to a conflict.

Received on Monday, 3 February 2014 16:05:13 UTC