Archive for the ‘ARIA’ Category

Apple’s iOS 4 supports WAI-ARIA landmarks

Tuesday, June 22nd, 2010

This is, I believe, my 100th post on this blog, and I’m using it to announce that Apple’s iOS 4, released yesterday for the iPhone and iPod Touch, supports WAI-ARIA landmark in the VoiceOver screen reader. VoiceOver has had, since its inception, a feature called the rotor. The rotor allows users to set a particula rweb element by which the one-finger-flick up and down gesture moves in mobile Safari and other apps that use a web display. This feature is now highly customizable. Not only can you enable and disable certain features (for example if you never want to navigate by graphics, you can disable it completely and it won’t show up in the rotor). But the rotor settings also include a new feature called landmarks. This rotor setting is disabled by default, but can be enabled through the Web settings sub window of the VoiceOver settings. Once enabled, and the user switches to it via the rotor gesture, navigating by WAI-ARIA landmarks on a page works very nicely. The one thing that VoiceOver does not do yet is announce the type of landmark, be it banner, main, search, complementary etc. Furthermore, the landmarks also include what is called automatic web spots in the VoiceOver on Snow Leopard for the Mac. So not only do you jump to the actually marked up landmarks, but a few more spots on a page Apple deems interesting. In my experience, these usually are quite useful spots, too, so this doesn’t harm the original landmark feature at all.

It is fantastic to see that WAI-ARIA is getting more and more adoption in mainstream products. VoiceOver is available on any iPhone 3G S and iPhone 4, as well as the newest generation iPod Touch models (32 and 64 GB), and the iPad. The iPad does not include the landmarks feature yet, since its iOS hasn’t been updated to version 4 yet.

Further reading

Easy WAI-ARIA tip #4: Landmarks

CSUN 2010 recap

Monday, March 29th, 2010

From March 22 to 27, the 5th Annual International Technology & Persons with Disabilities Conference took place at the Manchester Grand Hyatt Hotel in San Diego, California. It is most commonly referred to as CSUN 2010.

The Mozilla Foundation had a booth at CSUN for the fourth year in a row. David, Alexander Surkov and I were present to man the booth, talk to people, and also participate in a couple of general sessions at the conference to gather information and news, and also to network.

Adobe announces broad range support for IAccessible2

One of the biggest news bangs to come out of the conference is Adobe’s announcement to support the IAccessible2 and WAI-ARIA standards in thenext versions of their Flash and Flex products. Both these standards were heavily driven by, among others, Mozilla, IBM and several assistive technology vendors such as NV Access of the NVDA project. Support for the native GNOME and Mac OS X accessibility APIs is also in the works.

In addition, Adobe announced that they will also include IAccessible2 support in their Acrobat and Reader products.

This means that another big player in the software industry is coming forward and supports these widely recognized standards. It is good to see Adobe getting behind the over-all accessibility efforts and helping to drive adoption in this manner!

Three Firebug-related sessions

Hans Hillen of the Paciello Group had two very successful talks about the UI accessibility support in Firebug. The first was a demo of many of the features, using NVDA as the screen reader to demo them. the second was a use-case talk, where Hans explained in some more technical detail how he went about making the Firebug UI accessible to screen reader users.

Both talks were very well received. The first one had quite a broad audience, while the second audience was smaller, but very focused and involved.

In addition, Jon Gunderson of the University of Illinois at Urbana-Champaign held a talk on the Accessibility Testing Extension for Firebug. But unfortunately, due to my travel schedule, I did not have a chance to visit this talk.

It was good to see two Mozilla grantees doing talks at this year’s CSUN, giving visibility to the many facets of Mozilla’s accessibility strategy.

Newer mobile accessibility technologies marching forward

Apple, RIM and Google, the three vendors of mobile devices with well-defined accessibility APIs, all had well-visited talks at CSUN. In addition, I am aware of at least two talks involving the accessible iPhone and iPod Touch 3rd generation that put these technologies to good use to provide a new generation of assistive software, built on mainstream devices.

Well-visited booth

The Mozilla Foundation booth was well visited on all three days that I helped staff it. Comments and questions ranged from the very flattering “I love Firefox and I love what you guys are doing for accessibility!” to “What’s a browser vendor doing at this conference?”. When we then explained why we attended, many of them were keen on trying out Firefox when they got home or back to thheir hotel rooms.

Also, this conference made quite a number of people aware of other Mozilla products than Firefox. While many had heard about Firefox, they had not heard at all about Thunderbird before. But with the better accessibility in Thunderbird, we can now change this and spread Thunderbird in the accessibility community even more!

I personally had a very moving moment on Friday when a deaf/hard of hearing gentelman and his interpreter stepped up to our booth. He was very interested in what we do for accessibility. Before I knew it, I was talking to him through his interpreter, but wasn’t actually noticing it until well into the conversation. At some point, I mentioned Thunderbird, at which point he started joking about the Ford Thunderbird. David, who was present at this conversation, can probably tell a bit more about this, since this was very visual and I only got a third of what he was actually meaning. :)

David and Alex also took a lot of pictures, which they’ll hopefully upload and share very soon so you all can get a better picture about what CSUN 2010 was like! Mozilla received a big big chunk of good attention, our funding of other accessibility-related open-source projects such as NVDA, Orca and others, definitely is being recognized in the industry as being exemplary. Also, we got a very nice compliment from a gentleman from the Office of homeland security, who told us that he thought our Voluntary Product Accessibility Template is among the best he has encountered so far.

One big failure is there, though

One big problem, which I think should not go unmentioned, is the lack of good internet connectivity in the exhibition hall. For a 2010 information technology conference, having no useable WIFI connection down in the exhibition hall at all is simply unacceptable. The internet connections that were offered were hideously priced, almost like in the mid 1990s when internet connectivity was still not as common as today. Up in the session rooms, the situation was a bit better, at least there were hotspots one could use most of the time.

For next year, one thing I’d like to see is a well thought-through strategy for free wireless internet connectivity throughout all conference locations. A technology conference lives and breathes with the buzz people can create around it by tweeting, uploading pictures etc. People with disabilities are no exception, and instead of roadblocking it, the responsible powers at CSUN should embrace this trend and encourage people to get the word out as easily and hazzle-free as possible!

In summary

I can only say that it was worthwhile going to CSUN yet again, and I am hoping we’ll have a chance to participate next year as well!

Easy ARIA Tip #5: aria-expanded and aria-controls

Wednesday, February 10th, 2010

In this Easy ARIA tip, I will give you a bit of a hint on how to make not too complex, but still dynamic, menus accessible. We often encounter menus that pop in and out upon a mouse click or activation of an element using the keyboard.

An example can be found at this German blog site. Look for the “Archive” heading, which is a clickable element that shows or hides the archive choices offered by this blog.

Right now,NVDA speaks this item as “clickable”, so the blind user already gets notified that there is a possibility here to press Enter on the item and something will happen. Now how cool would it be if, in addition, NVDA would tell me that something will be expanded, or is currently expanded, and I can press Enter to collapse it?

Fortunately, we have WAI-ARIA to rescue us from this desire! :)

