Last Comment Bug 368873 - (ia2) [meta] IAccessible2 API support
: [meta] IAccessible2 API support
: access, meta
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 All
-- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: alexander :surkov
Depends on: 289188 433667 614571 614572 684141 873437 873440 873441 873444 873445 873451 78296 166994 335668 345780 346146 357430 363230 369777 370276 370676 370790 371273 371591 372708 winable 373329 373364 373531 374487 374790 375534 376032 376832 377285 377294 377302 378038 379366 379579 379585 379608 380021 380022 380038 380508 380524 381049 381302 381312 383095 383608 385317 385573 387857 390212 390414 391592 391617 391622 392153 392626 392895 393897 394117 395077 395081 405747 405756 406959 407589 407592 417018 577727 754230 873438 873439 873447 873450 873453 877985 1233118
Blocks: keya11y
  Show dependency treegraph
Reported: 2007-01-31 12:28 PST by Aaron Leventhal
Modified: 2015-12-16 09:51 PST (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Aaron Leventhal 2007-01-31 12:28:34 PST
For the actual API see

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

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.
Comment 1 User image David Bolter [:davidb] 2009-06-16 11:47:09 PDT
Mass un-assigning bugs assigned to Aaron.
Comment 2 User image Trevor Saunders (:tbsaunde) 2011-11-01 07:37:40 PDT
we support this api
Comment 3 User image alexander :surkov 2011-11-20 19:35:20 PST
(In reply to Trevor Saunders (:tbsaunde) from comment #2)
> we support this api

we support but aren't free from IA2 specific bugs (see unfixed blockings), it's good to keep meta for this
Comment 4 User image Raj Patil 2013-12-25 05:53:39 PST
I have a question about IAccessible2 support in Firefox and any NPAPI based add-on/plug-in which also support this interface. Right now, as we have seen, when you hover over this plug-in, firefox is returning "embedded Object" as a response back, and doesn't give a chance to the underlying application.  Any way to tell Firefox that the plug-in supports IA2 and let it take care of sending control information?
Comment 5 User image alexander :surkov 2013-12-27 06:10:45 PST
I should say the bug is not right place to ask generic questions, you need to do to this at mail list like Plugins implement accessibility itself by answering WM_GETOBJECT message (windowless plugin are not accessible).

Note You need to log in before you can comment on or make changes to this bug.