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!

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.

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!

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!

The try server has saved the accessibility team members’ butts so many times over the past two years that I’ve stopped counting. Just now, as we’re working hard to fix our performance problems on trunk, and putting in some other much needed reorganization, this try server build system has proven to be an invaluable tool for finding regressions before they even become such.

For example on this document handling reorganization bug, I tested various try-server builds before confirming that this huge code refactoring didn’t break us. Much of it is caught by Mochitests, but not all of it is, because some things are in platform-dependent wrapper classes that cannot be tested by the Mochitest unittest framework.

Likewise, we’re currently fighting a regression in the patch for a performance booster bug that would break a popular screen reader on many pages if it landed as the patch is now. I found this while testing the try server build for this patch. Tests pass and the code looks correct, but something is wrong nevertheless. The try server allows us to go through as many incarnations of the patch as needed until the problem is resolved without affecting the production of nightly builds. It avoids having to file follow-up bugs and having to go back to the same area of the code weeks later.

For my job as Mozilla’s accessibility QA engineer, the try server has become an invaluable tool as part of my day job. I encourage everyone doing testing in tandem with a developer to utilize this tool heavily!

Since this is the first issue, and my last update on a concrete new feature/major change has been a while, here’s a broad overview over what we’ve been up to over the past two months or so.

Automated tests on all three active Firefox development branches

Since December 18, 2008, all three Firefox branches that are under development run accessibility mochitests. These branches are:

• Gecko 1.9.0, off which Firefox 3.0.x is being released. These tests actually have been running since roughly the Firefox 3.0.4 timeframe in October.
• Gecko 1.9.1 AKA Firefox 3.1. This is the branch Firefox 3.1 will be released from.
• Mozilla-central. This is the development branch where the next major release after Firefox 3.1 is being developed, with new features going in and more experimental stuff is happening right now.

The most interesting of these is definitely the mozilla-central branch. Both Gecko 1.9.1 and 1.9.0 receive back ports of important features/bug fixes from this branch. The number of tests that run in the accessibility code has surpassed the 2,000 mark two to three weeks ago. We started in December with about 1100 tests.

ARIA 1.0 compliance patches

David has been working on ARIA 1.0 compliance patches and started to put in some good infrastructural stuff as well. Interesting items are:

• The change from aria-grab to aria-grabbed
• The removal of role=”description”
• Some urgently needed fixes for when the document node gets an ARIA role
• Some infrastructural changes and fixes to which ARIA roles can receive what states, and what these states should be

Alex implemented the ARIA spec’s name from subtree calculation algorithm. Of course, despite all the tests, a regression had to creep in, but after that’s fixed, I believe we’re in good shape. The visible result, especially for authors of ARIA-enabled we bapps, is that the Firefox 3.2a1pre nightlies should now always behave according to spec when calculating the name from those elements/widgets that call for its subtree to be aggregated as its name.

As a side note for those interested in the effect our automated tests now have: When Alex tried to land a fix for bug 463645, it clashed with the above mentioned name from subtree bug in an unexpected way, causing an immediate orange flag on the unittest tinderboxen. We’re looking for a solution to that problem right now. Hadn’t we had these tests in place, it would have taken a while for this regression to creep up in manual testing. This way, due to an immediate backout of the offending code, no nightly build ever saw this happen.

New for text attributes

David implemented the conversion to pt algorithm that IAccessible2 calls for on Windows. This change is also in Firefox 3.1.

Alex implemented a faster way of retrieving text attributes,a nd he and I teamed up on better better test coverage for this area.

Accessible relations improvements

Alex worked on better accessible relations support, allowing for a relation to have multiple targets. This will allow assistive technologies to get at aria-labelledby relations correctly. As a sequel, 1:1 relations between tabs and tabpanels were also implemented, allowing ATs to better identify which tab a tab panel belongs to.

Proper reorder events

Alex, our man for big patches , also created a fix for a long-standing bug involving reorder events on DOM mutation changes. Several screen readers need these events to keep track of dynamic changes on web pages to keep their virtual buffers up to date. Some recently inconsistent behavior that often required the user to refresh their virtual buffers manually, should now work much better. This change also is included in the Gecko 1.9.1 branch already, waiting to debut in the upcoming beta 3 of Firefox 3.1.

Thunderbird 3 reading panes

The Thunderbird 3 reading panes received a fix to the way they expose the “from: ” etc. header information. When tabbing through these header fields, one now immediately hears which type of header this is with a compatible screen reader.

This fix was done by Yuen Hoe, a student at the University of Singapore, as part of the NUS Mozilla students project. He picked this bug specifically. Thanks Moofang!

Because this patch relates very closely to SeaMonkey, it was ported there as well, however users can’t take full advantage of this yet in SeaMonkey because of a keyboard navigation issue in the message reading panes.

Better accessibility in SuMo’s live chat

SuMo, Mozilla’s support community, offers a live chat facility that alows users to get help quickly. This live chat was previously not very accessible.

