Archive for the ‘Thunderbird’ Category

Thunderbird 3 is coming out soon, and it’s accessible!

Thursday, November 19th, 2009

The release of Thunderbird 3 is just around the corner. Aside from all the great new features Thunderbird 3 has in general, its accessibility story is also one which should be celebrated once the release has happened.

Thunderbird 3 is based on the Gecko 1.9.1 platform, which is the same version that Firefox 3.5 is based on. As such, Thunderbird 3 has learned all the great new features of the platform, many of which have a significant impact on users with disabilities. Please allow me to highlight the major improvements and new features.

Support for new accessibility APIs

Thunderbird 3 supports the IAccessible2 standard on Windows. IAccessible2 is a major enhancement to Microsoft Active Accessibility (MSAA), which allows assistive technologies to directly interact with the rich content an HTML e-mail message can have, through a defined set of APIs. Screen readers for the blind, for example, no longer need to rely on old-school screen-scraping methods to try and guess what the application is showing. Instead, headings, block quotes (such as in quoted messages) etc. are all identifiable without question. Font and styling information is available as well. NVDA 2009.1, Window-Eyes 7.1 and JAWS 10 and above take advantage of these technologies already and offer a hugely improved experience for their user bases over what Thunderbird 2.0 had to offer.

This also includes support for in-line spell checking. If enabled, screen readers can identify misspelled words just like in Firefox, and users can go and correct their mistakes on the fly without having to invoke the extra spell checking dialog.

Accessibility on the GNOME Desktop

Thunderbird 3 is accessible to Orca users on the GNOME desktop in Linux. While Thunderbird 2 offered close to no accessibility support, Thunderbird 3 offers a wide range of accessibility to visually impaired users.

Also, the support for ATK/AT-SPI allows other assistive technologies such as GOK (GNOME On-screen Keyboard) to interface with Thunderbird and allow the use by people with motor impairments.

Tabbable and properly labelled message headers

When reading messages, most of the header fields of a message are now reachable via the tab key. This is a huge improvement for any keyboard user. Access includes the “star” that allows to quickly add a contact to the address book or to edit a previously added contact.

All these fields and controls also have proper accessibility labels so that screen reader users immediately know what they’re interacting with.

One known problem is that the multi-functional “reply” control currently isn’t part of the tab order.

Better support when composing messages

Aside from the above mentioned API improvements, the UI also received some love to better communicate the happenings when filling out the from:, to: etc. fields while composing a message. Selecting a different field type now also does not throw newer versions of screen readers into limbo or confused states any longer. Working with the Contacts side bar is also supported.

Over-all UI improvements

Over-all, the various dialogs in Thunderbird such as Tools/Options, Tools/Account Settings and others have received a major accessibility overhaul esp with regards to properly labeling textboxes, radio groups and other XUL widgets so screen reader users get accurate information while tabbing through. Infact, a Thunderbird XUL UI fix was my very first patch when I started contributing to Mozilla. :)

New UI features were also made accessible

New UI features such as the all-new facetted search were also made largely accessible. The new Search, for example, makes heavy use of WAI-ARIA to allow both an appearance that’s visually appealing and keyboard and assistive technology communication that’s accessible. The one exception in this new piece of the product is the graph that shows the search results over time. This is based on SVG, which is totally inaccessible at the moment.

A call-out to Thunderbird extension developers

With the above improvements now being in place, it is equally important for Thunderbird extension developers to follow these simple rules to make their extensions accessible, as it is for developers of extensions for Firefox. DOM Inspector offers an accessibility view which allows you to check whether your XUL has proper labels for textboxes and other good markup! Also, don’t be shy to ask questions! The accessibility team hangs out on the #accessibility channel on irc.mozilla.org and will be happy to assist!

A few known problems remain

