The below is a preliminary recap of the new features in accessibility for the upcoming release of Firefox 4.0.

API support

Most of the changes are under-the-hood changes that do not have API changes as a consequence. There is one new addition that helps get around the now absent window hierarchy, see this post for details and bug numbers if you’re interested.

However, there are a few enhancements that one should be aware of:


Improving speed was one of the major goals for Firefox 4 in general, and also for the accessibility APIs. A couple of highlights:

  • A site like BlindCoolTech, when loaded into the virtual buffer by NVDA, took approximately 6 to 6.5 seconds when loaded with Firefox 3.6.x. With Firefox 4, we’ve managed to cut this time down to under 1 second!
  • We also support the very performant Lazy Frame Construction in a very speedy manner so an accessibility-induced lag should hardly be noticeable.
  • When calculating meta data for big data tables, we’ve improved the speed by a huge factor. While Firefox 3.6 sometimes would hang for over 5 minutes while calculating data for a 20,000 cell table, this takes only a few seconds now.

New HTML5 elements

We have support in place for the following HTML5 enhancements of Firefox 4:

  • The html:output element is supported. We expose it as a text frame, and if it is being controlled by a form or form element, we also properly set the AccessibleRelations. In addition, it receives the implicit <emA<ria-live="polite" attribute. Screen readers will therefore read text inside the output element automagically.
  • We have support for the required attribute by setting the ‘required’ accessible state flag on the accessible.
  • We’re also working on getting the invalid state supported for the final Firefox 4 release.
  • New HTML5 input types like email, number etc. have basic support and are all viewed as text fields currently.

Changes in the WAI-ARIA support

We made changes to the WAI-ARIA support as the spec developed to the new last-call state. We removed features that are no longer supported in the specification. And we made the change that the aria-labelledby attribute now takes precedence over aria-label. When first implemented in Firefox 3.5, and for a long time in the specification, aria-label took precedence over aria-labelledby when used on the same element. Now, this is swapped around. If aria-labelledby is present, aria-label is being ignored.

Bug fixes

Of course, we also fixed a lot of bugs on the way, making the code more stable and secure. Some are part of the performance refactors, some specifically targetted. For example, there are HTML constructs that can cause bad hangs on Linux which we finally nailed down and fixed.

UI and keyboard navigation

There have been several visible UI changes, some of which also have consequences for keyboard users.

Tab strip moved to the top

The tabs moved to the top of the screen, now encompassing the URL bar and search field. Previously, these were not part of the active tab. As a consequence, the tab bar is now reachable by:

  1. pressing Ctrl+L to go to the awesome bar
  2. pressing Shift+Tab twice to land on the tab bar

So instead of pressing Tab twice when on the awesome bar, now it’s Shift+Tab twice. Other features like accessing the context menu for a tab by pressing Applications remain unchanged.

Pinned tabs

Pinned tabs are tabs that remain visible even when there are so many tabs on the tab bar that it needs to scroll. So your favorite tabs are always visible/accessible. For screen readers, there is currently no distinction between a normal and a pinned tab, but it is exposed nevertheless. And obviously, the context menu item is accessible.

The menu bar is gone, but not quite

The menu bar is no longer visible right away. Instead, a single popup menu, hidden behind the “Firefox” button, is replacing most of the menu bar’s functionality. However, as a keyboard user, you don’t really notice. Press Alt, and the menu bar reappears and you can use it right away again. In fact, I, being blind myself, didn’t even notice that the menu bar was gone because I was simply using the shortcut keys like Alt+F just as I did before. It was not until Surkov asked me whether the Firefox button was accessible that I noticed that there was a UI change.

Note that there is talk of mapping the Alt+F keystroke to specifically open the menu hidden behind the Firefox button in the future. So if Alt+F no longer brings up the “File” menu in the future, this is why.

Add-Ons Manager redesign

The Add-Ons Manager has been redesigned completely. It now also manages Jetpacks, search engines and much more. Moreover, it opens in a new tab instead of a modal dialog. This makes interaction much nicer, one does not have to alt-tab between windows all the time.

