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
by 27 January 2014 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 proposed 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: Proposal not accepted

-------------
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:
--------------------------------
option is only allowed in a listbox. Listbox itself may be used in other
contexts such as combobox, but the option still only applies to the
listbox. Menu uses menuitem, not option.

----------------------------------------------------------------------


Comment 426: Drop the requirement that host languages must allow a token list as the value of the role attribute
Date: 2013-08-20
Archived at: Drop the requirement that host languages must allow a token list as the value of the role attribute
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 7.1. Role Attribute <http://www.w3.org/TR/2011/CR-wai-aria-20110118/#host_general_role>
Status: Proposal not accepted

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

Comment:  Please drop the requirement in the ARIA spec that host languages
must allow a token list as the value of the role attribute.

The ARIA spec should instead make it a document-conformance (authoring)
error for a role value to have multiple tokens. Or at the very least the
spec should allow host languages to make it a document-conformance error.

Details/rationale: The ARIA specification does not identify any valid use
cases for role values that contain multiple tokens, nor do any of the
examples in the ARIA spec contain role values with multiple tokens, nor do
any of the examples in other ARIA-related W3C documents.

What possible valid use case actually exists for a document to have a role
attribute that contains multiple tokens? Why would an author ever
intentionally (non-accidentally) use a role attribute with multiple
tokens?

If there's no good reason for an author to ever intentionally use a role
value with multiple tokens, rather than doing it accidentally, then the
ARIA spec should make it a document-conformance error to do so.

Also, speaking as an implementor of an HTML+ARIA validator, I can tell you
that it's not practical to implement support in the validator for doing
HTML+ARIA validation if role values are allowed to contain multiple tokens
and the validator is expected to process them.

To be specific: Given the complexities of the other requirements defined in
the ARIA specification for the use of the role attribute, if the role value
is also -- on to top of all the other complexities -- allowed to have
multiple tokens, the only practical way to implement validation support for
checking the role attribute and usefully reporting errors is to write all
of the ARIA validation support in custom code (e.g., in Java, for the case
of the W3C validator) rather than being able to express most of it using a
grammar/schema (e.g., a RelaxNG grammar, for the case of the W3C
validator).

Adding support for validating role values that can contain multiple tokens
would probably require at least an order of magnitude more time and work to
implement than what was needed to implement the existing ARIA support that
we currently have in the validator. And that existing ARIA support in the
validator has already by far required more time and work to implement than
any other language feature that's supported in the validator.

--------------------------------
Response from the Working Group:
--------------------------------
This is an important provision for future compatibility and the spec
provides a procedure to process multiple role tokens.

Received on Tuesday, 21 January 2014 00:24:06 UTC