The global attribute aria-expanded is used for exactly this purpose. It takes one of two values: true or false. true means a section that this element denotes is currently expanded (visible), false means the expandable section or items is/are currently collapsed (invisible). In the above example, aria-expanded must be defined, and by default set to false. In the Javascript that handles the expansion and collapsing of the categories, another code block must be added to touch this attribute and change its value to true when the categories are made visible, and back to false when they are made invisible. Since there is already JavaScript in place to handle the visibility of the categories, this can be plugged in very easily.

There is one more piece to this: Modern screen readers such as NVDA, Orca or modern versions of the commercial screen readers, can also make use of another attribute that tells which element is actually being affected. In this case, the list of categories. This is done through an attribute called aria-controls. The value of this attribute is the ID of the affected element and is set either once or whenever the controlled element changes. In this example, the value would point to the html:ul element with the ID of “archivliste”. The attribute gets set on the same element that also gets aria-expanded and does all the magic. Screen readers then know which element is being referenced, by something called Accessible Relations.

In summary:

  • aria-expanded receives a value of “true” when the elements in question are visible. It is set to “false” when those elements are actually not visible.
  • aria-controls is set to the ID of the top level element that gets made visible or invisible.

Both attributes get set on the element that actually does the magic (the same element that has the onclick handler or click/keyboard event listener).

[Update] One word about placement of the expandable items: Ideally, they should be following the item that expands and collapses them, as can be seen in the example above. The list of archive months follows the heading that has the click handler to expand and collapse it. The result is that screen reader users can expand the items and simply down arrow without having to look for the new content. This makes it feel very natural and efficient.

Also, some screen readers have intelligent detection of dynamic changes and speak them automatically. This is sort of what WAI-ARIA live regions do, but without the explicit live region markup. The result is that upon expansion, the new items might automatically be spoken, which might be undesirable. For example, this list of months would be very undesirable to be rattled off by the synthesizer whenever the list gets expanded. To prevent this, another attribute can be applied, aria-live with its value set to “off”. This prevents supporting screen readers from ever treating this particular region as a live region. This attribute, however, in the example above, would go on the html:ul element, not the element that expands and collapses the list.

Thanks to Aaron Leventhal for these two excellent points![/update]

Previous Easy ARIA Tips

  1. aria-required
  2. aria-labelledby and aria-describedby
  3. aria-invalid and role “alert”
  4. Landmarks

Easy ARIA Tip #4: Landmarks

Saturday, October 31st, 2009

Yes, they’re back! This is the fourth Easy ARIA Tip in a trilogy of Easy ARIA Tips. :)

This week, WebAIM published the results of their second screen reader survey. One of the things to note for me was that not many users seem to be aware of a feature in the WAI-ARIA (Accessible Rich Internet Applications) specification called landmarks. This article aims to provide an easy to follow guide to implement landmarks in a matter that makes sense, in the hopes that more folks will start using them in their web projects and more screen reader users will take notice and utilize them in their daily surfing experience.

What the heck are they?

WAI-ARIA landmarks are a new method of providing easy navigation to certain points or hot spots on a page. Traditionally, this is being accomplished by providing visually hidden “skip links” to various anchor points. A commonly encountered one is the “skip to main content” or similarly named link that provides a quick way to navigate past all the navigation, search etc. features a site may have, and start reading directly at the main content of a page.

However, as the above cited survey results show, skip links aren’t nearly as important for most screen reader users as a good heading structure is. Skip links are usually also very useful for keyboard users (who need not necessarily be screen reader users).

However, one of the biggest problems is that “skip links” aren’t consistent. They might be called “skip to…” or “jump to …”, “skip past …” etc., and they may vary in what features they provide. This may also cause complaints for usability. I’ve been demoed pages that provide 20 or so skip links at the top before an actual link to a site feature is encountered. Needless to say, it didn’t provide a skip link for the skip links. :)

WAI-ARIA attempts to rectify that by standardizing a certain number of navigational anchor points to allow easy and quick access to portions of a page that are frequently needed.

How are they added?

Landmarks are added to a page by specifying the role attribute on certain HTML elements. If you view the source of this blog page, for example, and search for the word “role”, you’ll find it added to some HTML elements that start blocks of interest. The addition is very simple, the only thing that really needs to be done is give some thought about placement of the landmarks.

Screen readers such as JAWS version 10 and above, Orca, NVDA from version 2009.1beta and above recognize WAI-ARIA landmarks in Firefox 3.0+ and IE 8. They usually provide one of their quick navigation keys to navigate to each landmark in turn, and JAWS and NVDA also provide lists of landmarks on a page. NVDA even shows the nesting of landmarks.

The different landmarks

Below is an explanation of the intention of each landmark from a practical standpoint.

banner

The banner landmark denotes the portion of a page where a company logo, site slogan or the like would be found. Providing this landmark will allow a screen reader user to easily access that information to, for example, copy the text info to paste somewhere for providing information, correct spelling etc.

complementary

the complementary landmark denotes a section with complementary information to the main content of the page. For example for a page that shows a single blog post, the complementary information could be links to related articles.

contentinfo

The contentinfo landmark denotes the section of a page that contains the copyright notice, link to privacy statement etc. It can also be used to denote a section with footnotes, but I’ve not seen an example of that yet.

main

The main landmark denotes the section of a page that contains the main content. This is equivalent to the target of a “skip to main content” link. On a page showing a single blog post, this is obviously where the title of the post is which starts the article.

Note that it is explicitly stated in the WAI-ARIA spec that this landmark should only appear once in a document. I believe the reason is obvious: If you had more than one main content on a single page, you should split that into two pages. :) All other landmarks can appear more than once (in fact it makes sense for them to do so in some circumstances), but main should only appear once.

navigation

The navigation landmark denotes one or more sections of a page that contain navigational items. Usually these are links to various features of your site.

search

The search landmark denotes the section of a page that starts your search feature. This is not necessarily the search textbox itself, but starts usually at the search form level to also include advisory information or the label you might want to include for your search.

application

The application landmark is a special landmark in that it does not just provide an anchor point but also usually causes different screen reader behavior. The application landmark denotes a section of a page that should not be treated like just any other ordinary web content, but provides features that are more closely related, in concept, to what a desktop application would provide. An example is the Search feature on the Yahoo! pages that provides a very rich experience with widgets not found in standard HTML.

When a screen reader encounters such an application section, what happens is, at least on Windows, that they switch out of their virtual document reading modes into a more interactive mode called “Focus mode” or “forms mode”. In addition, contrary to normal form elements, they usually prohibit switching back to virtual mode as long as focus is inside the application section. The user is required to interact with whatever keyboard navigation and other feedback (for example through the use of live regions) the web app author provided.

Having said that, the application landmark is usually not found when it comes to providing simple navigation anchors. When the application role is used, you should expect the web author to also have implemented an accessible rich internet application experience and can expect widgets to appear you wouldn’t find in your standard HTML element. If someone uses the application landmark without providing real rich widgetry, it’s probably a bug on their part and they’d most likely appreciate a friendly hint. ;)

Personally, I don’t consider application to be just another landmark role. For me, application clearly belongs more in the space of true rich internet application development. I just mention it here because it is listed in the same section in the specification.

