Archive for the ‘Accessibility’ 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

Roundup: What is the Mozilla Accessibility Team working on?

Monday, May 10th, 2010

Well, it’s been a while since I posted here I’m afraid. The reason was not an outbreak of laziness, but on the contrary the fact that the accessibility team at Mozilla is alive and kickin’, and working on the next version of the Gecko platform. And to give you an idea what we’re working on, here’s a quick round-up.

De-XPCOM-ing the Accessible module

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

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

Event management

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

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

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

HTML5 form element enhancements

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

UI work

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

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

Other areas

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

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

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

Stay tuned!

Update: Article translation

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

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!

The new “Freedom Of Choice” does not account for accessibility needs!

Tuesday, February 23rd, 2010

Before continuing, please read this post by Steve Faulkner of The Paciello Group on the same topic.

This is primarily a warning to all screen reader users who read my blog that the only choice you have is to install Mozilla Firefox as an alternative to MS Internet Explorer. While you can, in theory, install the other browsers as well, and some of their marketing statements sound pretty shiny, none of them will work with your assistive technology!

As Steve points out in his post, none of the statements of what the browsers offer talk about accessibility or no accessibility. There isn’t even hidden text that would be visible only to screen reader users indicating something like “if you are a screen reader user, use only either Firefox or IE”.

