Yesterday's news about IAccessible2 was written mostly from press releases, but further details and insights didn't take long to hit the Web. Here are some of the more interesting ones that I've read so far.
The first is from Ian Murdock's Weblog (Ian Murdock is the founder of the Debian Project, and currently the CTO of the Free Standards Group, the consortium to which IBM contributed IAccessible2). Ian talks about why a Linux standards group would get involved in a Windows standard:
The first clue is that iAccessible2 is an accessibility API for Windows. Windows? Yes, the FSG is primarily a Linux organization (our main project is, of course, the Linux Standard Base), so why on earth are we now involved in building APIs for Windows?
First of all, we'll be moving this project forward as an extension to our existing accessibility projects - which, given the way the FSG is structured, flow into the LSB as they are adopted by the Linux distributions (who, as I've already mentioned here, are active participants in the LSB project, so we're not just hoping the distros adopt our work, we're proactively trying to drive consensus on these key issues). So, this definitely impacts our Linux work by bringing accessibility features to Linux that not only equal those of Windows but exceed them (iAccessible2 itself came about because Microsoft Active Accessibility has notable shortcomings).
But it's more than that. Another way to look at this is that the LSB APIs will be taking on a distinctly more cross platform flavor, particularly in the "around the edges" cases such as this. Again, that begs the question: Why is cross platform support important for a Linux organization? That one's simple. APIs are for application developers. Application developers target multiple platforms. The less Linux specific work an application developer has to do to support Linux, the more cost effective a Linux version will be, the more likely it is to get done. It's all about more Linux apps.
There's another dimension to it as well. There are a certain class of features that the vast majority of developers don't think much about because that vast majority doesn't need them. There's no itch to scratch, as it were. Accessibility is a great example of such a feature: I have no idea what it's like to be blind, nor do most people. If we can provide a set of open, cross platform APIs that allow application developers to easily add such features to their products, more standards based products will support them.
For those with an interest in how accessibility can be achieved at the technical level, the go-to expert is Peter Korn (you can find a link to his blog in the “Blog’s I read” list in the right column). Yesterday he posted a very detailed and interesting entry that gives a 20 year history of accessibility efforts (that’s how long he’s been involved in them), as well as a perspective on how IAccessible2 builds on, and was informed by, that history. He also comments on the interplay between IAccessibility2, Windows and ODF in the context of this project:
While IBM has clearly believed for some time that supported accessibility APIs are the right way to do accessibility, the accessibility concerns around ODF in Massachusetts brought home the clear need for these APIs in Windows. The Massachusetts ODF experience further underline the need for those APIs the work in more than just Windows Vista, and the need for them to provide all of the information needed to convey the richness and complexity of an office suite and ODF document content. Proof that this was a good approach has been evident from the early success of essentially the same accessibility API working well in UNIX = with the Orca screen reader on UNIX providing increasingly powerful and satisfying access for blind user to ODF via the OpenOffice.org and StarOffice applications. Further proof came with IBM’s work with Freedom Scientific as they together tested this API and its implementation to provide rich access to ODF via the JAWS screen reader.
I won’t even try to summarize all of the data in his entry, but here are his bullets on the significance of IAccessible2:
Which brings us to today, and the IAccessible2 announcement. I will leave it to IBM and Rich Schwerdtfeger to explain why they felt it was important to define an accessibility API for Window (given Microsoft’s UI Automation coming for Vista). But there are a few important benefits with IAccessible2 that are worth noting:
- IAccessible2 is based on and is an extension of MSAA. This means that is a natural and comfortable extension of what Windows AT vendors are already supporting, and what a number of Windows application vendors are already using.
- IAccessible2 looks remarkably like the UNIX Accessibility API (no surprise, it was derived from the OpenOffice.org UNO Accessibility API implementation designed for use in UNIX). This means that cross platform applications that want to run on Window and UNIX systems can implement accessibility support in largely the same way for both platforms.
- IAccessible2 works today, and on Windows XP. We don’t need to wait until Vista market penetration reaches some magical tipping point before it makes sense to start supporting a rich accessibility API for Windows.
- In addition to looking a lot like the UNIX (and Java, and Mozilla, and OpenOffice.org) Accessibility API, IAccessible2 looks a lot like the WAI ARIA specification for rich dynamic web applications. This too is no accident – Rich Schwerdtfeger of IBM is one of the editors of that W3C specification. This means that it should be fairly straightforward to map accessible “web 2.0” applications to work with assistive technologies on Windows via IAccessible2 – in just the same straightforward way one would mapping those APIs to work with assistive technologies on UNIX – via the UNIX Accessibility API.
- IAccessible2 is coming under the control of the Free Standards Group, where application vendors and AT vendors and interested parties from academia and the disability community can together chart the evolution and future of this API. This means that more than just one entity will have a real say in how the API develops going forward.
There’s a wealth of additional information there, so don’t settle for reading just the bullets above.
Another entry you might find interesting on IAccessible2 appears at the Blindconfidential commentary site at BlogSpot.com, a blog that focuses on accessibility issues. You can find that entry here, as well as links to many more related resources.
For further blog entries on ODF, click here
subscribe to the free Consortium Standards Bulletin
(and remember to Buy Your Books at Biff’s)
This is good news for open standards and for open software. It is even better news for computer users and for forward-thinking companies. It was not too long ago that a large retailer was sued in California because its Web site was not accessible. Thus, it is only a matter of time before such suits hit employers that do not deploy accessible software (or make reasonable accomodations) so that their employees can use their computers to do the tasks for which they were hired.
I hope that most office suites and most accessibility software/hardware vendors quickly implement this on all the platforms they develop for. It will greatly help companies that deploy these tools to be more productive and more competitive.
Mark Pilgrim’s accessibility site at http://diveintoaccessibility.org/ is a good read, even though it is mostly oriented toward making Web sites accessible.