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!
This morning, Jeff Walden pinged me on IRC to ask me whether the new indeterminate DOM property for checkboxes that is being introduced in HTML 5 and which recently landed on Mozilla 1.9.2, has any accessibility implications. I did a quick check, and it indeed does have an implication: We don’t expose the partially checked checkbox state properly for html:input @type=”checkbox” yet.
Jeff then filed a bug on the issue, and I took on the task of exposing the correct state. It turns out to be a small fix that is needed to expose this extra state, so hopefully in a few days the sample page will work correctly in the nightlies.
This shows the importance of collaboration between the various backend and frontend teams and the accessibility team. Jeff was unsure, so he asked, and we “attacked” the problem right away, before it became a real problem, in the sense: We potentially release a product that has this not unimportant issue.
So if you implement something new in Gecko like new HTML 5 features, and you are unsure whether there could be any accessibility issues involved, I strongly encourage you to ping surkov, davidb or myself (MarcoZ) on IRC or shoot us an e-mail, or ask in the mozilla.dev.accessibility newsgroup. It may turn out to not be an issue, which is good. Or it may turn out that we have a work item to take care of, which is also good since this is not going to bite us out of nowhere in the future. Also, when the implementation is still new, we’re more likely to have the right fix in place with all memories still fresh.
Asking never hurts, so just ask once too often rather than once too less!
The Mozilla Corporation has the following job opportunity available:
The Mozilla Corporation is looking for a full time engineer to develop accessibility in its software.
The job will involve working with a small team to develop support for a wide variety of 3rd party assistive technologies such as screen readers, screen magnifiers, on-screen keyboards and voice dictation software on a variety of operating systems.
The candidate we are looking for will be an excellent C++ programmer, with experience in COM or XPCOM, as well as working on OS X and either Linux or Windows. Previous experience with the Mozilla codebase is a plus. The candidate should be interested in developing solutions which improve how users with disabilities interact with the web.
Mozilla Firefox already has a strong foundation in this area. However, as the web progresses to provide ever more interactive and complex applications, interesting challenges continue to present themselves. For example, users with significant visual or physical impairments need to be able to interact with applications as complex as online word processors and spreadsheets, as well as content which includes technical information such as diagrams and mathematics. These users will be interacting with the content using text-to-speech, Braille displays, on-screen keyboards, voice input software, and other interesting technologies.
The candidate should be passionate about improving the Mozilla platform and be interested in pushing forward in a truly challenging and interesting area, which improves the lives of users with disabilities by removing barriers to participation on the web.
Some of the standards we will work with include HTML 5, SVG, MathML, WAI-ARIA, OS X’s AXAccessibility API, ATK/AT-SPI and IAccessible2. The team will assist the candidate in becoming more knowledgeable with respect to accessibility topics and the APIs involved.
Occasional travel will be part of the job, such as to disability-related conferences like CSUN and Mozilla project events such as on-sites and summits.
If this sounds interesting to you, get in touch and send in your resume!