I was contacted by our marketing team about the issue of accessibility, so I can say with conviction that we tried to bring this into the discussion. But for the EU, Microsoft and all other parties, this issue didn’t seem important enough to highlight. Thanks for this great service! :(

Please spread the word to your friends and warn them accordingly! You can help them avoid unnecessary frustration.

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

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!

New accessibility features in Firefox 3.6

Monday, November 9th, 2009

Firefox 3.6 is just around the corner, and despite all the birthday celebrations, and the looking back that comes with it naturally, I think it is also time to look ahead. So here’s a roundup of what accessibility features will be in the next major release of our favorite browser.

Support for voice dictation software in Windows Vista and Windows 7

Firefox 3.6 introduces support for the Microsoft Text Services Framework. Among other things, this allows users to dictate into text fields on the web using the Microsoft voice dictation software that comes with Windows Vista and Windows 7.

Because this is fairly new technology to Firefox, and because there are undoubtedly quirks to iron out, this support has to be specifically enabled in the advanced configuration editor. To do this:

  1. In an empty tab, type about:config in the awesome bar.
  2. Acknowledge the warning by clicking the “I’ll be careful, I promise!” button.
  3. Type the letters tsf in the filter textbox
  4. In the list that appears, select the preference intl.enable_tsf_support. This is off by default (its value is FALSE).
  5. Right-click that preference and choose the “Toggle” menu option. This will change the option to read TRUE.
  6. Restart Firefox.

This setting will now be saved in your profile and the functionality is available to you.

This expands the range of supported accessibility-related APIs yet again and offers good integration with one more native feature of the Windows Vista and 7 operating systems. Now, users with typing difficulties can use Firefox in a more efficient manner than before.

Windows 7 task bar integration

The new task bar integration in Windows 7 is accessible. If you have more than one tab open, and you navigate the task bar using the keyboard, a screen reader such as NVDA will announce “sub menu” for the Firefox task bar icon. This means that you can use the up and down arrow keys to select the tab you want to bring to the foreground when you switch to Firefox. This is just as seamless as sighted users will choose the tab preview from the Windows 7 task bar using the mouse.

More consistent focus handling

This affects everyone, keyboard and mouse users alike, but is mentioned here nevertheless since it brought us a few bug fixes for free like more consistent tabbing on pages that have the tabindex attribute on some elements but not others. Also, when saving executable files on Windows, the dialog that comes up prompting to save the file is now automatically being announced by screen readers.

Support for the IAccessibleTable2 interface

I blogged about this in more detail here. This gives screen readers access to all kinds of table structures, be it ordinary data tables, ARIA tree grids, XUL tree tables and other possible table constructs, in a unified and consistent manner.

More consistent and maintainable naming rules

Also in line with the user agent implementor’s guide for WAI-ARIA, we’ve improved the way we calculate the accessible names (often similar to on-screen text) of various elements in HTML and XUL. This makes our code more robust, predictable and maintainable, and therefore will allow easier adding of new features/element support in the future.

Notifying screen readers when an object attribute’s value changes

For better support of WAI-ARIA Drag And Drop, we’ve added support for the IAccessible2 object attribute changed event. This event notifies screen readers when an accessible’s object attribute’s value has been changed by the page. This usually happens if a certain HTML element’s attribute is exposed via its corresponding accessible’s object attributes, and that element’s attribute value is changed by a user action (usually done via JavaScript).

And again tons of bug fixes

Of course, there have also been a good number of fixes for existing features that were reported to use by users and assistive technology vendors alike. We’ve also kept track and participated in last-minute changes to the WAI-ARIA spec and kept our implementation up to date.

The whole accessibility team hopes that you’ll enjoy using this new version of Firefox as much as we enjoyed creating and testing it!

Happy birthday, Firefox!

Monday, November 9th, 2009

In case you haven’t noticed already: Today is Firefox’s 5th birthday! On November 9th, 2004, Firefox 1.0 was released to the general public after more than two years of development.

And boy, was I jealous! All my sighted friends could try out this cool new thing, an alternative browser to the omnipresent, and some would even say, omnipotent, Internet Explorer! An alternative! But it was not yet fully accessible. There were first glimpses: When I ran Firefox 1.0 with JAWS 6.0 back then, I could navigate the menus, and most dialogs talked. But the main functionality, the browsing experience, was not yet available to me.

That all changed with Firefox 1.5 and the donation IBM gave to the Mozilla project in August 2005. At the same time, Window-Eyes 5.5, and a bit later JAWS 7.0 were released with initial support for Firefox 1.5. Suddenly, the virtual cursor worked, quick navigation keys brought you from heading to heading or form field to form field, just like in Internet Explorer 6! And boy, was it fast!

It also had a ton of problems. Pages not rendering completely, esp pages with frames giving users huge headaches by not rendering at all often times, etc. Many users including myself had to decide that Firefox was just not ready for prime time use on a daily basis for screen reader users just yet.

But I kept up with development and also tested Firefox 2.0, which came out in October 2006. Many of the problems were still there, but some were a lot better. And the initial support for what back then was still known as “dynamic HTML” surfaced, giving a first glimpse of what later became WAI-ARIA and which has already changed the landscape of accessible web applications.

In December 2007, I started as Mozilla’s Accessibility QA engineer and took matters into my own hands. For Firefox 3, the accessibility community accomplished a huge lot: Firefox 3 was the first UI browser to become accessible on Linux. There was now an open-source screen reader taking full advantage of all the new features of the IAccessible2 standard on Windows. WAI-ARIA compliance was very high. All content-related problems were a thing of the past and the browsing experience was as reliable in Firefox as it was in IE. Moreover, value was added by projects such as WebVisum, which is a social tagging and captcha solving service exclusive to blind users using Firefox. When Firefox 3 was released in June of 2008 and we got in the Guinnes book of world records, I’m sure there were quite a number of blind folks participating in that effort!

But we didn’t stop there. For Firefox 3.5, we added support for text attributes, giving blind users the ability to in-line spell check their entries on the web just like any sighted people do. The community worked together to give open audio and video to everyone, not just sighted people, but also screen reader and keyboard users. WAI-ARIA compliance was increased to nearly 100%. Stability was further increased. Two more Windows screen reader vendors stepped up to support Firefox, making the total number of screen readers for the blind supporting Firefox 3.x 5 on the Windows platform.

And on its 5th birthday, my colleagues in the QA team and I are working hard to get a beta refresh out to all of you of the next major release, Firefox 3.6. In fact I’m writing this blog post using the candidate build. And we have a cool set of features assembled for Firefox 3.6 on the accessibility side, about which I’ll blog next.

All I can say is: Thank you Firefox! Thank you to everyone in the community who has been and is working so hard to make the web a better place for everyone! I’m grateful and proud to be a part of this community!

Happy birthday, Firefox!

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”

Firefox 3.5.4 fixes certain comboboxes on Linux with Orca

Wednesday, October 28th, 2009

If you haven’t noticed yet, Firefox 3.5.4 hit the web last night. For accessibility, this brings one major fix all of our Linux and Solaris users will appreciate: Certain comboboxes such as the “Security Question” one on the GMail signup page, were broken in the initial releases of 3.5. When you arrowed, Orca would not speak the newly selected item. This was a regression from 3.0 where this worked.

We initially fixed this for Firefox 3.6 alpha and now also backported the fix to the 3.5 branch.

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!

The importance of placement of HTML elements in a document

Wednesday, October 7th, 2009

This was an issue I ran into today, so thought I’d blog about it.

When dealing with dynamically added and removed content on web pages, there are usually two approaches: One approach is to show and hide content in the place where the trigger for this change is. An example of that is the Mozilla Corporation Careers page. Clicking one of the links “Meet Mozilla”, “The team”, “Life at Mozilla” links will replace one text portion with another, in the same place, right below the list of these items.

The second approach is to add the new content to the end of the HTML document, and then use CSS to position the content on top of, or in the place of, a specific location visually. An example of this is the jQuery Thickbox demos page. Clicking one of the demo links, for example for the image, the gallery or the “keep in mind” demo, the text is being added to the end of the HTML, probably by some document.addXxx method in JavaScript or the like.

Visually, these two methods may vary a bit in styling, but have the same effect: You click something, and some text or images become visible or are being replaced by something else, without a page being reloaded.

For a screen reader user, the two methods make a profound difference. In order for a screen reader to present a web page to the blind user, a form of accessible tree traversal or even DOM or HTML parsing has to take place so the screen reader knows which elements there are, and in what order they appear. CSS styling is then used to determine whether something is hidden or visible, formatted as a block or the like. Also, some attributes for text etc. are being derived from this information. But positioning information is always secondary to the actual order in the source HTML, be it hard-coded or generated via JavaScript.

To put it in other words: Even a three-column page layout will appear to the screen reader user in a single-column, top-to-bottom fashion for easier readability.

The consequence is that, in the second example, the new content will always be found at the end of the screen-reader-rendered content. On Windows, this is at the end of the virtual buffer, even below the copyright notice or the like. On Linux and the Mac, one also has to use navigational methods to get to the end of the rendered content (for example by navigating all the way to the end with Orca or by getting to the last element while interacting with the HTML content on Mac). This is true across browsers (Firefox, IE, Safari). So to read the content that newly appeared in the thickbox, the user has to scroll all the way to the end, do whatever is necessary there, and then return to the top and navigate down using heading navigation or the like to find the place they left off. This is not very efficient or intuitive.

The same can be observed on Facebook where if you add a friend, the question whether you really want to send the friend request, will be appended and is found far down at the very bottom of the page for a screen reader user. Visually, it appears in the vicinity where a sighted user clicked the “Add as friend” button.

The Mozilla example, on the other hand, replaces the text right below the list, making it easily accessible within the context the user is currently working in anyway. The user never has to leave the general vicinity to get from introduction to the “Meet the team” etc. parts. Navigation back and forth is quick and efficient.

Therefore, when you design dynamic content, write an accordeon widget or the like, please please please always take the time to chose an appropriate div element in the vicinity of where the user is, and add or remove the dynamic content there instead of taking the maybe easier, but far less intuitive, route to simply dump to the end of the document node’s children and then use some weird styling to craft it visually. You’ll help all screen reader users visiting your site by offering them more efficiency in that they don’t have to navigate between chunks of the content that are far apart.

New approaches to Flash and Java accessibility in the browser on Windows

Friday, October 2nd, 2009

Mick and Jamie from NV Access, the organization behind the free and open-source NVDA screen reader for Windows, are taking new approaches to accessing accessible Flash and Java applets inside the browser.

Traditionally, Adobe Flash content is being rendered into the virtual buffer in Windows screen readers such as JAWS. Over the years, this has proven to cause several issues:

  • Dynamic content frequently updating causes the virtual buffer to either get out of date, or to update so frequently that reading the content is close to impossible.
  • Accessing content can be cumbersome if Forms Mode or similar concepts are not properly handled.

For these and other reasons, the WebAIM screen reader survey taken last year ranked Flash as the technology posing the most accessibility obstacles on the web for blind users. 71% of all participants found Flash to be difficult or extremely difficult to use. Inaccessible Flash applets, which take up the vast majority of Flash content out in the wild, are doing the rest to strengthen this view.

With Java applets, things get even more complicated. For one, one has to install the Java Access Bridge from Sun Microsystems, to get Java to be accessible at all, inside the browser and elsewhere. Once that hurdle is taken, Java applet content is not rendered inside the virtual buffer, but is present somewhere within the browser window, and one usually has to try to tab to it and get focus to it that way, outside the context of the virtual buffer. Accessible Java applets are very rare and currently hardly play any role when considering accessibility on the web. If at all, they’re viewed as obstacles and something to be avoided.

However, this could change with the approach the NV Access team is taking. In their latest snapshot build, they are introducing an interaction model that is remotely similar to what blind Mac users have come to know and appreciate from Apple’s VoiceOver screen reader. What you do is this:

  1. You load a web page that contains Flash content. For example, take any YouTube video.
  2. You navigate to a spot that says “embedded object clickable” with the normal virtual buffer navigation methods. For easiest access, NVDA provides the quick navigation key o to get to embedded objects.
  3. Press Enter.
  4. What this does is zoom in on the embedded Flash object and give it focus. Now, use Tab and Shift+Tab to navigate around the Flash app. Other keys such as the arrow keys also will perform differently now, for example left and right will scrub through the video on YouTube.
  5. When done, press NVDA+Space to leave the embedded object and zoom out, returning to the parent web page. Your virtual buffer navigation will now function the same way as it did before you zoomed in on the Flash.

One note of caution: I fell into the trap that I thought the content would be rendered in the virtual buffer, as is traditionally done with Windows screen readers. To be honest, I didn’t read the note on this feature before I played with it. :) But if you don’t tab after pressing Enter, you will immediately leave the embedded object and continue navigating with the virtual cursor. This is because Flash does not focus any particular object inside the applet by default when the applet itself gains focus.