What about validation?

Oh yes, that may be important to some! The current W3C validator doesn’t validate XHTML+ARIA or HTML+ARIA yet, which includes the landmarks. However, if you don’t care, or you can convince your client that landmarks are a viable new feature for their sites, Steve Faulkner of The Paciello Group has worked out a way to validate the landmarks.

Further reading

A slightly different approach to explaining the WAI-ARIA landmarks has been done by Steve Faulkner of The Paciello Group in January of this year.

Previous Easy ARIA Tips

  1. aria-required
  2. aria-labelledby and aria-describedby
  3. aria-invalid and role “alert”

NVDA 2009.1 beta, what’s in it for Firefox users?

Tuesday, October 27th, 2009

En route to their 2009.1 final release, the NV Access team has released 2009.1beta1. Here’s a run-down of new features since their 0.6p3 release, of which I did a similar post. This does not cover everything, just the bits that impact the use of NVDA with Firefox and other Mozilla-based products.

WAI-ARIA landmark support

When in virtual buffers, D and Shift+D can be used to skip between WAI-ARIA landmarks. Landmarks are also announced while reading a web page. The new Elements List also has a section for landmarks. Even the possible nesting of landmarks is announced.

WAI-ARIA Drag And Drop support

NVDA now supports WAI-ARIA Drag and Drop, with some help from Firefox 3.6 and later.

More features

  • Sounds can now indicate the switching on and off of Focus Mode. Sounds are the default setting, but you can switch back to using indication via speech.
  • N and Shift+N can be used to skip past blocks of links to the next/previous block of non-link text.
  • On pages that take longer than 1 second to load, you can interact with your system while the page is being rendered. NVDA will tell you that it is processing the page, and it will no longer block the system while doing so.

Also, the Flash and Java interaction model discussed in an earlier post are included in this beta.

For more new feature information, I suggest studying the What’s new document and try out the beta for yourself!

You’re a table, and I don’t care what lies underneath

Friday, September 11th, 2009

Over the past couple of weeks, Alex, David and I have been hard at work refactoring, discussing, and implementing better support for accessible tables in Gecko. Some of this has seen the light in Firefox 3.6alpha, but the heart of the work is currently only in mozilla-central (AKA Firefox 3.7). Update: As of October 29, these changes have also been ported to the Firefox 3.6 AKA the Gecko 1.9.2 branch and will be in the final release of Firefox 3.6. It will not yet appear in the upcoming release of Firefox 3.6b1, since that was branched off before we landed the IAccessibleTable2 support.

The goal was to:

  1. Refactor our code to become more maintainable.
  2. Expose the same kind of interface to assistive technologies regardless of what lies underneath is a true HTML table, an ARIA table, an ARIA data grid, a XUL tree table etc. There are so many commonalities that ATs should be able to expect similar, if not identical, information from any of these table types.
  3. Implement the IAccessibleTable2 interface that was defined within the IA2 group over the summer.
  4. Get rid of many “todo” items in our Mochitest unit tests.

For The Minefield (Firefox 3.7a1pre) nightly build that will come out today, Friday September 11, the patch that implements IAccessibleTable2 has landed. All header/table cell relations are now defined through proper method calls rather than special forms of accessible relations. This was a big patch with almost 550 kb in size. A quarter of this were IDL changes for IA2, but the rest was all code that had to be reviewed and super-reviewed. It’s definitely the biggest patch I’ve been working on so far since I started working for Mozilla.

Over the past few weeks, Alex also refactored our XUL tree exposure to better meet our goal. With 235 KB, this was the second biggest patch I have been working on so far.

Other changes that went in concern selection of cells, rows, unselecting parts of tables etc. Some of these have caused our long “to do” item list of around 80 items to drop to a mere 7 throughout the whole a11y test suite. The table tests were among the first written when we started doing automated tests on a11y some 20 months ago, and it’s cool to finally see this area of the code properly addressed!

With these changes, our number of passing tests is now at 10205 and a total of 7 to-do items.

And this is where you come in! If you’re an accessible tables junkie, know a lot about HTML table make-up, or know of very weird tables out in the wild, go download the latest nightly build and throw the tables at it! Let us know your results, for example by commenting here on the blog, and if you find something that definitely isn’t exposed right, file a bug! We appreciate any and all help you can give us here!

If you’re an AT vendor and plan on implementing support for IAccessibleTable2, here’s a model you can use!

Finally, I’d like to thank all the cool people (module peers and super reviewers) who helped us accomplish what we’ve accomplished so far! With their knowledge and wisdom about the inner workings of Gecko and their respective modules, they helped make our code faster, better and more robust. Keep on rockin’!

Blind web devs, jump on the Firebug train!

Thursday, July 16th, 2009

Late yesterday, Firebug 1.4 was released. Firebug is the web development and debugging tool for Firefox, with a huge user base worldwide.

As JJB mentions in his post, UI accessibility was provided for many of the Firebug features by Hans Hillen of the Paciello Group. The Mozilla Foundation funded the first of this work, and the Mozilla Corporation is now continuing funding to finish the remaining UI pieces like the “Net” panel, fix remaining issues, and also to work with the University of Illinois to develop Firebug features that will help web developers check their sites and applications for accessibility and fix issues in that area.

I am not going to iterate over the features one by one, since the documentation on the accessibility features is very comprehensive. I urge all developers wanting to utilize these features to RTFM (read the fantastic manual) in its entirety before starting to use accessible Firebug.

Once you are up and running with it, you’ll find that all of the described features work as advertised in the documentation. And even more: The documentation currently still states that the script panel’s source code viewer cannot be read with NVDA. However, Hans, Jamie from the NVDA team, and I managed to fix that problem shortly before beta 1 of Firebug 1.4. I notified Hans to update the documentation.

Compared to Firebug 1.3, Firebug 1.4 offers a wealth of accessible web development tools. Firebug 1.3 was effectively not accessible, Firebug 1.4 is, with a few small exceptions, fully accessible, which is an almost 100% leap forward within a single version number increment!

This opens up whole new opportunities for blind developers. To my knowledge, the development tools offered by the Redmond browser do not offer this wealth of features. In testing I did while fixing my example form to also work in IE 8, I found the tools to be unreliable and shaky in many areas. Firefox 3.5 and Firebug 1.4, on the other hand, together with NVDA, which currently best supports the former, are a vehicle to open up new job opportunities! With Firebug, a blind person has full control over the styling and layout of a web application or page. For example, taking my example form from the Easy ARIA Tip #3, and looking at the label and input elements for the “name” entry, I can immediately be told that the label is to the left of the input, and how many pixels there are between the two. I can make sure they’re visually at the same height. The box model of the Layout sidepanel of the Firebug HTML panel is fully accessible and gives me a feel for a page I’ve never had before!

Communication of search results within the HTML panel, or when encountering a breakpoint, is just awesome! Being able to inspect the DOM or a single element’s properties, being able to in-line edit properties and immediately be able to test the effect a certain ARIA attribute might have on your screen reader output is just productivety at its best!