As always, nothing can be perfect, but we’re striving to be as perfect as possible. Having said that, there are a few issues that remain, but for which fixes are already visible on the horizon:

  • When viewing messages as threads, the fact whether a thread is expanded or collapsed is not yet communicated to screen readers. This will be different once a new version of Thunderbird switches to using Gecko 1.9.2 or later, which includes the all-new tables support.
  • The same is true for the “subscribe” dialog for newsgroups and IMAP folders. Right now, screen readers do not yet get the state whether a certain folder is checked or not. This will also change with a switch to the new Gecko platform.
  • Folders in the folder pane cannot be navigated to using first-letter navigation. I’m hoping we’ll find a solution to this often voiced request in the future.
  • The picker for rearranging the columns in the message list isn’t accessible via the keyboard yet. You can use the mouse emulation of your screen reader to get to that button to the right of the column headers to access options.

Thanks!

I’d like to thank everyone who has been writing to me over the past two years pointing out Thunderbird accessibility issues. As was expected, these actually made up a higher volume than Firefox since there were more UI-related issues. Keep the feedback coming!

I’d also like to extend a huge thank you to the team at Mozilla Messaging and the voluntary contributors who all helped with implementations, reviews, suggestions and advice while improvements for Thunderbird 3 were requested, triaged and acted upon. I really feel that accessibility is being taken seriously, and I honestly hope that a lot of users worldwide will show their appreciation by downloading and using Thunderbird 3 when it comes out! I’ve been using it for over 2 years now while it was being developed and haven’t regretted making the switch!

Keep up the good work!

Last weeks in the “Accessible” module, May 11, 2009

Monday, May 11th, 2009

Sorry for being a slacker in updating you guys regularly on what’s been happening! But we’ve been quite busy at getting some stuff finished and hopefully ready for inclusion in 3.5. I already posted about the return of the descriptions last week. So here’s what else happened since my last report:

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!

NVDA 0.6p3 released, quite some news for Mozilla users!

Monday, February 16th, 2009

As you may or may not have read, the NVDA team released NVDA 0.6p3 last night. Below, I’d like to highlight those of the changes that are of special interest to those using Mozilla products such as Firefox or Thunderbird with it.

Support for text attributes and spell checking

NVDA takes advantage of the new text attribute and spell checking support of Gecko 1.9.1, which will enable exposure of the inline spelling features of Firefox 3.1 and Thunderbird 3.

  • NVDA+F will report things such as font, point size, styles such as bold etc.
  • When reading through text character by character or word by word, if a spelling mistake is encountered, NVDA will announce it, and also where it ends.

This feature will not work with Firefox 3.0.x, as the version of the Gecko platform used with this version of Firefox does not have accessibility information for text attributes and spell checking.

Automatic switching of focus mode

When browsing web pages in Firefox, certain controls such as textboxes, comboboxes etc. can now automatically cause NVDA to switch to focus mode without the user having to press Enter. Escape or NVDA+SpaceBar can be used to turn focus mode off and browse mode back on. Interacting with forms is much more seamless this way, so I recommend everyone to try out this new mode! You can configure it through the Virtual Buffers preferences dialog.

Better reading of the notification bar

Firefox, and to a lesser extent Thunderbird, make use of the notification bar to convey information without interrupting the user’s flow of work. NVDA 0.6p3 has improved the way it reads these important yet unobtrusive notifications by suppressing double-speaking, and other tidying up of the whole process.

Use NVDA to explore the accessible hierarchy of your web pages

From the What’s New document:

* new: In virtual buffers, the review cursor now reviews the text of the buffer, rather than just the internal text of the navigator object (which is often not useful to the user). This means that you can navigate the virtual buffer hierarchically using object navigation and the review cursor will move to that point in the buffer.

This means that the navigator commands (NVDA+NumPad8, NVDA+NumPad2, etc.) will work inside the virtual buffer of a web page, take the review cursor with them as you go, and allow you to bisect your page accessible node for accessible node, in case you wonder why your users complain about accessibility issues.

This makes NVDA not only suited for blind users relying on access to the Windows operating system and its applications, but also for web developers who need (or want) to get a feel for what their web page or application appears like to a blind visitor.

Miscelanious fixes