When I tried this on YouTube earlier, I had the feeling I had never seen so many details of the YouTube player before! :)

One more thing: The above technique will work in Firefox 3.5.x and the latest Minefield nightly builds, and it will also work in the 3.6b1 that’ll be available some time soon, but is not going to work in the 3.6alpha release we issued beginning of September, due to a regression that only recently got fixed in the 3.6 codebase.

With this new, in my opinion more user-friendly approach to accessing Flash content and Java applets, making sure your Flash or Java applets are accessible is becoming even more important than it already is, since blind users will be able to interact with applets more seamlessly than before.

And while we’re at it, the better support in NVDA for Flash should also be an incentive to Adobe to make Flash accessible on other platforms such as Linux and Mac. For the Mac, maccessibility.net have a petition to Adobe for making Flash accessible on the Mac. If you haven’t already done so, I encourage you to show your support by signing that petition!

The current state of accessible Firefox on the Mac, your help is appreciated!

Tuesday, September 22nd, 2009

I’ve been asked time and time again about what the current state is of the possibility of an accessible Firefox on the Mac that interacts with the VoiceOver screen reader. Well, let me recap what the current affair is.

First of all, the bad news is that getting the remaining quirks out of Mac accessibility is not going to happen this or next quarters.

The main reason is that our code currently needs to be made ready for future enhancements. Our recent work on the IAccessibleTable2 interface showed us that painfully: The refactoring and reorganization needed took much longer than we had estimated and required us to touch much more code than we had hoped. We also have some nasty event firing problems that have been a pain in the neck for those ATs supporting us that we desperately need to attack these now.

