[Kde-accessibility] An accessible Qt? I think not.

[Peter Korn]

Hi Leo,

 > ...
 >
> Me too :)  I am a newbie at all this stuff, but it certainly is
> interesting.  Playing with Inspect32 is fascinating, it is amazing how
> much information can be retrieved from the MSAA framework (and I
> suspect any other accessibility framework) if it is properly
> supported.  Names, default actions, screen positions, and the widget's
> parents and children.  It even works for web pages (at least Firefox
> does an excellent job of exposing the DOM of a page through MSAA).
> 
> That's why I was surprised to read Peter Korn's statement that
> "Microsoft Active Accessibility (MSAA) - fails to provide most of the
> information needed for screen reading and other AT uses, and is being
> supplanted in future Windows releases."  I don't profess to know how
> current screen readers are getting their info, but from my experience
> it seems like MSAA is perfectly good at exposing the necessary
> information.
> 
> For example, if MSAA is properly supported, I can grab all the menus
> and menu items from an application without ever activating those
> menus.  This allows me to present those menus in a way that is easier
> to navigate with low-precision input devices.  Like so:
> http://mushroomstamp.ca/menus.png

The problem is that MSAA isn't really applicable to the content region of 
complex apps.  Nor does it expose text attribute information, or character 
bounds information.  Thus if I want to write an MSAA-based screen reader, how 
can I get the content region of, say, OpenOffice.org?  If my screen magnifier 
is simply responding to caret movement events, then MSAA is arguably 
sufficient, but not if I want to drive my magnifier in sync with my reader 
(e.g. products like those from Texthelp).  Also if you look at a program like 
GOK that provides editing commands in a dynamic editing keyboard, again you 
need more information than MSAA provides.

Fundamentally MSAA has three problems:

  1. it doesn't do enough
  2. it isn't extensible (no easy way to add new capabilities to it)
  3. because of (1) and (2), it gets overloaded to try to do things it
     really can't, and so AT vendors and app vendors have app-specific
     MSAA implementations (rather than going generally just to the API),
     which means you loose much of the value of having a standard
     accessibility API


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.