Recent happenings in accessibility-related projects financially supported by Mozilla

For several years now, Mozilla has funded varying projects in the field of accessibility development. Projects like Orca’s support for WAI-ARIA live regions, GNOME Accerciser, NVDA, or more recently, audio and video accessibility work and Firebug accessibility, are, in whole or in part, being funded by the Mozilla Foundation and other Mozilla resources to help fulfill the Mozilla manifesto and the Mozilla Accessibility Strategy.

Here’s a summary of what’s currently happening in Mozilla-funded accessibility-related projects. Most of these surfaced over the past quarter, or last half a year.

NVDA

In early August, it was announced that the Mozilla Foundation would renew its funding for the NVDA project. Mick posted a summary of the goals to the NVDA blog.

The project is well underway, en route to their 2009.1 release with improved support for WAI-ARIA landmarks, a totally revamped list of elements, support for 64 bit operating systems and much more!

Spearheaded by the Mozilla Foundation, who were the first to fund NVDA starting in 2007, Microsoft, Yahoo! and Adobe have since joined in supporting this open-source screen reader for Windows, offering a compelling alternative to commercially available assistive technologies on this platform.

For more news such as winning the Vision Australia Making A Difference award, check out their blog.

Audio and Video accessibility

Frank already detailled much of this in his blog post above, and Silvia Pfeiffer just recently published a progress report on the grant.

Silvia also gave me some demos to test, and if you use JAWS or NVDA or Orca, I suggest you try them out yourself to see how cool they are!

This work has the potential to involve a lot of volunteers in helping make more movies, songs, and other material accessible to a large number of people with varying disabilities. Talk about crowd-sourcing!

Firebug UI accessibility and the Firebug accessibility testing extension

There are currently two grants happening in regards to Firebug, the web development tool of choice for many thousand web workers.

One is the work the Paciello Group is doing to make the UI accessible. I posted about the Firebug 1.4 release already, but the work doesn’t stop there. The next alpha release of Firebug 1.5, 1.5xa25, will include accessibility of the net panel, a component that was still missing in 1.4. The documentation has already been updated with information on how this will work. I gave this a whirl this week using a custom build I received from Hans (the developer in charge), and it works as advertised! So keep your eyes on the Firebug release cycle to not miss this cool update!

The other portion is work the University of Illinois UIUC is doing to develop an extension that will allow web developers to test whether they’re using correct accessibility-compliant markup. The extension will honor the WCAG 2.0 guidelines and WAI-ARIA specifications. Development has started recently, and I will be testing an early version soon to see how it fares! Keep your eyes on this blog for more info as it becomes available!

Once this work is completed, Firebug will be a solution for web developers to do testing of accessible web pages with an accessible UI. It means that Mozilla will be able to offer, directly or indirectly, a full range of testing and usage tools starting from the browser itself, the screen reader, and the testing and development side, all in an open-source fashion, driving the accessible web standards effort forward in thus far uncharted territory.

So, let’s boldly go! 🙂

The current state of accessible Firefox on the Mac, your help is appreciated!

I’ve been asked time and time again about what the current state is of the possibility of an accessible Firefox on the Mac that interacts with the VoiceOver screen reader. Well, let me recap what the current affair is.

First of all, the bad news is that getting the remaining quirks out of Mac accessibility is not going to happen this or next quarters.

The main reason is that our code currently needs to be made ready for future enhancements. Our recent work on the IAccessibleTable2 interface showed us that painfully: The refactoring and reorganization needed took much longer than we had estimated and required us to touch much more code than we had hoped. We also have some nasty event firing problems that have been a pain in the neck for those ATs supporting us that we desperately need to attack these now.

However, the good news is that since early May, the accessibility unit tests (Mochitests) have been running mostly successfully on the Mac on both the mozilla-central and mozilla-1.9.2 branch tinderboxes. Those tests had been running successfully on Windows and Linux since December already. They’ve been intermittently showing some flakiness (what we call random orange) in especially the events area, which is what we’ll be working on in the immediate future anyway, but otherwise been quite stable.

On top of that, at least investigating and driving the Mac accessibility effort forward has been sort of a pet project of mine all the while, even though Mac a11y is no longer part of our team’s official goal set for this year.

What I’ve been doing is build Mac builds with accessibility enabled on my MacBook and test them whenever I had some cycles. On Mac OS X 10.5 (Leopard), VoiceOver and the Firefox builds played terribly together, with lots of sluggishness and delayed responses that made it impossible to get any really useful testing done.

This, however, has changed with Snow Leopard. Without consciously changing things on our end, a build done under Snow Leopard is much more responsive with VoiceOver. We’re nowhere near the good performance blind people have come to appreciate from Safari yet, but we’re doing much better now. Whether it’s the improved VoiceOver or the fact that we’re now building against the MacOS10.5 SDK, or both, I don’t know.

