Plugins in Gecko-based browsers have a lot of accessibility issues. Here is a rundown of problems and the planned solutions:
New! See the plugin keyboard navigation proposal to see how the largest problems can be solved.
| Problem | Planned solution | Owner | Targeted completion |
|---|---|---|---|
| 1. All browser keys unavailable when plugin has focus | Focused plugins currently have no choice but to consume all keyboard events. The new plugin API will allow plugins to bubble unused keypresses to the browser. This will allow keyboard users to still access menus, close the current page, scroll, move back and forward in history, etc. If the plugin needs those keystrokes, the can consume them and not pass them on. See the plugin keyboard navigation proposal for the implementation plan. The same solution will be used for Bug 140566 (full page plugins) and Bug 78414 (partial page plugins), as well as the Linux-specific bug 84159 and Mac-specific bug 180426. | ? | No target |
| 2. Focus gets stuck in plugin. User cannot keyboard navigate out of a plugin | We will apply the same solution as in problem 4 above. The plugin will be responsible for bubbling up shift+tab and tab when the user has reached the end of the tab cycle within the plugin. The bug tracking this work is bug 93149. | ? | No target |
| 3. Many plugins lack accessibility API support | Most plugins that work with Mozilla do not yet support accessibility APIs. A notable acception is the Adobe PDF plugin on Windows, which supports MSAA. In other cases, vendors need to find or be convinced of the business justification so that resources are applied to the problem. | Plugin vendors. | Unknown |
| 4. Seamonkey has no message bar for plugin installation | The message bar will be ported to Seamonkey as part of the toolkit merging work that will occur for xulrunner. | Mozilla community | No target |
Document Tags and Contributors
Last updated by:
openjck,