The premise

The base for my talk is my third easy ARIA tip, where I enhanced a form with some basic local form validation to help users fill it out and avoid errors upon submission. If you are not or no longer familiar with what I did there, stop reading here and go read that post again as a recap. If you are caught up, let’s move on!

From WAI-ARIA to HTML5

Since then, a lot of time has passed, and we’re now much better equipped with native markup magic that HTML5 supplies us. Thankfully, Firefox and also other browsers implement most, if not all, these features now, so we can move ahead with our changes. To remind you, WAI-ARIA is there to enhance, not substitute, native markup, so whereever possible, we should use native markup when available. These changes are:

1. Strip all JavaScript: Let’s start clean and see how far the new native markup stuff gets us!
2. Throw out all aria-required="true" instances and replace them with the HTML5 required attribute. This gives us automatic flagging of a required field not only via accessibility APIs, but also through visual indicators. Also, a required field is automatically flagged as invalid if it is empty.
3. For the field ‘name’, add a pattern attribute containing a regular expression that defines a valid name consist of some characters, one space, and some more characters. This will cover most cases, and if you’d like something more complex, consider me giving you some homework.
4. The field “email” gets the type “email”, the field “website” gets the type “url” set. This gives us proper validation of e-mail addresses and URLs respectively right upon entry. Moreover, on mobile devices with a virtual keyboard, the most common extra keys are usually provided right out of the box.

In addition, for a better error message, I am using the non-standard x-moz-errormessage attribute on the “name” field to tell users that the name was entered wrong rather than the standard “patterns don’t match” error message the browsers usually throw at users in the instance of them having entered a wrong value.

In addition, the name field contains (already in the ARIA example) a title attribute that tells users that a name must consist of at least two words.

Filling out this form now gives us validation upon submission. Firefox sets focus back to any invalid field it finds when users press the “submit” button. In addition, an error message is displayed describing the problem.

…and back

Our original example, however, was better in that it provided validation right at the point when an entry lost focus. Since this is a dynamically created alert box that is not yet a native HTML5 element, we have to resort to WAI-ARIA again to make this work the same, but using the HTML5 validation benefits. So, let’s enhance our example:

1. Bring back the first two functions from the original ARIA version unchanged. These remove any existing alert box, and they create a new alert with the given message.
2. Adjust the function that is called in the onblur handler of the “name” and “email” fields (see below):
   1. First, we have to adjust the function name to something that doesn’t clash with a reserved word. I used testIfEntryIsValid.
   2. Now, get rid of the search string and error message parameters. These are no longer needed because the validation is done by the browser, and we simply use the HTML5 form constraints API to ask the browser for the relevant info. Also, the browser provides us with the appropriate error message, so no need to generate one ourselves here.
   3. In the if clause, simply ask if the call to the checkValidity() method of the element we obtained in the line above gives us a “true” or “false” result. If true, simply remove the old alert. If false, create an alert and use the element’s validationMessage property as the message parameter. The browser will handle the rest for us.
   4. Remove the lines that set aria-invalid. These are no longer needed, since the browser’s constraint validation will provide the invalid or valid states automatically.
3. For the “name” and “email” fields, add back onblur handlers pointing to the above function and simply pass in the field’s ID.

Testing this example, it shows that we’ve got our original functionality back. In addition, if we ignore the intermediate error messages, the browser’s validation mechanism will throw us back to any of the wrongly filled out fields upon a submission attempt. Note that not all browsers do this last step. Safari on the Mac, for example, will submit the form even if it contains invalid entries.

In summary

The new version of our form is much improved over the version we had originally. It still contains some WAI-ARIA where it makes sense, since there is no native HTML5 alert box yet. But the rest is HTML5. The JavaScript code is a bit less bloated since we don’t have to do our own validation any more, and we benefit from all the builtin constraint validation mechanisms.

Feedback is welcome! But before you throw things at me for my sloppy JavaScript, please keep in mind that this is just a proof of concept. If you would like to re-use this technique, I encourage you to put your best knowledge to use and put in better handling of events or such, appropriate for your web application.

The example pages can be found (in English and German) at this address. Happy hacking!

First and foremost, we participated in the improvements to memory usage and speed. More accessibility classes participate in our garbage collection mechanism, reducing the memory consumption greatly. Long sessions with a screen reader running should no longer result in huge amounts of memory being consumed. This is especially evident if you run with multiple tabs and open lots of pages.

A bug was fixed that caused large additions to xul:tree elements to hang for long times when accessibility was turned on. This could be observed in add-ons such as Adblock Plus on occasion.

If role="presentation" has been specified on an element and this element is made focusable, for example by setting tabindex="0" on it, the role of presentation is now ignored, and an accessible is created for the element nevertheless. This is to avoid situations where one would suddenly land on a focused item for which there is no accessible. This was the cause for some screen reader confusion.

On HTML table elements, the way the summary attribute and caption elements were handled has been switched around. Now, if the caption element is present, it becomes the primary source (ARIA not withstanding) for the name of the table. summary is now being converted into the accessible description, which is used to communicate additional information to users. Only if the caption element is omitted, summary will still become the accessible name’s source. Until Firefox 6, summary would always become the accessible name’s primary source. This brings Firefox in line with other browsers. Also, if assistive technologies query for the relation between the caption and table elements, the relation is now LABELLED_BY instead of DESCRIBED_BY.

In addition, some crash bugs were fixed that were found in earlier updates of Firefox, so this version is not only less memory-hungry and faster, but more stable, too. Happy browsing!

For my testing, I used the latest release of Firefox, version 6.0.2, and NVDA 2011.2 (the current release). I also found that it is a good idea to look in the Mail Accessibility help, and there especially the keyboard shortcuts.

First steps

Armed with this information, I logged into my Yahoo! mail account. First, I was prompted to switch to the new Yahoo! mail. Go ahead and do so if you haven’t done already.

I was then greeted with the What’s New tab of the new interface. This is a web document one can browse to find out the latest headlines, but at the top it also gives you the choice to switch to your inbox. It tells you how many unread messages you have, and how many in total.

The inbox

I went ahead and activated the link to go to the inbox. What followed was a switch to focus mode from the default browse mode. The reason became evident: i was no placed in the messages list, a rich widget that allows for navigation through the messages with the arrow keys up and down. Speech feedback is just marvelous, one gets all the relevant information one would expect to hear, just like one was in a desktop client like Thunderbird or Outlook.

Also, as can be seen in the above linked to shortcuts list, a lot of shortcuts that are familiar from desktop clients simply work in this e-mail client, too: delete deletes a message and provides great speech feedback, r initiates a reply, f forwards one. Yes, these are different from Thunderbird and Outlook, but hey, with each new program, you have to learn some new shortcuts, even when switching from Outlook to Thunderbird.

Reading a message

Pressing enter opens a message for reading. And here’s one of the beauties of this WAI-ARIA enabled e-mail client: The markup used is really being used in a sensible and intelligent way. While the messages list definitely needs to be treated in application mode, the message itself is a document and thus should make use of NVDA’s browse mode (virtual cursor). And this is exactly what happens. Without having to do anything, NVDA will switch to its browse mode and start reading the e-mail you just opened. If this is an ordinary e-mail message, there is a reply box right at the bottom, so one can answer the e-mail from here. There is no quote functionality, though, so if you want to do some fancy stuff, you’ll have to use the full e-mail dialog that you can reach by hitting r from the messages list.

Pressing escape brings one out of the message and back into the message list. It remembers the position, so one gets put right at the spot where one wants to continue browsing messages.

More to find

Tabbing around the main interface, one finds several tool bars. Again the keyboard navigation is very smart: Tab jumps from the higher-level items such tool bars to the next, while, when in a toolbar, one can inspect each available option within it using left and right arrow keys. So even if a tool bar contains 10 items, tabbing will only stop once on the tool bar. If you do not want to go through the 10 items, you don’t have to.

The Contacts tab works in a similar fashion as the mail tab, where you can manage your contact list, import from other accounts etc. The switch between application and browse modes is seamless as on the inbox tab, and information is presented in a very comprehensive manner.

