NPAPI:NativeAccessibility

Status

Under consideration.

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.

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.

Current Proposal

Specification

NPAPI Native Accessibility Support for Linux

• Last modified: June 26, 2009
• 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.

When a plugin's accessible is requested from an assistive technology, or when the plugin is first created, the web browser should call the NPN_GetValue method, passing NPNVNativeAccessibleAtk as the variable parameter.

If the plugin sets value to NULL, the browser should use an empty accessible to represent the plugin.

If value is not NULL, the browser should cast it to an AtkObject, and insert the object into the accessibility hierarchy as a child of the plugin's DOM parent.

The plugin's accessible reference should be incremented (via atk_object_ref) right after the call to NPN_GetValue, and decremented (via atk_object_unref) 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.

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 NPN_GetValue and make their root accessible a child of the container.

Implementation Recommendations

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.