There are two new ARIA resources that recently entered the web which I’d like to point you to if you’re interested:
Paciello Group have started an ARIA tutorial.
Peter Thiessen of ATRC in Toronto, Canada, has started a blog on Live Regions.
Cool stuff, guys!
Litmus is Mozilla’s community testing platform that allows anyone to test Firefox or other Mozilla products by running a set of testcases and giving us feedback about whether the test passed or failed. The Mozilla QA team uses these test runs to do basic functionality tests (run before every beta release), full functionality tests (run before releases or release candidates), or other set of tests to ensure that certain areas of the product behave as expected with a given set of steps.
For RC1 and the upcoming RC2, I’ve now created testcases for accessibility areas. These tests should be performed using Firefox on either Windows or Linux, and using a screen reader like NVDA, JAWS, or Window-Eyes on Windows, or Orca on Linux. To sighted people not using a screen reader, these expected results do usually not make much sense since they are especially tailored towards output generated by screen readers for the blind.
If you’re interested in helping out testing Firefox on the accessibility side, go get a Litmus account and run the Firefox 3.0 Accessibility test run.
There are a lot of other test runs to perform if you’re interested. You may have to find keyboard equivalents for certain mouse-driven actions, but that should be no problem if you know your Firefox!
Look forward to your results!
As Firefox 3 is fast approaching, and you extension developers are getting ready to update your products, it is a good time to also give your extensions a thorough accessibility checkup. Can the extension be launched without using a mouse? Are labels properly associated with the controls they are labelling?
To help you out, there are XUL accessibility authoring guidelines available that cover these and other topics extension authors should be aware of. Firefox 3 is much more accessible than previous versions were, also on one additional platform (Linux), so the userbase that may be using your extensions without a mouse and/or with the help of assistive technologies is growing!
Over the past few weeks, I’ve approached a few developers of extensions I use frequently to suggest some accessibility improvements. Here’s a list of extensions who have become more accessible recently:
- Enigmail, an extension for Thunderbird and SeaMonkey that allows you to sign your messages with OpenGPG, has become much more accessible when used with Thunderbird or SeaMonkey Trunk.
- ScribeFire, a blogging extension for Firefox and SeaMonkey, has added a couple of good enhancements recently that make it much more useable with the keyboard. I’ve proposed a few more enhancements, especially missing label/control associations, so upcoming versions will hopefully see more improvements there!
- ChatZilla, an IRC client for Firefox, and part of the SeaMonkey suite, has received a big number of improvements over the past couple of months. I helped test these enhancements and worked with the authors on a couple more keyboard navigation and control labelling issues.
I’d like to thank these extension authors for being so responsive and willing to make their extensions more accessible to a wider audience! I found that often it was only a missing resource like the above mentioned authoring guidelines that can help make an extension more accessible. So, if you are an extension developer, go check them out!
If you have any questions about ways to make your extension more accessible, feel free to contact me either here on my blog, on the #accessibility channel on IRC, or by sending mail to the mozilla.dev.accessibility newsgroup. I’m sure someone from the growing accessibility community or myself will be able to help you out!