AT-SPI and IAccessible2 information (was Re: Using Google Chrome with a screen reader)

aloha, jason!

thank you for your thoughtful analysis -- more information about 
IAccessible2 (IA2), for those who are curious or who wish to utilize IA2, 
is available from the Open Accessibility Workgroup at:

* IAccessible2 Workgroup (developing IA2) - http://a11y.org/ia2
* IAccessible2, version 1.0.1 - http://a11y.org/ia2-spec

note that a new release of IAccessible2, version 1.0.2 -- having finished
a Request For Comments period -- is awaiting approval from the Open 
Accessibility workgroup before transitioning to a formal standard - the 
RFC versions of IAccessible2, version 1.0.2 are available either as HTML 
files:

http://www.linux-foundation.org/~ptbrunet/ia2/docs/html/

or as IDL files:

http://www.linux-foundation.org/~ptbrunet/ia2/api/

the change log from version 1.0.1 to 1.0.2 can be found at:

* http://www.linux-foundation.org/~ptbrunet/ia2/changelog.txt

note that the Open Accessibility Workgroup is also the petri dish in which 
the port of AT-SPI (the Assistive Technology Service Provider Interface) 
to D-Bus is being coordinated:

* http://a11y.org/atspi
* http://a11y.org/d-bus (currently under revision)
* http://a11y.org/a11yspecs/atspi/AT-SPI_on_D-Bus_20080730.html (archived
  snapshot of the previous version of the AT-SPI on D-Bus wiki page)

both projects -- AT-SPI and IAccessible2 -- are reflections of the Open 
Accessibility Workgroup's "Statement of Intent", located at:

http://a11y.org/a11yweb/soi.html

which states, in part, the Open Accessibility Workgroup's approach to 
collaborative and open work on accessibility frameworks and architectures:

<q cite="http://a11y.org/a11yweb/soi.html">

We wish to allay any concern that our standardization efforts might be 
focused on any one particular toolkit or desktop technology to the 
exclusion of other toolkits and desktops. We believe it is imperative 
to preserve choice and to maximize available options for users. 
Therefore, we are developing an accessibility standard based on 
functional performance criteria implemented in messaging protocols 
fully independent of any particular toolkit or desktop technology. We 
believe users who are persons with disabilities should be empowered to 
choose technologies from any and all environments which provide 
accessibility just as other desktop users today routinely use a mix of 
technologies from different desktop environments. Our goal is seamless 
interoperability.

While some of the accessibility interfaces being discussed as candidates 
for standardization within FSG Accessibility (now the Open Accessibility
Workgroup at the Linux Foundation), primarily AT-SPI, originated in 
GNOME, we as a group are committed to toolkit-neutral accessibility 
interface standards. A key goal of our ongoing standardization effort, 
which is inclusive rather than exclusive, is the long-term 
interoperability of accessibility solutions for the free desktop 
environment. The current KDE4 roadmap, for example, calls for 
interoperability with existing GNOME assistive technologies, using the 
AT-SPI bridge of Qt4. The KDE Accessibility Project also plans to port 
its own assistive technologies to AT-SPI so that GNOME users can benefit 
from them. The GNOME team is excited about this commitment and the 
willingness of the KDE developers to integrate technologies that 
originated within GNOME in those cases where they offer immediate 
tangible benefits to users.

At the same time, we are actively working together to develop and 
implement a strategy which will eliminate dependencies on any particular 
desktop, library, or toolkit, including KDE accessibility on GNOME 
libraries, or vice versa. The current plan of action, which was agreed 
to at a face-to-face meeting of FSG Accessibility during January 2005, 
is to standardize on a set of interfaces (most likely specified in IDL), 
and allow for multiple conformant implementations as long as basic 
interoperability requirements are met. This will allow for increased 
technology sharing and help future-proof our standardization efforts.
</q>

gregory.
----------------------------------------------------
  The optimist thinks that this is the best of all
  possible worlds; the pessimist knows it is.
----------------------------------------------------
 Gregory J. Rosmaita: gregory@linux-foundation.org
Vice-Chair & Webmaster, Open Accessibility Workgroup
http://a11y.org/              http://a11y.org/specs/
----------------------------------------------------

---- Jason White <jason@jasonjgw.net> wrote:
> On Wed, Sep 03, 2008 at 11:16:05AM +0100, Joshue O Connor wrote:
> >
> > Sorry for cross posting.
> >
> > I just tried to use a beta of Google Chrome with JAWS 9 and Window Eyes  
> > on Win XP. The only output I got from JAWS 9 was tab, tab, as I moved  
> > though a webpage with no ability to browse by headings, jump to form  
> > fields etc. With Window Eyes there was no output at all. Does anyone  
> > know if Google plan to make Chrome play nice with AT?
> 
> I don't know, but according to the details posted at
> http://lwn.net/Articles/296508/ it is based on WebKit. Support for Aria and
> the ATK/AT-SPI accessibility interfaces is currently being developed for
> WebKit under Linux, which is the operating system that I use and know most
> about with regard to accessibility.
> 
> I may be wrong, but it is my understanding that WebKit already supports
> accessibility under MacOS, which should make it easier for Google to
> incorporate this into Chrome. In the comments following the LWN article that I
> cited, it is speculated that Google may have written their own user interface
> support for WebKit under MS-Windows, instead of using the APIs developed by
> Apple for this purpose. What this entails regarding support for accessibility
> APIs I leave for others to judge, preferably after looking at the source code
> that Google developers have released. I don't know much about Windows as I
> don't use it, but my understanding from mailing list discussions is that the
> accessibility APIs available in that environment are not as comprehensive or
> sophisticated as, for example, ATK/AT-SPI, and so the assistive technology may
> need to do more of the work in making the application accessible. There is
> also a Windows-based technology, IAccessible2, developed by IBM that
> apparently offers superior accessibility API support, which may provide a
> better opportunity to make the software accessible without requiring as much
> work from assistive technology developers.
> 
> The QT version of WebKit may also become the subject of accessibility efforts
> now that accessibility APIs are being supported in QT 4. Of course, to make
> Chrome accessible via such APIs, it will also be necessary to ensure proper
> implementation in those parts of Google Chrome that are not based on WebKit.

Received on Wednesday, 3 September 2008 13:27:04 UTC