However, the good news is that since early May, the accessibility unit tests (Mochitests) have been running mostly successfully on the Mac on both the mozilla-central and mozilla-1.9.2 branch tinderboxes. Those tests had been running successfully on Windows and Linux since December already. They’ve been intermittently showing some flakiness (what we call random orange) in especially the events area, which is what we’ll be working on in the immediate future anyway, but otherwise been quite stable.

On top of that, at least investigating and driving the Mac accessibility effort forward has been sort of a pet project of mine all the while, even though Mac a11y is no longer part of our team’s official goal set for this year.

What I’ve been doing is build Mac builds with accessibility enabled on my MacBook and test them whenever I had some cycles. On Mac OS X 10.5 (Leopard), VoiceOver and the Firefox builds played terribly together, with lots of sluggishness and delayed responses that made it impossible to get any really useful testing done.

This, however, has changed with Snow Leopard. Without consciously changing things on our end, a build done under Snow Leopard is much more responsive with VoiceOver. We’re nowhere near the good performance blind people have come to appreciate from Safari yet, but we’re doing much better now. Whether it’s the improved VoiceOver or the fact that we’re now building against the MacOS10.5 SDK, or both, I don’t know.

The following are what I’d consider the most pressing issues before we could even think about sending this off to a bunch of voluntary testers:

  • VoiceOver is not speaking most accessible roles of UI and web page elements. Strangely enough, when pressing a button, it will say “Press button” and the like.
  • VoiceOver skips over plain text on pages, and the text is also not visible in VoiceOver’s Obbject Chooser menu.
  • Other inconsistencies having to do with roles like VoiceOver not recognizing our HTML area as such and not automatically starting to read pages etc.
  • Performance problems: Right now, navigating from one element to the next takes about half a second, which is unacceptable.

