Bite Size projects for open accessibility

The open accessibility community is growing all the time.

An ecosystem of successful projects is developing, yet there are still many ways to have a big impact without getting pulled into a giant codebase.

For practical idealists, open a11y provides an opportunity to help bridge the technology divide and help a lot of people get a leg up. There are a lot of interesting people to work with and you can get the sense of how a real open community works by starting small. It’s a good feeling.

Here are some bite-size projects that need owners:

Enhance WebVisum

The WebVisum extension for Firefox is one of the only unique “killer” features for Firefox accessibility that impact screen reader users directly in a big way today. Among other things, it does OCR and solves captchas. It also lets users share accessibility repairs across web pages. For example, if one user labels an image the others all get that same fix when they load the page.

There is an endless list of possibilities when you have a whole community of users connected to each other. Unfortunately, the WebVisum team is stretched thin (they also have a lot of server-side work), and the extension itself could use some love.

Or, if you want to help WebVisum in a way that involves more hardcore coding, help improve the open source Tesseract OCR and the results it provides for web images.  The quality is not high enough yet. Compare that with the very expensive ABBYY FineReader, which works really great, even on web images.

If you’re interested, contact WebVisum via, or find supastuff on #accessibility.

Degree of difficulty: medium (it’s just Firefox extension coding, although the challenge is really as high as the killer ideas you can come up with). Note, WebVisum is planning to GPL the extension soon, but they need to finish up this process.

Help set up

When I try to put myself in the shoes of a developer new not to just WAI-ARIA, but perhaps to accessibility as well, it’s a bit frightening. We’re lucky if developers even find WAI-ARIA. For example, if you do a web search for “AJAX accessibility” or “Web 2.0 accessibility”, you get mostly older articles which talk about how it’s not possible. This is not true — Firefox has been shiping WAI-ARIA support since version 1.5. WebKit, IE and Opera are all adding support to upcoming releases.

As an author, there’s almost nothing to help me. What training materials are there other than some scattered examples and articles across the web? How do I know when I did it right

The site is intended to be a one-stop, vendor-neutral resource for developers looking at Web 2.0 accessibility. Right now it’s darn ugly and lacking content. We need someone who can drive change yet involve the entire free-aria community in putting something together.

Degree of difficulty: medium (WAI-ARIA is not simple to understand, it’s a complex disconnected ecosystem and we need to bring it together)

Killer WAI-ARIA apps

It’s great that WAI-ARIA is picking up steam, but thus far most users haven’t really noticed the difference.  This is because only a few high visibility applications are starting to support it.
Some fairly simple things can be done to large, popular open source projects which lots of users will end up seeing if they use Firefox. As an example, Marco Zehe recently added some nice WAI-ARIA support to the commenting form. Please read his easy ARIA tips and pepper you forms with aria-required, aria-invalid, and the alert role. Having some client side validation in addition to traditional server-based validation will make your forms more usable in general.

For a bigger challenge, look at some of the hard-core open source web apps out there. If I was a computer science student looking for an accessibility project that could end up in a job, I would seriously think about hacking WAI-ARIA into a Google app.
Degree of difficulty: medium

Assistive technology development

Certainly the open source screen readers Orca (Linux) and NVDA (Windows) provide many possibilities to innovate on how blind users access the web. Both of these projects are on solid footing but a lot more can be done. They’re both written in Python although NVDA uses some C++.

There is also Jambu, another Python-based AT which is a project that intends to develop a next generation tool for people with who can’t use a computer keyboard.  — the idea is to get the onscreen keyboard out of the way as much as possible, and let people interact directly with the UI. Jambu could definitely use some love at the moment! Why should tools for people with physical disabilities be generations behind what people with visual impairments have?

Another important area is the development of a good Linux tool for people with low vision.
Degree of difficulty:: high — AT programming is a generally a very delicate matter. Both application and platform-specifics have an impact on the design.

Firefox extension lovefest

There are at least 5900 Firefox extensions on alone. This isn’t counting many addons found out on the web. Many of them are accessible or provide great features for people with disabilities, but users don’t know about them. Others have great potential but have important accessibility issues.
A great project would be to go through the most popular extensions and:

  1. Test & provide a11y feedback to the developers on a11y issues. Are they even keyboard navigable? Do they work with a screen reader? Help developers understand the XUL accessibility guidelines and the most common accessibility issues in extensions.
  2. For important extensions where the developers do not respond, write a patch to fix them
  3. Prod Mozilla to use Mark Finkle’s automated XUL validator (which includes a11y) as part of their review process, and run that on the extensions on addons now.
  4. Prod Mozilla to add a field to the addons database to describe the state of a11y for that addon, and get that filled in where possible. Allow users to enter that.
  5. Create an a11y category for addons, for those addons that are specifically targeted at accessibility (like Fire Vox, WebVisum, Accessibar)
  6. Write up the best a11y extensions for
  7. Help improve the XUL a11y guidelines and the XUL validator as you learn what the common mistakes are

Degree of difficulty: low to medium (but quite interesting and useful)

Firebug accessibility

Firebug is the tool for web app developers, but it’s not accessible! Tragic! We must fix that.
You’ll need to work in the Firebug codebase. There are people in the community currently looking at ways to add accessibility checking features to Firebug (e.g. help tag AJAX live regions with the aria-live property). Making Firebug accessibility and adding accessibility info to it will increase the number of developers that think about a11y issues a lot.

Degree of difficulty: low-medum

Want to Discuss?

Pop by #accessibility (I’m aaronlev, and many others in the community hang out there), or join the Mozilla accessibility mailing list.


One Response to Bite Size projects for open accessibility

  1. Olivier says:


    I like a lot the content and the spirit of this post. It was an awesome idea to begin with, showcasing examples of what people can do to make a difference. I bet there are many talented folks who are willing to help, but fail to find out how and where.

    If it helps, I would like to draw your attention to other similar opportunities:
    – Project:possibility (, a “nonprofit, community service project committed to creating groundbreaking open source software for persons with disabilities”
    – Social Accessibility Project (, that helps improving websites accessibility by building up a community of users and volunteers, very much like Webvisum does
    – The Helen Project ( which collects users comments about pages with accessibility issues
    – the works of Chris Heilmann around accessihacking, always inspiring and thought-provoking:
    – AccessMonkey ( which is “a framework for improving the accessibility of web pages after they have been published”


%d bloggers like this: