The W3C Accessible Rich Internet Applications 1.0 specification (ARIA) is currently in "Last Call". The purpose of ARIA is to provide a means for web authors to explicitly identify roles, states, and properties of interactive user interface components on web pages, thereby making them accessible to users of assistive technologies (AT).
ARIA introduces the role attribute, and defines several dozen roles that can be assigned to this attribute. Seven of these are so-called landmark roles, which identify specific sections that commonly appear on web pages: banner, navigation, search, main, complementary (for sidebars), and contentinfo (for footers). Those of you who were counting may be wondering why I only listed six landmark roles.
That's because the seventh, "application", is fundamentally different. The other six landmarks are useful as targets for AT, such as the popular screen reader JAWS, which jumps directly to the next landmark when users press the semi-colon key. Historically web authors have had to add this functionality themselves using "Skip navigation" and similar links, which jump to defined targets on the same page.
The "application" role is supported in the same way as other landmark roles (for navigation), but it has a much greater role than the others in determining how AT will behave. According to the "application" section of the ARIA spec:
The intent is to hint to the assistive technology to switch its normal browsing mode functionality to one in which they would for an application. User agents have a browse navigation mode where keys, such as up and down arrows, are used to browse the document. This native behavior prevents the use of these keys by a web application.
In other words, when screen readers and other assistive technologies encounter role="application", they're supposed to relinquish control of users' keystrokes to the web application.
This raises some concerns for me:
- How will users handle their AT not working as they expect it to?
- Will web application developers do a satisfactory job of providing keyboard and non-visual access to their applications, so that the usual AT keystrokes truly aren't necessary?
- Will web applications be built using standard keyboard interfaces, so users don't have to memorize a different set of keystrokes for every online application they encounter?
If web authors can't answer Yes to questions 2 and 3, I question whether it's safe for AT to relinquish control.
An Example Web Application
An excellent example web application is QueueMusic (thanks, Jayme Johnson!). This application allows you to "Find music, put it in your queue, and then let it stream." The body element looks like this:
<body role="application">
In this application, the web page is divided into three main sections, each corresponding with one of the three steps in the process. Each section has a heading atop it (marked up with <h3>): Song Search, Your Queue, and Now Playing.
In the Song Search section, there is a search field. You enter a search phrase into that field, press Enter, and a list of results appears. If you're a mouse user you can now click any item in the results list and that's added to Your Queue (the middle section of the page). Then, if you click any item in Your Queue it plays in the media player that occupies the Now Playing section.
Here's what happens if you're a screen reader user (specifically, if you're using JAWS 11). The behavior is more-or-less the same whether you're using Firefox 3.5 or Internet Explorer 8:
You launch the page, and immediately JAWS announces "Application Mode On". On most web pages, you would now press "H" to jump through the headings on the page, because this gives you a sense of how the page is organized and structured. You try that on this page, and there are in fact headings on this page that might be beneficial for navigation, but JAWS doesn't respond because you're in Application Mode, so you don't know there are headings and even if you did you couldn't jump to them. Something's amiss here though because usually when there are no headings on a page JAWS tells you this, whereas in this case JAWS isn't doing or saying anything. Curious, you try Insert+F6, which normally brings up a list of headings. Now JAWS says "This feature is only available from within a virtual document, such as a page on the Internet." You curse JAWS, because you know with some certainty that you are in fact visiting a page on the Internet.
You also try Insert + F7, which normally would bring up a list of links from the page. JAWS, however, repeats what it told you a moment ago, and you curse JAWS a second time, this time louder and more profane than the first.
You press "f" to jump to the first form field, but nothing happens. (Even after you've found the form field by other means, this will continue to be a frustration for you because you can't easily get back to the form field to search again).
You eventually discover that you can tab to the search field, and you type in your text and press Enter. This returns a list of results and you're able to navigate down through that list with the down arrow. However, when you find the item you want to add to your queue, pressing Enter doesn't queue it. If you had eyesight, you may or may not guess that right arrow is the key that adds the item to your queue, since your queue is positioned to the right of the results list. Since you're navigating audibly, this spatial relationship is meaningless to you.
Once an item is in your queue, you might think you send that item to the media player using right arrow, since that worked in the previous step and the same spatial logic still applies. Not so though. The Enter key may have failed you in the previous step, but it actually works in this step. If you had read the application Help in the beginning, you would have discovered and memorized the sixteen keystrokes that operate this application, but you didn't do that because the Help link is at the very bottom of the page, and it didn't show up when you pressed Insert+F7 to see a links list. Plus, that's a lot of keystrokes to remember. You use many different web applications each day, and it's unrealistic for you to have to memorize a different set of keystrokes for each one.
Someday you will also know that you can toggle application mode off. When you're in Application Mode in JAWS, Insert + V cycles through Application Mode and Virtual Mode. Currently, Application Mode isn't documented at all within JAWS Help.
What Users Are Saying
It may be too soon to know how users are reacting, or will be reacting, to web applications as defined by ARIA. This is all new enough that it isn't yet in widespread use. I encourage those who are actively working to define the ARIA spec to do usability testing with average AT users. I did find a couple of user comments on-line:
First, there's this post from the JAWS-Users list:
Hi Listers, I'm using Jaws 10 and Vista. Tonight everytime I try to go to Yahoo mail, Jaws says application mode on. I don't have any idea what that means, but I can't navigate the page at all with the PC/virtual cursor. I can read with the Jaws cursor, but when I route PC to Jaws, reading is very strange with Jaws not recognizing links or responding to any commands. I would like to understand what application mode is and how to not have it come on without being asked for.
Similarly, there's this two-part quote from a single thread on the WebAIM list:
I dont know what you've done but it messes up JAWS real bad. I checked the 2 examples and somewhere down the page JAWS goes into a mode I've never heard before, applications mode. When it is in this mode I cant navigate anywhere and have to close the page. I'm using JAWS 10.0...
...I have never heard of applications mode, I found it frustrating and if I run into it I'll just close down the page and leave, how many others will do the same?
Conclusion
Despite my being critical in this blog post, I don't necessarily think role="application" is a bad idea. However, all stakeholders need to carefully consider what to do with it. AT makers need to carefully consider the impact on their users, and implement support in a way that makes web applications easier for their users to use, not harder (take note, Freedom: Telling users this feature only works on the Internet is not good implementation). And web authors need to carefully consider whether using role="application" is truly necessary for their site, and if so, they need to be extremely thorough in developing an interface that works well for AT users whose typical interface no longer works. This obviously will require extraordinary attention to detail, and most importantly, plenty of usability testing that includes AT users.
I haven't seen any great resources yet on how to develop web applications that meet these conditions. Section 3.2.6.2 of the WAI-ARIA Best Practices provides some useful guidance, but we need more and better tutorials or I'm afraid we'll just end up with a bunch of bad apps. If folks know of more and better resources, let me know and I'll add them here.
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
