Last weeks in the “Accessible” module, May 11, 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!

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

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

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.