E-mail List Archives

Re: Maximum number of keystrokes (operations) to get to any item on a webpage?

for

From: Ryan Hemphill
Date: Dec 19, 2011 7:00PM


I think one of the things that I have found interesting is how designs for
one type of accessibility don't always carry over every well to the next.

As mentioned, the alt+i gets the inbox refresh to occur, but that assumes
that you know about it - and if you aren't a screen reader user (but still
use a keyboard) this would not be obvious at all. As a result, you would
probably end up shift+tabbing like mad to get back there because there was
no apparent way to accomplish this goal.

What I would like to see more of is a cohesive approach to a11y. 30 access
keys is definitely excessive, to be sure - but creating a design that has a
great deal of overlap between needs is not.

It was mentioned earlier in the conversation that contextual relationships
were as (or more) important than just headings. Very true...and yet while
we have things like 'ARIA Landmarks', these things do not translate to use
outside the screen reader community at all, despite the fact that they are
designed specifically to tie the page together as a collection of
regions...it only works for one user group.

It would be interesting to see designs that were centered on crossing
several needs at once. Has anyone seen a sophisticated example of
something like this?


Ryan.

On Mon, Dec 19, 2011 at 8:39 PM, Ryan E. Benson < <EMAIL REMOVED> >wrote:

> Birkir,
>
> I wouldn't point to Google/Gmail as a good example. From being a part
> of a list for Google, their mindset that I have seen is roughly: What
> they do is way ahead of what web standards, so they cannot follow
> standards. It is sort of sad in my opinion that they have this
> mindset. Of course they code it to look the best in Chrome, and mainly
> work with ChromeVox. Other screen readers have varying results, but
> the experience isn't always the best. There was a conversation a few
> months ago about how instead of making their products accessible, they
> just make these hotkeys, which can be seen as "separate but equal"
> approach. That argument could probably work pre-2003, but not 2011.
>
> --
> Ryan E. Benson
>
>
>
> On Mon, Dec 19, 2011 at 7:55 PM, Birkir R. Gunnarsson
> < <EMAIL REMOVED> > wrote:
> > Hi guys
> >
> > Good observations.
> > Yes, I had to step in and comment on a site that had literally 25 or
> > 30 "AccessKey" shortcuts, that absolutely no one was using (I am also
> > a part of the screen reader training team, and my colleague, who has
> > done this for 10 years, said users did not want this).
> > It took some time to convince the site admins about this, but I have
> > managed to get them to remove all but two AccessKey attributes from
> > the site.
> > As I said, I still believe the AccessKey attribute is useful, if used
> > very sparingly and in situations where a link is used very often, but
> > is not immediately accessible in another way (think the alt-i for
> > Inbox on www.gmail.com .. using Basic HTML).
> > I agree with everyone, I just think the "few keystrokes" philosophy
> > might work as a sort of teaching technique/challenge for web
> > accessibility presentations more than anything.
> > I am mostly thinking of how we can get regular web developers, who
> > perhaps attend a lecture on web accessibility in school or
> > professional education series, actually intreagued or interested
> > enough to really give these problems some thought, and something
> > concrete like this seems to be a good point to create discussions
> > around. At the same time, as you guys point out, we don't want to
> > simplify the problem of accessibility to a check list or a number,
> > because it is, fortunately or unfortunately, more complex than that.
> > -B
> >
> >
> > On 12/19/11, Tim Harshbarger < <EMAIL REMOVED> > wrote:
> >> Another issue with focusing on keystroke counts is that fewer keystrokes
> >> does not also mean increased usability.
> >>
> >> For example, you could design a membership form for an organization so
> that
> >> every field and choice uses an access key. This would mean you had
> designed
> >> the form with the fewest keystrokes possible. However, someone using a
> >> screen reader would have to read through all those fields to find out
> what
> >> the access key is. Even if you provided a list at the top of the page,
> a
> >> screen reader user would still need to read through the list.
> >>
> >> I definitely think fewer keystrokes is better than more, but how much is
> >> "fewer" probably depends on other things. Just off the top of my head,
> I
> >> would think that "fewer" might depend on the user's expectations on how
> the
> >> interactions should work, how often they need to complete that
> interaction,
> >> and the discoverability of the keystrokes they need to use.
> >>
> >> I think it ends up being like most of accessibility and usability--fewer
> >> keystrokes is good, but context matters.
> >>
> >> Thanks!
> >> Tim
> >> Tim Harshbarger
> >> -----Original Message-----
> >> From: <EMAIL REMOVED>
> >> [mailto: <EMAIL REMOVED> ] On Behalf Of Benjamin
> >> Hawkes-Lewis
> >> Sent: Sunday, December 18, 2011 7:41 AM
> >> To: WebAIM Discussion List
> >> Subject: Re: [WebAIM] Maximum number of keystrokes (operations) to get
> to
> >> any item on a webpage?
> >>
> >> On Fri, Dec 16, 2011 at 10:55 PM, Birkir R. Gunnarsson
> >> < <EMAIL REMOVED> > wrote:
> >>> All of this being said, has accessibility ever been framed or
> >>> evaluated in terms of number of keystrokes needed to get to an element
> >>> on a page?
> >>
> >> Yes. The WCAG2 supporting documentation explains that this is an
> >> advantage of headings:
> >>
> >>
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-descriptive.html
> >>
> >> See also:
> >>
> >>
> http://lists.w3.org/Archives/Public/public-comments-wcag20/2011Sep/0032.html
> >>
> >> for a rationale of why WCAG does not go to include a precise metric
> >> around the number of keystrokes.
> >>
> >> Note also that different mechanisms implemented by different user
> >> agents can radically change the number of keystrokes required, even in
> >> the absence of semantic markup. For example, typeahead find and
> >> spatial navigation can radically reduce the time taken to activate a
> >> link.
> >>
> >> --
> >> Benjamin Hawkes-Lewis
> >>