Speaking of tabs: There are instructions given on navigation wherever something might work slightly differently from what one is used to from desktop applications. For example when focused on the tabs, one is instructed to navigate left and right, and that enter will actually make that tab active. In Windows applications, simply focusing different tabs already makes them active, so this is a slight difference between the interaction models which is clearly communicated. Very nice!

Social networks

The fourth of the default tabs is called “Updates”, and it allows you to connect your Yahoo! profile with those you have on Facebook, Twitter etc. While the tab itself is mainly for configuring those updates and for sending updates to the connected social networks, the reading updates app gets launched in a new browser tab. That one is a regular web site that gives you a good, and more importantly, fully accessible overview of your Facebook and Twitter timelines. While both social networks still have their accessibility issues to sort out, Yahoo!’s interface to these is fully accessible and hardly leaves anything to be desired.

Setting prefs

From the main navigation area, you can open the options/preferences for mail and other parts of the Yahoo! set of web applications. Especially in the mail preferences, you can set a few things to make your life a bit easier. One is to have messages displayed in paginated form, which gets rid of the preview pane and other stuff that might get in the way of accessibility. Also, you can set to have the inbox tab selected upon login automatically. This is something that I set since I want to do mail when I log into mail first.

You can also connect other mail accounts here. This is one of the few areas which irritated me: The link to add an account is at the very top of this virtual document, near the “Save changes” button, not down in the explanation of what adding accounts actually means, as I would have expected it to appear.

Third-party apps

One can include third-party apps in the Yahoo! mail interface. There is an app called “My social networks”, for example. These, as they are being developed and delivered by third-parties, are not guaranteed to have the same level of accessibility. Some may even be entirely inaccessible, because they use plugins such as Flash or Silverlight and may not adhere to accessibility standards within these platforms. But Yahoo! is not to blame for that. Instead, accessibility should be evangelized to those content providers that have the powers to make their apps accessible.

In summary

What Yahoo! are delivering here is a really outstanding example of putting the WAI-ARIA and other HTML accessibility techniques to very good use. WAI-ARIA has previously been deployed mainly in some enterprise/intranet or specialized public sections and gained limited exposure. Yahoo! mail is the first mainstream web application to put this technology to use and deploy it to a wide range of users worldwide.

Personally, I can even see myself switching to a web client away from a desktop client for the first time since this is the first instance of a web e-mail client that I found I can use as productively as my favorite desktop client. Other examples like the big G are far to inefficient, and for my work, the Zimbra web interface is totally inaccessible, so I have to use a desktop client for these.

Yahoo! Mail, along with the very accessible rich search interface, is a very good example of an all-inclusive, accessible, web application approach that puts others to shame that suggest to turn off their standard interface and use a basic one if one uses a screen reader. Needless to say, that basic interface is then severely limited in functionality. Or the same company that suggests to turn off their instant feature if one uses a screen reader, or search results might no longer be really accessible. Yahoo! are taking an inclusive design approach here that to my knowledge is unparalleled among big stock holder web app companies.

Of course, there are still some small kinks to work out here and there. if one uses the German version of Yahoo! Mail, for example, closing a tab requires a different keystroke than the English Ctrl+\. Unfortunately, the German version of the Mail Accessibilit yhelp topics don’t seem to have been translated yet. Searching for Barrierefreiheit didn’t yield any results, and searching for Zugänglichkeit only gave a general page about My Yahoo! accessibility, but nothing specific to mail. But I am sure these are things that will be fixed/documented in a timely manner so people whose first language is not English can benefit from the features in the same way.

I applaud Yahoo! for their newest version of the mail interface for its inclusive design principles and good accessibility for everyone! Keep up the good work!

If you’d like to read this article in German instead, here’s the translation on my German blog.

As this was a bigger update, it is time to also point out the new stuff to watch out for in accessibility. One thing I already blogged about is the HTML progress element, so I won’t cover that here. Some of the other things to be aware of are:

Seamless plugin accessibility integration on Linux

One feature that’s been baking in a bug forever, but which finally got its final push and made it into code is plugin accessibility for Firefox on the GNOME Desktop on Linux! There is only one plugin currently called Moonlight that actually uses this, but if other plugin authors want to, they can now plug into Firefox and expose their accessible content to Orca and other assistive technologies.