And this is where you might be able to help us! Are you a developer who is fluent in Objective-C, and (as a bonus) versed in Apple’s accessibility APIs? We could use your voluntary help in trying to nail this down!

So if you’d like to help improve Firefox on the Mac and have an idea about what might be going on here, go grab the source and build it! In order for accessibility to be turned on, in addition to all the stuff you need to put into your MOZCONFIG file, you need to add the following line:

ac_add_options --enable-accessibility

With this exception, commence as described in our docs.

Once you’ve got Firefox built, you can press CMD+F5 to turn on VoiceOver. A friendly male voice named Alex will start talking to you immediately and give you feedback on your actions through your Mac’s speakers. CMD+F5 is a toggle, so the same keystroke will turn VoiceOver off and leave no trace of it having been active.

Once VoiceOver is running, the following is a list of hot keys that can be used to navigate. Note that VO refers to the VoiceOver modifier, which is both Ctrl and Option held down.

Key Description
VO+Arrows Navigate in all 4 directions. Left and Right from item to item sequentially.
VO+Shift+DownArrow Interact with the currently spoken item. Interacting is examining an item in more detail. For example, interacting with a table will expose the individual cells to VoiceOver and restrict navigation inside this container.
VO+Shift+UpArrow Stop interacting and return to the parent level of navigation.
VO+Space Press or activate the current item. This will perform the default action, which is usually identical to clicking the mouse.

More information is available on Apple’s accessibility site. A Key commands chart (PDF) will give you more keystrokes, and the linked-to bugs above will give exact steps to repro the bugs themselves.

Since Firefox is not a native COCOA application on the Mac in the sense that we implement all our UI elements ourselves, we have to expose the whole accessibility contract and are obviously doing some things wrong there. The initial work that was done was done by a Mozilla Foundation grantee back in 2006, but this project was never finished and the project had been in limbo since then.

If you are willing to help, feel free to connect with me through e-mail (available from my About page) or via IRC on the #accessibility channel. I’ll be glad to assist with getting involved. The accessibility team definitely would appreciate it, and so would many community members I’m sure!

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’!

Use CSS3 transforms, makes your pages more accessible!

Wednesday, August 19th, 2009

If you’re one of those types who likes to visually twist, rotate or tweak some text, in previous years the only real choice was to use pictures to achieve such visual effects. However, thanks to CSS3 transforms, supported in Firefox 3.5 and later, Safari 3 and later, and Opera 10 beta, it is now possible to use plain text and rotate, twist and tweak its looks via CSS. The big advantage: Screen readers will still read the text OK because their reading order is not influenced by the visual appearance of the text. So even text rotated by 45 or 90 degrees will appear correctly in a screen reader’s virtual buffer.

There even is a workaround for IE, but it doesn’t work in IE 8. To quote a friend from Germany: “Maybe IE 17″. :)

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!

My first experience using an accessible touch screen device

Monday, June 22nd, 2009

Yes, you read correctly: An accessible touch screen device! This morning, I went to a retail store carrying mostly Apple products and had a look at the new iPhone 3G S that was released in Germany on Friday. Apple revealed during the WWDC keynote two weeks ago that it would have a built-in screen reader named the same as is included in Mac OS X: VoiceOver. This is a feature not available on the regular iPhone 3G, as its hardware capacity is insufficient.

I was not at all sure what to expect. From reading a bunch of posts on the VIPHone Google Group, I knew that people were going through a learning curve, a steep one at times. Up to now, something usable via a touch screen or touch-only keys would always mean a dead-end to me and other blind people. The iPhone 3G and the iPod Touch are not usable for me. Likewise, elevators that have keys you only need to touch, not press, to get toa different floor, are a real challenge. In fact I once tripped an alarm while trying to use such an elevator, alone int he cabin and touching the emergency button accidentally.

