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

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”

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

NVDA (Non-visual Desktop Access) is a free and open-source screen reader for the Microsoft Windows operating system. Unlike its commercial counterparts, which have to be purchased to be legally used for testing web sites, NVDA does not cost you any money. Moreover, it is light-weight yet powerful, and can be installed on both physical as well as virtual desktops. Your system won’t be impaired by it, no video drivers will be installed. If you like, you can even put the portable version onto a USB thumb drive and run NVDA from there, requiring no installation at all.

How to get NVDA

NVDA can be downloaded from the project’s homepage. Generally, you have two options:

• Download the release version, which at the time of this writing is 0.6p3. This is a stable release which is suitable for most tasks. However it may not contain the latest updates.
• Download a current development snapshot. This may be a bit more unstable, or features may be in flux or temporarily unavailable, but those features that are available are the latest cutting edge. For example, if you want or need to test your web sites with Internet Explorer 8 in addition to Firefox, there’s no way the current release version, 0.6p3, can do that reliably for you. However, please be aware of some limitations when testing Accessible Rich Internet Applications (WAI-ARIA) enabled web apps with IE. Also, NVDA’s support for IE dynamic updates and ARIA support are still heavily under development at this point, so results may not be as good yet because of that.

Once downloaded, install it, or put the portable version on a suitable USB thumb drive and insert it.

First start

Starting NVDA is easy. The installer offers to run it right after it finishes. Running it from the USB drive is as easy as opening it in Explorer and double clicking the NVDA executable.

On first start, a quick start guide will appear. I encourage you to at least browse it. You can then choose to disable this dialog and click OK. Now, NVDA will sit in your system tray, talking to you through your sound card.

Visual speech output

NVDA offers a handy feature for those who cannot, or do not want to, get used to the default voice that ships with it. It comes with a synthesizer that instead of speaking, outputs what it would say into a small window on your screen. To turn this on:

1. Right-click the NVDA icon in your system tray.
2. Select Preferences -> Synthesizer.
3. From the drop down, select the Display synthesizer.
4. Click OK.
5. If you want to save your changes to make them permanent, right-click the NVDA icon again and select “Save settings”.

Opening your first web site and looking at it with NVDA

Now, it is time to start Firefox and open a web page to make sure you get the proper output.

Once the page loads, NVDA should automatically announce the title. Now, it is time to familiarize yourself with the virtual buffer concept common to all Windows screen readers on the market. In a nutshell, what happens is that NVDA takes the HTML of the page and converts it into a flat document with semantic information. Links, headings, form fields, images and other information is being spoken along with the actual text of the page. It is done in the order the HTML appears in the source that Firefox just loaded.

This so-called virtual document is what NVDA presents to you by default. You can use the arrow keys to navigate the document by character or line, and with the Ctrl key added, also by word. You can even select text using Shift plus arrow keys and copy that selected text to the clipboard.

If you encounter an interactive control such as a textbox, combobox or listbox, you can switch to what NVDA calls Focus Mode, in which the virtual buffer reading mode is stopped and focus is set to the control at hand, ready for you to interact with it using the keyboard, as if NVDA was not running at all. You invoke focus mode by pressing Enter when the virtual caret is on the relevant field. Using Escape, you switch back to reading inside the virtual document. If you navigate the page with the Tab key, focus mode will automatically be switched on and off for you.

As you navigate the virtual document, NVDA will update the real browser focus to each focusable element as you hit it with the virtual caret. You will often get visual indication of where you are on the page if you get lost.

As you navigate, NVDA will also speak semantic information such as “link”, “heading level 1″ (through “heading level 6″), “button” or the like. It will indicate whether you enter or leave lists and how many items these lists have.

Virtual buffer navigation keys

While the virtual buffer is active, the following key combinations can be used to perform actions.

Note: The NVDA key is usually the Insert key on the number pad, but can be configured in the Preferences/Keyboard… settings of the NVDA menu to be the CapsLock key.

The following is a list of quick keys to move the virtual cursor. These single letter keys can be combined with the Shift key to perform the same function in the reverse direction.

So, if you’re browsing this article with NVDA, pressing Ctrl+Home, followed by t once will bring you to the first table, which is the table with the general purpose keystrokes. Pressing t again will move you to the second table which contains the virtual buffer quick keys.

Checking for different aspects of your web page

OK, now that you’ve made yourself familiar with how NVDA works, it’s time to load your own web pages and give them a check up. Things that NVDA can help you determine quickly:

• Do your headings follow a logical structure and substructure? Or did you put everything at one heading level even though something may be a sub section of something else?
• Do your form fields like edits and buttons have labels? In other words, does NVDA speak something like “User name: edit” automatically, or does it just say “edit”? If the latter, your labels aren’t properly associated with the field they’re labelling. This is an error in your markup which is easily corrected.
• Do your important images have proper alternative text? All images that are part of links, and all images that communicate something important must have alternative text. Otherwise, screen readers cannot pick up the meaning of the image. They will try to guess part of the src attribute as the image name, but this is at most cryptic if not completely useless.
• Are things such as navigational links grouped together inside a list of some sort? Putting them in a list helps to add structural information to your pages.
• If using WAI-ARIA, are you using landmark roles for navigation, search, main, footer etc.? This will aid in identifying specific parts of your page and thus help in navigation/understanding of the layout.
• Also if using WAI-ARIA, are your form fields that are required using the aria-required attribute? Screen readers such as NVDA can use this to give an unambiguous indication that this field is required to be filled in.

Of course, there are more things to check than the above, but these are starting points where NVDA can help you assess quickly whether your markup is good.

Advanced techniques

NVDA provides a mechanism called Object Navigation. This mode is a walker of the accessible hierarchy exposed by Firefox and other accessible applications. There is a root accessible object usually representing the main window or frame, and as its children, grandchildren and grand-grandchildren etc. are all the objects the UI and the currently loaded web page expose. There are tools such as Microsofts Accessibility Explorer or IBM’s AccProbe to visualize this, but if you do not have these at hand currently, or want to listen to your tree rather than see it, NVDA offers you the means to do so.

NVDA also provides some default information such as whether the element is actually being displayed (visible), unavailable (grayed out) or other similar info. The following are some basic keystrokes to get you started:

Siblings refer to objects which have a common parent, just like in ordinary family relations.

When navigating your page with this mechanism, you will hear every list, every div (exposed as sections), every form and its formfield children, etc., and can get a feel for how your markup affects the output to the accessibility programming interfaces.

More information on the object navigation is available in both the quick key reference and the NVDA user guide, which were both installed onto your system when you installed NVDA.

In conclusion

This article is not meant to replace the NVDA user guide. It is hoped that this article is going to be useful for web developers who want to add one more testing tool to their daily workspace to test the human interaction factor of their web sites.

Having said that, feedback is, of course, very welcome! You can find information on how to contact me on the “About” page.

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.

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

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

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

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

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

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

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

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

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

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

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

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

As an appreciation for the work devs at Google such as Srinivas Annam are doing to provide better access to GMail, this post starts a series of articles on the subject of putting ARIA into GMail, either after I’ve been pointed to specific areas or by finding new features myself.

The first in this series of reviews of GMail ARIA features concerns a very simple, yet effective, one: Alerts. As I already mentioned in my Easy ARIA Tip #3, alerts are a great way to immediately notify users about important status updates, but without taking focus away from where you are currently working.

As I found out rather by accident, GMail now uses an ARIA landmark role of “alert” for the piece of the UI that pops up with an important status message for a few seconds after certain actions have been performed. It disappears again after a few seconds, but because this is an alert, screen readers pick it up and speak it automatically as soon as it appears. Alerts, in the assistive technology terminology, are important status messages that can pop up anywhere on the screen and should be spoken or otherwise indicated to the user immediately. Another example of an alert is the notification box that appears when Firefox asks the user whether they want to remember the password just entered. It is an important notification the user might want to act upon, but still less intrusive than a modal dialog.

Actions that cause this alert to appear are such ones as moving a contact from the “Recommended contacts” to “My Contacts”, deleting a label, sending an invitation to someone for Google Talk/Chat, adding a contact, etc.

This way, actions that previously used to only pop up a message now provide immediate feedback. There is no need to look for the message, and when one finds it, find out that it just disappeared after the timeout.

The problem: You have a form, a contact form, for example, that you want to put some accessible error checking into. Common problems are e-mail addresses that are not valid, or a name that does not contain at least a first and a surname.

The form

Let’s start out with a simple form.

<html>
<head>
<title>Contact form</title>
</head>
<body>
<form method="post" action="post.php">
<fieldset><legend>Please enter your contact details</legend>
<label for="name">Your name (required):</label>
<input name="name" id="name" aria-required="true"/><br />
<label for="email">E-Mail address (required):</label>
<input name="email" id="email" aria-required="true"/><br />
<label for="website">Website (optional):</label>
<input name="website" id="website"/>
</fieldset>
<label for="message">Please enter your message (required):</label><br />
<textarea name="message" id="message" rows="5" cols="80" aria-required="true"></textarea><br />
<input type="submit" name="submit" value="Send message"/>
<input type="reset" name="reset" value="Reset form"/>
</form>
</body>
</html>

Straight and simple, but we’re not here to win beauty prices anyway.

Checking for validity and notifying the user

Checking the validity and notifying the user consists of several steps:

1. Checking if the e-mail address or entered name are valid. To keep it simple, we’ll check whether the e-mail address contains the “@” symbol, and if the name entry contains at least 1 space characters ” “.
2. Setting the field’s aria-invalid attribute and giving it a value of “true”.
3. Notifying the user via an alert that the value entered was incorrect. Instead of using an intrusive dialog box created by the JavaScript ‘alert’ function, we’ll use a simple WAI-ARIA widget to do it. This notifies the user, but lets them continue interacting with the form without any interruptions.

All of this happens when the input loses focus, meaning in the “onblur” handler.

The JavaScript code I wrote looks like this, inserted above the closing “head” tag:

<script type="application/javascript">

  function removeOldAlert()
  {
    var oldAlert = document.getElementById("alert");
    if (oldAlert)
      document.body.removeChild(oldAlert);
  }

  function addAlert(aMsg)
  {
    removeOldAlert();
    var newAlert = document.createElement("div");
    newAlert.setAttribute("role", "alert");
    newAlert.setAttribute("id", "alert");
    var msg = document.createTextNode(aMsg);
    newAlert.appendChild(msg);
    document.body.appendChild(newAlert);
  }

  function checkValidity(aID, aSearchTerm, aMsg)
  {
    var elem = document.getElementById(aID);
    var invalid = (elem.value.indexOf(aSearchTerm) < 0);
    if (invalid) {
      elem.setAttribute("aria-invalid", "true");
      addAlert(aMsg);
    } else {
      elem.setAttribute("aria-invalid", "false");
      removeOldAlert();
    }
  }

</script>

The checkValidity function

The core is the checkValidity function. It takes three parameters: The ID of the input that is to be validated, the term to search for to ensure validity, and the error message to be inserted into the alert.

To see if it is valid, the function checks whether the indexOf the input's value is anything greater than -1. A value of -1 or less is returned if the index of the search term could not be found within the value.

If invalid, the function does two things:

1. It sets the element's aria-invalid attribute to "true", which will indicate to screen readers that there is invalid content in here.
2. It will call the addAlert function to add the alert with the provided error message.

If the search term is found, the aria-invalid attribute is reset to "true". In addition, any alert that still might be around is removed.

The addAlert function

This function first removes any old alerts. The function is simple: It looks for an element with id "alert", and if found, removes that from the document object model.

Next, the function creates a div element to hold the alert text. It gets an ID of "alert". And it gets a role set of "alert". This is actually ARIA-inspired, even though it doesn't say "aria" in the attribute name. The reason is that role is based on the XHTML role attribute module that was simply ported to HTML for simplicity.

The text is added to the div element, and the div element is added to the document.

The moment this happens, Firefox will fire an "alert" event to assistive technologies when this div appears. Most screen readers will pick this one up automatically and speak it. This is similar to the Notification Bar in Firefox that prompts you whether you want to save a password. Our one does not have any buttons to press, it just tells us what's wrong.

Adding the magic to the "onblur" event

All that's left now is add the event handler. We need to change the two inputs for e-mail and name for this:

<input name="name" id="name" aria-required="true" onblur="checkValidity('name', ' ', 'Invalid name entered!');"/><br />
<input name="email" id="email" aria-required="true" onblur="checkValidity('email', '@', 'Invalid e-mail address');"/><br />

Testing the example

I've put up the above as an static example page for you to try it out. If you use Firefox 3 and a current supported screen reader, try the following:

1. Enter only your first name as the name. When tabbing, you'll hear an alert that tells you you've entered an invalid name. You can then shift-tab back and correct the error.
2. Enter an e-mail address that has no "@" symbol. When tabbing out of this field, you should hear a warning that says you didn't enter a valid e-mail address.

In both cases, when returning focus to the field in question, your screen reader should tell you that this field is invalid. JAWS 9 supports this, but JAWS 8 does not, so this may not work in all versions of the screen readers supported.

A few questions that you might have

Why did you put both "(required)" in the label text and the aria-required attribute on some of the inputs?

Because if this were a real live form, and the site was being visited by a browser that does not yet support ARIA, we'd still want to give an indication that this is a required field.

Why don't you set focus back to the invalid field automatically?

Because this is not allowed by at least the Windows API specs and possibly others. Also, letting the focus jump around without real user interaction too often is not a nice thing to do in general.

In conclusion

Personally, it is my hope that websites would include such techniques more often in the future when filling out forms. There's nothing more frustrating than filling out a form with 20 or so fields, submitting it, only to find that field 3 was invalid, and having to go through all fields again to make sure the values were retained, or supplying some information redundantly.

This is one of those examples where, in my opinion, more direct accessibility and user-friendliness can be achieved by explicitly using some JavaScript in combination with ARIA.

I hope you found this little tutorial of some use! I'd welcome your feedback as always!

And of course, you're welcome to enhance this little example as a "homework" to also check whether something valid was entered for the "message" textarea.

Previous Easy ARIA tips

1. aria-required
2. aria-labelledby and aria-describedby

However, the implementers of Firefox accessibility have done their homework: Ben’s examples work nicely with Firefox 3. The association is made properly, the label accessible is built up fine, and the input accessible gets its accessible name defined correctly. I also tested with that other browser that came with my Windows XP, and users there are less fortunate: IE does not properly make up the accessible name for the label and also does not correctly associate the accName of the input type with the label’s full content.

So, does Ben’s example now completely obsolete the need for the aria-labelledby and aria-describedby attributes? Most definitely not! There may always be cases where nesting the input into the label is impractical/not wanted, or where the description cannot be so nicely densed into the label as Ben shows using my example. For those cases where you explicitly need to specify something to become the accDescription, you definitely can still use ARIA. You can even use aria-describedby inside an input that’s nested within a label.

Imagine this: You have a form where you ask your user a question, but the answer is actually part of the sentence the question is made of. A classic example we all know from our browser settings is the setting “Delete history after x days”. “Delete history after” is to the left of the textbox, x is the number, for example 21, and the word “days” follows the textbox, actually forming a sentence that is easy to understand.

If you’re using a screen reader, have you noticed that, when you go to this setting in Firefox, it actually tells you “Delete history after 21 days”?, followed by the announcement that you’re in a textbox, and that it contains the number 21. Isn’t that cool? You do not need to navigate around to find out the unit. “Days” could easily be “months” or “years”, and in many ordinary dialogs, there is no way to find this out other than navigating around with screen reviewing commands.

Well, we have to thank Aaron and all the other great people who invented ARIA, for this capability! The solution is in an ARIA attribute called aria-labelledby. Its parameter is a string that consists of the IDs of the HTML or XUL elements you want to concatenate into a single accessible name. Yes, you read right, this not only works in HTML, but in XUL, too!

A second attribute that works very similarly is called aria-describedby. It can also take IDs of one or more elements to make up an additional description. In Microsoft Active Accessibility, this is converted into the AccDescription of the element. Some screen readers like NVDA pick this description up and speak it automatically after the name and type of the control, assuming that this information is giving the visually impaired user additional information that a sighted user also gets.

aria-labelledby and aria-describedby are both specified within the element that is to be labelled, for example an html:input or a xul:textbox. In both cases, the label for/label control bindings that may also exist, are overridden by aria-labelledby. If on an HTML page you provide aria-labelledby, you should also provide a label for construct to also support older browsers that do not have ARIA support yet. With Firefox 3, your blind users will automatically get the better accessibility of the new attribute, but the users of older browsers are not left in the dark this way.

And here is an example I made up for demonstration purposes:

A Note for JAWS 8 users

JAWS 8.0 has its own logic to find labels, causing it to always override the accessibleName the textbox of an HTML document gets. With JAWS 8, I have not found a way to get it to accept the label from the example above. But NVDA and Window-Eyes do it just fine, and Orca on Linux also has no problems.

Previous Easy ARIA tips

1. aria-required

The first attribute I’d like to cover is called aria-required. It is one of the universal aria attributes, which means, as stated, that it can be used on any conventional HTML element such as input or select.

Let’s look at this sample excerpt:



In this excerpt, both the firstName and lastName input elements have the aria-required attribute set. Note that in normal scenarios, you’d also stype them or their label differently, or put an asterisk “*” after the label.
However, if you cannot or do not want to put an asterisk on the label, but only style it with bold text or the like, screen readers usually cannot pick up the information automatically that this is a required field. If you use the aria-required attribute as shown above, modern screen readers will indicate that this is a required field automatically, if used together with Firefox 3.
Screen readers that already support this feature are NVDA, JAWS 9.0, and Window-Eyes 5.5 or higher. JAWS 8 does not support this attribute yet. Also, ORCA does not seem to pick this attribute up yet, at least my testing showed that Orca did not indicate the required state to me when tabbing through that form.

On the browser side, Opera 9.5 is going to include ARIA support, so this technique is not limited to Firefox. Also, as this technology spreads, more browsers will pick up on it, and your sites will automatically be compatible and more accessible once these other browsers also support ARIA.

This is the first of a couple of examples that demonstrates how easily you can use ARIA without implementing a whole widget to improve accessibility on your web sites. Start using it today, and you’ll make sure that you help insure good accessibility for people using modern browsers and screen readers!