For the actual API see http://www.linux-foundation.org/en/Accessibility/IAccessible2 ** 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.

Mass un-assigning bugs assigned to Aaron.

we support this api

(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

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?

I should say the bug is not right place to ask generic questions, you need to do to this at mail list like https://lists.mozilla.org/listinfo/accessibility. Plugins implement accessibility itself by answering WM_GETOBJECT message (windowless plugin are not accessible).