First and foremost, we managed to fix a whole range of bugs related to focus reporting. For more details, please read this post.

In Linux, the caret position is now correctly updated again when using atk_text_set_caret_offset is used.

Accessibility now supports the list attribute on inputs and the datalist element of HTML5. An indication is given that this input supports autocompletion and that it has a list. Pressing DownArrow will put you in a list of choices, enter will allow you to accept the selected item and put it in the entry.

Info about the map tag is now being reported correctly.

The feature to read highlighted text via the Mac OS X speech feature under the “Edit” menu has been fixed to work properly in Lion. This also applies to Thunderbird where this issue was first reported to us.

Telemetry has been updated to report the use of the iSimpleDOM interface by assistive technologies. It also now reports if depricated IAccessible2 methods are still being used by any AT out there. For more information on what telemetry is and how we use it, please read my post on this subject.

If a table has the datatable attribute’s value set to “0″, we now always treat it as a layout table and set the object attribute for the table accessible accordingly. The algorithm to determine whether something is a layout table has been enhanced so that it no longer picks up data table elements from nested tables.

We fixed a few issues having to do with accessibleRelation exposure for select elements that are nested inside labels, and with xul:tree elements and their children.

All in all, we almost reached the 50 fixed bugs mark in this cycle in the Accessibility APIs component alone. Congrats to the whole team and all external contributors who also helped with a number of these!

When I wrote the original blog post, what we had was very basic content rendering to VoiceOver or Accessibility Verifier. And I mean really basic. We had just crossed the point where loading a second page, or opening a new tab, would actually tell VoiceOver what content there was. Previously, it would not even take notice of the new content and still show the old stuff. Also, the web area was just now then being announced as “HTML content” by VoiceOver, like in Safari.

Since then Hub:

• got headings to be announced.
• got tabs to count correctly, and all roles to be spoken.
• got dialog texts and other text to speak completely.
• got links to be pressable through VoiceOver.

Pretty amazing, eh?

Of course, there are still quite a number of things left to do. To name a few:

• Navigating by character, or interacting with, the text in the awesome bar does not speak the character.
• Firefox doesn’t tell VoiceOver when a page has finished loading.
• password entry fields not identified as such, entering password does not generate typical audible click.
• VoiceOver does not see form fields that are nested inside label elements
• VoiceOver says “text” after each chunk of text it reads inside paragraphs, does not do that in Safari.
• Various form element states not communicated to VoiceOver
• WAI-ARIA landmarks are not communicated to VoiceOver.

As you can see, we still have quite some work ahead of us, and we’ll undoubtedly find more along the way, and with your help once I announce a build that has less known bugs than this above list.

Recently, we also started to incorporate statistics about the way the accessibility features of Firefox are being used.

Our newest addition to this feature is the collection of data about which screen reader is being used with Firefox on Windows. For Linux, there is only one screen reader that’s widely used really, so we primarily concentrated on Windows, since there are a variety of screen readers and screen magnifiers out there that Firefox is being used with.

So, to get a better idea about what our user base is using Firefox with, we’d like to call out for assistance in gathering this data! Let me stress once more that this is purely voluntary, but that this will help us improve our over-all support even more focused once we know better what assistive technologies are the most used. Moreover, this is anonymous data, so there is no way we can link a particular screen reader to a particular user. Which assistive technology you use is and stays your private matter. You’ll only be contributing to an over-all picture of usage statistics.

So how do you turn this on? In Firefox:

1. go to Tools/Options.
2. With the arrow keys, navigate to the list item called “Advanced”.
3. Tab once to set focus to the tab page selection.
4. Select the “General” tab using the left and right arrow keys.
5. Tab through the dialog until you reach a check box called “Send performance data”. Note, instead, you can also press Shift+Tab a couple of times to get there faster, since this is the very last checkbox before the “OK” button.
6. Press Space to check it if it is unchecked.
7. Tab once to get to the “OK” button and press Space to close the dialog and save your changes.

Firefox will now send anonymous usage data to us and inform us about any relevant performance like memory usage, screen reader in use (if any), or whether accessibility is instanciated at all.

Note that part of this feature is currently only in the Nightly development builds of Firefox. If you use a regular release like Firefox 9.0.1, this checkbox will not have any effect for screen reader usage data yet. But for other data such as the memory consumption, you can still enable it. Once you get upgraded to Firefox 12 in 3-4 months, you’ll start sending us data about your screen reader usage automatically.

