Mozilla Plugin Accessibility 编辑
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 |
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论