Re: Invitation to review WAI-ARIA before Last Call deadline

Resending:

Use cases:
For a multi-user chat system, suppose the behavior for sighted users is that
messages appear as the chat progresses and messages that are directly
addressed to them are bolded so that it draws the users' eyes towards those
more important messages first. If we want to duplicate that experience for
visually impaired users, we would need to be able to specify the priority
and flushing behavior of the messages. All the messages would be live, but
messages that are directly addressed to the user would have a higher
priority level. These higher priority messages should not flush out the
lower priority messages however.


On the other hand, for a news website with stock information that has
headlines and stock price updates as live, it may make more sense to have
the headlines as higher priority and have it flush out the lower priority
price changes to prevent too much chatter.

-Raman and Charles

On Tue, Apr 28, 2009 at 2:00 PM, Janina Sajka <janina@rednote.net> wrote:

> Hello:
>
> Just a quick email to let you know that we have not received your
> response to the email below. So, if you sent us a response already,
> please resend it. And, if not, please do so as we're holding further
> action on your comment pending receipt of the additional information we
> have requested below.
>
> Janina Sajka, WAI-PF Chair
>
>
> --------------------------------------------------------------------------------
>
> Dear Charles:
>
> Thank you for your comments on WAI-ARIA Last Call. We would appreciate
> additional clarification on the following.
>
> 1.)     Provide use cases that demonstrate why these priority levels and
> the ability to flush address queue are needed.
>
> 2.)     Explain how this is implemented in Google Reader and Firevox.
> How does this work for the user?
>
> Thank you.
>
> Janina Sajka, WAI-PF Co-Chair
>
>
> Charles Chen writes:
> > On Mon, Mar 16, 2009 at 1:44 PM, Charles Chen <clchen@google.com> wrote:
> >
> > > 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.
> > >
> > > -Charles and Raman
> > >
> > >
> > > On Mon, Mar 9, 2009 at 10:27 AM, T.V Raman <raman@google.com> wrote:
> > >
> > >> Yes, we'll send you Last Call comments based on our  collective
> > >> experience in building ARIA-support library Google-AxsJAX
> > >> http://google-axsjax.googlecode.com,
> > >> our experience in integrating ARIA  support into sophisticated
> > >> Web-2.0 applications, as well as
> > >> Charles' expertize from building Fire-Vox. Stay tuned, and thanks
> > >> again for asking.
> > >>
> > >> James Craig writes:
> > >>  > Charles and TV,
> > >>  >
> > >>  > As representatives for a company with several web apps and a
> browser
> > >>  > that implements a portion of the WAI-ARIA draft, we consider your
> > >>  > feedback invaluable, so the editors of the WAI-ARIA drafts would
> like
> > >>  > to invite you to review the latest working draft before the new
> last
> > >>  > call date of April 17th. Due to the length of the document and
> > >>  > proximity to the SXSW and CSUN conferences, the review date has
> been
> > >>  > extended.
> > >>  >
> > >>  > Please send all specification comments to <mailto:
> > >> public-pfwg-comments@w3.org
> > >>  >  > before 17 April 2009.
> > >>  >
> > >>  >      WAI-ARIA Specification, Last Call Working Draft
> > >>  >      http://www.w3.org/TR/wai-aria/
> > >>  >
> > >>  > If you have time to review the other WAI-ARIA documents, we'd
> > >>  > appreciate any feedback you can provide.
> > >>  >
> > >>  >      WAI-ARIA User Agent Implementation Guide, First Public Working
> > >> Draft
> > >>  >      http://www.w3.org/TR/wai-aria-implementation/
> > >>  >
> > >>  >      WAI-ARIA Best Practices Guide, Working Draft
> > >>  >      http://www.w3.org/TR/wai-aria-practices/
> > >>  >
> > >>  > Thanks.
> > >>  > James Craig
> > >>  > Member, PFWG, W3C
> > >>
> > >> --
> > >> Best Regards,
> > >> --raman
> > >>
> > >> Title:  Research Scientist
> > >> Email:  raman@google.com
> > >> WWW:    http://emacspeak.sf.net/raman/
> > >> Google: tv+raman
> > >> GTalk:  raman@google.com, tv.raman.tv@gmail.com
> > >> PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
> > >>
> > >>
> > >
>
> --
>
> Janina Sajka,   Phone:  +1.202.595.7777;
>                sip:janina@CapitalAccessibility.Com
> Partner, Capital Accessibility LLC      http://CapitalAccessibility.Com
>
> Marketing the Owasys 22C talking screenless cell phone in the U.S. and
> Canada
> Learn more at http://ScreenlessPhone.Com
>
> Chair, Open Accessibility       janina@a11y.org
> Linux Foundation                http://a11y.org
>
>