If you’re on the Aurora channel, you’ll get this feature with the next big uplift that will happen early February.

To all who enable this feature, thank you! Your helping us improve Firefox even more is appreciated!

And to those of you who do not wish to send us your anonymous information, that’s perfectly fine, too! No grudges will be held against you.

Hub Figuière, a new member of the Mozilla accessibility team who started in November, has taken on the task of bringing our support of Apple’s Universal Access up to speed. Work on this support had initially started some time in 2006, but stalled for a number of years despite a pleas for help on this blog in 2009. However, demand for it has always been there, every Firefox release I’m being asked when Firefox will finally become accessible to VoiceOver.

Well, the time isn’t here just yet, but we’re on a very good way!

And in the next couple of weeks, we’ll be announcing the availability of builds for those who are willing to help us test accessible Firefox on Snow Leopard or Lion! They will be builds off our hot development branch, so nothing for the faint of heart. They will have problems, some of which we may have found internally, but undoubtedly many we will not have found yet. And if you feel like you can help us make sure the accessibility of Firefox on the Mac is good, join the fun and provide feedback! How that can be done, I will announce in a separate blog post. If you already know your way around the Mozilla community, you’ll be able to find us easily right now and can follow this meta bug for progress.

In the meantime, you are invited to show your support, be it in testing or good morale, by leaving a comment here!

The new sub menus are a way to more quickly access items in the sub menus of “Dashboard”, “Posts” etc. without having to reload the page with the menus opened. Instead, the menus are opened and closed dynamically by either hovering the mouse over the item that is, by NVDA, announced as “sub menu link”, or by executing a press of the enter key on such an item.

The problem arises from the fact that screen readers on Windows capture the enter key and many others and execute functions based on their functionality inside the virtual documents/browse mode documents. For example pressing enter on a link usually clicks the link.

In this case, a click on a link is not what we want, since that would indeed reload the page. The menu would still be opened, but we’d lose all advantages of the more dynamic, time-saving approach that is made possible in 3.3.

Instead, what we do is the following:

1. Position NVDA’s virtual cursor on the desired sub menu item.
2. Press NVDA-key+F2 to invoke the function to pass the next key press straight through to the application.
3. Press enter.
4. Navigate down with the virtual cursor to find a newly expanded sub menu with links we can click.

Your preferred screen reader offers the same functionality, no doubt. Be aware, however, that some screen readers do not set focus to focusable items under the virtual cursor automatically, so an additional key press before step 2 may be needed to route the system focus or PC cursor to the item the virtual PC cursor is pointing to.

This way, we can easily access the dynamic menus. It requires an extra keystroke, yes, but this is still quicker than having to wait for a page load and looking for the new items starting from the top of the virtual document.

Happy blogging!

First and foremost, the emphasis in this release was on performance and stability. We fixed a number of lingering crashes and inconsistencies on both Windows and Linux that may have impacted some users in Firefox 7. An example of this is inconsistent behavior when printing in Linux and using assistive technologies.

We fixed a bug that would sometimes cause iframe content not to be properly loaded into the virtual buffers of screen readers under Windows.

On Linux, access keys are now included in ATKAction information.

A state change event for elements having the “mixed” state (e. g. a tri-state checkbox) is now fired also for elements that aren’t in focus.

If you decide to opt into sending data to improve Firefox, we’ll be told if you have accessibility instanciated. This is most likely the case when you have a screen reader running, but may also be instanciated by some password entry assistants (like finger print scanners) or some anti-virus software, esp on Windows.

And once again the note that, due to a technical change introduced in Firefox 4.0, you have to make sure to load your screen reader before Firefox or Thunderbird, or virtual buffers may not work correctly. Also if you are one of those people running multiple screen readers, make sure to shut down Firefox and/or Thunderbird before shutting down one screen reader, and loading the other screen reader before restarting Firefox and/or Thunderbird. This is true for Firefox 4 onwards and also includes Firefox and Thunderbird 8.

Happy browsing!

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!

First and foremost, we participated in the improvements to memory usage and speed. More accessibility classes participate in our garbage collection mechanism, reducing the memory consumption greatly. Long sessions with a screen reader running should no longer result in huge amounts of memory being consumed. This is especially evident if you run with multiple tabs and open lots of pages.

A bug was fixed that caused large additions to xul:tree elements to hang for long times when accessibility was turned on. This could be observed in add-ons such as Adblock Plus on occasion.

If role="presentation" has been specified on an element and this element is made focusable, for example by setting tabindex="0" on it, the role of presentation is now ignored, and an accessible is created for the element nevertheless. This is to avoid situations where one would suddenly land on a focused item for which there is no accessible. This was the cause for some screen reader confusion.

On HTML table elements, the way the summary attribute and caption elements were handled has been switched around. Now, if the caption element is present, it becomes the primary source (ARIA not withstanding) for the name of the table. summary is now being converted into the accessible description, which is used to communicate additional information to users. Only if the caption element is omitted, summary will still become the accessible name’s source. Until Firefox 6, summary would always become the accessible name’s primary source. This brings Firefox in line with other browsers. Also, if assistive technologies query for the relation between the caption and table elements, the relation is now LABELLED_BY instead of DESCRIBED_BY.

In addition, some crash bugs were fixed that were found in earlier updates of Firefox, so this version is not only less memory-hungry and faster, but more stable, too. Happy browsing!

As this was a bigger update, it is time to also point out the new stuff to watch out for in accessibility. One thing I already blogged about is the HTML progress element, so I won’t cover that here. Some of the other things to be aware of are:

Seamless plugin accessibility integration on Linux

One feature that’s been baking in a bug forever, but which finally got its final push and made it into code is plugin accessibility for Firefox on the GNOME Desktop on Linux! There is only one plugin currently called Moonlight that actually uses this, but if other plugin authors want to, they can now plug into Firefox and expose their accessible content to Orca and other assistive technologies.

The Windows magnifier and the writing caret

There is a problem in Firefox 4 and 5 that will prevent Windows Magnifier and possibly other low-vision products from tracking the writing cursor properly when on the URL bar or in some other places. We were able to fix this in Firefox 6.

Improvements to the notification popup

The new notification popup that asks, for example, whether you want to save an entered password, has been improved a great deal. For one, it now announces itself to assistive technologies as an alert like the old notification bar did, which means that the text that the user is to be notified about is automatically being read by NVDA, JAWS and others. Secondly, we made the “Close this message” button tabbable again. One thing that we didn’t manage to solve in time is the inconsistency with the menu button that, when SPACE is being pressed on it, doesn’t actually do much, but you have to tab to a secondary regular button with the same label to get the actual function. We’re working on a solution to improve keyboard accessibility for these menu buttons in general, and the notification popups will benefit from this as we do.

ARIA support

In regards to WAI-ARIA, there are a number of changes/additions:

• aria-sort now fires attributechange events when its value is being changed.
• aria-selected is no longer being ignored for ARIA tabs.
• aria-busy now properly fires statechange events.
• ARIA documents children can now properly be queried via accChild API methods.

Others

Other noteworthy fixes are:

• The Untrusted Connection page is again accessible via the virtual cursor in screen readers.
• When deleting text from edit fields, the wrong text was reported through at-spi. We fixed that problem.
• We got rid of the bogus pref accessibility.disableenumvariant.
• The About… dialog is more readable than it used to be.

This means that web devs can use the progress element in web applications, and we will now no longer expose the alternative text enclosed in the opening and closing tags, but the actual visual representation of a progress meter. The accessible object for the progress meter will expose the AccessibleValue interface for all relevant platforms (e. g. ATK and IAccessible2), so that assistive technologies can query for not only the value string but also the float values for:

• the current value
• the minimum (always 0)
• the maximum (if not specified, the default is 1 as in the specification)

By default, NVDA will expose the current percentage as you can test in this example with a current version of NVDA.

Note that there were no changes required on NVDA’s side to support this. So if your screen reader currently supports WAI-ARIA progress meter elements, and the screen reader does not do any funky stuff with their own HTML parsing here, this should just work.

Another note: While we were here, we also fixed a few things regarding XUL:progressmeter elements that were buggy in the past, but were not really uncovered until now. The user visible impact will be minimal for this, but for our code this was definitely benefitial, as we’re now dealing with the proper maximum value for xul:progressmeter elements, which differs from the default max for html:progress.

For Firefox 5, however, the focus has been on polishing and stabilizing what we delivered in Firefox 4.

To that effect, the very first builds of what we call the Aurora channel are now available. The above linked post has more details.

For those of you interested in the very technical details, we have several bug fixes for crashers, inconsistencies when building the accessibility tree, and other not so obvious fixes in that improve performance and stability.

You’re welcome to try out these builds and give us feedback as always! Aurora builds are more stable and feature-frozen builds that get stabilized in the weeks leading up to the next Firefox release. The next Firefox release will be Firefox 5, expected at the end of this quarter.

Enjoy!

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 is that the WebVisum developers do currently not have the resources to port the extension over to Firefox 4.

So if you are a skilled extension developer, please consider donating some of your valuable time to this extension and help port it to FX 4! You’ll be helping a growing part of the Mozilla community continue to participate in today’s web offerings!

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!

Landmark elements mapped to WAI-ARIA landmark roles

We are mapping the following HTML5 landmark elements to accessibles with WAI-ARIA landmark role semantics:

In a second small patch landing the next few days, we will also map the html:aside element to the “complementary” role. This was a small oversight on our part in the first patch.

Both NVDA and Orca will pick these changes up without any additional action required on their parts. Other screen readers will hopefully implement or pick up the support ASAP so web authors can use these new elements without having to worry about support or lack thereof.

The placeholder attribute

This attribute can be used on form elements to predefine text that disappears as soon as the field gets focus. It#s a visual indication of what is expected in the field. If, and only if, the field has no label otherwise, this placeholder text will be used to generate the AccessibleName, the name the screen reader speaks for the field when it gains focus. If the field has a label provided by the label element or an ARIA construct, the placeholder text will be ignored.

Proper events being generated when required/invalid/disabled states change

For a few weeks now, we have had support for the disabled, required attributes and the invalid state evaluation of patterns. Now, if any of these conditions change, we now generate the proper StateChange events to notify screen readers and other assistive technologies.

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:

Speed

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 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)

Panorama

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.

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!

De-XPCOM-ing the Accessible module

XPCOM is used to communicate to the Mozilla core, getting information out of and into it from languages such as JavaScript, Java, Python and C++. Unfortunately, due to historic reasons, modules internal to the Gecko platform also used to use XPCOM to get information. One of these modules was (and partially still is) the Accessible module. XPCOM, while very powerful, also has some performance limitations when querying for a lot of information via QUERY_INTERFACE. Therefore, over the past couple of months, Alex and David have been working on de-XPCOM-ing our module to make it more performant and ready for the future.

To the end user, this will feel more performant especially on complex pages.

Event management

Firing events, and calculating when and how to fire them, has been a big performance killer for the Accessible module in the past. While this was for the most part not particularly noticeable for screen reader users, since we are sort of limited by the rate our synthesizers talk, recently more and more technologies have started using the Accessibility services. Fingerprint devices to enter passwords into Firefox, tablet PC interfaces etc., all use parts of the Accessible module. Since there is currently no way to turn parts of it on or off, as soon as any piece of software accesses just a single accessibility service, the whole engine gets started, and from that point on, all calculations take place as if a screen reader for the blind was present.

Again, since this cannot currently be selectively turned off, and it is not certain that this will ever be possible, it is our goal to make this fact the least noticeable to users. To that end, we’ve started a project called event coalescing. Event coalescing will, as the name suggest, coalesce the stream of events we get from the DOM to only fire those event assistive technologies absolutely need. However, the rules have not been finalized yet, and the code as it is in the current platform based on some initial ideas and feedback, is not very performant, in parts even less performant than in Firefox 3.6, which fires more events but calculates less before sending them.

For those interested in the very technical details, the wiki page for event coalescing is here.

HTML5 form element enhancements

While we’re working hard on improving performance, work in other areas of Gecko is also progressing, requiring us to work together to make sure these enhancements are also accessible. One of these is the work that needs to be done to make new additions that HTML5 brings to form elements accessible. I wrote up a summary with bug links and some information here. If you have feedback on the ideas and proposed roles, you’re welcome to contact us by leaving a comment down here or on the #accessibility IRC channel.

UI work

As the road to the next major release of Firefox is being walked, there are also some UI redesigns happening. One, which has already landed, was the conversion of the tab strip to a real toolbar. My job was to make sure screen readers can still cope with them after this change. Some minor regressions were found, but all in all this still works great.

Another, much bigger change, is the redesign of the Add-Ons Manager to include support for language packs, Jetpacks and other ways to extend Firefox. This work is still underway, and I recently took a first round of testing. Some keyboard navigation issues, and one XUL markup issue that needs to be addressed, but so far, although this is a major UI change, things look very accessible, and I’ll make sure it stays that way.

Other areas

Work that is not directly related to the Gecko platform, but which is also important in the field of accessibility, is, among others:

• Thunderbird 3.1 Beta2 has been released recently. Thunderbird 3.1 comes with the same platform version as Firefox 3.6. Due to the table enhancements in the Gecko 1.9.2 platform, the message list and other areas will be much more accessible to screen readers. Information such as the unread status, the presence of attachments etc. can now be queried using the IAccessibleTable2 interface or equivalent on other platforms. The control is now a real table control rather than a flat ListView on Windows, giving much more accurate semantics.
• The Instantbird team has also done a great job at providing good XUL markup in their multi-instant-messaging client. We’re currently working together to work out some very specific problems with buddy status and others, but Instantbird is a great multi-messenger worth trying!

As you can see, lots of exciting stuff happening, some of it very user-visible, other more technical and very low-level in nature, but all exciting!

Stay tuned!

Update: Article translation

Thanks to community member Patricia Clausnitzer, this blog post is now available in Belorussian. How cool is that! Thank you very much! And BTW: This is a first!

Exposing HTML 5 audio and video elements

The initial exposure for the HTML5 audio and video elements to screen readers landed, causing a minor regression that was quickly fixed. In testing this with NVDA, I found that the button labels weren’t properly exposed and that the slider values were not really useful. The progress meters were showing the number of bytes downloaded, or the milliseconds elapsed instead of useful percentage values. Along those lines, Alex also added a bug to expose proper names for each progress meter, so a screen reader user knows which slider is for what purpose.

Except for the last patch, all others have landed on mozilla-central and will be available for testing starting with the 11th of May nightly build.

To make it clear: This is for those HTML5 audio and video elements that have the controls attribute set, indicating that the internally available controls should be used. Other forms of controlling the media playback, such as from external HTML controls/widgets, already worked in the past since these were not part of the actual audio or video element itself.

Tree view item rectangle exposure

We received a report that in Thunderbird 3 beta on Windows, the rectangles for tree view items were not exposed correctly. The rectangle was too small, not encompassing the whole item. Alex investigated this and fixed the bug, putting an optimization in as a second step for all platforms. This also landed on mozilla-1.9.1 after having baked on mozilla-central for a while, and is available since the May 9th nightly builds of Shiretoko, Thunderbird and SeaMonkey.

The ARIA live region background tab leakage

David has been taking different stabs at bug 444644, with some good results thanks to feedback from Roc and BZ during the Mozilla all-hands week. However, we’re still fighting a situation where the creation of virtual buffers by NVDA is causing the live region updates from background tabs to be spoken again. Investigation is ongoing

Other ARIA-related triage

David’s also been a busy bee clearing out some ARIA-related bugs, gathering feedback here and there, closing others as they’ve been solved by other bugs, etc.

Firebug accessibility

This is not strictly inside the “Accessible” module of the platform, but very closely related to the Mozilla eco system. Accessibility of the Firebug UI has been shaping up very nicely over recent weeks. I spent a fair amount of time last week pounding the different alpha releases to help make sure things stayed in shape.

On Friday, Hans from the Paciello Group, Jamie from the NVDA team and I also managed to get the biggest outstanding problem solved in a very productive meeting on IRC, and that’s the reading of the Firebug JS panel by NVDA. Watch this space for a review once Firebug 1.4 goes to beta!

That’s it for this week, thanks for the read!

In Firefox 3.0.x, we expose the screen text, in this case the word “regression” as the accessible name. This is the piece that screen readers speak when focus lands on the link, and which usually also gets rendered into the virtual buffer.

If there is also a title attribute, in this case “@title attribute no longer exposed on accDescription”, this will be translated into the accessible description of the link object. This is additional information that can be spoken by the screen reader on demand. For example, in NVDA, focus the link or arrow to it in the virtual buffer, and hit NVDA+Tab. NVDA will speak first the name, followed by the fact that this is a link which is linked to something, followed by the description.

The one exception where we do not expose a description is when the screen text and title attribute contents would match. This is considered bad practice anyway, because it is redundant information, and thus we suppress it.

Firefox 3.5b4, and in fact all builds that date back to mid October last year, have a bug in that the title attribute is no longer exposed as the accessible description. Jamie from the NVDA team found this recently and notified us.

I’m happy to report that this functionality got restored in the Firefox 3.5b5pre nightly builds starting with the May 7, 2009 build. Sorry for any inconvenience this may have caused!