There are still some keyboard navigation quirks to be worked out, and some of this may come in an 4.0.x update, but the general functionality is there also for screen reader users.

New UI features that don’t work (yet)


The new enhanced tab management feature Panorama, previously known as Tab Candy, is currently not very well navigagble using the keyboard, and hardly exposes any useful information to screen reader users. However, it is going to be possible to make these accessible, we just need a little time to do it. If you’re interested, you can follow the keyboard navigation and assistive technologies support bugs to watch progress.

This blog post has to do with the reasons why Firefox 4.0Beta 5 and Beta 6 are totally inaccessible to most, if not all, Windows assistive technologies, and also cause problems with some mouse drivers and such.

It all started with Bug 130078, a sequence of digits probably everyone in the Mozilla platform team will memorize for a long time. 😉 What this patch essentially did was remove all but the most top level window from the window hierarchy so commonly used in Microsoft Windows. In Windows, every window (visible and otherwise) usually is associated with a window class, a string that loosely identifies what the window does. Experience having worked with a screen reader vendor for 8 years, however, has shown that this can also be quite bogus stuff. In the dark ages of Windows development, where there was virtually nothing else than screen scraping and some basic MSAA, this was the most reliable way for screen readers and other software to identify certain parts of the UI of an application.

However, times are better now, and have essentially been, since Firefox 3.0. There, we already knew that this removal of several window widgets with associated class names, would be upon us one day. So we started evangelizing with screen reader vendors to use newer, more future-proof methods of finding our accessibility information. But as time went by, this somehow got lost by the sideways, and suddenly, August 27, 2010, was upon us.

This was the day when Bug 130078 landed on the Mozilla-Central Mercurial repository. The August 28 nightly build was broken for all screen readers on Windows. Subsequently, I filed Bug 591874. In addition, the landing of Bug 589529 made things even worse for some of the screen readers, since now, no focus events or such were processed at all any more.

This, and David’s alert blog post, shook up assistive technology vendors, open-source and commercial alike, enough so they started to tell us what kept them from using the newer methods, or what additional things they’d require to be able to work without relying on the Windows widget information any more. Subsequently, Bug 592913 was filed, which, when fixed, did get NVDA back in working order. With some adjustments on their end, which are included in the recent NVDA 2010.2Beta1 release, they are now able to work with both Firefox 3.x that still has the window hierarchy, and also Firefox 4, which has the newer method for them to get all the information they need.

A second bug, Bug 594413 is going to land very soon, which should give all those assistive technologies still primarily using iSimpleDOM to also get all the required information without having to rely on Windows widgets.

As a fall-out from the above fixes, we had to deal with Bug 594775 and some fall-out from that as well, but believe we now have most things in order again. Most, if not all of this will be in Beta7, so the user experience should again be much better than it was in beta 5 and 6, and users can again experiment with the newest and greatest Firefox beta versions.

Also, the above quoted bug 591874 is fixed now, giving select older versions of commercial assistive technologies the benefit of an emulated window hierarchy, so users do not need to upgrade their screen readers at a fee to be able to use Firefox 4. However, it must be stated that this is not going to be there forever, so we strongly recommend that software that still relies on this window hierarchy use the better and more reliable methods to detect our accessible tree and get away from using things like MozillaContentWindowClass to rely on. We now turn this emulation on only for some commercial screen reader vendor versions, but strongly suggest to also backport the new solutions to older existing user bases as soon as possible. It will go away, but we haven’t decided yet when exactly that will be.

Talk to us, we’ll be glad to assist you!

From March 22 to 27, the 5th Annual International Technology & Persons with Disabilities Conference took place at the Manchester Grand Hyatt Hotel in San Diego, California. It is most commonly referred to as CSUN 2010.

The Mozilla Foundation had a booth at CSUN for the fourth year in a row. David, Alexander Surkov and I were present to man the booth, talk to people, and also participate in a couple of general sessions at the conference to gather information and news, and also to network.

Adobe announces broad range support for IAccessible2

