First off, thank you all for thinking of me;-)

Like many here, I'm frankly disappointed to the extent to which
ARIA  has been mis-marketed, mis-communicated and consequently
mis-understood.

Here is a very brief engineer's description of ARIA --- based
both on how it was conceived and designed, and why. This should
help set the backdrop for designing accessibility solutions that
actually work for the end-user, rather than the typical exercise
in "checking the accessibility box" that happens  far too often.
I'll conclude this note with how I would engineer access
solutions for SVG/Canvas based on what is available via ARIA.

Summary: Why/How ARIA?

In 2003, we faced a situation where Web pages were no longer
documents -- they were turning into applications whereas
screenreaders continued to treat them as static text.
Secondly, screenreaders evolve slowly, have a lock on the
end-user, and are themselves limited by the platform-level APIs
provided by the platform they run on --- most commercial
screenreaders  are for MS Windows and are designed around
MSAA --- an API that was finalized in the mid to late 90's. Note
that for the record, MS  itself has moved to a newer (and
supposedly better)framework in UI Automation --- however the
screenreader vendors are still on MSAA.

So in 2003, the technical problem that needed to  be  solved was:

How do you get the browser to communicate through the funnel
called MSAA   to the  user's Adaptive Technology?
DHTML  widgets  are not static markup --- their behavior is
determined by handlers written in a Turing complete
language. What's needed for "introspection" and "reflection" of
these widgets?

ARIA  was designed as a Least Common Denominator solution to this
problem by:

  1. Drawing up a table of basic GUI widgets,
  2. Enumerating the MSAA events raised by the corresponding
     Win32 widgets,
  3. And defining additional DOM properties that could be
     attached to the underlying DOM representation of a DHTML
     widget so that browser could in turn raise the appropriate
     MSAA events.

It then remained to "define" these DOM  properties --- laying
aside 5 years of complex haggling over namespaces and other
irrelevancies, this looks exactly as it did in 2003:

1: Static property "role" declares what type of widget you have
e.g., menu or checkbox These do not change once set.

2. Dynamic state properties that get continuously updated during
   runtime to reflect the "state" of a control --- e.g. enabled,
   checked.

Now, it's completely inappropriate to pretend that the handful of
properties defined by ARIA solves all of the world's
problems. For example, it has been repeatedly asserted elsewhere
that ARIA somehow "magically" solves problems for users with
learning disabilities. For the record, it was never designed to
do so, and I dont believe that it somehow magically does anything
for anyone but the screenreader user. Similarly, somehow
"sprinkling" ARIA in dynamic SVG or Canvas controls will solve
nothing --- most of the semantics of such controls that would be
needed to help a blind user work with such controls will need to
be coded by the developer via context-specific script
handlers. (These handlers would in turn manipulate the low-level
ARIA bits in a concerted manner to produce the desired end-user
effect).

Further, it is erroneous to think of ARIA as a markup solution
--- it was explicitly designed for a world where things are
dynamic. This is also why I really do not expect ARIA properties
to appear in HTML markup directly --- to be useful, they are most
usefully set and updated from JavaScript. In fact I'd go as far
as to say that setting ARIA properties in the HTML markup is
likely to be error-prone, (except for role values which do not
change at run time) since whatever value you set a property to in
the markup *changes* by definition at runtime. In my experience,
initializing and updating ARIA properties from within JavaScript
is less error-prone, since the code is all in one place.

Now, turning to the canvas and SVG issue --- if you view the
actual problem to solve, namely "what should we do to make these
apps usable by a blind user" as opposed to asking the more
pedantic "how shall we put ARIA markup in SVG or Canvas", the
answer you come up with is both different, and IMHO more useful
to the end user.

In this context, if you think of HTML DOM and JavaScript as a
basic "assembly language" for Web browser hosted user interfaces,
then think of the tuple (aria-role, aria-state) as additional
opcodes in this assembly language. We can build higher-level
abstractions above this assembly language in order to produce
meaningful feedback to the end-user --- as an example, a
JavaScript programmer who is making his aplication work with a
screenreader would find it easier to code to a "speakNode" or
"speakText" function, rather than having to set and modify
low-level DOM properties at each step. (This is no different from
mainstream UI toolkits for AJAX providing higher-level
abstractions that free one from DOM-bit tweaking at every
turn). For an example of such a library, see
http://google-axsjax.googlecode.com -- it's presently used in a
number of Google applications including Google Reader to enable
screenreader support via ARIA.

So returning to the canvas/SVG question, I believe we can build
on what the ARIA support via browsers and screenreaders gives us
--- however to pedantically state "put ARIA in your SVG, somehow
it will magically work" is likely to lead to disappointed users
and developers alike. One interesting artifact that I would
personally like to see merge is a set of suporting libraries
analogous to to Google-AxsJAX for SVG and Canvas --- with the
goal of later enabling developers using these constructs to
inject accesibility support with minimal effort. I'll close this
note with a short bullet list of what I mean by "accessibility
support"; note that this is intentionally written to be broader
than "screenreader support" but is still specific to visually
impaired users.

Access-Enabling A User Interface:

  1. Enable user to reach all portions of the application through
     the keyboard. Combination of accelerator keys for oft-used
     actions and explicit traversal of the app --see "trails" in
     AxsJAX.

2. Ensure that constructs have the relevant metadata available in
   the DOM, e.g. a div that is a menu has aria-role=menu

3. Ensure that all user actions produce auditory feecback ---
   using ARIA, this involves either using live-regions or
   innovative uses of "activedescendent" -- both these idioms can
   be seen in action in the google-axsjax library.

4. Ensure that all automatic updates to the UI produce
   appropriate feedback -- typically via live-regions.

5. Enable user the "query the state" of the application from the
   keyboard --- think of this as a substitute for the eye being
   able to "look" at  key portions of the interface.

Hope this note generates more light than heat:-)

--Raman

--
Best Regards,
--raman

Title:  Research Scientist      
Email:  ra...@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman
GTalk:  ra...@google.com, tv.raman...@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc