NPAPI:NativeAccessibility: Difference between revisions

no edit summary
No edit summary
Line 39: Line 39:
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.
==== In Process Plugins ====
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 the plugin sets <tt>value</tt> to <tt>NULL</tt>, the browser should use an empty accessible to represent the plugin.
Line 49: Line 50:
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.
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.


''NOTE'': This approach should be extensible to other accessibility frameworks, e.g.: windowless Windows plugins or OS X Accessibility.
==== 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. The two corresponding objects involved in this process using ATK are <tt>AtkPlug</tt> and <tt>AtkSocket</tt>.  Together, they are used to connect accessibility hierarchies from two 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. The plugin's out of process host would then call <tt>NPN_GetValue</tt> with <tt>NPNVNativeAccessibleAtkPlugId</tt> 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 can 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 should be not only transparent to ATs, but 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.


= Implementation Recommendations =
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.  It is slated to be complete by Q1 2010.
=== 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 can take one of two paths:


* Use the <tt>AtkPlug</tt> and <tt>AtkSocket</tt> objects to remote accessibles across process boundaries.  Briefly -- the browser would create an <tt>AtkSocket</tt> object, and place it in the plugin's spot on the accessibility hierarchy.  The browser would then call <tt>NPN_GetValue</tt> with <tt>NPNVNativeAccessibleAtkPlugId</tt> as the variable parameter.  Compatible plugins would return the value of <tt>atk_plug_get_id()</tt> (a <tt>char*</tt>) which can be used to attach the plug to the socket using <tt>atk_socket_embed()</tt>.  A detailed description of the mechanics of this API is available on the [http://mail.gnome.org/archives/gnome-accessibility-devel/2009-September/msg00012.html gnome-accessibility-devel] mailing list.  It is slated to be complete by Q1 2010.
''NOTE'': This approach should be extensible to other accessibility frameworks, e.g.: windowless Windows plugins or OS X Accessibility.
* Create proxy objects that wrap methods on the plugin's accessible, and remote the calls over IPC. This requires that the browser have a custom remoting implementation for Atk objects. Vendors may already have designed such a system for accessibility support of out of process pages/tabs.  As this is a large amount of implementation effort, this is not a recommended method.
26

edits