As JJB mentions in his post, UI accessibility was provided for many of the Firebug features by Hans Hillen of the Paciello Group. The Mozilla Foundation funded the first of this work, and the Mozilla Corporation is now continuing funding to finish the remaining UI pieces like the “Net” panel, fix remaining issues, and also to work with the University of Illinois to develop Firebug features that will help web developers check their sites and applications for accessibility and fix issues in that area.

I am not going to iterate over the features one by one, since the documentation on the accessibility features is very comprehensive. I urge all developers wanting to utilize these features to RTFM (read the fantastic manual) in its entirety before starting to use accessible Firebug.

Once you are up and running with it, you’ll find that all of the described features work as advertised in the documentation. And even more: The documentation currently still states that the script panel’s source code viewer cannot be read with NVDA. However, Hans, Jamie from the NVDA team, and I managed to fix that problem shortly before beta 1 of Firebug 1.4. I notified Hans to update the documentation.

Compared to Firebug 1.3, Firebug 1.4 offers a wealth of accessible web development tools. Firebug 1.3 was effectively not accessible, Firebug 1.4 is, with a few small exceptions, fully accessible, which is an almost 100% leap forward within a single version number increment!

This opens up whole new opportunities for blind developers. To my knowledge, the development tools offered by the Redmond browser do not offer this wealth of features. In testing I did while fixing my example form to also work in IE 8, I found the tools to be unreliable and shaky in many areas. Firefox 3.5 and Firebug 1.4, on the other hand, together with NVDA, which currently best supports the former, are a vehicle to open up new job opportunities! With Firebug, a blind person has full control over the styling and layout of a web application or page. For example, taking my example form from the Easy ARIA Tip #3, and looking at the label and input elements for the “name” entry, I can immediately be told that the label is to the left of the input, and how many pixels there are between the two. I can make sure they’re visually at the same height. The box model of the Layout sidepanel of the Firebug HTML panel is fully accessible and gives me a feel for a page I’ve never had before!

Communication of search results within the HTML panel, or when encountering a breakpoint, is just awesome! Being able to inspect the DOM or a single element’s properties, being able to in-line edit properties and immediately be able to test the effect a certain ARIA attribute might have on your screen reader output is just productivety at its best!

What Hans accomplished here is done almost entirely through WAI-ARIA, and by implementing very intelligent keyboard navigation mechanisms. Through ARIA, such widgets as the log rows for the console, when you enter something such as document;, or dir();, are pushing the boundaries of known desktop widgets. The fact that tabs have popup menus attached to them is being communicated to the user by NVDA straight away, thanks to a very open and flexible architecture that does not assume certain facts about traditional static desktop widgetry such as “tabs never have menus attached to them”. The pure visual box representation of the Layout side panel of the HTML panel is another great example. This even blew David Bolter away when I showed it to him during the Mozilla all-hands in late April, and David is a long-standing and accomplished a11y guru!

Implementing some of these features in desktop applications usually requires very customized implementations of the platform’s accessibility APIs. ARIA, however, is so open and flexible that it can be easily applied to make such visually complex tools like Firebug accessible without ever touching the Mozilla core codebase. Firebug is a mix of XUL (the Mozilla UI language) and HTML+CSS.

So, Victor Tsaran of Yahoo! is already firebugging, and so am I. When are you?

In the version that is currently on addons.mozilla.org, there are several problems with missing label7control associations in the Options dialog as well as problems navigating the tree, and more importantly, opening a feed article via the keyboard.

Not too long ago, I contributed a patch to the project to fix these problems, and Chris has accepted it and put it into a recent beta version of Feed Sidebar. He also made it possible to access the sorting options from the context menu.

The latest beta brings a better updating mechanism that is less resource hungry.

For those of you who have asked me about a way to view feeds in a tree like structure, this is definitely worth a try! Go download the latest beta version here! I’ve found it to be very stable and accessible. Of course, feedback is welcome! You can either contact Chris directly of course, or leave a comment here, I’ll then forward it to him.

Enjoy!

• Ability to tag graphics, form fields, links, and other page elements. While some or all of these features have been available in some screen readers already, this feature is unique in that it works across platforms. It also sends the data back to the WebVisum web service so other members of the community can benefit from the labels someone provided.
• Optical Character Recognition (OCR) to try and identify those images that absolutely won’t tell us through their SRC what they’re all about.
• Visual page enhancements such as a high-contrast profile.
• Suppression of automatic page refreshes or Flash content
• And most astonishingly: CAPTCHA solving!

A few days ago, I was approached by the WebVisum development team if I would consider beta testing their extension. So, I had a bit of a head start with this tool, and I was very surprised when I started testing some of the features.

The tests

From my main screen reader, I already knew the capability to label graphics or HTML form elements that have missing alt text or labels. Instead of using those techniques, I applied a few labels to the main navigation images on the CakeWalk homepage using WebVisum. After labelling the graphics from my Windows computer, I fired up my Linux box, installed the extension there and surfed to cakewalk.com. Orca immediately picked up the labels I had given the graphics and used them as the link text.

I then went ahead and labelled the Search combobox on the German Heise Newsticker site. Again, after visiting the page from the other computer, the label for the combobox was read aloud.