One of the biggest news bangs to come out of the conference is Adobe’s announcement to support the IAccessible2 and WAI-ARIA standards in thenext versions of their Flash and Flex products. Both these standards were heavily driven by, among others, Mozilla, IBM and several assistive technology vendors such as NV Access of the NVDA project. Support for the native GNOME and Mac OS X accessibility APIs is also in the works.

In addition, Adobe announced that they will also include IAccessible2 support in their Acrobat and Reader products.

This means that another big player in the software industry is coming forward and supports these widely recognized standards. It is good to see Adobe getting behind the over-all accessibility efforts and helping to drive adoption in this manner!

Three Firebug-related sessions

Hans Hillen of the Paciello Group had two very successful talks about the UI accessibility support in Firebug. The first was a demo of many of the features, using NVDA as the screen reader to demo them. the second was a use-case talk, where Hans explained in some more technical detail how he went about making the Firebug UI accessible to screen reader users.

Both talks were very well received. The first one had quite a broad audience, while the second audience was smaller, but very focused and involved.

In addition, Jon Gunderson of the University of Illinois at Urbana-Champaign held a talk on the Accessibility Testing Extension for Firebug. But unfortunately, due to my travel schedule, I did not have a chance to visit this talk.

It was good to see two Mozilla grantees doing talks at this year’s CSUN, giving visibility to the many facets of Mozilla’s accessibility strategy.

Newer mobile accessibility technologies marching forward

Apple, RIM and Google, the three vendors of mobile devices with well-defined accessibility APIs, all had well-visited talks at CSUN. In addition, I am aware of at least two talks involving the accessible iPhone and iPod Touch 3rd generation that put these technologies to good use to provide a new generation of assistive software, built on mainstream devices.

Well-visited booth

The Mozilla Foundation booth was well visited on all three days that I helped staff it. Comments and questions ranged from the very flattering “I love Firefox and I love what you guys are doing for accessibility!” to “What’s a browser vendor doing at this conference?”. When we then explained why we attended, many of them were keen on trying out Firefox when they got home or back to thheir hotel rooms.

Also, this conference made quite a number of people aware of other Mozilla products than Firefox. While many had heard about Firefox, they had not heard at all about Thunderbird before. But with the better accessibility in Thunderbird, we can now change this and spread Thunderbird in the accessibility community even more!

I personally had a very moving moment on Friday when a deaf/hard of hearing gentelman and his interpreter stepped up to our booth. He was very interested in what we do for accessibility. Before I knew it, I was talking to him through his interpreter, but wasn’t actually noticing it until well into the conversation. At some point, I mentioned Thunderbird, at which point he started joking about the Ford Thunderbird. David, who was present at this conversation, can probably tell a bit more about this, since this was very visual and I only got a third of what he was actually meaning. 🙂

David and Alex also took a lot of pictures, which they’ll hopefully upload and share very soon so you all can get a better picture about what CSUN 2010 was like! Mozilla received a big big chunk of good attention, our funding of other accessibility-related open-source projects such as NVDA, Orca and others, definitely is being recognized in the industry as being exemplary. Also, we got a very nice compliment from a gentleman from the Office of homeland security, who told us that he thought our Voluntary Product Accessibility Template is among the best he has encountered so far.

One big failure is there, though

One big problem, which I think should not go unmentioned, is the lack of good internet connectivity in the exhibition hall. For a 2010 information technology conference, having no useable WIFI connection down in the exhibition hall at all is simply unacceptable. The internet connections that were offered were hideously priced, almost like in the mid 1990s when internet connectivity was still not as common as today. Up in the session rooms, the situation was a bit better, at least there were hotspots one could use most of the time.

For next year, one thing I’d like to see is a well thought-through strategy for free wireless internet connectivity throughout all conference locations. A technology conference lives and breathes with the buzz people can create around it by tweeting, uploading pictures etc. People with disabilities are no exception, and instead of roadblocking it, the responsible powers at CSUN should embrace this trend and encourage people to get the word out as easily and hazzle-free as possible!

In summary

I can only say that it was worthwhile going to CSUN yet again, and I am hoping we’ll have a chance to participate next year as well!