26
edits
BradTaylor (talk | contribs) (Slight rewording) |
BradTaylor (talk | contribs) |
||
Line 27: | Line 27: | ||
* Author: Brad Taylor, Novell, Inc. | * Author: Brad Taylor, Novell, Inc. | ||
* Contributors: | * 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 <tt>NPN_GetValue</tt> method, passing <tt>NPNVNativeAccessible</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 the base type of the native accessibility toolkit, and insert the object into the accessibility hierarchy as a child of the plugin's DOM parent. | |||
If the accessibility toolkit supports reference counting, the plugin accessible's reference should be incremented right after the call to <tt>NPN_GetValue</tt>, and decremented when the plugin is freed. If the accessible object provided is a pointer, the value ''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. |
edits