The below is a small collection of other notable changes that don’t warrant an own section.

  • fix: Fix the issue where tabbing to a checked checkbox in a Mozilla Gecko virtual buffer and pressing space would not announce that the checkbox was being unchecked.
  • fix: Correctly report partially checked checkboxes in Mozilla applications.
  • fix: When reading with the mouse, text in Mozilla Gecko edit fields should now be read.

In Summary

If you run the beta or nightly builds of both Firefox 3.1 and Thunderbird 3.0 AKA Shredder, you should be able to take advantage of all the new features in NVDA 0.6p3. If you use Firefox 3.0.x, you’ll be missing out on the new spell checking and formatting feature, and if you still use Thunderbird 2, most of the good support for Gecko 1.9 and above will not be available to you since that version of Gecko doesn’t work well with NVDA any more.

Go get it, and give it a whirl!

Support for text attributes and spell checking is coming in Firefox 3.1!

Thursday, July 17th, 2008

For those of you on the bleeding edge, namely on the Firefox 3.1a1pre nightly builds, the Friday’s nightly build will include one big new feature in accessibility for 3.1: Text attributes and spell checking support!

This means that assistive technologies now have access to the attributes of any text run on a page via the IAccessibleHyperText::getAttributes or ATK/AT-SPI equivalent API calls.

For example, running today’s nightly build of Firefox 3.1a1pre on Windows, visiting my blog’s main page, bringing up Accessibility Probe, and navigating to the link below the Heading Level 1 that says “Marco’s Accessibility blog”, a call to IAccessibleHyperText::GetAttributes on the link accessible will get you this result:


getAttributes(1) = NULL

Not very fancy, huh?

Tomorrow’s build, however, will yield a completely different result:


getAttributes(1) = org.eclipse.actf.accservice.core.win32.ia2.IA2TextSegment[text=font-style:normal;language:en-US;text-align:center;font-size:40px;background-color:transparent;font-weight:bold;text-indent:0px;color:rgb(255\, 255\, 255);font-family:'Trebuchet MS'\,'Lucida Grande'\,Verdana\,Arial\,Sans-Serif;text-underline-style:underlinesolid;,start=0,end=26]

So, not only do you get information about the font-family, style, color and backgroundcolor, you also get the language this text is in, the underline style, the font-weight etc.

Also when editing, and you misspell something, as soon as you hit spacebar and the red underline appears, the attributes of that word will change and will include “invalid:misspelling;”, indicating that this word is invalid in that it is misspelled. Of course, an according IA2/ATK event will be fired accordingly! Note that the denotation of this may change if the IAccessible2 and ATK groups decide on a different notation for misspellings. Right now, it follows the aria-invalid convention, and we hope that this will be accepted by the groups.

Over the next few weeks, we’ll fine-tune this feature to be a bit more performant and also iron out any last details that might come up.

But if you’re an assistive technology vendor and you’ve been waiting for us to finally expose these text attributes, now is the time to try them out and provide feedback.

Note that Thunderbird and other projects that will be moving to use the Gecko 1.9.1 platform will also get this feature. This means that inline spell checking notification can also be supported for those apps soon!

[Update]: This patch made it into Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008071803 Minefield/3.1a1pre just fine. So go take a peek!

Extension developers: 5 things to make your extension more accessible

Tuesday, July 1st, 2008

