New in Accessibility in Firefox 4.0

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.


14 thoughts on “New in Accessibility in Firefox 4.0

  1. i don’t know if it’s a firefox issue or in my case jfw, but i do hope that the issue with jaws loss of speech and firefox outright crashing when encountering a webpage with hundreds of links is addressed. i am a power seller on ebay with over 1200 items in my store and for example, when i go to my all selling list everything stops. no jaws, no firefox and as i said, often it’s an outright mozilla crash. this also happens in instances such as blog postings where there are hundreds of responses etc.

  2. great post. thanks. It’s a very exciting time, with Firefox 4 in beta, IE 9 in beta and Jaws 12 in beta!

    it seems like the accessibility snowball is really picking up speed now and the experience is going to get better and better.

  3. I’m sorry this question is off topic, but in thunderbird 3.14 is it possible to save or open an attachment using the keyboard?

  4. Re: the add-ons manager
    “This makes interaction much nicer, one does not have to alt-tab between windows all the time.”

    Correct, now instead of alt-tabbing between windows all the time you have to ctrl-tab between tabs all the time. 😉

  5. I have a minor issue with Firefox 4Beta7pre (and also with other beta), this not happens with FF 3.6.
    With the Windows magnifier on Windows XP with “follow keyboard” enabled, if I use the aposstrofe to navigate the page links (‘) it not focus the searchbar, this not happen with FF 3.6 In other words, when I type the link to search, I not see the typed words magnified in the magnify window.

  6. Also, i do look forward to improved aria support. trying to use google reader and other google products with aria can be hit or miss with the keyboard commands.

  7. When downloading 4.0 It claimed I could combine multiple emails in one area. By the time I finished download and setup, I could find no information.

    Can you explain how or where this information is?

  8. Dear Marc,

    I used the FireVox Screenreader Add-on but it is deactiviated with firefox 4.
    Unfortunately there are no Screen Reader Add-ons for FireFox 4.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.