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!

The Doc loading stuff

This involved quite a number of complex issues having to do with loading of documents in Firefox, firing the correct events at the correct times, and not firing events when we shouldn’t. For JAWS users on Windows, the mosst visible change of this is that in Thunderbird, every message should now again come up and be read without you having to switch virtual cursor on and off all the time to get messages to read. For Orca users on Linux, Firefox now again fires correct document load finished events and helps Orca to correctly read web sites when it is time to do so.

Focus no longer getting fired on items in non-focused widgets

OK, let’s start with an example: Have you been in the Add-Ons manager in Firefox recently? if so, you’ve probably noticed that, when you switch tabs from Extensions to Themes and back, that when you return to Extensions, your screen reader tells you something about a highlighted Extension. Firefox tricks screen readers into thinking that focus actually shifted. However, focus did not shift, but a focus event was fired when the selection was shown on the list of extensions.
A different example is in Thunderbird, where if you were in Inbox, then went to another folder, then arrowed back up to Inbox, the screen reader would tell you that focus shifted to the message you had last selected in the Inbox folder. Again, focus actually does not shift, but an event is fired for the widget not currently in focus.
Aaron and I put a stop to that happening. As a result, reading should be much more consistent now when you work in both Firefox and Thunderbird. Screen readers should no longer get confused as to where the focus actually is.
By the way: This issue had been around since Firefox and Thunderbird became accessible in their respective 1.5 versions. It was annoying as hell to me, and I am very glad we finally got that one nailed and dealt with!

Tree items updating when they change

When a tree item changes visually on the screen, like a newsgroup or IMAP folder updating its number of total and unread messages in Thunderbird, assistive technologies were until recently not notified of these changes. One had to shift focus away from, and back to the tree view to get the correct picture.
Not any more! Alexander Surkov, one of the great developers working on the accessibility module, has fixed this problem and made sure that ATs can now update when there’s a change.
This again makes working in Thunderbird, but also when you deal with changing bookmarks in Firefox, much more convenient and fluent.

If you haven’t already done so, I would suggest you update to the latest nightlies of both Firefox and Thunderbird on your respective platforms and try out these great improvements!

The problem is: Screen readers such as JAWS usually do not know what to do with these language names. They’re familiar with regular language names such as “en-us” or “de”, but not “x-western” or the like. As a result, the “language” is indicated with its attribute value. JAWS would also do this if you used Eloquence as your speech synthesizer, but encounter a web site that is tagged with lang=da” for the “Danish” language. JAWS would indicate to you that the web site is meant to be in Danish, but that the current speech synthesizer does not support this language. If you used RealSpeak and had the Danish voice installed, that voice would be then switched to, and the Danish text read out in the native tongue.

So what do we do to get rid of these announcements? There are two possibilities:

Turn off language detection for Thunderbird

One possibility is to turn offf the Language Detection feature for Thunderbird alltogether. The steps are rather simple, but you’d lose language switching if you read a blog feed or properly language-tagged HTML message. To turn off Language Detection, in JAWS you would do the following:

1. Start Thunderbird.
2. Press INSERT+F2 to bring up the List of Managers.
3. Chooose the Configuration Manager entry.
4. Inside Configuration Manager, go to the Set Options menu, then select Text Processing.
5. Within the Text Processing dialog, tab to the checkbox that says “Detect Languages”, and uncheck it.
6. Press ENTER to accept the changes, CTRL+S to save the configuration, and ALT+F4 to close Configuration Manager and return to Thunderbird.

See the relevant steps if you’re using a different screen reader and also want to turn off Language Detection.

Make those encoding languages simply use your default synthesizer language

A less drastic, yet a bit more involved method is to introduce those encodings to JAWS by making them simply use the default Eloquence language you’re using.

JAWS stores language mappings in a [ShortName Language Aliases] section in the DEFAULT.JCF configuration file. There, language attributes such as “en-us” are mapped to Eloquence languages such as “American English”. This section can be enhanced or changed in application specific JCF files. To enhance the Thunderbird JCF file with the encodings that you no longer want announced:

1. In your User Settings directory, locate the Thunderbird.jcf file. If it is not already there, create one using NotePad or your favorite plain text editor. Note: You can go to your JAWS User Settings directory by going to Start Menu, All Programs, JAWS 8.0 (or 7.10 or 9.0), Explore JAWS, Explore My Settings.
2. In that newly created or existing Thunderbird.jcf file, add the following lines:
   [Eloq Language Aliases]
x-western=American English
x-unicode=American English
x-central-european=American English
x-cyrillic=American English
3. Save the file.

Let’s break this down a bit so you know what you just pasted:

• The [Eloq Language Aliases] section heading tells JAWS that this is a Language Aliases section for Eloq, the short name for the Eloquence synthesizer.
• To the left of each equals sign is the value that’s being put in the “lang” attribute, and which is not recognized by JAWS by default.
• To the right of the equals sign is the Eloquence language that is to be used whenever this “lang” attribute value is encountered.

Happy reading!