Extension developers: Give your extension an accessibility checkup for Firefox 3!

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!

7 comments:

  1. @Wladimir: Thanks for your reply! I know that finding shortcut keys that don’t clash is almost impossible with applications that are as extensible as Firefox, Thunderbird & Co. Since Adblock Plus also puts an entry in the Tools menu, and adds itself to the context menu of items on pages as well, it is both reachable and discoverable for keyboard users. So, you’re not becoming inaccessible by removing these shortcut keys.

    As for the number of times a particular dialog is needed: I’ve subscribed to two filter sets and have not needed to open the Adblock Plus preferences dialog ever since. Whereas I can very well see that web developers will need to edit CSS very frequently, I would really consider not clashing with it, as one commenter on your blog post also suggested.

  2. Due to the way Adblock Plus initializes its shortcut keys, the “clashes” are always going at the expense of Adblock Plus. So the web developer extension always wins, and its users can edit CSS while not being able to open Adblock Plus preferences. The only improvement that I want to implement is removing Adblock Plus shortcut keys entirely if conflicts are detected – just to make sure no dysfunctional shortcut keys are displayed in menus.

    That unfortunately doesn’t really solve the problem for Adblock Plus power users who have to open preferences regularly because of building their own filter list.

What are your thoughts?