However, Gijs Kruitbosch, the mastermind behind ChatZilla’s accessibility features, worked on a fix, which will see the light in one of the next Sumo updates.

I know this is not strictly the Gecko Accessible module, but nevertheless very important to the over-all Mozilla eco system, and that’s why I’m mentioning it here.

On other fronts

I’m currently working through some of the earliest test files to make them use the common accessibility retrieval and events structures that were implemented more recently. This will help maintainability and make sure that if we add new features to these common functions and classes, every test will benefit from them.

On Windows, all active branches will be more correct in what service IDs they accept when calling the QueryService function. This insures better compatibility with Windows 7, among other things.

Thanks for sticking with me until now! The next reports will be shorter, I promise!

Of course, we welcome your feedback on this kind of post, or on specific areas. So feel free to comment here!

The problem: The code that calculates the names for any created accessibles has been growing over time and became largely unmaintainable. New features suich as adding the aria-label property support requires code duplication for HTML and XUL, and in general the code has many stylish un-niceties.

So, our team has started a code cleanup and code refactoring series to get the code into better shape and maintainability.

As with any refactor, the result should be identical in output with what we started out from. However, as those of you familiar with software development know, the risk of regressions is there and should not be discounted.

While we do have test cases for many of these instances already, there may still be cases we’ve missed. So any help we get from the community will help make sure that the refactor goes smoothly, but also help fill in any possible gaps in our testcases.

So, how can you help? By downloading and installing the latest nightly builds of Firefox 3.1 for Windows or Linux, and testing the heck out of them. Use your favorite screen reader, use your familiar web sites, use it for day-to-day surfing. Obviously the most likely pages you’ll find differences on, if any, will be those pages you visit frequently, sites you know what the output should be.

If you find something that is different from what you know, you can download the last Windows or last Linux build before the refactor, unzip it into a separate folder, and compare your findings using that build.

If you find differences you did not expect to find, you have two main choices that will get the developer team’s attention:

1. File a bug in Bugzilla:
   • Component: Disability Access APIs
   • Version: Trunk
   • Platform: PC or whichever you use
   • OS: Windows or Linux, depending on where you found the bug.
2. Post a message on the mozilla.dev.accessibility newsgroup (Google Groups mirror).

In any case, your bug report should contain the URL of the page you are experiencing the difference with, the expected output of the element, and the output you’re now getting. Also, is that element a graphic, link, heading, form field etc.? Also, you should mention what screen reader you’re using. If posting to the newsgroups, it will also help to mention the operating system.

How to update the nightly builds to pick up latest code changes: The builtin Check for Updates feature, if invoked from a nightly build, will always grab an update to the latest nightly build and install it for you. So, you only need to download and go through the installation process once. You can then daily check for updates and get the latest code that way.

The first build to see changes will be the October 11 build, build ID 1.9b2pre/20081011.

Working with different profiles: If you don’t want to put your regular profile into the hands of the Firefox nightly builds, you can start Firefox.exe or the ./firefox executable with the -p option to bring up Profile Manager. You can then create a new profile and start Firefox with that profile. That way, your Firefox 3.0.x profile won’t be touched by the 3.1 nightlies if you choose not to. I’ve found, however, that the nightlies are very stable already, and I often flip back and forth between 3.0.x and 3.1 builds on the same profile without problems. The one thing that most certainly would happen is that some extensions may not work in 3.1 yet.

I’d like to thank all of you in advance who decide to participate in this effort and help everyone who relies on Firefox accessibility by testing out the code refactor. You can make a real difference because we obviously can’t test all of the web pages out there, and yours may just be the one we might miss out on.

Obviously, getting these tests running on the production tinderboxes so we immediately see when we broke something is the next step. But until that can be done, we need to find a solution for bug 441974. Basically what is happening is that tests pass when each test file is run stand-alone, but some of these tests fail randomly when running all files in one big batch. But I made some good connections at the Mozilla summit last week, and as soon as we get these passing we’ll start running those tests. They’ll then run along with the many other unit tests we have for Firefox and the Mozilla platform.

I’d like to thank our intern Lukas Blakk and a bunch of other members of the QA and build teams to help me with getting these configs for buildbot right!

For RC1 and the upcoming RC2, I’ve now created testcases for accessibility areas. These tests should be performed using Firefox on either Windows or Linux, and using a screen reader like NVDA, JAWS, or Window-Eyes on Windows, or Orca on Linux. To sighted people not using a screen reader, these expected results do usually not make much sense since they are especially tailored towards output generated by screen readers for the blind.

If you’re interested in helping out testing Firefox on the accessibility side, go get a Litmus account and run the Firefox 3.0 Accessibility test run.

There are a lot of other test runs to perform if you’re interested. You may have to find keyboard equivalents for certain mouse-driven actions, but that should be no problem if you know your Firefox!

Look forward to your results!