The following are what I’d consider the most pressing issues before we could even think about sending this off to a bunch of voluntary testers:

  • VoiceOver is not speaking most accessible roles of UI and web page elements. Strangely enough, when pressing a button, it will say “Press button” and the like.
  • VoiceOver skips over plain text on pages, and the text is also not visible in VoiceOver’s Obbject Chooser menu.
  • Other inconsistencies having to do with roles like VoiceOver not recognizing our HTML area as such and not automatically starting to read pages etc.
  • Performance problems: Right now, navigating from one element to the next takes about half a second, which is unacceptable.

And this is where you might be able to help us! Are you a developer who is fluent in Objective-C, and (as a bonus) versed in Apple’s accessibility APIs? We could use your voluntary help in trying to nail this down!

So if you’d like to help improve Firefox on the Mac and have an idea about what might be going on here, go grab the source and build it! In order for accessibility to be turned on, in addition to all the stuff you need to put into your MOZCONFIG file, you need to add the following line:

ac_add_options --enable-accessibility

With this exception, commence as described in our docs.

Once you’ve got Firefox built, you can press CMD+F5 to turn on VoiceOver. A friendly male voice named Alex will start talking to you immediately and give you feedback on your actions through your Mac’s speakers. CMD+F5 is a toggle, so the same keystroke will turn VoiceOver off and leave no trace of it having been active.

Once VoiceOver is running, the following is a list of hot keys that can be used to navigate. Note that VO refers to the VoiceOver modifier, which is both Ctrl and Option held down.

Key Description
VO+Arrows Navigate in all 4 directions. Left and Right from item to item sequentially.
VO+Shift+DownArrow Interact with the currently spoken item. Interacting is examining an item in more detail. For example, interacting with a table will expose the individual cells to VoiceOver and restrict navigation inside this container.
VO+Shift+UpArrow Stop interacting and return to the parent level of navigation.
VO+Space Press or activate the current item. This will perform the default action, which is usually identical to clicking the mouse.

More information is available on Apple’s accessibility site. A Key commands chart (PDF) will give you more keystrokes, and the linked-to bugs above will give exact steps to repro the bugs themselves.

Since Firefox is not a native COCOA application on the Mac in the sense that we implement all our UI elements ourselves, we have to expose the whole accessibility contract and are obviously doing some things wrong there. The initial work that was done was done by a Mozilla Foundation grantee back in 2006, but this project was never finished and the project had been in limbo since then.

If you are willing to help, feel free to connect with me through e-mail (available from my About page) or via IRC on the #accessibility channel. I’ll be glad to assist with getting involved. The accessibility team definitely would appreciate it, and so would many community members I’m sure!

You’re a table, and I don’t care what lies underneath

Over the past couple of weeks, Alex, David and I have been hard at work refactoring, discussing, and implementing better support for accessible tables in Gecko. Some of this has seen the light in Firefox 3.6alpha, but the heart of the work is currently only in mozilla-central (AKA Firefox 3.7). Update: As of October 29, these changes have also been ported to the Firefox 3.6 AKA the Gecko 1.9.2 branch and will be in the final release of Firefox 3.6. It will not yet appear in the upcoming release of Firefox 3.6b1, since that was branched off before we landed the IAccessibleTable2 support.

The goal was to:

  1. Refactor our code to become more maintainable.
  2. Expose the same kind of interface to assistive technologies regardless of what lies underneath is a true HTML table, an ARIA table, an ARIA data grid, a XUL tree table etc. There are so many commonalities that ATs should be able to expect similar, if not identical, information from any of these table types.
  3. Implement the IAccessibleTable2 interface that was defined within the IA2 group over the summer.
  4. Get rid of many “todo” items in our Mochitest unit tests.

For The Minefield (Firefox 3.7a1pre) nightly build that will come out today, Friday September 11, the patch that implements IAccessibleTable2 has landed. All header/table cell relations are now defined through proper method calls rather than special forms of accessible relations. This was a big patch with almost 550 kb in size. A quarter of this were IDL changes for IA2, but the rest was all code that had to be reviewed and super-reviewed. It’s definitely the biggest patch I’ve been working on so far since I started working for Mozilla.

Over the past few weeks, Alex also refactored our XUL tree exposure to better meet our goal. With 235 KB, this was the second biggest patch I have been working on so far.

Other changes that went in concern selection of cells, rows, unselecting parts of tables etc. Some of these have caused our long “to do” item list of around 80 items to drop to a mere 7 throughout the whole a11y test suite. The table tests were among the first written when we started doing automated tests on a11y some 20 months ago, and it’s cool to finally see this area of the code properly addressed!

With these changes, our number of passing tests is now at 10205 and a total of 7 to-do items.

And this is where you come in! If you’re an accessible tables junkie, know a lot about HTML table make-up, or know of very weird tables out in the wild, go download the latest nightly build and throw the tables at it! Let us know your results, for example by commenting here on the blog, and if you find something that definitely isn’t exposed right, file a bug! We appreciate any and all help you can give us here!

If you’re an AT vendor and plan on implementing support for IAccessibleTable2, here’s a model you can use!

Finally, I’d like to thank all the cool people (module peers and super reviewers) who helped us accomplish what we’ve accomplished so far! With their knowledge and wisdom about the inner workings of Gecko and their respective modules, they helped make our code faster, better and more robust. Keep on rockin’!