When I arrived at the store, I had already made arrangements with them to be allowed to take an in-depth look at the 3G S. As we went over to the iPhone stand, one of the sales assistants already knew how to turn on VoiceOver. Apple are documenting this in the regular iPhone user’s manual, no special docs needed. The assistant helping me turned it on, and a clear crisp voice came out of the built-in speakers. She was a bit confused by the changed gestures. I had done some reading, and took over from there.

And I must say this was an amazing experience! My fingers definitely need to get used to gestures such as flicking or tapping, or using a rotor. But having an iPod Nano 4th generation helped with that, since moving the finger over the screen like on a dialer felt most like tracking around the iPod’s click wheel. Even the sound the rotor makes is the same. :)

Responsiveness to gestures was amazing. I own an Nokia N82, which is to date probably the handset that reacts fastest to keyboard commands with the Talks or MobileSpeak screen readers, but the responsiveness on the iPhone beats that by lengths!

Finding my way around the iPhone’s UI took some getting used to. Traditional mobile screen readers, also like most Windows or Linux screen reader solutions, give the blind user a filtered view of the world, by default constrained to the focus location. Only on demand can one explore the screen using mouse emulation or similar techniques. On the iPhone, you interact with the real thing right from the start. You touch the screen in the lower half, somewhere on the right, and you’re told that the Safari or iPod symbol is there on the Home screen. You move your finger to the left, and you’re told what’s right next to it. To interact with the menu bar of the Phone app, you need to move your finger down to the bottom and move from left to right to hear the options such as “Contacts” or “Phone pad”. Yes, there are VoiceOver gestures to explore the screen top to bottom, left to right. You do this by flicking left to right anywhere, and the accessible controls are being walked one by one. But the interaction model is very close to the actual screen layout most of the time. This tremendously helped when I walked through a couple of applications with the sales assistant standing next to me. She could literally point me to the correct spot, and VoiceOver would speak what I needed to hear. Or she could give me verbal directions, and my finger would find the controls.

Typing is probably going to take the most adjusting. It is nothing like typing on the number pad of my N82. James Craig’s typing tip for VoiceOver on iPhone helps a lot: You look for the correct key with one hand, keep your finger there, then tap somewhere on the screen with another finger from the same or the other hand, and the character is input. Gladly, the keyboard doesn’t change position, and after a few letters I had a very good idea where each letter should be, and my typing sped up within 10 typed letters already. In addition, one can turn on word prediction/completion, which is another accessibility feature that can also aid people with motor impairments make typing easier. It plays nicely with VoiceOver.

This is by far not a comprehensive review or comparison. I couldn’t use many of the features since the SIM card in that exhibited model was locked, and I don’t have my own model yet.

Apple are speeding ahead and breaking down conventions in accessibility, or as Mike Calvo of Serotek wrote: They’re getting to the future first. They’re the first to include a screen reader for the blind on one of their mainstream models. Google are going to do something similar with their G1 efforts. The API is there, and some basic console work seems to be working already, but this is by far not as comprehensive as what Apple are doing. RIM also have an accessibility API, but from what I’m told, the screen reading solution that has been hinted every now and then over the past couple of weeks is going to cost extra money, which Apple’s solution does not. The traditional mobile accessibility solutions on Windows Mobile and Symbian S60 all require an additional payment of $200 to $350 for a screen reading solution, or in some cases even proprietary hardware that then costs $2000 or even more.

And this, of course, opens up other possibilities for future implementations of touch screen use cases, not just by Apple, but by other companies as well.

And one more bit of info: The gestures and touchy interface also come to VoiceOver in Snow Leopard with compatible new MacBooks with the multi-finger trackpad. So whenever a colleague tells me to lok for something in the top right quadrant of the screen, I can do that once I have Snow Leopard running on my MacBook. I’ll just put my finger there and let VoiceOver tell me what’s there!

Now my only problem is to get an iPhone. It would appear that my current contract doesn’t allow me to upgrade, since I upgraded it only recently, but too long before I knew the 3G S was coming. We’ll see how I get my hands on a device, it’s not freely available without contract in Germany.

My first touch screen experience was an amazing one!