E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 6 (In chronological order)

From: Birkir R. Gunnarsson
Date: Fri, Dec 16 2011 3:54PM
Subject: Maximum number of keystrokes (operations) to get to any item on a webpage?
No previous message | Next message →

Hello gang

In my recent salvo of accessibility work, I have concentrated on
trying to make website developers use things like headings, landmarks
and other html structures (even AccessKeys in very specific
instances), to aide navigation for users of Assistive Technology (I
have been somewhat screen reader focussed, but I try to include advice
on other user groups to the best of my ability).
This has made me wonder if anyone has ever formulated accessibility in
terms of maximum number of operation a user should have to go through
to find an element on a page (link, text, graphic etc)?
Using html structures is so vital. On www.brandonsanderson.com, as a
totally random example, you need to use the arrow keys around 70 times
to get to the main content of any blog entry page, but it is aheading
level 1, so you can get there with one keystroke.
Similarly www.nhl.com/scores utilizes tables so you can look at scores
in every game simply by using the "t" key in most screen readers to
jump to game summary tables.
www.nhl.com/news has each news story title aheading level 2, and so on
(yes, I am married to a woman who spent 8 yers in canada *grin*).
I have advised the use of an AccessKey on two occasions where
frequently used links such as "log in" are nestled in a long list of
links far down the page, where it would take around 15 to 20 key
strokes to get there, even utilizing html structures on the page, at
least as a short term solution when people are not ready to do a major
page overhaul or review).
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?
I generally find that one should need much over 10, maximum of 15, key
strokes to find any element on a page, if it is suitably organized
with headings, lists, tables etc (exceptions are, of course, very long
tables or other data structures, but it begs the question whether
those should not be split up).

Just curious if anyone has any thoughts on this approach.
It sounds like it might, at least, make an interesting teaching tool
for website accessibility classes, to have people design websites or
projects in such a way that users can access any part of it with x or
fewer key strokes.

-B

From: Benjamin Hawkes-Lewis
Date: Sun, Dec 18 2011 6:39AM
Subject: Re: Maximum number of keystrokes (operations) to get to any item on a webpage?
← Previous message | Next message →

On Fri, Dec 16, 2011 at 10:55 PM, Birkir R. Gunnarsson
< = EMAIL ADDRESS 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

From: Tim Harshbarger
Date: Mon, Dec 19 2011 6:45AM
Subject: Re: Maximum number of keystrokes (operations) to get to any item on a webpage?
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Mon, Dec 19 2011 5:57PM
Subject: Re: Maximum number of keystrokes (operations) to get to any item on a webpage?
← Previous message | Next message →

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 ADDRESS 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
>

From: Ryan E. Benson
Date: Mon, Dec 19 2011 6:39PM
Subject: Re: Maximum number of keystrokes (operations) to get to any item on a webpage?
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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
>>

From: Ryan Hemphill
Date: Mon, Dec 19 2011 7:00PM
Subject: Re: Maximum number of keystrokes (operations) to get to any item on a webpage?
← Previous message | No next message

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 ADDRESS 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 ADDRESS 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 ADDRESS 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
> >>