The debate between “screen scraping” and “accessibility API” seems to have been won by the proponents of the API model. Sun and Microsoft have done excellent jobs with the gnome Accessibility API and UIA respectively and now IBM gets in with an interesting entry that may win the day.
In the article pasted below, copied verbatim from Blind News, Aaron Leventhal, one of the real heroes of AOL and most recently IBM accessibility projects, describes the new API in detail. I haven’t read all of the supporting information but this one looks like a winner at first glance.
I still believe that a lot of attention needs to be paid to accessibility as regards context and do not know if this provides such a facility but, alas, it is a major step forward from MSAA that won’t require a total rewrite of the accessibility portions of a program.
Aaron’s article:
IBM and the Free Standards Group (FSG), today announced IBM’s donation
Of a new accessibility API, called IAccessible2, to the Free Standards
Group.
** Why a new API?
The need for the development of this new accessibility API was clear:
1) Crucial features added: the first generation Windows accessibility
API, called MSAA or IAccessible, lacked crucial features, such as
Support for the caret and selection, accessible relations, rich text
editing, multiple actions and many other features necessary for quality
Support in assistive technologies.
2) Accessibility efforts preserved: an evolutionary path was needed for
Applications which already had MSAA (IAccessible) support, to support
these new features. Rather than throw away the MSAA support that
applications already had, it was considered less expensive for both
applications and assistive technologies to grow new solutions on top of
today’s code.
3) Harmonized with other platforms: an API was needed that did not
require separate accessibility implementations for each platform. The
amount of different code between the ATK/AT-SPI implementations for UNIX
accessibility, and IAccessible2 implementations will be minimized, thus
saving resources.
This API draft was developed with consultation from a number of groups,
including assistive technology vendors, application developers from
Mozilla, developers working on ODF accessibility, and others.
** What is IAccessible2?
With the new API, an assistive technology will be able to QueryInterface
from an IAccessible*, to IAccessible2*, and to any other supported
interfaces.
The IAccessible2 interface itself collects important ATK features from
other areas, as well some completely new methods and features. These
tend to be methods that you may need on any object. For the most part,
features were added either to bring Windows capabilities up to the level
of ATK/AT-SPI, or in order to support the features of ARIA (previously
known of DHTML accessibility). For more information on ARIA, see the
links at the end of this email.
There are also specialized interfaces which are used only on objects
with the given capabilities of that interface. These interfaces
generally have a very close equivalent under ATK. In the following list
of interface matchups, ATK interfaces are prefaced with “Atk” and
IAccessible2 are prefaced with “IAccessible”:
AtkText ~= IAccessibleText
AtkEditableText ~= IAccessibleEditableText
AtkHyperText ~= IAccessibleHyperText
AtkHyperlink ~= IAccessibleHyperlink
AtkImage ~= IAccessibleImage
AtkTable ~= IAccessibleTable
AtkAction ~= IAccessibleAction
AtkValue ~= IAccessibleValue
AtkRelation ~= IAccessibleRelation
That should give a rough idea that what we’re doing is expanding MSAA
while matching ATK/AT-SPI to a very helpful degree. For more detail than
that, please see the draft interfaces, available here:
http://accessibility.freestandards.org/a11yspecs/ia2/docs/html/
** What are some benefits of IAccessible2 for application developers?
1) Support advanced features while preserving investment in MSAA
2) True support for editing: new events and methods to expose selection
changes, caret movement, text changes and text formatting will help with
features such as rich text editing and “select and say” in Dragon
Naturally Speaking. These features will also remove the need for screen
reader hacks to find the caret and selection. Currently, Windows screen
readers must replace the video driver on the system and look for screen
draws of vertical blinking lines.
3) Maximize code reuse: for example, Mozilla has in already moved most
of the ATK/AT-SPI support code out of the Linux-only files into a
cross-platform area of the code. The code still supports ATK, but it is
now also ready to support the IAccessible2 interfaces once they are
dropped into the codebase.
4) Support AJAX applications: IAccessible2 has object attributes which
will alow browsers such as Firefox to expose any author-supplied ARIA
hints to help make live regions of a web page accessible. In general
there are a number of features for the delivery of advanced ARIA
features, such as extensible roles, relations and actions.
** What are some benefits of IAccessible2 for assistive technology
developers?
1) Preserve investment in MSAA: because IAccessible2 is
backwards-compatible with MSAA, the current support of Windows screen
readers and other assistive technologies can continue to work on
applications that add IAccessible2 support. However, the newer
IAccessible2 capabilities will also be exposed, and thus newer assistive
technologies will be able to take advantage of them.
2) Enable more powerful features in more places, such as rich text
editing and features such as “select and say” in Dragon Naturally
Speaking, and sensible support for powerful widgets in rich internet
applications, in browsers that support ARIA through IAccessible2.
3) Simplify maintenance: over the long term, IAccessible2 is a rich API
that will simplify screen reader maintenance. For one thing, it reduces
the need for interference with the low level drivers on end user systems.
** Where can I learn more about IAccessible2?
1) FSG IAccessible2 Home Page:
http://www.freestandards.org/en/Accessibility/IAccessible2
2) IBM Announcement on IAccessible2:
http://www.ibm.com/press/us/en/pressrelease/20773.wss
3) Showing the Accessibility Way: IBM Contributes Project Missouri to
the Free Standards Group by Andy Updegrove:
http://www.consortiuminfo.org/standardsblog/article.php?story=20061214050334512
4) IBM project aims to help blind use ODF applications – InfoWorld:
http://www.infoworld.com/article/06/12/13/HNibmblindodf_1.html
5) IAccessible2 announcement in Japanese:
http://release.nikkei.co.jp/detail.cfm?relID=148610&lindID=1
Where can I learn more about ARIA and accessibility for rich internet
applications?
1) Roadmap for Accessible Rich Internet Applications (ARIA Roadmap):
http://www.w3.org/TR/aria-roadmap/
2) Roles for Accessible Rich Internet Applications (ARIA Roles):
http://www.w3.org/TR/aria-role/
3) States and Properties Module for Accessible Rich Internet
Applications (ARIA States and Properties): http://www.w3.org/TR/aria-state/
4) Mozilla ARIA documentation:
http://developer.mozilla.org/en/docs/Accessible_DHTML
Where do I learn more about ATK, AT-SPI and UNIX/Linux accessibility in
general?
http://developer.gnome.org/projects/gap/
This is an exciting time. A number of people worked very hard on this
API, and as the press release indicates, a number of organizations have
come out to declare support.
Feedback and questions are of course welcome.
Thank you,
Aaron Leventhal
IBM web accessibility architect
Afterward
About a million years ago, when I worked for Turning Point Software, we had a lawyer named Andy Updagrove. I wonder if he is the same one mentioned in this article?
— End
Aaron is one tenacious dude. I have spoken to him in email, on the phone and in person a few times. At CSUN this year I went on a quest to meet up with him at the mozilla booth. I love his take on the AT industry in general and to hear him speak on DCM is to hear a Garage Band Musician speak out against DRM. He has some direct views but mainly he is all about the fair use and open standards of access. His articles in the Mozilla archives are a little dated, however, they are great reads for where we were in 2003.
BC..
You know there is a war coming in 2007. And it will be fought not only for the hearts and minds of the genearl user. No it will be fought over what constitutes a .1 release, a true upgrade and what it will cost those of us to be on the leading [not bleeding] edge. And the first battle will be on the breaking of DCM. You may want to touch on this holy war in 07 my friend because before it’s all over some arms will be twisted and a few noses between venders will be seriously out of joint. And for those of us who run multiple AT software in Windows, either by choice or by design, will all be caught in the middle of this tug’o’war of market dominance.
The scariest thing in AT today is to walk the minefield of choices in such a way that your desired configuration doesn’t eat up tons of resources or that the parties involved just don’t play well together because one of them has their own solution for the program you are trying to have a play date with on your system. Explaining this to non IT people can be a challenge and I feel very bad for those in Education circles who have bought into a bill of goods just because the idea of one source solutions looked good on paper at the time of purchase. Runing one system for non Screen Magnification and one for those who do run Screen Mag will be almost a best practice in my blurry eyes next year. And running multiples on a laptop with a laptop assisted Video Magnifier will be a real challenge as well.
Yep.. a war is coming…