What Hans accomplished here is done almost entirely through WAI-ARIA, and by implementing very intelligent keyboard navigation mechanisms. Through ARIA, such widgets as the log rows for the console, when you enter something such as document;, or dir();, are pushing the boundaries of known desktop widgets. The fact that tabs have popup menus attached to them is being communicated to the user by NVDA straight away, thanks to a very open and flexible architecture that does not assume certain facts about traditional static desktop widgetry such as “tabs never have menus attached to them”. The pure visual box representation of the Layout side panel of the HTML panel is another great example. This even blew David Bolter away when I showed it to him during the Mozilla all-hands in late April, and David is a long-standing and accomplished a11y guru!

Implementing some of these features in desktop applications usually requires very customized implementations of the platform’s accessibility APIs. ARIA, however, is so open and flexible that it can be easily applied to make such visually complex tools like Firebug accessible without ever touching the Mozilla core codebase. Firebug is a mix of XUL (the Mozilla UI language) and HTML+CSS.

So, Victor Tsaran of Yahoo! is already firebugging, and so am I. When are you?

The WAI-ARIA Windows screen reader shootout

Wednesday, July 1st, 2009

Firefox 3.5 has been released, and now it’s time to take a look at what features of WAI-ARIA are being supported by which Windows screen reader. Competition is healthy in this market, and two new screen readers have started supporting Firefox during the 3.5 development cycle: Dolphin’s Hal/SuperNova and Serotek’s System Access (including the free SAToGo offering). So to document the current state of affairs, I’ve taken each one of the following screen readers running on the Windows platform on a tour through some WAI-ARIA implementations that are out there for everyone to use. I’ve chosen not to do a widget-by-widget walkthrough of the Dojo DIJIT Toolkit or some other JS library already including WAI-ARIA, but instead concentrated on stuff users will actually encounter while surfing the web under non-clinical conditions.

The following are the candidates:

The scoring is simple: For each important feature that is fully supported, each screen reader gets 1 point. A particular web app may have more than 1 feature, so it is possible to score multiple points for web apps.

Note that, even if WAI-ARIA support is not explicitly documented, it is still possible to score points because Firefox exposes many widgets through MSAA and IAccessible2 that are not standard HTML widgets. The interesting question here is: Are the various forms of Forms/Focus mode flexible enough to deal with these?

Landmarks

WAI-ARIA landmarks are one of the most widely used features of the spec already. They allow another means of navigating a web page, finding things such as the banner, main content, search, complementary or footer information. The newly relaunched Mozilla Add-Ons website uses them now, as does this blog.

NVDA
No.
JAWS
Yes. Landmarks are announced, they can be navigated to using the Semicolon quick navigation key, and there’s a list of landmarks available through JAWSKey+Ctrl+SemiColon. 1 point
Window-Eyes
No.
SuperNova
No.
System Access To Go
No.

So after the first round, JAWS is in the lead with 1 points.

Contact form from my Easy ARIA tips

The example contact form I created for my Easy Aria tip #3 offers several features that can be incorporated without having to create widgets, and which have appeared in some form or another on pages throughout the web already:

  • Does the fact that the Name, E-Mail and Message fields are required get indicated by anything other than the label saying “required”?
    • By navigating the virtual buffer
    • When in forms/focus mode and tabbing around
  • When entering an invalid name by just entering the first name:
    • Does the alert get spoken when tabbing away?
    • When tabbing back, does the field get indicated as having an invalid entry?
    • Does the fact that this field has an invalid entry get indicated when navigating in the virtual buffer?

In total, there are 5 points to score for this test.

NVDA
NVDA indicates the field as being required in v cursor mode and when tabbing around. 2 points. It speaks the alert. 1 point. It indicates the invalid attribute both when navigating the virtual buffer and when in focus mode and tabbing around. 2 points. Total: 5 points
JAWS
While the label gets spoken in virtual cursor mode, when JAWS switches to forms mode automatically when hitting the entry field, the plopping sound drowns out every indication of attributes such as required or invalid. Only when deviating from default settings and turning AutoFormsMode off one will hear those attributes in V cursor mode. No points for these two. The alert gets spoken. 1 point. When tabbing around, the attributes such as required and invalid do get announced with the default settings. 2 points for these. Total: 3 points
Window-Eyes
The fact that the field is required gets spoken in both browse and focus modes. 2 points. The alert gets spoken. 1 point. The fact that the field has an invalid entry gets spoken in both browse and focus modes. 2 points. Total: 5 points
SuperNova
None of the asked for features work. Sorry, 0 points.
System Access To Go
The alert gets spoken. 1 point. None of the attributes are spoken when navigating or tabbing. Total: 1 point.

After round 2, NVDA and Window-Eyes take the lead with 5 points each, JAWS follows on third place with a total of 4 points, System Access has 1 point, and SuperNova has 0 points.

Yahoo! Search

The new Yahoo! Search is an interactive widget allowing browsing of possible search terms and related concepts that fit the currently selected search term. It uses a whole range of WAI-ARIA widgets, properties and states, live regions etc. When performing a search, the following things should be working:

  • When focusing the textbox:
    • Does the screen reader speak the name “Search query”?
    • Does the screen reader announce the description “Use the up and down arrow keys to select suggestions, or press down and then right to explore concepts.”?
  • When typing, does the screen reader announce that search suggestions are available?
  • When search suggestions are available, does pressing DownArrow properly announce that focus shifted to the list of suggested search terms, and what to do to get back to the search field?
  • Does pressing RightArrow announce the shift to the “related concepts” list and the selected item?
  • When arrowing through either list, does the highlighted/focused item get spoken, and does the search that will be performed when pressing Enter get announced by the screen reader?

So, there are 7 points to score for this one.

NVDA
It speaks the “Search query” label. 1 point. It speaks the “Use the..” description. 1 point. When search suggestions are available, the fact is announced. 1 point. When pressing DownArrow, the transition to the list of suggested terms is announced along with the full instructions and the selected item. 1 point. When arrowing left and right to the related concepts and back, each focus transition is properly announced and the highlighted item read. 1 point. When arrowing up and down through either list, the newly highlighted search term is announced, and the search that is going to be performed is announced automatically. 2 points. Total: 7 points
JAWS
When focusing the search field, the “Search query” label is announced. 1 point. The “use …” description is not announced automatically. It is also not being announced when pressing JawsKey+Tab or Insert+F1. The only way to get to it is to use their HomeRow utility functions and cycling to the “Description” item with HomeRow+F10 and then listening to it with HomeRow+F9. For this almost non-discoverability I can’t give a point, sorry. When search results are available, this gets announced. 1 point. When pressing DownArrow, the transition to the list is announced along with the prompt. 1 point. When RightArrowing, the transition to the “Explore related concepts” list is announced. 1 point. When arrowing up and down, the newly highlighted item is not announced, and neither is the search that is going to be performed. One can get the currently focused item by using Insert+Tab, but the description is once again burried in HomeRow. I’m willing to give half a point for this one since initially it will be confusing to users that they don’t hear anything when arrowing up and down. Total: 4.5 points
Window-Eyes
The label “Search query” is announced. 1 point. The “Use…” description is announced. 1 point. The availability of search results is not announced. The transition to the search term suggestions is partially announced: The focused item is, but the prompt is not. Half a point. The transition to the “Related concepts” and back is announced partially: The newly focused item is, but the prompt isn’t. half a point. When arrowing up and down, both the search suggestion and the search that is going to be performed are being announced. 2 points. Total: 5 points.
SuperNova
Announcing the “Search query” label works. 1 point. But unfortunately, that’s where the fun ends. The description is not announced, the availability of search term suggestions is neither. And the rest of the functionality of this widget is broken. DownArrow is captured by SuperNova and will not fall through to the widget, getting one stuck inside the textbox. Tabbing around will only get up to the “Submit your site” link, but the search terms aren’t reachable. SuperNova will say “bottom”, and no further can one go. Total: 1 point.
System Access To Go
The picture is roughly the same as with SuperNova. The label “Search query” is spoken. 1 point. The description is not spoken. The availability of search term suggestions neither. DownArrow gets you to the “Search” button instead of the list of search terms. In fact, this virtual buffer also ends at the “Submit your site” link. Total: 1 point.

At the end of this round, NVDA leaps ahead with 12 points. Window-Eyes is second with 10 points, followed by JAWS with 8.5 points. System Access scores a total of 2, and SuperNova got their first point!

GMail Chat

GMail has an integrated Google Talk widget that I talked about before. The following should be working:

  • Ability to activate the “Set status here” label by pressing Enter on it to input a personal status message.
  • Ability to activate the “status menu” and navigate inside it with speech output.
  • Navigate inside the list of buddies and hear their names and status.
  • Inside the Chat window, announce typed and incoming messages.
  • Track going to the Chat window toolbar.

Once again, there are 5 points to score. Let’s see how everyone fares!

NVDA
Pressing Enter on “Set status here” works fine, and one can input a status message. 1 point. Activating and navigating in the status menu works fine. 1 point. The list of buddies talks fine. 1 point. Chatting works fine. 1 point. Trying to access the toolbar items by first going out of focus mode with Escape made NVDA hang each time I tried it. It somehow has a conflict with the chat widget. Sorry, no point for this one. Total: 4 points
JAWS
The label to input a status message is not activable by pressing Enter. It can only be activated using the JAWS cursor emulation. Since this is a well-known workaround, I’m giving half a point. The Status menu is activable and works fine. 1 point. The list talks fine. 1 point. The incoming and typed messages are spoken in the chat output. 1 point. The chat toolbar to pop out the chat into its own window is accessible. 1 point. Total: 4.5 points.
Window-Eyes
Accessing the label to input a status message works with workaround of routing WE cursor to element, then mouse to WE cursor, and clicking with the mouse. However, I cannot input a status message afterwards, even though I hear the prompt for it. a quarter of a point for that. The status menu cannot be activated through any means. The list talks fine. 1 point. The chat window works with restrictions: It can be activated and typed in, but incoming messages are not read. half a point for that. Trying to access the toolbar items of the chat window sort of works by turning browse mode back on, and then searching, but since the last position is not retained, I can only give half a point for this one. Total: 2.25 points.
SuperNova
Activating the “Set status here” works. I can input a new status. 1 point. The status menu button does not work, cannot be activated or found through other means. The list of buddies talks. 1 point. Activating a chat with a buddy does not work. Consequently, since the chat window never comes up, the toolbar items for the chat window obsolete themselves. Total: 2 points.
System Access To Go
The “Set status here” and Status menu items are not accessible. The list talks fine. 1 point. Activating a chat works. 1 point. Finding the toolbar buttons is not possible, because the cursor gets stuck within the textbox of the chat window and there’s no way to move it out. Total: 2 points.

…and the winner is…

Congratulations go to the NV Access team and their screen reader! In this WAI-ARIA shootout, you scored 16 points.

Number 2 is JAWS by Freedom scientific, scoring a total of 12.5 points.

Window-Eyes by GW Micro is third with a total of 12.25 points.

Fourth place goes to Serotek with their System Access screen reader product line, with a total of 4 points.

And SuperNova by Dolphin receives 3 points.

In summary

This was a close match, although there is clearly a dividing line between the three screen readers that have been supporting Firefox for a longer period of time, and those that came on board fresh within the past year or so.

I hope this little competition encourages each of the vendors to better themselves for the benefit of the users. We’re here to help each and everyone of you with technical advice and discussion on how things should be implemented.

Keep on rockin’!

New accessibility features in Firefox 3.5

Friday, June 26th, 2009

Firefox 3.5 is fast approaching, and it’s time to list all the user-visible changes to the accessibility support in this new version!

Support for text attributes, formatting and spell checking

Firefox 3.5 exposes text attributes such as bold, underlined, and color information through the AT-SPI and IAccessible2 attributes properties of their respective AccessibleText interfaces. Information about formatting such as left aligned, centered etc., is also provided. In addition, in rich editing and other text entry environments where the spell checker is enabled, when a word is misspelled, this information is also provided so screen readers can pick up and notify the user. Since my original blog post on this subject, Orca 2.28, NVDA 0.6p3 and JAWS 10 have added support for this feature, allowing a seamless proof reading of entered text in both Firefox 3.5 and the upcoming Thunderbird 3 release. This works also when writing a message in GMail or other rich editing environments, not just textboxes or textareas.

Better compliance with WAI-ARIA 1.0

We’ve made sure that the WAI-ARIA 1.0 spec is adhered to to the most extent possible, removing attributes that are no longer in the spec, and adding/changing those that were agreed upon in the progression towards finalizing ARIA 1.0, which is currently in a late review stage. One of the most significant attributes added is aria-label, which allows any text to be associated with a widget that doesn’t appear anywhere else within the web app. For extension devs: This also works in XUL, not just HTML. One project that makes heavy use of this is Firebug 1.4 in the accessibility UI enhancements that Hans from the Paciello Group has put in. This is also the reason why Firebug 1.4 works better in Firefox 3.5 than 3.0, what accessibility is concerned, since Firefox 3.0 doesn’t support this new attribute.

Also, aria-expanded can be used on all elements now, allowing better exposure of states for buttons that drop down a list of items, for example.

Support for the exposure of embedded HTML 5 audio and video controls

As recently announced, we’re also supporting the exposure of the embedded controls of the HTML 5 audio and video elements to assistive technologies.

Better event firing in dynamic web applications

We fixed a significant issue with firing proper events when nodes get hidden or made visible through JavaScript or Ajax calls. This should allow a much better experience with accurate visibility of nodes within virtual buffers of various screen readers.

And a ton of bug fixes for stability

Of course, each cycle also goes with a ton of bug fixes that improve stability and accuracy. These are mostly under the hood and often deal with edge cases, but these are no less important to our user base.

When Firefox comes out, I encourage everyone to upgrade as soon as possible, since it will provide an even more rich experience when browsing the web than Firefox 3.0 already did. Probably the most important extension for blind users, WebVisum, already works with this release, so you won’t lose anything on that front! Also, other extension devs are working hard to make their projects work with Firefox 3.5.

Enjoy!

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!

Last week in the “Accessible” module, April 20, 2009

Monday, April 20th, 2009

After the Easter holidays, pace has picked up again in the development of accessibility features and other work surrounding our eco system.

Actions for sorting and expansion/collapsing

After some minor setbacks, David’s patch on exposing actions for ARIA sort and expand/collapse attributes finally landed today. This means that:

  • An element that has aria-sort set, will expose an action of “sort” to assistive technologies.
  • An element that has aria-expanded set to “true” will expose an action of “collapse”, one that has aria-expanded set to “false” will expose an action of “expand”.

These can be used to exactly determine what action will be performed once it is being performed.

Exposure of the HTML5 audio and video element controls

Alexander’s patch to expose the embedded controls of the HTML 5 video and audio elements has landed on mozilla-central. With NVDA, one can now see the grouping where the controls are, and invoke the action on each of the buttons. One can even switch to focus mode on the sliders and use the arrow keys to manipulate them. Note: Due toa different approach in reading our information, JAWS does not yet expose these controls despite this patch. Other screen readers are pending tests.

There are a few problems still which will be addressed soonish: For one, the buttons don’t have text labels yet, and the slider percentage values reflect times rather than actual percentages, so we need to see how we’re going to expose this properly.

In other news

The team, along with a number of community members, has worked on a new high-level accessibility strategy document. Frank Hecker has a blog post explaining this in greater detail.

Spreading the good work of ARIA to mainstream open-source CMS

Peter Krantz, accessibility expert from Sweden, has started an effort to contribute WAI-ARIA landmark roles to mainstream open-source content management systems. If you know one of the CMS that don’t have patches yet, feel free to jump in!

That’s it for this week, see you next week for a new edition!

Updated ARIA-spiced form example to work in IE 8

Tuesday, March 31st, 2009

I updated my simple form example from the third Easy ARIA Tip to also work in IE 8. I had to explicitly state a doc type to put IE out of quirks mode into proper IE 8 mode, and I also had to change the type attribute’s value of the script tag to “text/javascript” from “application/javascript” for it to recognize the functions declared in the script block.

The example works visually, but has a number of accessibility issues which make testing IE 8 with it a not so pleasant experience:

  • Neither aria-required nor aria-invalid take any effect with either JAWS or NVDA. It’s as if the attributes weren’t set, yet the IE DOM exposes them correctly, as JAWS’s Element Info keystroke, Insert+Shift+F1, clearly indicates.
  • Neither JAWS nor NVDA see the alerts come up, and thus don’t speak them. The alerts appear visually, so the JavaScript is working, but the DOM mutation is not being picked up. Only after a refresh in the respective screen readers is the content of these visible in the virtual buffer.

For testing, I used the latest update to JAWS 10, build number 10.0.1142, and NVDA trunk snapshot 2828. And of course, the release version of IE 8.

For those of you doing web application development and testing, this is an indication that your best bet to get proper results is definitely the combination of a strong implementation of ARIA in Firefox and a supporting screen reader.

Last week in the “Accessible” module, March 30, 2009

Monday, March 30th, 2009

The last week was rather short, but no less busy.

First, on the off-code side, I attended the European Accessibility Forum Frankfurt (EAFRA) conference on Friday, March 27. Christian Heilmann from Yahoo! posted a great summary of the event and also caught my guide dog Falko sleeping while I talked. The videos will appear here.

On the code side, the action happened in the mozilla-1.9.1 repository AKA Firefox 3.5b4pre this time. Today, I checked in all the approved mozilla-1.9.1 nominated patches. From Tuesday’s 3.5b4pre nightly build onwards, Firefox will:

  • Expose font sizes in PT units instead of PX, as specified in the IAccessible2 spec.
  • Support the value of “undefined” on aria-checked/aria-expanded etc. attributes, as specified in the ARIA 1.0 spec
  • Drop support for aria-channel, container-channel, and aria-datatype
  • Support aria-expanded on more roles
  • No longer support role=”description”
  • Require aria-grab to be changed to aria-grabbed for drag and drop to work in the future
  • Expose non-editable documents as readonly, regardless of role
  • Expose the ‘checkable=”true”‘ object attribute

This brings Firefox 3.5beta4 very close to the ARIA 1.0 spec. We’ll take another look to make sure we don’t miss any details from the specification for implementation. Thanks to Mike Beltzner for not jumping our throats at these 10 or so approval requests we threw at him at once!

In other news, some progress is being made towards finding the leak that running the accessibility Mochitests on Mac OS exposes. It turns out that these same objects can also be leaked by other tests, which are not accessibility related, but ours are still the best bet at reproducing them. So our master of leak detection, Carsten Book AKA Tomcat has kindly agreed to help debug this beast.

Last week in the “Accessible” module, March 16, 2009

Monday, March 16th, 2009

Last week, we focused mostly on some solidification on our code and test framework. We are having some strange problems with tests failing randomly or not being run at all. To that end, I fixed the loading of remote images in Mochitests, which is always a dangerous source of failure if an image can’t be loaded from the remote site. David also discovered and worked on protection against some failures in our doAction tests.

David also fixed a PRBool violation uncovered by code analysis. He also cleaned up our object attribute exposure code and added tests to make sure aria-sort gets exposed as an object attribute properly.

David also fixed exposure of mixed and checked states for ARIA and HTML 5. Mixed should not be checked at the same time, and vice versa. I helped out with tests on this one.

I refactored our nsAccessNode caching test. There are only 2 files left to refactor now, and one of those is currently disabled.

Alex cleaned up static casts to ATK roles. He and Ginn Chen from the Sun Microsystems China office also chased down one of our top crashers and Gionn found the root cause for this we believe.

David and I agreed to request that accessibility and the accessibility unit tests be enabled on the mozilla-central unit test tinderbox for Mac. This is the first step in getting Mac accessibility efforts moving again. We are currently anxiously awaiting test results from a run on the staging servers. Cross your fingers!

In other matters, David, Alex and I will be at CSUN in Los Angeles this week, so if you’re in the area, come and drop by our booth! We’re being joined by Frank Hecker of the Mozilla Foundation, Mick and Jamie from the NVDA team, Eitan Isaacson, a regular Mozilla grantee, and Aaron leventhal, without whom we’d probably not be sitting here today.

The venue opens Wednesday at 4 PM and runs through 7 PM, Thursday and Friday it runs from 9:30 AM to 5 PM, and on Saturday it runs from 9 AM to 1 PM. I’ll be holding a presentation on Friday at 12PM talking about what we’re currently doing, and planning to do in the future, with Mozilla accessibility, so if you can still get a seat, come on over and let’s have a chat!

See you all next week, where I’ll be reporting a bit about what the venue has been like. I’ll also be updating my tweets, so if you like, follow the hashtag #csun09 on Twitter for my and other people’s updates.

Last week in the “Accessible” module, March 9, 2009

Monday, March 9th, 2009

Last week’s work saw quite some code cleanup.

Unification of role and finalRole

Previously, our nsI*Accessible interfaces exposed both role and finalRole properties. While role returned a preliminary role, finalRole always returned the finally determined role after all markup and ARIA processing had taken place.