And then I actually tried a CAPTCHA. I chose digg.com as my first target since I know they also offer an audio CAPTCHA. Of course this is not a 100% satisfactory solution because deaf-blind people are still left dead in the water with this, but it gave me a good reference to compare the results. I went into the new account creation process on digg, and when it came to the CAPTCHA, I let WebVisum do its magic. Within less than 30 seconds, I got a result back, placed on my clipboard by the extension, ready to paste in. I compared it to what the audio CAPTCHA told me, and the results matched!

I repeated this step two more times because I had first chosen a user name that was already taken, and then goofed up something else in the form, and each time, the result was correct. Totally stunning!

I tried the same on Technorati who also offer an audio CAPTCHA, and got the same results: The CAPTCHA was correctly resolved.

As my third target, I chose MozillaZine, who, despite a couple of attempts on my part, still do not offer an audio CAPTCHA for registration or sending a reply to a forum without being logged in. Without this fall-back mechanism, this is a real-world scenario that visually impaired people are being faced with on an almost daily basis. And I’ll be darned, it worked out! I could register with the MozillaZine forums without any sighted assistance.

The conclusion

There are actually a couple of conclusions, concerns and questions that this extension raises.

The educational aspect

So here we are, having been trying to educate web developers all over the world to use W3C accessibility authoring guidelines, comply with section 508 and what not, and now an accessibility comes along that allows for labelling controls, providing alternative text for graphics, and even share this with the community. So did we do all this educational endeavor invain?

The answer can only be a firm and resolute: “No, we didn’t!” While this extension allows to correct for obvious mistakes like a missing alt attribute on an image, it cannot correct all the requirements there are to meet for section 508 compliance. And it should not! On the contrary: All mistakes one has to correct should be counted against a ranking on a “Wall of shame” kind of statistic that depicts the sites requiring the most corrections. Similarly to the Firefox “Report a broken website feature”, that in Firefox 3.0 also has a “Disability Access” component that allows to report an inaccessible web site, this data should be used to advertise for better accessibility in a future relaunch of that particular site.

Furthermore, there are so many websites that are part of the so-called web 2.0 that are not publically-owned or from a big company, but which are just as compelling to participate. These can usually either not be bothered or cannot financially make it to be 100% sec 508 compliant. Having the possibility to enhance these pages will make the web 2.0 a much more compelling place than it already is in the future.

The CAPTCHA solver

This is probably the most controversial feature. The fact alone that WebVisum is able to solve the CAPTCHAs will probably send shivers up and down the spine of many web developers, website administrators, blog owners etc. that have to fight spam every day. The fact that WebVisum can do it probably means that spambots will sooner or later also be able to do it. Even worse, some could argue that the WebVisum service may be abused by spammers to get CAPTCHA resolution for free.

The WebVisum developers assured me that they’ll make sure that only real people will be able to use their service. Furthermore, the number of CAPTCHAs that can be solved per day per site is limited.

While it is correct to advertise for alternatives to visual CAPTCHAs, the reality is that audio CAPTCHAs, which are the most common alternative, do not allow every person to use them. I already mentioned deaf-blind surfers. But also people who have a hearing impairment and have difficulty deciphering the distorted audio have trouble with this alternative. The CAPTCHA resolution feature allows to solve the problems of these people and also anyone who has trouble reading or hearing the text who is not visually impaired.

Also, this allows access to those private sites and blogs that are under no pressure government- or image-wise to implement an audio CAPTCHA. It definitely lowers the barrier for participation in the web 2.0 world!

Aside from all that, CAPTCHAs only offer a false sense of security. There are much more effective ways of fighting spam than imposing these things upon everybody. My blog, for example, has no CAPTCHA entry for commenting, and still my spam fighting measures have kept this blog clean for as long as it has been in existence. But the sad reality is that CAPTCHAs are an “evil” we currently have to cope with, and WebVisum certainly helps a lot in circumventing these artificial barriers.

My hope is that the WebVisum folks manage to keep their user base spambot-free and that there won’t be any other way to abuse the feature for unsolicited activities.

A few wishes for the future

I see for this extension the potential to become much more than “just” a web helper for the visually impaired. For example, I can imagine this being enhanced to allow hearing-enabled people to provide a textual transcription of an audio clip for deaf surfers, sighted people giving a textual description of not just an image, but a video clip or the like, and other similar cross-impairment possibilities. After all, any hearing-enabled blind could provide such textual transcription of an audio clip for a sighted deaf person.

Aside from this larger-scale vision of mine, a few more basic features such as an undo feature that allows to revoke a server-submitted enhancement will hopefully make its way into near-future versions of the extension.

So: To be able to make up your mind for yourself, go check out the website and extension at www.webvisum.com.

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!

This thing is truly awesome, and it adds even more awesomeness to the AwesomeBar of Firefox 3! For mouse users, there is a little icon to the right of the AwesomeBar that allows you to post whatever you typed right to your Twitter account. If you hover the mouse over it, it will show you the remaining character count.

However for keyboard users, it is truly awesome as well. When you have finished writing your update, simply hit space and type the characters

--post

, and without having to hit Enter, it will send the text you typed to the Twitter account just the same!

So now not only can I rummage through my tags, bookmarks and history, I can post to my twitter account without having to give it *any* more thought. How cool is that!

The only thing I will want to work out with Chris Finkle is the issue of how to get to the information how many characters I have left to type without using a mouse.