Tenon.io is a new tool to test web sites against some of the Web Content Accessibility Guidelines criteria. While this does not guarantee the usability of a web site, it gives you an idea of where you may have some problems. Due to its API, it can be integrated into workflows for test automation and other building steps for web projects.

However, sometimes you’ll just quickly want to check your web site and get an overview if something you did has the desired effect.

The Tenon team released a first version of a Chrome extension in December. But because there was no equivalent for Firefox, my ambition was piqued, and I set out to build my first ever Firefox extension.

And guess what? It does even a bit more than the Chrome one! In addition to a tool bar button, it gives Firefox users a context menu item for every page type so keyboard users and those using screen readers have equal access to the functionality. The extension grabs the URL of the currently open tab and submits that to Tenon. It opens a new tab where the Tenon page will display the results.

For the technically interested: I used the Node.js implementation of the Firefox Add-On SDK, called JPM, to build the extension. I was heavily inspired by this blog post published in December about building Firefox extensions the painless way. As I moved along, I wanted to try out io.js, but ran into issues in two modules, so while working on the extension, I contributed bug reports to both JPM and jszip. Did I ever mention that I love working in open source? 😉

So without further due: Here’s the Firefox extension! And if you like it, a positive review is certainly appreciated!

Oh, and if you’re into WordPres development or have often-changing content on your WordPress site, I highly recommend you check out Access Monitor, a WP plugin that integrates with tenon.io, written by Mr. Joe “WordPress Accessibility” Dolson!

Have fun!

This is a shout-out to all interested extension developers who have some time to donate to the WebVisum extension project. As you can read in my review of the extension, it is one of the most important extensions for blind users, helping to improve web pages here and there by allowing to label improperly labelled graphics or form fields, and – more importantly – it includes the connection to a captcha solving service, which has allowed blind users to participate more equally in web forums, certain blog systems and other services that still require graphical captcha entry.

The problem is that the WebVisum developers do currently not have the resources to port the extension over to Firefox 4.

So if you are a skilled extension developer, please consider donating some of your valuable time to this extension and help port it to FX 4! You’ll be helping a growing part of the Mozilla community continue to participate in today’s web offerings!

Late yesterday, Firebug 1.4 was released. Firebug is the web development and debugging tool for Firefox, with a huge user base worldwide.

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?