In the nightly Firefox builds, which are already at version 10.0a1, a big refactoring patch was checked in mid of last week that reworks how the accessibility code handles focus changes and setting of the focus and its associated states for screen readers and assistive technologies.

Among the improvements this rework introduces are bug fixes to some long-standing problems we were having, but could not solve in an easy-to-do manner because of the previously used architecture. For example, handling of focus inside of html:select elements whose size attribute has a value of 2 or greater, has been greatly improved. Now, one knows immediately which item is selected, if any, or even if multiple items are selected if the control supports it.

Also, entering the menu bar or context menus when inside a multi-line edit field AKA html:textarea element, has been improved, and focus is no longer stuck when coming back out of those menus and tabbing or shift-tabbing around the page afterwards. Also, some inconsistencies when entering some edit fields has been fixed for assistive technologies that use IAccessible2.

Handling of autocomplete popups has been improved as well. Assistive technologies now get proper events for the popup’s selected autocomplete item and other associated information.

There’s more, but these are the most user-facing ones.

Users of NVDA and Orca should notice improvements immediately, although both projects told me they’re looking at the builds and see if they need to rework/remove any workarounds they might have had to put into their sources for our lack of proper events/states. Other supporting assistive technology vendors will be contacted by us and urged to do the same for their end users so the user experience will be much improved for everybody.

If all goes according to our rapid release cycle, this will be in Firefox 10, the first release coming out in 2012. If you’re on the Nightly builds and testing the most cutting edge stuff, you already have this code running if you’re on the 2011-09-29 build or later. If you’re on Aurora, you’ll be getting this in mid November when we merge the next time. This code will hit beta in late December.

If you’re running the nightly build now and would like to tive us feedback, please feel free to do so! We’re always interested in your findings and welcome any and all feedback on this you might have. If you’re noticing any inconsistencies, we wanna know about them so we can address them in due time!

Firefox 4 has finally hit the release channels and is available for download immediately!

This is a major update that brings a lot of new features and enhancements as well as loads of stability and performance fixes to your browsing experience. And of course it is accessible!

Some recent posts on the subject by me:

  1. New in Accessibility in Firefox 4
  2. New support for HTML5 elements and attributes, with a lively discussion and some revamping going on for a very near future update esp to the landmark piece

If you’re a user of NVDA, Orca, JAWS, Window-Eyes, Dolphin SuperNova, Serotek System Access or Baum Cobra, you’ll be good to go with current versions of the products! Please make sure to update to the latest revision for your screen reader that you can access before using Firefox 4, as it was reported to us that some early revisions of JAWS 11, for example, cause problems invoking the virtual buffer.

We expect all screen magnifiers that worked in Firefox 3.6 to work in 4, too. Same goes for speech recognition and other assistive technology programs on Windows and the GNOME Desktop on Linux.

This already happened a while ago, but I just now found time to blog about it. It was during preparation of Firefox 4.0Beta11 that I found a critical accessibility issue while the second build candidate was already in testing. The issue, documented in Mozilla bug 631160, was that due to a regression introduced in a combination of bugs 570710 and 630001. The first introduced the problem, the second uncovered it.

The problem was that the nightly build beta 11 was based on arrived late in my day so I had already gone off-line and didn’t see it until build candidates for beta 11 had already started. When I came to my desk early the next morning, downloaded the nightly build, I immediately noticed the problem on sites like the Google homepage where suddenly, NVDA would no longer see the search textfield. On other sites, images, separators and other parts were also missing.

Had we shipped Beta11 with this bug, we would have left users with a largely unusable beta release and would have lost valuable feedback.

My first action item was to talk to Alexander Surkov, the accessibility module owner, about this problem. He then filed the bug since he immediately found what was wrong.

An hour later, he gave me a patch to try. I started a local build based off of the current code base, with the patch applied, and within 90 minutes, was able to confirm that this patch fixed the bug.

I then ran that local build, whose build configuration was very close to what comes out of Tinderbox for releases and nightlies, for the remainder of that day to make sure the patch didn’t introduce any negative side effects. Also, the patch had to get proper reviews and approvals.

In parallel, I wrote an e-mail to the release drivers and QA mailing lists explaining the problem and its severity, and asked for permission to take this patch on the beta11 release branch and respin beta11 with a third build candidate. Luckily, this was a very contained fix that didn’t invalidate any of the other QA testing that had already gone on. I assured juanb about this fact as part of this process. In addition, the patch had unit tests that now properly covered this area of the code so a likelyhood of this regression being reintroduced is now minimized.

Fortunately, we could take another obvious fix, a crash fix, as a ride-along which would have given us false crash data otherwise of a crash that was already fixed.

After the release driver crew had evaluated my proposal, I got approval to land the fixes on the release branch for 4.0Beta11.

I checked in the code myself and pushed to the Mercurial repository, in effect taking responsibility for keeping the tree green or breaking things.

Well, as you all have seen over the past weeks, the tree didn’t break, and you all got Beta 11 early the week after, with NVDA perfectly being able to read Google.

As a post-mortem, I then explained how it happened that this bug slipped me initially.

All in all, this was a very good team effort: From finding the problem, analyzing it and then making sure we could deliver the fix to users at the lowest possible risk, it was a good experience taking charge and driving this forward, working with people from different teams such as a11y, QA, release engineering etc. to get the fixes landed in an orderly manner and without having to re-test everything that had been done already. The delay was minimal, but the gain was extremely high!