From kde-accessibility Wed Nov 27 19:04:56 2002 From: "Volker Hilsheimer" Date: Wed, 27 Nov 2002 19:04:56 +0000 To: kde-accessibility Subject: Re: [Kde-accessibility] Fwd: KDE Accessibility X-MARC-Message: https://marc.info/?l=kde-accessibility&m=103842411900423 <...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 _______________________________________________ kde-accessibility mailing list kde-accessibility@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-accessibility