Response to your comments on WAI-ARIA 1.0 User Agent Implementation Guide

Dear Loretta Guarino Reid:



Thank you for your comments on the 24 February 2009 First Public Working
Draft of WAI-ARIA 1.0 User Agent Implementation Guide
(http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/). 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 1 February 2010 to say whether you accept them or to discuss additional
concerns you have with our response. 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=5;



* 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 WAI-ARIA 1.0 User Agent
Implementation Guide editors' draft at
http://www.w3.org/WAI/PF/aria-implementation/20091214/.



Due to the scope of changes made in response to comments on the Last Call
Working Draft of WAI-ARIA, we are returning the specification to Working
Draft status. We will shortly publish a public "stabilization draft" of
WAI-ARIA and updated Working Drafts of the accompanying documents. While
these versions will not incorporate further discussion based on your
acknowledgement of our response to your comments, we will work with you on
your feedback as part of our preparation for the following version. You are
also welcome to submit new comments on the new public versions in addition
to sending your acknowledgement of our response to your previous 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 WAI-ARIA 1.0 User Agent Implementation
Guide.



Regards,



Janina Sajka, PFWG Chair

Michael Cooper, PFWG Staff Contact


Comment 204: Must add focus and blur methods
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0065.html
Relates to: WAI-ARIA 1.0 User Agent Implementation Guide - 2.1. Controlling focus with tabindex <http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/#keyboard-focus_tabindex>
Status: Accepted proposal

-------------
Your comment:
-------------
Why is item 3 SHOULD instead of MUST? "The focus and blur methods should be
added to the HTMLElement interface (available to script for every type of
element)." 

--------------------------------
Response from the Working Group:
--------------------------------
We agree. This requirement has been changed to a MUST. 

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


Comment 205: References to HTML
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0065.html
Relates to: WAI-ARIA 1.0 User Agent Implementation Guide - 2.1. Controlling focus with tabindex <http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/#keyboard-focus_tabindex>
Status: Accepted proposal

-------------
Your comment:
-------------
This section includes several references to the HTML5 Spec, which is still
evolving. Is that a problem? 

--------------------------------
Response from the Working Group:
--------------------------------
We think it is okay to discuss what we are confident will be allowed in
HTML 5 but, as you point out, linking to the spec before it is a W3C
recommendation is not a good idea. We have included the relevant
information from the HTML 5 spec in the User Agent Implementation Guide and
reduced the links to the document. 

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


Comment 206: tabindex in various browsers
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0065.html
Relates to: WAI-ARIA 1.0 User Agent Implementation Guide - 2.1. Controlling focus with tabindex <http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/#keyboard-focus_tabindex>
Status: Accepted proposal

-------------
Your comment:
-------------
The last paragraph lists several references to tabindex documentation for
different browsers. Do they all agree? Are they consistent with the
requirements of this section? How is a user agent implementor expected to
use this information? 

--------------------------------
Response from the Working Group:
--------------------------------
We have decided to change the last paragraph of the section to clarify. It
now reads:



"Over time, user agents have provided differing implementations and levels
of support for the tabindex attribute. Examples include: The Gecko
documentation on Key-navigable custom DHTML widgets; the documentation of
IE's tabindex behavior in MSDN: tabindex Property; Opera simple testcases.
The HTML 5 spec documents what the extended behavior of tabindex should be
([HTML5], Section 6.5.1) and user agent implementations."

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


Comment 207: focused or focusable states
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0065.html
Relates to: WAI-ARIA 1.0 User Agent Implementation Guide - 2.2. Controlling focus with ARIA <http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/#keyboard-focus_aria-activedescendant>
Status: Accepted proposal

-------------
Your comment:
-------------
We don't understand the parenthetical remark on item 2 "(iow don't use the
states FOCUSED or FOCUSABLE)" 

--------------------------------
Response from the Working Group:
--------------------------------
We have removed the subject remark to avoid confusion.

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


