26
edits
BradTaylor (talk | contribs) |
BradTaylor (talk | contribs) 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. | ||
==== 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. | |||
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. | |||
''NOTE'': This approach should be extensible to other accessibility frameworks, e.g.: windowless Windows plugins or OS X Accessibility. | |||
edits