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

Dear Charles Chen:

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 337: Limitations of aria-live as defined
Date: 2010-10-05
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0000.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-live (property) <http://www.w3.org/TR/2010/WD-wai-aria-20100916/#aria-live>
Status: Proposal not accepted

-------------
Your comment:
-------------
There is no way to specify queuing policy. Polite notifications always
queue, assertive notifications always flush. This means you can't implement
the case where you have a series of polite notifications, pause those
notifications, speak an assertive notification, then go back to the polite
notifications. A good example of where this would be needed is a chat room
web app. In the main chat room, the messages in the log are polite.
However, if someone sends you a direct message, you would want that to
pause the notifications in the main chat, speak the direct message with a
different voice, then resume speaking the notifications in the main chat.
Right now, if the direct message were polite, it would be at the end of the
queue, and if it were assertive, it would clobber all the messages in the
main chat.


--------------------------------
Response from the Working Group:
--------------------------------
We agree there are use cases for the "rude" value. However, we are
concerned that authors might not understand the distinction between "rude"
and "assertive" and there could be widespread implementation that is highly
problematic for users. We also think the handling of this value by
assistive technology needs to be carefully considered. Therefore, we plan
to revisit this question in a future version of ARIA. This is tracked via
our ISSUE-161 (http://www.w3.org/WAI/PF/Group/track/issues/161).

We do think it is problematic if there are assistive technologies that
flush the queue when an "assertive" live region updates. If you aware of
implementations with this problem, we suggest you file bugs with those
vendors.

Note for the record: See also comment 10
(http://www.w3.org/WAI/PF/comments/details?comment_id=10).

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