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

Dear Charles Chen:



Thank you for your comments on the 24 February 2009 Last Call Working
Draft of Accessible Rich Internet Applications (WAI-ARIA) 1.0
(http://www.w3.org/TR/2009/WD-wai-aria-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=1;



* 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/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 Accessible Rich Internet Applications
(WAI-ARIA) 1.0.



Regards,



Janina Sajka, PFWG Chair

Michael Cooper, PFWG Staff Contact


Comment 10: Restore previous engineering of Live Regions
Date: 2009-03-30
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JanMar/0035.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.5.2. Live Region Attributes <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#liveregions>
Status: Proposal not accepted

-------------
Your comment:
-------------
Here are Google's Last Call comments on W3C ARIA based on our
implementation experience in having added ARIA support to a number of Web
2.0 applications such as Google Reader. Note that in addition, these
comments also reflect the experience gained from implementing live region
support in Fire-Vox --- a Google 20% project by Charles Chen that provides
a freely available Firefox extension that adds self-voicing capabilities to
the browser.



Specifically, we believe that the last minute changes to the definition of
live regions --- AKA  changes between last public WD  and Last Call Working
Draft  lose significant functionality with respect to using W3C  ARIA  for
highly interactive applications.



We understand that these changes were made at the behest of AT vendors.
Though we realize that AT implementations are a key part of the end-to-end
solution, we would also point out that they are but one piece of the
solution pipeline; further, they also tend to be the component that changes
the slowest.



In our experience, content follows based on what is supported in
mainstream browsers; significant availability of content accompanied by
browser support eventually gains attention from mainstream AT  with respect
to gaining support.  Finally, the combination of available content, browser
support, and AT behavior defines accessibility guidelines that get
recommended

 to developers.



Given the length of time it takes to bake a W3C REC, we strongly suggest
bringing back the  live-region functionality that has been dropped in the
Last Call WD,  since:



 A) It has been shown to be both implementable, and necessary.



 B) Given time, AT vendors will support it  --- something that is borne
out by the overall experience re live-regions in ARIA --- as  acase in
point, no AT  vendor supported any part of live-regions about a year ago.



The live-region functionality that has been dropped in the Last Call WD
makes it impossible to implement support for certain types of interaction,
see details below.



To conclude, failure to fix this will leave W3C  ARIA  crippled for many
years to come , given the pattern we have observed

 with respect to the evolution of access guidelines.



Live Regions:LC  Version Compared to Last Public WD:



 The current (last Public WD) implementation of live regions gives us:



1. a priority queue

2. a maximum priority which will

trump everything else (including earlier messages that were also at the
max)

3. a message flushing strategy



The change made in the Last Call WD, namely, removing "rude" from the
politeness levels and using alert or alertdialog instead, is a bug. A rude
live region is still a part of the current context, while an alert or an
alertdialog should be something that comes up which

takes over the current context; conflating the two would be a mistake.



To see this, note that an alert is not the same thing as a rude live
region. If you have a region that has some status information, then giving
it a role of alert will mean that all changes to that region have the
highest priority possible. But if some status messages should be high
priority and others not, then you can't get that distinction. With live
region settings, you can just change the

politeness level dynamically and have it work.



 Based on implementation experience of channels in Fire Vox, the main
contribution that channels provides is a way to specify whether or not
something that is higher priority should flush previous messages.



 These simplifications will break existing implementations that use live
regions. If we are going to break things this late in the game, we should
make sure that we are doing the right thing and that we don't lose the
functionality that currently exists. So a suggested fix:



 1. Keep polite, assertive, and rude and allow numbers. Much like CSS
allows for small, medium, and large values, polite would be the minimum,
assertive would be in the middle, and rude would be the maximum.



 2.. Drop channels and add an attribute to specify whether or not the
current message should flush previous messages. This attribute should have
a sensible default value of true to prevent too much chattering.

--------------------------------
Response from the Working Group:
--------------------------------
Author proposes user disposes.  



"To see this, note that an alert is not the same thing as a rude live
region. If you have a region that has some status information, then giving
it a role of alert will mean that all changes to that region have the
highest priority possible. But if some status messages should be high
priority and others not, then you can't get that distinction. With live
region settings, you can just change the politeness level dynamically and
have it work."



In response to the comment above.  Status messages can be put as either
high priority or low priority by using aria-live="assertive" or
aria-live="polite"  This enables the author to have the flexibility you
desire of having higher or lower priority messages.  We believe this
distinction is enough to enable Web 2.0 scenarios that need to convey a
sense of priority.  We believe the highest priority interruption of a user
should be conveyed through the use of an alert dialog that requires user
input.  This behavior maps to the thought that all scenarios that require
this type of priority should require all users (using AT or not) to
respond.



"2.. Drop channels and add an attribute to specify whether or not the
current message should flush previous messages. This attribute should have
a sensible default value of true to prevent too much chattering."



We believe ATs should decide whether to flush the message queue.  We
expect that some ATs will use aria-live "assertive" to flush any aria-live
"polite" messages ahead of the queue.  Depending on the number of events
raised, ATs may choose different behaviors.  We do not believe this is
something a web page author could anticipate in advance.  Web developers do
not typically think programatically of flushing messages and we do not
believe they would be able to effectively use this feature.



Live regions are the newest concept introduced in ARIA.  We want to keep
the scenarios focused for version 1.0 of live regions so that we can learn
from how authors use this feature.  We have an action item to improve live
regions in version 2.0 of ARIA.  At that time we will take lessons learned
from version 1.0.

Received on Tuesday, 15 December 2009 00:33:49 UTC