Re: [note: two-level nav in WAI-ARIA] [was: Re: reCAPTCHA implementation problems]

Hi Ben,

Gez has made some really good points in his last post about the
importance of keyboard accessibility. It really is not an edge case and
shouldn't be considered as such ( I am not saying that you feel this is
the case but I just wish to reiterate it - as its important to be clear).

>> I think that (at least for people without disabilities) providing a tab
>> order that reflects the most common navigation path can be beneficial.

Yes, but thinking about giving the same logical tab order for all users
is equally beneficial - and I don't see why this cannot be the case.
There is no need to think 'I have got this right for *normal* users (and
BTW if you ever meet any please let me know) and now I must cater for
the *others* or people with disabilities. I am not being facetious here
- it is a fact that good design and development practice can facilitate
ease of use for many diverse needs.

>> Take Gmail. To composte an email,one can press "c" which brings up the
>> following window:

That may be but if a screen reader user tries to do this when using
JAWS, pressing c will trigger an action in their screen reader which
jumps to the first combo box on the page. So be aware that there are key
bindings and combinations that have a pecking order (AT first, browser
second) and it is very easy to interfere with the user experience by
getting this wrong.

Josh


Ben Maurer wrote:
> 
> Hey,
> 
> On Wed, 18 Jul 2007, Gez Lemon wrote:
>>> However, when a11y changes also change behavior for other users,
>>> we obviously need to evaluate that much more carefully. If the change
>>> doesn't work as well for the majority of our users, we'll look for
>>> ways to
>>> fix the issue.
>>
>> All users (people with and without disabilities) should be able to
>> navigate to primary content using the keyboard alone, The expected
>> behaviour to navigate to primary interface elements is using the tab
>> key.
> 
> I think that (at least for people without disabilities) providing a tab
> order that reflects the most common navigation path can be beneficial.
> Take Gmail. To composte an email,one can press "c" which brings up the
> following window:
> 
> To: ______________
> 
> Add Cc | Add Bcc | Choose from contacts
> Subject: ______________
> 
> Attach a file    Add event info
> 
> (big text area)
> 
> The "to" textbox is focused, one tab  goes to subject, next to the
> content box.
> 
> Another example:
> 
> https://signin.ebay.com/ws/eBayISAPI.dll?SignIn&_trksid=m37
> 
> Username: ____________
> Forgot your username?
> 
> Password: ___________
> Forgot your password?
> 
> The tab order is username then password.
> 
> While functionalities such as "add cc" or "forgot your username" are
> unarguably important, they also cleary distract from the workflow that
> goes on 99% of the time (even with CAPTCHA, we're frequently not the
> last element in a form, stuff like accepting ToS comes after us -- so
> enter doesn't work).
> 
> Is there no way to say "this link isn't part of the normal work flow,
> don't put it in the tab flow. However still let people get to it without
> the mouse"? It seems like having tabs be the only way to make an element
> accessible to the keyboard is an issue for some sites.
> 
> If there is absolutely no way to do this, we'll try doing a user study
> in the form of logging how users interact with reCAPTCHA on the client
> side (eg, request an image when they tab out of reCAPTCHA). This will
> help us gauge what will work best for our users.
> 
> -b
> 
>

Received on Wednesday, 18 July 2007 09:25:12 UTC