NPAPI:NativeAccessibility: Difference between revisions

← Older edit

NPAPI:NativeAccessibility (view source)

Revision as of 18:04, 28 April 2010

1,071 bytes removed , 28 April 2010

no edit summary

Josh

Confirmed users, Bureaucrats and Sysops emeriti

1,680

edits

@@ Line 1: / Line 1: @@
 = 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 =
@@ Line 16: / Line 14: @@
 * '''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 =
@@ Line 33: / Line 32: @@
 '''NPAPI Native Accessibility Support for Linux'''
-* Last modified: Oct 8, 2009
+* Last modified: Apr 28, 2010
 * Author: Brad Taylor, Novell, Inc.
 * Contributors:
@@ Line 41: / Line 40: @@
 ''NOTE'': This approach should be extensible to other accessibility frameworks, e.g.: windowless Windows plugins or OS X Accessibility.
-==== In Process Plugins ====
+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.
-When a plugin's accessible is requested from an assistive technology, or when the plugin is first created (depending on implementation), the web browser should call the <tt>NPN_GetValue</tt> method, passing <tt>NPNVNativeAccessibleAtk</tt> as the <tt>variable</tt> parameter.
-If the plugin sets <tt>value</tt> to <tt>NULL</tt>, the browser should use an empty accessible to represent the plugin.
-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.
-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.
-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.
-==== 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, we utilize the AT-SPI registry to coalesce accessibiles from the two processes. 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 from different processes in a manner that is transparent to ATs.
-In this example, the browser would create an <tt>AtkSocket</tt> object, and place it in the plugin's spot on the accessibility hierarchy in the main process.  The plugin's out of process host would then call <tt>NPN_GetValue</tt> with <tt>NPNVNativeAccessibleAtkPlugId</tt> as the <tt>variable</tt> parameter.
+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.
 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.
-A valid return value would be remoted to the main browser process, 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 seamless for the browser.
+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.
 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.
@@ Line 65: / Line 52: @@
 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.
-''NOTE'': The proposed addition to ATK is not yet available, and slated for completion in Q1 2010.
+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.