It turned out that the role was hardly ever used, but everyone always asks for the finalRole. So, the decision came about to file bug 481357 and get rid of finalRole and make role do what finalRole did previously.

As a prequel to that, bug 482013 was fixed, refactoring all test files to use the common getRole and testRole functions in the testing framework. As a result, only one instance of .finalRole had to be dchanged to .role in the bug linked to above, to make all tests still work right.

This change will be exclusive to Gecko 1.9.2, since it will need some adjustments in DOM Inspector and other extensions that use our accessibility interfaces.

Crash fix in tree table code with some side effects

Alex also fixed a crasher in the tree tables implementation of getChildAtPoint/getDeepestChildAtPoint. After a fix for a leak that was uncovered by the test, the tests are still failing on Linux because of wrong coordinates we’re getting back. Investigation into this is still ongoing.

Originally, bug 471493 was also supposed to introduce crashtests specific to a11y. However, it appears that, once a crash test has turned on accessibility, that remains on for the remaining crash tests, and some of the others didn’t react well to that. A solution is under investigation.

Speaking of leaks

While investigating bug 420068, Alex found this memory leak. After he fixed that, the other bug seems to have been resolved, too.

Further test refactoring

I took on our table testing code and refactored it to use the new infrastructure. 4 more files that no longer use their separate implementations of retrievals of accessibles etc. That leaves 3 more files to go, and one of them is disabled right now because of bug 437980.

I also finally got the tests for aria-activedescendant refactor off my back. This one had been going on forever (or so it felt).

HTML 5 features

One thing I forgot to mention last week was that a few weeks back, the “indeterminate” property new to HTML5 was introduced to HTML:input @type=”checkbox” elements, effectively giving them the ability to be partially checked, for example as a master checkbox to dependent checkboxes. As expected, we didn’t expose the mixed state properly on these yet, so I took on that task. As a sequel, I’m currently working on exposing a proper action name for these as well. I’m having some trouble getting the tests to run properly, though. The tests go into an endless loop when I run them locally, so until I found out why, I’m hesitant to throw these at the tinderboxen. If anyone has seen this happen at all, suggestions are welcome. A sample log excerpt can be found here. The tests start running this test_comboboxes.xul file, then the whole a11y test suite starts running all over.

More text attribute fixes

Alex got the font-weight bug resolved, so font-weights are now properly exposed according to the visual representation and not through some seemingly arbitrary numbers.

aria-sort, aria-grabbed, and aria-expanded action exposure

David has been sinking his teeth into this one and has come up with a great idea to solve this. Since no desktop app ever exposed many of these things especially when it comes to a controlled drag and drop action from a screen reader’s point of view, this one requires careful thinking and design as well as good communication with AT vendors to get right.

Progress on plugging in accessible trees from plugins

Recently, community member Brad Taylor approached us with the question of plugging in accessible trees from plugins into our accessible tree on Linux, integrating third party plugin accessibility nicely with ours. A bug was filed, and Brad has been working on this, regularly communicating on the accessibility channel with David. A first WIP patch was posted on Friday.

That’s it for this week.

JQuery UI 1.7 released

Saturday, March 7th, 2009

The jQuery UI team has released jQuery UI 1.7. Congrats on this release!

One thing the team did not mention in the above blog post is the fact that jQuery UI 1.7 is the first version to contain WAI-ARIA enhancements, making the widgets more, or at all, accessible. WOOT!

It’s really cool to see another big player in the JS widgets field to adopt WAI-ARIA, making modern websites more accessible the moment they just switch to this version of jQuery UI.

Last week in the “Accessible” module, March 2, 2009

Monday, March 2nd, 2009

This is the first in an ongoing weekly series where I’ll highlight items that the accessibility team has been working on over the last week. I’ll be reporting on fixed bugs, or will also call out on items that we might appreciate your help on.

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

Automated tests on all three active Firefox development branches

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

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

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

ARIA 1.0 compliance patches

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

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

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

New for text attributes

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

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

Accessible relations improvements

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

Proper reorder events

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

Thunderbird 3 reading panes

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

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

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

Better accessibility in SuMo’s live chat

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

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

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

On other fronts

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

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

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

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

At FOSDEM 2009

Thursday, February 5th, 2009

I’ll be at FOSDEM in Brussels this weekend. I’ll be at the Mozilla booth or attending sessions in the dev rooms. If you feel like dropping by and talk accessibility, ARIA and such, feel welcomed!

JAWS 10 public beta’s Firefox 3 support: A review

Tuesday, August 26th, 2008

In the August issue of the “FS Cast” podcast, Freedom Scientific announced the soon-to-be expected availability of JAWS 10 public beta. They also demoed many of the new features, like the automatic forms mode switching. They also mentioned that they improved Firefox support a lot and that the web should feel transparent now regardless of which of the supported browsers the customer would be using: IE or Firefox. ARIA support, also with an emphasis on live regions, was mentioned, too.

The public beta was released on August 25, and I took it for a test ride. Here’s what I found:

In general, the display of static pages has improved quite significantly over previous versions of JAWS. Especially text being run together with certain HTML constructs is no longer an issue. Missing line breaks are a thing of the past now, too. This makes the over-all reading experience much more pleasant.

One big plus I also noticed is that, when you open a link and then later return from the newly loaded page using Alt+LeftArrow, JAWS correctly sets the virtual cursor to the link you activated. It used to put the virtual cursor at the top of the page.

The automatic forms mode switching works on textboxes and textareas, but Alt+DownArrow on a combobox does not pop into forms mode and open the listbox yet, as was demonstrated in the podcast using IE.

Speaking of listboxes: JAWS 10, unlike 9, shows all items in an HTML listbox (a select with size greater 1). It used to only show the selected entry. In IE, it still does that, but in Firefox, it dumps all the items into the virtual buffer. If you have a list of over 100 items, this can become very annoying.

In terms of ARIA support, there are clear signs that work has been done on this front. For one thing, JAWS now honors the ARIA role of “application”, which means it does not go into virtual PC cursor mode on such pages or in properly marked-up web application environments. An example can be seen here.

Also, live region updates are nicely read on this page.

However, there are also still quite some areas where both ARIA support in general and live region support in particular should be improved before final release. Here are some points where I am still seeing problems:

  • While the live region support works great on the above page, it does not work at all in the ChatZilla Firefox extension. ChatZilla uses an HTML table with role of “log”, and both “polite” and “assertive” live regions. JAWS currently runs all the text inside this table together in one big string, without line breaks. Also, markup such as links inside these chat output messages is completely ignored. While JAWS 9 didn’t support live regions yet, it did properly format the output into a very readable form. As a plus: Updates to the view are now automatically picked up, which was not the case in JAWS 9. There, you had to constantly refresh the virtual buffer to see the newest messages.
  • Live Region support in Google Talk, as I describe in my ARIA in GMail
    #2
    post, is flaky. Sometimes new text that comes in gets spoken, sometimes it doesn’t. I haven’t found a consistent pattern yet. Also, the chat window still needs to be popped out into its own window, as also was the case in JAWS 9, to be able to read it at all.
  • Speaking of Google Talk: The ARIA list of contacts behaves inconsistently with Forms Mode. It has a tendency to unexpectedly pop out of forms mode when you arrow from one list item to another. In addition, Enter does not yet work to open a chat or new e-mail message, depending on whether the contact is available for a chat or not. Forms Mode is instead turned off, and the virtual cursor lands somewhere unpredictable, preferably at the very bottom of the virtual buffer.
  • A similar unexpected leaving of forms mode can be observed in this
    Dojo treeView test example. Focusing the tree view, turning on forms mode, and arrowing among the items, opening and closing them works in the downward direction. However, as soon as I go from “Africa” back up to the root element “Continents”, forms mode is popped off.
  • One other problem I discovered was that alert messages have a tendency to get out of sync. I was trying out my example from Easy ARIA tip #3. I called up that page directly after I had started Firefox. Upon launch of Firefox, WebVisum told me that I was now logged in, via an alert. When I then triggered my first alert from the sample page, the “You are now logged into WebVisum” message was repeated. Consequently, all subsequent triggers of alerts would then speak the previous alert message instead of the current one.