Comment 208: Frequency of notification
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0065.html
Relates to: WAI-ARIA 1.0 User Agent Implementation Guide - 3.1. General rules for exposing ARIA semantics <http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/#mapping_general>
Status: Accepted proposal

-------------
Your comment:
-------------
Paragraph 2 says "Conversely, assistive technology notification of property
changes depends on the method by which an assistive technology communicates
with the user agent." The following examples then talk about the expected
frequency of changes to property vs changes to state. How does this relate
the way that AT communicates with the user agent, and does the relative
infrequency mean that user agents should not notify AT if a property does
change?

--------------------------------
Response from the Working Group:
--------------------------------
You are correct that the examples do not relate to the statement about how
AT communicates with the UA. While state changes should always be
communicated to the AT, most property changes are not relevant to the user
and should not be communicated to the AT. AT should only be notified of
property changes when an accessibility API defines an change event for that
property. 



The UAIG text has been modified as follows:



User agents MUST notify assistive technology of state changes but SHOULD
only notify assistive technology of property changes if the accessibility
API defines a change event for the property. For example, IAccessible2
defines an event to be used when aria-activedescendant changes. 

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


Comment 209: Events on role change
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0065.html
Relates to: WAI-ARIA 1.0 User Agent Implementation Guide - 3.4.  Role mapping <http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/#mapping_role>
Status: Alternate action taken

-------------
Your comment:
-------------
If dynamic role changes are considered errors, why list the events that
would be associated with changing a role? And if they are listed, it would
be helpful to state explicitly that these are the events triggered by a
role change. This ought to be combined with, or reference, Section 6.5,
where this is discussed in more helpful detail.

--------------------------------
Response from the Working Group:
--------------------------------
The WAI-ARIA spec advises authors who wish to change a role attribute to
delete the object and its children and replace it with a new object with
the appropriate role. If authors ignore this guidance and change the role
dynamically, user agents are not required to do anything except map the new
role. As this will likely not be picked up by assistive technology,
however, user agents may want to try to make this work. 



In the UAIG, this note has been reworded to harmonize with the WAI-ARIA
spec wording and move up to the numbered list. The new wording is: 



5. Platform accessibility APIs typically do not provide a vehicle to
notify assistive technologies that a role has changed. Due to this and
document caching, assistive technologies are unlikely to process a change
in role attribute value. Authors who wish to change a role are advised by
the WAI-ARIA spec to delete the associated element and its children and
replace it with a new element having the appropriate role. If a role is
changed, however, user agents SHOULD update the mapping in order to reflect
the content in the DOM. Since assistive technology will not know that the
role has changed, a user agents MAY address this error condition by
treating it as removing a subtree item and inserting a new one as described
in 3.8.3. Changes to document content or node visibility.

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


Comment 210: Registered click handler
Date: 2009-04-16
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0065.html
Relates to: WAI-ARIA 1.0 User Agent Implementation Guide - 4.2. Actions <http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/#managed-states_actions>
Status: Answered question

-------------
Your comment:
-------------
How do you determine if an element has a registered CLICK handler? It may
be registered on an ancestor node in the dom, but whether CLICK handlers on
ancestors handle actions of an element depends upon the coding of the
handler. 

--------------------------------
Response from the Working Group:
--------------------------------
You are correct that a user agent can only reliably determine if a click
handler is registered on an element, not on its ancestor. If an author
registers a click handler on an element that has children that are also
clickable, additional coding is required. The clickable children must be
focusable or have ARIA roles, states, or properties that make them
interactive. 



We have logged an action item to create WCAG techniques and/or WAI-ARIA
authoring practices to address the correct coding techniques for this
scenario. We have also added the following rule to the set of rules in the
UAIG:



* the element is focusable



Note that the UAIG has undergone some reorganization and actions are now
described in section 3.7.

Received on Monday, 14 December 2009 23:11:28 UTC