Accessibility/Plugins: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 24: Line 24:
Every plugin having UI should embed its accessible tree into existing accessible objects hierarchy of Mozilla.
Every plugin having UI should embed its accessible tree into existing accessible objects hierarchy of Mozilla.


First of all plugin should obtain accessible object created for plugin host element (like html:object) by the following method
Plugin SDK is extended with the helper method used to get accessible object created for plugin host element (like html:object).


<code>
<pre>
NPError NPN_GetPluginAccessible(NPP aInstance, nsIAccessibleTreeNode **aNode);
NPError NPN_GetPluginAccessible(NPP aInstance, nsIAccessibleTreeNode **aNode);
</code>
</pre>


where
The returned accessible object implements <code>nsIAccessibleTreeNode</code> interface used to set up the first child of obtained accessible object.


<pre>
<pre>
Line 39: Line 39:
</pre>
</pre>


and then set up the first child for the obtained accessible object.
The proposed first child accessible must implement <code>nsIAccessible</code> interface.


=Crossplatfrom accessibility code=
=Crossplatfrom accessibility code=

Revision as of 09:06, 2 March 2009

<< Back to Accessibility Home Page

Introduction

What is this?

This page is designed to provide specification for Mozilla plugins accessibility. This specification is intended to introduce the approach how to make plugin's UI accessible with the help of internal Mozilla accessibility API. Implementation of this specification results in extension of Plugin SDK, we refer to as A11y Plugin SDK.

Why is it necessary?

In the meantime plugins authors are forced to care about accessibility itself. They need to implement AT API interfaces for UI interfaces of their plugins for each platform plugins are intended to work. That means plugin authors must implement MSAA/IA2 on Windows, AT/AT-SPI on Linux, Universal Access on OS X. So plugin authors need to learn different APIs for each platform and it's getting hard to share common accessibility code between platforms. As well even plugin author cares about accessibility itself he doesn't have a way to embed accessible tree of plugin's UI interface into accessible tree of Firefox (or any other Mozilla product).

What do we get?

The article subject is getting specification to allow plugin authors to embed their plugins into accessibility hierarchy of Mozilla products and write common (platform independent) code for his plugins.

Benefits are

  • plugins are embedded into Mozilla accessibility hierarchy
  • plugins have crossplatform accessibility code

Disadvantages are

  • learning specific Mozilla accessibility API

Embedding into Mozilla accessible tree

Every plugin having UI should embed its accessible tree into existing accessible objects hierarchy of Mozilla.

Plugin SDK is extended with the helper method used to get accessible object created for plugin host element (like html:object).

NPError NPN_GetPluginAccessible(NPP aInstance, nsIAccessibleTreeNode **aNode);

The returned accessible object implements nsIAccessibleTreeNode interface used to set up the first child of obtained accessible object.

interface nsIAccessibleTreeNode : public nsISupports
{
  setFirstChild(nsIAccessible *aNode);
};

The proposed first child accessible must implement nsIAccessible interface.

Crossplatfrom accessibility code

Base classes

Plugin SDK provides set of accessible base classes. You can inherit your accessible classes from these base classes to get some accessible functionality for free.

In the meantime there are available two base accessible classes. The set of base classes can be extended on demand.

class npnAccessible : public nsIAccessible {};
class npnTextAccessible : public npnAccessible,
                          public nsIAccessibleText,
                          public nsIAccessibleEditableText {};
class npnDocAccessible : public npnTextAccessible,
                         public nsIAccessibleDocument

Interfaces

Here's the list of interfaces you might want to implement in your accessible objects.

Implementation Notes