In summary, there are clear advancements visible in JAWS 10 with regards to support of Firefox 3. Especially the more readable flow of text and the fact that you always return to the same spot when going back a page are big plus points. However, while there are also advancements visible in the ARIA and live region support, for a public beta after as long a development cycle as was mentioned in the podcast, I would have expected a much more polished first beta.

Having said that, it must not be forgotten that this is still beta software. All above issues were reported to Freedom Scientific prior to publishing this blog post, and the Mozilla accessibility team will work with the developers at FS to resolve these issues.

For the next public beta release of JAWS 10, I am planning an ARIA shootout among all screen readers across all platforms that support ARIA already. So stay tuned!

ARIA in Gmail #2: Enhancing the Chat experience

Wednesday, August 6th, 2008

This post continues a series on the implementation of ARIA (Accessible Rich Internet Applications) in Gmail.

On July 30, Orca team lead Willie Walker forwarded a message to the Orca mailing list titled Orca & gmail. The message is originally by Srinivas Annam, an accessibility web developer at Google. He describes a couple of enhancements that had been made to the Gmail user interface and were pushed live recently. I’m going to review each feature in turn so you get an impression of what accessibility improvements these changes actually brought about.

I tested with JAWS 9.0, Window-Eyes 7.0 Beta 1, NVDA snapshot as of Wednesday August 6, and Orca snapshot as of Wednesday August 6. Unless noted otherwise, all features are fully useable using Firefox 3.0.1 and these versions of the screen readers.

All of the below are in the Chat area of the Gmail interface. So after you’ve logged into Gmail, make sure to activate the “Chat” link to be able to follow the descriptions.

The “Set Status Here” label

This is the label right below the “Search, Add or Invite” textbox. Pressing Tab from that textbox focuses the label. You can press Enter to get another textbox where you can put in a personal status message that others will see when they have you in their chat lists. Note if you’re using JAWS, press JawsKey+3 (3 on the number row) to pass the key through to Firefox directly. Otherwise, JAWS will capture the Enter key and turn off Forms Mode when you don’t want it to.

The “Status” menu button

This follows directly in the tab order after the “Set status here” label. You can press Enter on it to bring up a context menu to navigate and set a predefined status. This button is also discoverable with the virtual cursor in all three Windows-based screen readers, and Enter works on all of them to open the context menu.

Inside the context menu, navigating the items with Up and Down arrow keys properly issues the focus events, making use of the aria-activedescendant attribute to indicate which of the menu items is active.

A known problem is that, when pressing Escape to close the menu, focus does not yet return to the menu button. Use screen reader navigational commands to return to where you left off.

The chat contact list

This is an ARIA listbox with list items. It follows the “Status” menu button in the tab order. The Windows-based screen readers allow navigating to it using their virtual cursors, and pressing Enter for Forms Mode/Virtual off/PassKey mode. With Orca, you can simply navigate or tab to the list. The list uses aria-activedescendant to indicate which item has focus.

Navigating inside the list is done using Up and Down arrow keys. Besides the contact’s name, the status is given “chatting”, “available”, “idle”, “offline”.

Pressing Enter will do one of two things. Note that if you’re using JAWS, again use the JawsKey+3 keystroke to pass the key through, or it will turn off Forms Mode.

  • If the contact is available or idle, a chat window will open. See the next section for features within this window.
  • If the contact is offline, a new mail message to it will be started, and the focus will be placed in the “Subject:” textbox.

Below the list is another menu button labelled “Options”. However, the menu that opens does not yet use the aria-activedescendant attribute. The result is that no screen reader follows the focused item within this menu yet. It is hoped that this menu be accessible soon since it contains a number of useful functions.

The chat window

If you’ve opened a chat window to one of your contacts, the focus is placed inside a textbox where you can type your message. Press Enter when done to send your message.

The chat output pane uses ARIA live regions to enable screen readers to speak incoming messages automatically. These can either be your own, or the ones your chat buddy types. A suggestion: The message output uses aria-live=”assertive”. The other portion that gives messages such as “xxx is typing” does not use live region markup at all yet. It would be good if this used aria-live=”polite” to allow screen readers to also speak this information. Since this message is not as important as the actual output, using “polite” here can help screen readers prioritize the speaking of these updates.

Currently, both Orca and NVDA support speaking of live region updates. This means that, when inside the chat area and a message comes in, both screen readers will automatically speak them. Additionally, you can turn off PassKey through mode in NVDA and navigate upwards to review the last messages. With Orca, simply navigate upwards to review the last messages.

Note: If you’re using JAWS, you should pop out the chat into a separate window. For some unknown reason, JAWS will not pick up the contents of the output window unless the chat is inside its own window. To do this:

  1. Press JawsKey+3, followed by Ctrl+DownArrow to focus the Chat window toolbar.
  2. Press Tab to move to the “Pop out” button.
  3. Press Enter to activate it. Note you might get a warning from your popup blocker that it prevented Gmail from opening a pop up, and an error dialog by Gmail itself that tells you how to disable popup blocking for Gmail. I suggest you do this to more easily open those pop outs.

The Chat window toolbar

You can reach this by pressing Control+DownArrow while focused inside the chat entry textbox. It places focus on an “Options” menu button. Press Enter to open it. Navigation inside it is just like in the “Status” menu, also works using aria-activedescendant.

Alternatively, you can press Tab to reach the “Pop out” button, allowing you to put the chat into its own window.

Finally, Ctrl+UpArrow will put focus back into the chat entry textbox.

In summary

With these enhancements in both keyboard navigation and ARIA semantics, Google have turned this portion of Gmail into a really useful tool also for blind and visually impaired users. With Firefox or another ARIA-capable browser and a compatible screen reader, you can now use this part just like your sighted buddies do.

With this, Gmail is not just web mail, it becomes a communication center as it already is for the sighted users.

I’d like to thank Google again for putting ARIA into Gmail in this fashion. It shows that the work Mozilla, IBM and the W3C, under the leadership of Aaron Leventhal, put into this spec is indeed usable in real-life scenarios and not just, as suspected by some, a nice geeky thing on the drawing board.

Previous ARIA in Gmail posts