Accessibility/Projects
Mozilla Accessibility Projects and Grants
Mozilla accessibility has come a long way since the release of Firefox 1.5. We now have support from the two largest screen readers (JAWS and Window-Eyes), as well as the industry's first DHTML and AJAX accessibility support. Our keyboard support is mostly complete, although there are a couple of important issues.
So what remains to be done? The following is a list of standalone accessibility projects that can be attempted by a single person or group.
In many cases, Mozilla Foundation grants can be received for doing work in these areas.
Note: where possible, our project strategies should be in sync with our long term goals:
- Support for standards
- Develop solutions in open source
- Section 508 compliance, which allows U.S. government procurement (see our VPAT compliance statement, which has some open issues remaining)
- Involve the wider open source community in accessible software development (documenting, educating and evangelizing may be necessary)
- Get end user and industry uptake. It is often more beneficial to get our accessibility features adopted by the end user in existing products, rather than create new extensions or software modules.
- Support cross platform accessibility
- Develop the documentation, tools and infrastructure so that users with disabilities themselves are encouraged to get involved in the open source process
| Project | Description | Notes |
|---|---|---|
| 1. Website a11y evangelism tool | Turn the Firefox "Broken Website Reporter" tool and evangelism teams into a force for web accessibility. In Firefox 3, Disability access will be added to the list of website issues. Hook up existing interested parties in web accessibility to the tool and online database at reporter.mozilla.org. Start the community moving in the direction of using these statistics to improve a11y on the web. | Good project to help unify the industry which already spends a lot of resources in different ways to evangelize web accessibility. Requires a self-starter with communication and leadership skills. |
| 2. DHTML accessibility tooling |
Add support for DHTML/AJAX accessibility to an existing open source widget library, framework or authoring tool for creating web applications. |
DHTML accessibility is a breakthrough technology that allows accessibility of web applications written with DHTML and/or AJAX. We're looking to get more industry adoption, but this is currently considered a technology with a lot of promise, with the ability to release the creativity of web developers for Web 2.0, while maintaining or even increasing the level accessibility we've had with static HTML. |
| 3. Killer App using DHTML accessibility |
Use DHTML/AJAX accessibility to create a powerful open source web application that shows off its capabilities, thus helping evangelize the future of accessibility |
Potential apps: web mail, web calendar, an MSDN-style reference guide with a tree view |
| 4. Support users with learning and cognitive disabilities | Analyze a variety of end user types and discover problems which may require changes to the Firefox UI, new accessibility preferences, or new Firefox extensions which allow configuration to modify the UI. |
Requires creativity, insight, and involvement in the Firefox toolkit (XUL + JS + CSS) |
| 5. Development tool accessibility | Identify gaps in the accessibility of the Mozilla software development process and fix them. Find and work with developers with disabilities interested in using these tools and make the process work for them. |
Unless the tools and process used by the open source community are accessible, then we will never really fix the long term problems. Examples of tools: irc.mozilla.org, Bugzilla, Tinderbox, LXR, Bonsai, cygwin, Talkback, Wikis, JavaScript console, DOM Inspector and the Venkman JavaScript debugger. |
| 6. Architectural Review of Mozilla Accessibility | Review mozilla/accessible code with an eye to finding it's key flaws | Output would include better documentation of the architecture, bugs to be filed, and potentially an follow-up grant to fix problems found. |
| 7. XUL authoring environment a11y | Ensure that XUL authoring environments under development are accessible and produce accessible UI's. |
It's not clear whether current XUL authoring environments are on the track to adoption. If they are, then they certainly need to address a11y. We need to take a look at Verbosio and other solutions under development. |
| 8. Sunbird accessibility |
Analyze accessibility problems with Sunbird Calendar client and look to solve problems within core Gecko a11y module or in Sunbird XUL front end, or by driving Sunbird or assistive technology developers. |
Calendar apps require a high degree of keyboard navigation tweaks and typically involve many custom widgets that are not accessible out of the box. The benefit is high. Currently users with disabilities are pushed to MS Outlook. An opportunity to get involved with a great project closer to the beginning, rather than tacking a11y on at the end. A VPAT for section 508 compliance should be published. |
| 9. Firefox with voice input on Linux | Hook up open source voice input engines to work well with Firefox | Need info on what voice input engines work well on Linux, and whether any command and control or dictation software even exists for the desktop. Perhaps could share some code with onscreen keyboard tools, for UI grabbing. |
| 10. Screen reader compatibility on Linux | Work on top-notch screen reader support for Firefox on Linux | Starting points: LSR or Orca |
| 11. Screen magnifcation compatibility on Linux | Work on top-notch screen magnifier support for Firefox on Linux | Starting points: gnome-mag or gscope magnifiers |
| 12. Accessibility scripting on a per-website basis |
Create a front end layer on top of GreaseMonkey or another engine for users with disabilities to help with common accessibility problems on popular web sites. Find or create a good location for these scripts so that as many users can benefit as possible. |
We can't expect end users to create actual GreaseMonkey scripts, so a UI layer on top which simplifies accessibility script writing would be useful. However, it should be possible to write the raw script as well. The more we can get people to share these the more useful they are. |
| 13. Web page simplification and repair. | Implement a heuristic to remove or toggle the presence of navigation bars and other structures that are identical within a given website. Take alt text repair patch the final mile (merge with trunk, get reviews and get it checked in). |
Improves the effectiveness of users who are blind, visually impaired, have motor impairments and learning disabilities by removing unneeded cruft from web pages. Less content to read, navigate through or get confused by. Possible implementation strategies: create a Firefox plugin, extension or Grease Monkey script that compares pages on the same website (and possibly remembers the results). May need to be able to crawl a page looking for links to similar content. See bug 277469 for a starter patch to repair missing text equivalents. |
| 14. W3C UAAG compliance |
Do whatever is needed to bring Firefox to the highest level of UAAG compliance possible/sensible. Work with any groups and Universities with the same goal (such as UIUC). |
Get involved in W3C standards. IBM will provide an analysis of the UAAG gaps in Firefox. This item may be broken up into several items depending on the complexity of each resulting task. |
| 15. Chatzilla accessibility |
Get involved in the Chatzilla project and implement accessibility support for it |
Chat rooms are not easy to use with a screen reader today. This may involve creativity in terms of developing simple yet powerful filtering options to enable following only the conversation the user is interested in. IRC is a crucial means of getting information about open source development. |
| 16. Gnome- and Linux- related projects |
Please visit the Gnome accessibility projects list. |
Accessibility on the Linux desktop is evolving quickly but there is tons of work to do! Many applications and assistive technologies need development. |
