The below is a preliminary recap of the new features in accessibility for the upcoming release of Firefox 4.0.
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.
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:
- pressing Ctrl+L to go to the awesome bar
- 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 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.