Accessibility/Plugins: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(New page: <small><< Back to Accessibility Home Page</small> =Introduction= This page is designed to provide draft specification of Mozilla plugins accessibility. In the meantime...)
 
 
(12 intermediate revisions by the same user not shown)
Line 3: Line 3:
=Introduction=
=Introduction=


This page is designed to provide draft specification of Mozilla plugins accessibility. In the meantime plugins authors are forced to care about accessibility itself. They need to implement AT API interfaces for UI interfaces used in their plugins for each platform plugins are intended to work. That means if plugin is assumed to be supported on all platform Mozilla works on then plugin authors must implement MSAA/IA2 on Windows, AT/AT-SPI on Linux, Universal Access on OS X. So it's getting hard to share common accessibility code between platforms, need to learn different APIs for each platform. This article subject is getting specification to allow plugin authors to embed their plugins into accessibility hierarchy and write common accessibility code for each platform the plugin is indented to work on.
===What is this?===
 
This page is designed to provide specification for [https://developer.mozilla.org/en/Plugins 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
Benefits are
Line 12: Line 20:
* learning specific Mozilla accessibility API
* learning specific Mozilla accessibility API


=Implementation=
=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).
 
<pre>
NPError NPN_GetPluginAccessible(NPP aInstance, nsIAccessibleTreeNode **aNode);
</pre>
 
The returned accessible object implements <code>nsIAccessibleTreeNode</code> interface used to set up the first child of obtained accessible object.
 
<pre>
interface nsIAccessibleTreeNode : public nsISupports
{
  setFirstChild(nsIAccessible *aNode);
};
</pre>
 
The proposed first child accessible must implement <code>nsIAccessible</code> interface.
 
==Implementation notes==
Embedding into existing Mozilla accessibility tree is the initial step of the specification implementation. We have two ways.
 
* Plugin SKD contains cross platform classes and interfaces intended to create accessible objects for plugin needs. As well plugin author is happy to use them.
* Plugin author wants to embed plugin accessible tree into existing Mozilla hierarchy but he doesn't want to use Plugin SDK to create his accessibles (or plugin SDK doesn't address this).
 
The problem of second choice is in the meantime accessible used as first child of plugin accessible must implement couple of interfaces additionally, including <code>nsIAccessNode</code>, few private interfaces plus be inherited from nsAccessible/nsAccessNode. We need to do big work to isolate navigation methods of <code>nsIAccessile</code> from rest code. As well we should get rid methods failures of accessible from existing tree if these methods make assumptions about interface support of plugin accessibles.
 
=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.
 
<pre>
class npnAccessible : public nsIAccessible {};
</pre>
 
<pre>
class npnTextAccessible : public npnAccessible,
                          public nsIAccessibleText,
                          public nsIAccessibleEditableText {};
</pre>
 
<pre>
class npnDocAccessible : public npnTextAccessible,
                        public nsIAccessibleDocument
</pre>
 
===Interfaces===


== Embedding plugin hierarchy to Mozilla hierarchy ==
Here's the list of interfaces you might want to implement in your accessible objects.


Extend plugin API to provide accessible object implementing nsIAccessible interfaces created for element embedding the plugin.
* [https://developer.mozilla.org/en/nsIAccessible nsIAccessible]
* [https://developer.mozilla.org/en/nsIAccessibleDocument nsIAccessibleDocument]
* [https://developer.mozilla.org/en/nsIAccessibleEditableText nsIAccessibleEditableText]
* [https://developer.mozilla.org/en/nsIAccessibleHyperLink nsIAccessibleHyperLink]
* [https://developer.mozilla.org/en/nsIAccessibleHyperText nsIAccessibleHyperText]
* [https://developer.mozilla.org/en/nsIAccessibleImage nsIAccessibleImage]
* [https://developer.mozilla.org/en/nsIAccessibleSelectable nsIAccessibleSelectable]
* [https://developer.mozilla.org/en/nsIAccessibleTable nsIAccessibleTable]
* [https://developer.mozilla.org/en/nsIAccessibleText nsIAccessibleText]
* [https://developer.mozilla.org/en/nsIAccessibleValue nsIAccessibleValue]


<code>
=Implementation Notes=
NPError NS?_GetPluginAccessible(NPP aInstance, nsIAccessible **aAccessible);
</code>

Latest revision as of 09:32, 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.

Implementation notes

Embedding into existing Mozilla accessibility tree is the initial step of the specification implementation. We have two ways.

  • Plugin SKD contains cross platform classes and interfaces intended to create accessible objects for plugin needs. As well plugin author is happy to use them.
  • Plugin author wants to embed plugin accessible tree into existing Mozilla hierarchy but he doesn't want to use Plugin SDK to create his accessibles (or plugin SDK doesn't address this).

The problem of second choice is in the meantime accessible used as first child of plugin accessible must implement couple of interfaces additionally, including nsIAccessNode, few private interfaces plus be inherited from nsAccessible/nsAccessNode. We need to do big work to isolate navigation methods of nsIAccessile from rest code. As well we should get rid methods failures of accessible from existing tree if these methods make assumptions about interface support of plugin accessibles.

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