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

Dear Todd Kloots:

Thank you for your comments on the 16 September 2010 Last Call Working
Draft of Accessible Rich Internet Applications (WAI-ARIA) 1.0
(http://www.w3.org/TR/2010/WD-wai-aria-20100916/). 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 9 December 2010 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 in the following ways:

* If you have a W3C account, we request that you respond online at
http://www.w3.org/WAI/PF/comments/acknowledge?document_version_id=9;

* Else, 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/, and may also
include links to the relevant changes in the Accessible Rich Internet
Applications (WAI-ARIA) 1.0 editors' draft at
http://www.w3.org/WAI/PF/aria/20101202/.

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 340: Exceptions to host language precedence
Date: 2010-10-28
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0012.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2. Using WAI-ARIA <http://www.w3.org/TR/2010/WD-wai-aria-20100916/#usage>
Status: Alternate action taken

-------------
Your comment:
-------------
The spec states that host language states and properties take  precedence
over ARIA states and properties to avoid a conflict.  This might have
exceptions.  For  example, in the case of creating a DHTML autocomplete
developers need to set the "autocomplete"  attribute on a textbox to "off"
in order to suppress the default browser autocompletion, but set the 
"aria-autocomplete" attribute to the appropriate value.  For example:

<input type="text" aria-label="Tag" role="combobox" aria-expanded="true"
autocomplete="off"
    aria-autocomplete="list" aria-owns="owned_listbox"
aria-activedescendant="selected_option">

<input type="text" aria-label="Tag" role="combobox" aria-expanded="true"
   aria-autocomplete="list" aria-owns="owned_listbox"
aria-activedescendant="selected_option">
 <ul role="listbox" id="owned_listbox">
   <li role="option">Zebra</li>
   <li role="option" id="selected_option">Zoom</li>
 </ul>

If browsers or AT manufacturers follow the spec as currently written, the
host language attribute of  "autocomplete" would win out over the
"aria-autocomplete" and AT wouldn't announce that the  control has
autocomplete.

--------------------------------
Response from the Working Group:
--------------------------------
The WAI-ARIA specification section 7.5
http://www.w3.org/TR/2010/WD-wai-aria-20100916/host_languages#host_general_conflict
defines that ARIA overrides host language semantics by default, unless the
host language defines more precisely how ARIA and the host language
interact. HTML 5 is defining this via the HTML to Platform Accessibility
APIs Implementation Guide. A unofficial in-progress draft of this document
is available at http://dev.w3.org/html5/html-api-map/overview.html.

Regarding this specific case, the HTML 5 accessibility API mapping simply
needs to state how user agent conveys the autocomplete information to off
and handle the error case for when the author applies an aria-autocomplete
to that element. That effort should also address API mapping issue when
native host language support overrides ARIA markup. Only the host language
can define the response to the error conditions as it depends on the host
language. The HTML 5 specification defines where WAI-ARIA is allowed and
where it is not to avoid host language conflicts.

To make sure your specific concern is addressed in the above documents, we
have created an action with the HTML accessibility task force, which is
working on ARIA to HTML mapping. This is their action 89
http://www.w3.org/WAI/PF/HTML/track/actions/89.

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


Comment 341: Extra markup on menuitems
Date: 2010-10-28
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0012.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.7.4. Text Alternative Computation Example #1 <http://www.w3.org/TR/2010/WD-wai-aria-20100916/#tac_example1>
Status: Accepted proposal

-------------
Your comment:
-------------
The example shows use of basic menutiems with the aria-haspopup property
set to "false".  For example:

<ul role="menubar">
 
 <!-- Rule 2A: "File" label via aria-labelledby -->
  <li role="menuitem" aria-haspopup="true"
aria-labelledby="fileLabel"><span id="fileLabel">File</span>
    <ul role="menu">

      <!-- Rule 2C: "New" label via Namefrom:contents -->
      <li role="menuitem" aria-haspopup="false">New</li>
      <li role="menuitem" aria-haspopup="false">Open</li>
    </ul>
  </li>
</ul>

Is this now the recommended approach?  If so, it seems like a waste of
bytes.  All previous ARIA menuitem markup examples I have seen show that
menuitems without a submenu just have a role of "menuitem" and that's it. 
I think that the "aria-haspopup='false'" should be implied if it is simply
left off.

--------------------------------
Response from the Working Group:
--------------------------------
Although this is perfectly valid given that aria-haspopup is a boolean we
agree that it is not necessary to indicate that a menuitem has an
aria-haspopup value of false. We have removed the property from the
elements, in the example, that do not support a sub menu.

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


Comment 342: Toolbar should be composite
Date: 2010-10-28
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0012.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.3.2. Widget Roles <http://www.w3.org/TR/2010/WD-wai-aria-20100916/#widget_roles>
Status: Alternate action taken

-------------
Your comment:
-------------
Section 5.3.2 lists the roles that act as composite containers.  However,
the role of "toolbar"  isn't on this list, but rather is listed in the
"Document Structure" roles list in section 5.3.3.   This seems like a
mistake.  A toolbar is a composite considering that, like all other
composite  controls, it has a set of decendant controls (buttons) whose
focusability needs to be managed by  the container.  This is further
reinforced later in the spec in the role definition for toolbar,  where it
states that "To be keyboard accessible, authors SHOULD manage focus of
descendants for all  instances of this role, as described in Managing
Focus."

--------------------------------
Response from the Working Group:
--------------------------------
Toolbar used to be listed as a composite role. The taxonomy changed b/c
toolbars can contain more than just buttons. For example, the following
composite widgets are often contained within a toolbar: popup button
sub-menus, single-select radio groups, and search comboboxes. We will add
an example to the Authoring Practices document showing a toolbar containing
another managed-focus widget, such as a radiogroup.

The text in the toolbar role definition related to managing focus has been
softened to a "MAY" statement.

Received on Thursday, 2 December 2010 22:26:53 UTC