MozillaWiki

NPAPI:NativeAccessibility: Difference between revisions

(Add OOP requirement)
No edit summary
 
(15 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Status =
= Status =


Under consideration.
Accepted. No NPAPI version number.
 
Currently stalled due to uncertainty about whether enough browsers will implement when plugins are out-of-process.


= Problem Summary =
= Problem Summary =
Line 16: Line 14:
* '''Document Object Model (DOM)''' - a in-memory tree representation of the content of a web page.
* '''Document Object Model (DOM)''' - a in-memory tree representation of the content of a web page.
* '''Interprocess Communication (IPC)''' - a way of communicating betweenthread and process boundaries.
* '''Interprocess Communication (IPC)''' - a way of communicating betweenthread and process boundaries.
* '''Plugin Host''' - in an out of process situation, the code which bootstraps the plugin inside of a separate process than the browser.  In an in process situation, this code resides in the main process.


= Related Approaches =
= Related Approaches =
Line 33: Line 32:
'''NPAPI Native Accessibility Support for Linux'''
'''NPAPI Native Accessibility Support for Linux'''


* Last modified: June 26, 2009
* Last modified: Apr 28, 2010
* Author: Brad Taylor, Novell, Inc.
* Author: Brad Taylor, Novell, Inc.
* Contributors:
* Contributors:
Line 39: Line 38:
Plugins have the need to provide accessibility support to the browser so they can be accessed by assistive technologies like screen readers and testing tools.  Most common web browsers already provide an accessible implementation of DOM content, but thus far, can only export a blank (and therefore useless) object when it comes across a plugin.
Plugins have the need to provide accessibility support to the browser so they can be accessed by assistive technologies like screen readers and testing tools.  Most common web browsers already provide an accessible implementation of DOM content, but thus far, can only export a blank (and therefore useless) object when it comes across a plugin.


When a plugin's accessible is requested from an assistive technology, or when the plugin is first created, the web browser should call the <tt>NPN_GetValue</tt> method, passing <tt>NPNVNativeAccessibleAtk</tt> as the <tt>variable</tt> parameter.
''NOTE'': This approach should be extensible to other accessibility frameworks, e.g.: windowless Windows plugins or OS X Accessibility.
 
To allow plugins to provide their own accessibility support in both in process (IP) and out of process (OOP) scenarios, we leverage the AT-SPI registry to coalesce accessibiles from the browser and the plugin. Two corresponding objects are involved in this process in ATK, namely <tt>AtkPlug</tt> and <tt>AtkSocket</tt>.  Together, they are used to connect accessibility hierarchies in a manner that is transparent to ATs.  These APIs work both for accessibles in the same process, as well as accessibles in different processes.


If the plugin sets <tt>value</tt> to <tt>NULL</tt>, the browser should use an empty accessible to represent the plugin.
In this example, the browser would create an <tt>AtkSocket</tt> object, and place it in the plugin's spot on the accessibility hierarchy.  The plugin's host would then call <tt>NPP_GetValue</tt> with <tt>NPPVpluginNativeAccessibleAtkPlugId</tt> (with value 19) as the <tt>variable</tt> parameter.


If <tt>value</tt> is not <tt>NULL</tt>, the browser should cast it to an [http://library.gnome.org/devel/atk/unstable/AtkObject.html AtkObject], and insert the object into the accessibility hierarchy as a child of the plugin's DOM parent.
Compatible plugins would return the value of <tt>atk_plug_get_id()</tt> (a <tt>char*</tt>), or <tt>NULL</tt> indicating that they do not provide remote accessibility support.


The plugin's accessible reference should be incremented (via <tt>atk_object_ref</tt>) right after the call to <tt>NPN_GetValue</tt>, and decremented (via <tt>atk_object_unref</tt>) when the plugin is freed.  The accessible provided ''should not'' be copied to ensure that the plugin can maintain the state of the plugin object.
A valid return value would be remoted (in an OOP scenario), or returned to the browser (in an IP scheme), and used to attach the plug to the socket via <tt>atk_socket_embed()</tt>.  The connection that is established via AT-SPI and atk-bridge in the background should be not only transparent to ATs, but be seamless for the browser.


This accessible does not need to be updated, so the browser may cache the object for the life of the plugin.  Plugins that need to regularly remove and re-add their root accessible object should return a container-type object from <tt>NPN_GetValue</tt> and make their root accessible a child of the container.
Vendors are expected to use <tt>g_object_ref</tt> and <tt>g_object_unref</tt> as normal to manage the lifecycle of plugs and sockets.


''NOTE'': This approach should be extensible to other accessibility frameworks, e.g.: windowless Windows plugins or OS X Accessibility.
A detailed description of the mechanics of this API in the Linux accessibility stack is available on the [http://mail.gnome.org/archives/gnome-accessibility-devel/2009-September/msg00012.html gnome-accessibility-devel] mailing list.


= Implementation Recommendations =
The new AtkPlug and AtkSocket API is now available in ATK 1.30 and AT-SPI2 0.1.3.  It will be shipped as the default accessibility toolkit by distributions which ship GNOME 3.0.
=== Out-of-process Plugins ===
Since accessibility objects are living objects, they cannot be simply serialized over an IPC between the plugin process and the browser process. Instead, implementors should create proxy objects that wrap methods on the plugin's accessible, and remote the calls over IPC.

Latest revision as of 18:04, 28 April 2010

Status

Accepted. No NPAPI version number.

Problem Summary

Plugins cannot currently provide accessible information about their contents on Linux platforms. This is Mozilla bug 78414.

Glossary

  • Accessibility - the degree to which a product is accessible by as many people as possible.
  • Assistive Technology (AT) - a piece of software or hardware that connects to the system's accessibility services to provide assistance to the user. This assistance can come in the form of a head tracking system for a user unable to use a mouse, a screen reader for a person with vision impairments, etc.
  • Microsoft Active Accessibility (MSAA) - the standard accessibility API for Windows 95 through Windows XP. Accessible objects in MSAA inherit from the IAccessible interface.
  • Accessibility Toolkit (ATK) - the standard accessibility API on Linux.
  • Document Object Model (DOM) - a in-memory tree representation of the content of a web page.
  • Interprocess Communication (IPC) - a way of communicating betweenthread and process boundaries.
  • Plugin Host - in an out of process situation, the code which bootstraps the plugin inside of a separate process than the browser. In an in process situation, this code resides in the main process.

Related Approaches

On Windows, plugins can provide their own accessibility support by responding to the WM_GETOBJECT WinEvent and returning an instance of IAccessible. Firefox (and other browsers) will call this WinEvent on the plugin object and if an IAccessible is returned, register the accessible into the accessibility hierarchy.

API Requirements

  • Plugins should be able to easily provide an accessible implementation (in ATK) to the Browser
  • The Browser should inject the plugin's accessible into its accessible hierarchy
  • The lifetime of the plugin's accessible should be the same as the lifetime of the plugin.
  • Browsers should be able to implement this specification for both in-process as well as out-of-process plugins.

Current Proposal

Specification

NPAPI Native Accessibility Support for Linux

  • Last modified: Apr 28, 2010
  • Author: Brad Taylor, Novell, Inc.
  • Contributors:

Plugins have the need to provide accessibility support to the browser so they can be accessed by assistive technologies like screen readers and testing tools. Most common web browsers already provide an accessible implementation of DOM content, but thus far, can only export a blank (and therefore useless) object when it comes across a plugin.

NOTE: This approach should be extensible to other accessibility frameworks, e.g.: windowless Windows plugins or OS X Accessibility.

To allow plugins to provide their own accessibility support in both in process (IP) and out of process (OOP) scenarios, we leverage the AT-SPI registry to coalesce accessibiles from the browser and the plugin. Two corresponding objects are involved in this process in ATK, namely AtkPlug and AtkSocket. Together, they are used to connect accessibility hierarchies in a manner that is transparent to ATs. These APIs work both for accessibles in the same process, as well as accessibles in different processes.

In this example, the browser would create an AtkSocket object, and place it in the plugin's spot on the accessibility hierarchy. The plugin's host would then call NPP_GetValue with NPPVpluginNativeAccessibleAtkPlugId (with value 19) as the variable parameter.

Compatible plugins would return the value of atk_plug_get_id() (a char*), or NULL indicating that they do not provide remote accessibility support.

A valid return value would be remoted (in an OOP scenario), or returned to the browser (in an IP scheme), and used to attach the plug to the socket via atk_socket_embed(). The connection that is established via AT-SPI and atk-bridge in the background should be not only transparent to ATs, but be seamless for the browser.

Vendors are expected to use g_object_ref and g_object_unref as normal to manage the lifecycle of plugs and sockets.

A detailed description of the mechanics of this API in the Linux accessibility stack is available on the gnome-accessibility-devel mailing list.

The new AtkPlug and AtkSocket API is now available in ATK 1.30 and AT-SPI2 0.1.3. It will be shipped as the default accessibility toolkit by distributions which ship GNOME 3.0.

Retrieved from "https://wiki.allizom.org/index.php?title=NPAPI:NativeAccessibility&oldid=219132"