After my first reach out to extension developers, Aaron and I have brainstormed and come up with the 5 most common things you as an extension developer should consider to make your extension more accessible. Here’s what we came up with:

  1. Make sure your extension is easily discoverable using the keyboard. A common pattern is to use an icon in the status bar or on a toolbar to launch an extension, but this is not possible to do when using only a keyboard, not a mouse. The easiest and most discoverable way is to add a menu item to the Tools menu to make sure keyboard users can launch it.
  2. Labels that are not associated with the control they’re labelling. As a result, screen reader do not know what a particular textbox, menulist, radiogroup etc. is for. Associate your controls with their labels by using the xul:label’s control attribute pointing to the id of the actual control. Works with xul:textbox, xul:menulist, xul:radiogroup and others and is an absolute accessibility must.
  3. Xul:page elements that are missing a title attribute. If you use xul:page elements in your chrome, make sure to give them a title attribute that is meaningful. That makes sure screen readers for the blind can properly pick them up and not read the chrome URL instead.
  4. Make sure any place holders are in the tab order by using
    <a href="#">

    or

    <div tabindex="0" role="button" onkeypress="if (event.keyCode == event.DOM_VK_ENTER) { ... }"/>

    Any items that are put into a web page to enhance the user experience, and which allow interaction, must be keyboard accessible. A good example is what Adblock plus does with the ability to block certain elements like Flash animations.

  5. Make sure all event handlers react to both a mouse and keyboard interaction schema. In fact, you should always completely test your extension without touching the mouse. Some common problems are:
    • For opening context menus, use the oncontextmenu event handler or the context attribute. Do not code context menus to open specifically on the click of the right mouse button, since this will exclude the use of the keyboard. Both oncontextmenu and context will react to the operating system specific context menu triggers.
    • Provide keyboard equivalents for mouse-dependent functionality such as mouseover, mousemove, or ondoubleclick. For example in a listbox where one can double-click a list item to perform a certain action with it, also allow the Enter key or an equivalent keystroke to perform the same action. For Drag And Drop actions, provide context menu alternatives, Copy And Paste, etc.

I hope these are helpful hints for you to make your extension, XULRunner application or the like more accessible to everyone!

For more information, see the XUL Accessibility guidelines on MDC.

Extension developers: Give your extension an accessibility checkup for Firefox 3!

Sunday, May 18th, 2008

As Firefox 3 is fast approaching, and you extension developers are getting ready to update your products, it is a good time to also give your extensions a thorough accessibility checkup. Can the extension be launched without using a mouse? Are labels properly associated with the controls they are labelling?

To help you out, there are XUL accessibility authoring guidelines available that cover these and other topics extension authors should be aware of. Firefox 3 is much more accessible than previous versions were, also on one additional platform (Linux), so the userbase that may be using your extensions without a mouse and/or with the help of assistive technologies is growing!

Over the past few weeks, I’ve approached a few developers of extensions I use frequently to suggest some accessibility improvements. Here’s a list of extensions who have become more accessible recently:

  • Enigmail, an extension for Thunderbird and SeaMonkey that allows you to sign your messages with OpenGPG, has become much more accessible when used with Thunderbird or SeaMonkey Trunk.
  • ScribeFire, a blogging extension for Firefox and SeaMonkey, has added a couple of good enhancements recently that make it much more useable with the keyboard. I’ve proposed a few more enhancements, especially missing label/control associations, so upcoming versions will hopefully see more improvements there!
  • ChatZilla, an IRC client for Firefox, and part of the SeaMonkey suite, has received a big number of improvements over the past couple of months. I helped test these enhancements and worked with the authors on a couple more keyboard navigation and control labelling issues.

I’d like to thank these extension authors for being so responsive and willing to make their extensions more accessible to a wider audience! I found that often it was only a missing resource like the above mentioned authoring guidelines that can help make an extension more accessible. So, if you are an extension developer, go check them out!

If you have any questions about ways to make your extension more accessible, feel free to contact me either here on my blog, on the #accessibility channel on IRC, or by sending mail to the mozilla.dev.accessibility newsgroup. I’m sure someone from the growing accessibility community or myself will be able to help you out!

A lot of small but noticeable usability improvements

Friday, February 29th, 2008

Beginning of this week, Aaron Leventhal, who is the module owner for Mozilla accessibility, and I met in Stuttgart, Germany to work on some hard to reproduce and nagging issues. Among one big issue having to do with how document loads are being processed, we also fixed a number of smaller, but no less important problems that vastly improve usability in Firefox 3 and Thunderbird 3 alphas.

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!

Funny language announcements when reading messages in Thunderbird

Thursday, December 20th, 2007

Have you ever noticed announcements like “x-western” or “x-cyrillic” when reading messages in Thunderbird? JAWS and possibly other screen readers that support the detection of language attributes in HTML content may announce this. The reason is that Thunderbird puts the encoding of a message into the “lang” attribute for each paragraph of content.

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!