1. Introduction: explain paradigm of keyboard navigation in introduction to address usability of Web 2.0 applications

I have made a start on this issue:

Some verbiage on Keyboard navigation paradigm. I am a little unsure of the correct /voice/ to use and have added a couple of questions at the end regarding how to complete the introduction. Should I indicate various resources, describe them in detail in the piece itself etc. Comments welcome.

1.	Introduction: explain paradigm of keyboard navigation in introduction to address usability of Web 2.0 applications

One of the most common methods of user interaction with the computer and web content is the mouse. In common parlance we are used to hearing if you wish to access this content its just a matter of going to this page and clicking on this icon so the language has entered common parlance and our everyday vernacular and is associated with ease of use.

However, this is only the case if you are a mouse user. If you cannot use a mouse and there are many who cannot (more of which I will talk about later) then this model of ease does not translate to your situation. Also as more people use mobile devices, various pointers etc the whole notion of what a click is needs to be revisited.

So who cannot use a mouse?

Many users who are blind for example cannot use a mouse at all. Simply because the use of a mouse requires that the user can firstly see the screen, successfully identify the various items on display and interact with them.

Other user groups who either cannot use a mouse or find using a mouse problematic are people with limited physical mobility, or tremors and other involuntary movements that make sensitive movement and control very difficult. There are many others but suffice to say that there is a need for a more accessible mode of interaction that will allow people who have problems with mouse, for whatever reason, interact successfully with web applications.

Happily, there is alternate hardware that is usually not a million miles from any mouse and that is the regular keyboard. The common or garden keyboard comes to the foreground as a very accessible navigation device that can be used by blind and vision impaired people, many people with disabilities and so on. There are also very many augmented and specialized keyboards that can be used by others who find the regular keyboard difficult for whatever reason.

Suffice to say many users will need to be able to interact with web content solely via the keyboard or augmented Assistive Technology. Therefore keyboard accessibility is vital for many users when they wish to use the ever more sophisticated web applications that are emerging today.

So how does it work?

There are several key aspects to accessible web applications but they are all governed by a simple premise  that every thing that one user can do with a mouse must also be do-able via the keyboard alone. This is relatively easy to hammer home  just get rid of your mouse when you are trying to use a website or application and if you can access the core parts of the application via the keyboard alone then you are closer to having an application that can be considered accessible and usable by wide range of users including people with disabilities and older people.

What to do?

<add piece on specific ARIA technologies>
<what currently works>
<comments/ideas>?

Good basic information Josh. But after talking to Michael Cooper about the history of this action item, what's needed for the UAIG is information on the ARIA keyboard navigation paradigm; i.e. that it's no longer limited to tab, tab, tab but is more desktop GUI-like. I'll take this one and come up with some text similar to what is in the other docs in the ARIA suite. 

We also created an action against the ARIA Primer to pick up Josh's proposed text.
http://www.w3.org/WAI/PF/Group/track/actions/458

Thanks for the heads up Andi. I will write up how ARIA is supported by AT (JAWS and WinEyes for example), and add that to bugzilla next week.

Added to section 2 in June 8, 2009, editor's draft.