** 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