[Kde-accessibility] Fwd: KDE Accessibility

[Volker Hilsheimer]

<...snip...>
> Unfortunately your assumption about MSAA - "that the flexibility it
offers
> is sufficient" is not true.  MSAA was developed in a climate where
there
> were already ~13 screen readers and ~10 screen magnifiers for Windows
3.1/95
> shipping.  These products used a variety of hacks, patches, and driver
> replacements to obtain the contents of the screen render it to users
with
> little or no sight.  Specifically screen readers would either patch
GDI
> (what ours did) or patch/replace the video driver (what most others
did) in
> order to filter all text rendering and other graphics calls, and build
an
> Off-Screen-Model (OSM) of the text contents of the screen.  As the
user
> tabbed through the UI (or used a "review mode" of the screen reader),
the
> screen reader would walk through its OSM and send the text it found
there to
> the speech synthesizer or Braille display.
>
> While a big mess, it was a system that was working (albiet poorly).
But the
> biggest problems screen access vendors were having at the time was
with
> working with Microsoft Office.  Office used non-standard UI elements,
and
> the patching/hackery was having a lot more trouble with Office.  It
was in
> this environment that Microsoft developed Active Accessibility.
>
> MSAA did NOT remove the need to patch the rendering sub-system and
build an
> Off-Screen-Model.  It was assumed that the text content region of all
> applications would be captured by existing techniques and retrieved
from the
> OSM.  While a number of people from the disability community,
including
> several assistive technology vendors (yours truly) argued forcefully
for a
> complete API that would do away with the need for OSMs, those voices
did not
> prevail.
>
> Today MSAA is widely seen by the community as a poor and insufficient
> solution to the problem, and Microsoft is rumored to be working on a
> replacement.  It's also worth noting that the more sophisticated
screen
> readers make only limited use of MSAA (e.g. JAWS for Windows), and
further
> make heavy use of application-specific COM APIs for improved access to
> specific applications (MS Word, Excel, and IE just to name a few).
>
>
> Specifically, MSAA lacks detailed action information (as you cited),
as well
> as text and table support - both crucial for access on UNIX desktops
(or
> anywhere where you don't already have an OSM approach in place).
Further,
> Sun and the GNOME community have developed a number of additional
> accessibility interfaces that are proving to be very useful, such as
the
> selection interface, and the new relation interface which is being
used
> fairly extensively by OpenOffice as well as the open source
Gnopernicus
> screen reader.
>
> > ...
> >
> > Well, please fwd. this to the respective lists/people. I would of
course
> > like to know more details about what parts seem to be insufficient
or
> > not flexible enough, so that we can add some fu in Qt. At least the
> > implementations we provide for all the Qt widgets should be
reusable.
>
> You may want to take a close look at the Mozilla accessibility effort.
They
> originally had a small staff working on MSAA support in their
underlying
> widget set (nsiAccessible).  Additional staff joined the effort and
expanded
> the nsiAccessible object through a series of sub-interfaces which are
then
> bridged to the GNOME ATK and thence AT-SPI interfaces.  We now have
early
> speech and Braille access to web pages via Gnopernicus and Mozilla on
> GNU/Linux and Solaris thanks to this work.  Had we limited ourselves
to the
> original nsiAccessible work that was needed to support MSAA in
Windows, this
> would not have been possible.

Hi Peter,

ok, sorry about my wrong assumptions about the usability of MSAA. The
reason we implemented is was that customers asked for it being
supported, and at that time the Sun/Gnome efforts were at the point that
the KDE discussion is now. We had - and still don't have - anybody who
would have been familiar enough with accessibility from a user's or
end-user-tool developer point of view, and were happy enough that we
could wrap the rather cluttered MSAA interface into something nicer ;-)

The idea behind our interface was to make it as easy as possible to
implement them for the different controls and control subelements, and
to leave it to the client to do something useful with this information
(e.g. to rather provide the text contents of a browser with HTML tags
and to leave it to the client to make them "visible" in a reasonable
way), and I still think that this is - as a concept at least - a
reasonable approach (assuming that there will be a significant number of
applications developed by clueless developers that should provide
accessibility information, and only a significantely smaller number of -
highly specialized - accessibility tools developed by people with much
clue about the issue).

The trick is now to provide as much information as possible, and to give
the client as many ways to interact with the objects as possible. The
infrastructure we have is IMHO flexible enough and should be easy to
extend to allow a good mapping to ATK, AT-SPI, MSAA and whatever comes
along on KDE.

We will try to put some resources into finding the "holes" in our API
(e.g. the relationship API in ATK has no equivalent, while the selection
handling has at least some etc.), and of course will hopefully receive
feedback from you guys ;-)

--
Volker