1. Make sure your extension is easily discoverable using the keyboard. A common pattern is to use an icon in the status bar or on a toolbar to launch an extension, but this is not possible to do when using only a keyboard, not a mouse. The easiest and most discoverable way is to add a menu item to the Tools menu to make sure keyboard users can launch it.
2. Labels that are not associated with the control they’re labelling. As a result, screen reader do not know what a particular textbox, menulist, radiogroup etc. is for. Associate your controls with their labels by using the xul:label’s control attribute pointing to the id of the actual control. Works with xul:textbox, xul:menulist, xul:radiogroup and others and is an absolute accessibility must.
3. Xul:page elements that are missing a title attribute. If you use xul:page elements in your chrome, make sure to give them a title attribute that is meaningful. That makes sure screen readers for the blind can properly pick them up and not read the chrome URL instead.
4. Make sure any place holders are in the tab order by using

   <a href="#">

   or

   <div tabindex="0" role="button" onkeypress="if (event.keyCode == event.DOM_VK_ENTER) { ... }"/>

   Any items that are put into a web page to enhance the user experience, and which allow interaction, must be keyboard accessible. A good example is what Adblock plus does with the ability to block certain elements like Flash animations.

5. Make sure all event handlers react to both a mouse and keyboard interaction schema. In fact, you should always completely test your extension without touching the mouse. Some common problems are:
   • For opening context menus, use the oncontextmenu event handler or the context attribute. Do not code context menus to open specifically on the click of the right mouse button, since this will exclude the use of the keyboard. Both oncontextmenu and context will react to the operating system specific context menu triggers.
   • Provide keyboard equivalents for mouse-dependent functionality such as mouseover, mousemove, or ondoubleclick. For example in a listbox where one can double-click a list item to perform a certain action with it, also allow the Enter key or an equivalent keystroke to perform the same action. For Drag And Drop actions, provide context menu alternatives, Copy And Paste, etc.

I hope these are helpful hints for you to make your extension, XULRunner application or the like more accessible to everyone!

For more information, see the XUL Accessibility guidelines on MDC.

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!