** 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 (Aaron Leventhal), 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/
** How does IAccessible2 help Mozilla?
1) Support AJAX applications. for example, we will 
now have the ability to provide any information 
necessary for completely accessible live regions. 
There are features for the deliver of advanced 
ARIA features, such as extensible roles, relations 
and actions.
2) Support selection and caret. this will help 
with features such as "select and say" in Dragon 
Naturally Speaking -- which is currently not 
supported. It will also remove the need for screen 
reader hacks to find the caret. Currently, Windows 
screen readers must replace the video driver on 
the system and look for screen draws of vertical 
blinking lines. Over the long term, IAccessible2 
is a rich API that will simplify screen reader 
maintenance, and it will minimize interference 
with the low level drivers on end user systems. It 
will also help provide much better screen reader 
support for rich text editing.
3) Maximize code reuse. in the summer of this year 
(2006), we moved most of the ATK/AT-SPI support 
code out of the Linux-only files into a 
cross-platform area. The code now supports ATK, 
but it is ready to help support the IAccessible2 
interfaces.
** When will Mozilla support IAccessible2?
It is expected that Mozilla will be able to 
deliver basic IAccessible2 support in the Gecko 
1.9 / Firefox 3 time frame (something like Q3 2007).
Because it is backwards-compatible with MSAA, the 
current support of Windows screen readers and 
other assistive technologies for Firefox will 
continue to work. However, the new capabilities 
will be exposed, and newer  assistive technologies 
will be able to take advantage of them.
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/
Where do I learn more about Mozilla's 
accessibility work in general?
http://www.mozilla.org/access/
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.
At the same time, in the Mozilla open community 
tradition, I'd like hear all kinds of feedback -- 
praise, questions and concerns.
Thank you,
Aaron Leventhal
IBM web accessibility architect
Mozilla accessibility lead
Regards,
Victor
It's really fantastic that so much effort has been expended on this by
IBM the FSF, Mozilla et al. A Open Standard API is something I've
wanted to see for a while. This should be of great use in my
alt-access project for more than the most basic of operations provided
by MSAA. I'll be pouring over the docs and trying it out as soon as it
arrives (I saw the article on Consortium Info article yesterday but
hadn't got around to reading it yet).
I have a couple of questions not answered from a quick initial scan.
* For Firefox will it be exposed for Chrome as well as the Document?
* What 'server' implementations are planned apart from OOo and Firefox?
* Like Victor I wonder how it will sit with those looking at
UIAutomation for accessibility (or testing)? Especially those only
thinking of the Win platform. Obviously the migration from MSAA and to
other platforms are a plus. Are there plans to provide iAccessible2
for Windows' native controls so AT developers can use it on windows.
(cif MSAA or Gail for AT-SPI).
* What about the harmonisation with the Mac?
-- 
Steve Lee
www.oatsoft.org
www.schoolforge.org.uk
www.fullmeasure.co.uk
> _______________________________________________
> dev-accessibility mailing list
> dev-acce...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-accessibility
>
> * What 'server' implementations are planned apart from OOo and Firefox?
I know of several key projects such as 
cross-platform toolkits, but we'll have to wait 
for those projects to make their own 
announcements. For now I just suggest that you 
take a look at some of the endorsements in the 
press release.
We'll answer the UI Automation related questions 
shortly.
I don't know of any plans to support IAccessible2 
in standard Windows widgets, but it could help 
solve problems if that were done.
> * Like Victor I wonder how it will sit with those looking at
> UIAutomation for accessibility (or testing)? Especially those only
> thinking of the Win platform. Obviously the migration from MSAA and to
> other platforms are a plus. Are there plans to provide iAccessible2
> for Windows' native controls so AT developers can use it on windows.
> (cif MSAA or Gail for AT-SPI).
> 
> * What about the harmonisation with the Mac?
I'll answer that in a separate thread.
> * What 'server' implementations are planned apart from OOo and Firefox?
I know of several key projects such as 
cross-platform toolkits, but we'll have to wait 
for those projects to make their own 
announcements. For now I just suggest that you 
take a look at some of the endorsements in the 
press release.
We'll answer the UI Automation related questions 
shortly.
I don't know of any plans to support IAccessible2 
in standard Windows widgets, but it could help 
solve problems if that were done.
> * Like Victor I wonder how it will sit with those looking at
> UIAutomation for accessibility (or testing)? Especially those only
> thinking of the Win platform. Obviously the migration from MSAA and to
> other platforms are a plus. Are there plans to provide iAccessible2
> for Windows' native controls so AT developers can use it on windows.
> (cif MSAA or Gail for AT-SPI).
> 
> * What about the harmonisation with the Mac?
That's good; no great.
It's probably me but it did not initially jump out from the press
release and other articles that this is so much more than a paper
spec. There is working, tested code already as Rich Schwerdtfeger says
'we have fully tested ATV support today'. That is powerful.
Do the tooling plans include something like a FOSS reference
implementation of both sides to help developers get up to speed and to
aid conformance testing?
Steve Lee
Rich said:
Yes, we covered just about all the bases here. An 
API is not much good without ATV support and you 
need to create it while you are developing your 
application and developer support. We make sure 
there is at least screen reader support for any 
API effort we are involved in. In the cases of 
Windows, screen readers are available so we worked 
with them. For Java we build a pure java screen 
reader when we worked with Sun on it. We are 
building an open source screen reader for Linux 
called LSR (Linux Screen Reader) which builds off 
of the Java Screen Reader design but is more 
advanced. It also supports a scriptable UI through 
Python. What is interesting about this is Aaron is 
leading the Firefox 3 Linux enablement effort and 
using our screen reader as well as Sun's to ring 
it out. Aaron will actually be backporting a 
tested implementation back to IAccessible2 in 
February. Full ARIA support will also be added. 
So, actually we will be doing testing for Firefox 
with 4 screen readers, and at least 2 magnifiers. 
IBM is in the unique position in having developed 
assistive technologies as far back as 1985. I 
worked on the first GUI Screen Reader for the IBM 
PC for OS/2 back in 1990 while I was at IBM 
research. Our Software Group Accessibility 
Architecture and Development team, which includes 
Aaron, is the creme of the crop. The manager was 
even the technical lead on Home Page Reader.
Tooling, I regret to say is a little bit behind 
where we need to be but it will not be long. We 
have an open source Inspect tool planned. We 
actually one running internally but because the 
developer based it off of the Microsoft's inspect 
tool the Microsoft licensing prohibits our 
distribution outside the company. The open source 
version will be better and free of restrictions 
like this.
IBM Research is building a new general purpose 
version of RAVEN which will work on IAccessible2, 
ARIA, Java, Eclipse, and ODF content. It is rules 
based and there is a very early version for Java 
on alphaWorks. API consistencies make this 
possible. IAccessible2 is a key ingredient in the 
convergence between rich web and rich desktop 
applications as well as multiplatform consistency. 
The lead engineer is blind and sharp as a tack. He 
can use the tool too. It blew me away watching him 
work with it.
We are creating developer guidelines for 
IAccessible2 that will help developers here as 
well. That document is 100 pages and growing. What 
to do for specific roles, mapping between UNIX and 
Windows. That will all go to the FSG.
My blog below talks a bit about the size of the 
development effort.
Rich
Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility 
Architect/Strategist
Chair, IBM Accessibility Architecture Review Board
blog: 
http://www.ibm.com/developerworks/blogs/page/schwer
Steve