Archive for October, 2009

Easy ARIA Tip #4: Landmarks

Saturday, October 31st, 2009

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

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

What the heck are they?

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

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

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

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

How are they added?

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

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

The different landmarks

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

banner

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

complementary

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

contentinfo

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

main

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

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

navigation

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

search

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

application

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

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

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

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

What about validation?

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

Further reading

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

Previous Easy ARIA Tips

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

Firefox 3.5.4 fixes certain comboboxes on Linux with Orca

Wednesday, October 28th, 2009

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

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

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

Tuesday, October 27th, 2009

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

WAI-ARIA landmark support

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

WAI-ARIA Drag And Drop support

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

More features

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

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

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

The importance of placement of HTML elements in a document

Wednesday, October 7th, 2009

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

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

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

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

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

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

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

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

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

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

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

Friday, October 2nd, 2009

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

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

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

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

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

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

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

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

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

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

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

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