The Windows magnifier and the writing caret

There is a problem in Firefox 4 and 5 that will prevent Windows Magnifier and possibly other low-vision products from tracking the writing cursor properly when on the URL bar or in some other places. We were able to fix this in Firefox 6.

Improvements to the notification popup

The new notification popup that asks, for example, whether you want to save an entered password, has been improved a great deal. For one, it now announces itself to assistive technologies as an alert like the old notification bar did, which means that the text that the user is to be notified about is automatically being read by NVDA, JAWS and others. Secondly, we made the “Close this message” button tabbable again. One thing that we didn’t manage to solve in time is the inconsistency with the menu button that, when SPACE is being pressed on it, doesn’t actually do much, but you have to tab to a secondary regular button with the same label to get the actual function. We’re working on a solution to improve keyboard accessibility for these menu buttons in general, and the notification popups will benefit from this as we do.

ARIA support

In regards to WAI-ARIA, there are a number of changes/additions:

• aria-sort now fires attributechange events when its value is being changed.
• aria-selected is no longer being ignored for ARIA tabs.
• aria-busy now properly fires statechange events.
• ARIA documents children can now properly be queried via accChild API methods.

Others

Other noteworthy fixes are:

• The Untrusted Connection page is again accessible via the virtual cursor in screen readers.
• When deleting text from edit fields, the wrong text was reported through at-spi. We fixed that problem.
• We got rid of the bogus pref accessibility.disableenumvariant.
• The About… dialog is more readable than it used to be.

This is a major update that brings a lot of new features and enhancements as well as loads of stability and performance fixes to your browsing experience. And of course it is accessible!

Some recent posts on the subject by me:

1. New in Accessibility in Firefox 4
2. New support for HTML5 elements and attributes, with a lively discussion and some revamping going on for a very near future update esp to the landmark piece

If you’re a user of NVDA, Orca, JAWS, Window-Eyes, Dolphin SuperNova, Serotek System Access or Baum Cobra, you’ll be good to go with current versions of the products! Please make sure to update to the latest revision for your screen reader that you can access before using Firefox 4, as it was reported to us that some early revisions of JAWS 11, for example, cause problems invoking the virtual buffer.

We expect all screen magnifiers that worked in Firefox 3.6 to work in 4, too. Same goes for speech recognition and other assistive technology programs on Windows and the GNOME Desktop on Linux.

Landmark elements mapped to WAI-ARIA landmark roles

We are mapping the following HTML5 landmark elements to accessibles with WAI-ARIA landmark role semantics:

In a second small patch landing the next few days, we will also map the html:aside element to the “complementary” role. This was a small oversight on our part in the first patch.

Both NVDA and Orca will pick these changes up without any additional action required on their parts. Other screen readers will hopefully implement or pick up the support ASAP so web authors can use these new elements without having to worry about support or lack thereof.

The placeholder attribute

This attribute can be used on form elements to predefine text that disappears as soon as the field gets focus. It#s a visual indication of what is expected in the field. If, and only if, the field has no label otherwise, this placeholder text will be used to generate the AccessibleName, the name the screen reader speaks for the field when it gains focus. If the field has a label provided by the label element or an ARIA construct, the placeholder text will be ignored.

Proper events being generated when required/invalid/disabled states change

For a few weeks now, we have had support for the disabled, required attributes and the invalid state evaluation of patterns. Now, if any of these conditions change, we now generate the proper StateChange events to notify screen readers and other assistive technologies.

API support

Most of the changes are under-the-hood changes that do not have API changes as a consequence. There is one new addition that helps get around the now absent window hierarchy, see this post for details and bug numbers if you’re interested.

However, there are a few enhancements that one should be aware of:

Speed

Improving speed was one of the major goals for Firefox 4 in general, and also for the accessibility APIs. A couple of highlights:

• A site like BlindCoolTech, when loaded into the virtual buffer by NVDA, took approximately 6 to 6.5 seconds when loaded with Firefox 3.6.x. With Firefox 4, we’ve managed to cut this time down to under 1 second!
• We also support the very performant Lazy Frame Construction in a very speedy manner so an accessibility-induced lag should hardly be noticeable.
• When calculating meta data for big data tables, we’ve improved the speed by a huge factor. While Firefox 3.6 sometimes would hang for over 5 minutes while calculating data for a 20,000 cell table, this takes only a few seconds now.

New HTML5 elements

We have support in place for the following HTML5 enhancements of Firefox 4:

• The html:output element is supported. We expose it as a text frame, and if it is being controlled by a form or form element, we also properly set the AccessibleRelations. In addition, it receives the implicit attribute. Screen readers will therefore read text inside the output element automagically.
• We have support for the required attribute by setting the ‘required’ accessible state flag on the accessible.
• We’re also working on getting the invalid state supported for the final Firefox 4 release.
• New HTML5 input types like email, number etc. have basic support and are all viewed as text fields currently.

Changes in the WAI-ARIA support

We made changes to the WAI-ARIA support as the spec developed to the new last-call state. We removed features that are no longer supported in the specification. And we made the change that the aria-labelledby attribute now takes precedence over aria-label. When first implemented in Firefox 3.5, and for a long time in the specification, aria-label took precedence over aria-labelledby when used on the same element. Now, this is swapped around. If aria-labelledby is present, aria-label is being ignored.

Bug fixes

Of course, we also fixed a lot of bugs on the way, making the code more stable and secure. Some are part of the performance refactors, some specifically targetted. For example, there are HTML constructs that can cause bad hangs on Linux which we finally nailed down and fixed.

UI and keyboard navigation

There have been several visible UI changes, some of which also have consequences for keyboard users.

Tab strip moved to the top

The tabs moved to the top of the screen, now encompassing the URL bar and search field. Previously, these were not part of the active tab. As a consequence, the tab bar is now reachable by:

1. pressing Ctrl+L to go to the awesome bar
2. pressing Shift+Tab twice to land on the tab bar

So instead of pressing Tab twice when on the awesome bar, now it’s Shift+Tab twice. Other features like accessing the context menu for a tab by pressing Applications remain unchanged.

Pinned tabs

Pinned tabs are tabs that remain visible even when there are so many tabs on the tab bar that it needs to scroll. So your favorite tabs are always visible/accessible. For screen readers, there is currently no distinction between a normal and a pinned tab, but it is exposed nevertheless. And obviously, the context menu item is accessible.

The menu bar is gone, but not quite

The menu bar is no longer visible right away. Instead, a single popup menu, hidden behind the “Firefox” button, is replacing most of the menu bar’s functionality. However, as a keyboard user, you don’t really notice. Press Alt, and the menu bar reappears and you can use it right away again. In fact, I, being blind myself, didn’t even notice that the menu bar was gone because I was simply using the shortcut keys like Alt+F just as I did before. It was not until Surkov asked me whether the Firefox button was accessible that I noticed that there was a UI change.

Note that there is talk of mapping the Alt+F keystroke to specifically open the menu hidden behind the Firefox button in the future. So if Alt+F no longer brings up the “File” menu in the future, this is why.

Add-Ons Manager redesign

The Add-Ons Manager has been redesigned completely. It now also manages Jetpacks, search engines and much more. Moreover, it opens in a new tab instead of a modal dialog. This makes interaction much nicer, one does not have to alt-tab between windows all the time.

There are still some keyboard navigation quirks to be worked out, and some of this may come in an 4.0.x update, but the general functionality is there also for screen reader users.

New UI features that don’t work (yet)

Panorama

The new enhanced tab management feature Panorama, previously known as Tab Candy, is currently not very well navigagble using the keyboard, and hardly exposes any useful information to screen reader users. However, it is going to be possible to make these accessible, we just need a little time to do it. If you’re interested, you can follow the keyboard navigation and assistive technologies support bugs to watch progress.

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

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!

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

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”

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

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 following are the candidates:

• NVDA, using the latest snapshot build, which actually does not behave much different from the current 0.6p3 release.
• JAWS 10.0.1154.
• Window-Eyes 7.1.
• SuperNova 11.02.
• System Access in the form of the free System Access To Go service.

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

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!

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!

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!

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.

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.