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

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

Received on Monday, 13 April 2009 16:53:58 UTC