Accessibility issue - onKeyDown

Dave Henson

Hi

I am checking a site for accessibility and Dreamweaver suggests making sure
that the menu is accessible via keyboard as well as mouse (i.e
device-independent). A question has arisen which is probably more to do with
my lack of understanding of how a user might interact with a web site
without using a mouse.

I have tried using the onKeyDown command but it does not seem to be
key-specific. If this command is added to eight menu links, how does the
system know which link to go to? I have pasted a simple file below showing
the code that Dreamweaver produces.

Thanks,
Dave Henson.

<HTML>
<HEAD>
<TITLE>Untitled Document</TITLE>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<script language="JavaScript" type="text/JavaScript">

</script>
</HEAD>

<BODY>
<P><A href="http://www.aaa.com"
onKeyDown="MM_goToURL('parent','http://www.aaa.com');return
document.MM_returnValue">Link</A>
</P>
<P><A href="http://www.bbb.com"
onKeyDown="MM_goToURL('parent','http://www.bbb.com');return
document.MM_returnValue">Link 2</A>
</P>
</BODY>
</HTML>

--
..

Jul 23 '05 #1

Follow Post Reply

2522

Philipp Lenssen

Dave Henson wrote:

onKeyDown

You'll introduce more accessibility hurdles with these tricks.

--
Google Blogoscoped
http://blog.outer-court.com

Jul 23 '05 #2

Stephen Poley

On Mon, 15 Nov 2004 13:53:03 -0000, "Dave Henson"
<no***********@hotmail.com> wrote:

I am checking a site for accessibility and Dreamweaver suggests making sure
that the menu is accessible via keyboard as well as mouse (i.e
device-independent). A question has arisen which is probably more to do with
my lack of understanding of how a user might interact with a web site
without using a mouse.

I have tried using the onKeyDown command but it does not seem to be
key-specific. If this command is added to eight menu links, how does the
system know which link to go to? I have pasted a simple file below showing
the code that Dreamweaver produces.

You've missed the point. Keyboard accessibility is not about providing
extra facilities; it's mainly about not screwing up those which the
browser provides as standard. Write a simple page using just HTML (no
CSS, script, whatever) and it will be accessible via the keyboard.
Perhaps not very conveniently if you have a huge number of links, but
it's possible.

So:
- write a very simple page with a few links, using a text editor rather
than something like Dreamweaver;
- learn how to navigate it with the keyboard in your favourite browser;
- check that you can navigate your "real" pages in the same way.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

Jul 23 '05 #3

Harlan Messinger

"Dave Henson" <no***********@hotmail.com> wrote in message
news:2v*************@uni-berlin.de...

Hi

I am checking a site for accessibility and Dreamweaver suggests making sure that the menu is accessible via keyboard as well as mouse (i.e
device-independent). A question has arisen which is probably more to do with my lack of understanding of how a user might interact with a web site
without using a mouse.

Ordinary <A> links are already keyboard-accessible. Each browser defines a
key (the tab key in Internet Explorer, for example) for moving the focus
from one link to the next.

Keyboard accessibility becomes a concern when you assume the user has
scripting enabled and you use onclick, onmousedown, etc., to respond to user
interactions, leaving keyboard-only users stranded.

Jul 23 '05 #4

Alan J. Flavell

On Mon, 15 Nov 2004, Stephen Poley wrote:

On Mon, 15 Nov 2004 13:53:03 -0000, "Dave Henson"
<no***********@hotmail.com> wrote:
I am checking a site for accessibility and Dreamweaver suggests
making sure that the menu is accessible via keyboard as well as
mouse
An accessibility checker would likely do the same, since this is
an objective checkpoint in the WAI recommendation.
(i.e device-independent).

Hmmm. That's a bit of a paradox, since a keyboard action is surely no
more nor less "independent" of an actual device than is a mouse
action.

Stephen responded:
You've missed the point.
"You might say that; I couldn't possibly comment"(SCNR)
Keyboard accessibility is not about providing extra facilities; it's
mainly about not screwing up those which the browser provides as
standard.
Accessibility checkers are inclined to tell you to resolve this issue
by adding an "onkeydown" for every "onmousedown", and so on. Even the
W3C does this - Google suggests a look at

http://www.w3.org/WAI/wcag-curric/sam70-0.htm

The wording is quite important here:

For scripts that do more than just change the presentation of an
element, content developers should do the following:

That's saying that if the effect is frivolous enough, then there's
no need of a keyboard equivalent, despite the checkpoint. IMHO/YMMV

Indeed: often the mouse action is just an optional extra way of
achieving some result that can be achieved anyhow; and adding an
unwanted keyboard action can make it subjectively /harder/ to use the
web page.

My "take" on this is that if the mouse action is sufficiently
frivolous, and you're mandated to pass all of the objective
checkpoints, then it's better to simply take it out.

If not, then consider carefully whether the suggested resolution
really does enhance the subjective accessibility, despite this
apparent violation of a WAI objective accessibility checkpoint. (If
you're into formal assessment, then make a note on the accessibility
audit that you considered the issue and took this deliberate
decision.)
Write a simple page using just HTML (no CSS, script, whatever) and
it will be accessible via the keyboard. Perhaps not very
conveniently if you have a huge number of links, but it's possible.

So:
- write a very simple page with a few links, using a text editor rather
than something like Dreamweaver;
- learn how to navigate it with the keyboard in your favourite browser;
- check that you can navigate your "real" pages in the same way.

I *think* you're saying approximately the same as me, just approaching
the topic from a different angle. But feel free to shout me down if
I'm misunderstanding you.

cheers

Jul 23 '05 #5

Nick Kew

In article <Pi******************************@ppepc56.ph.gla.a c.uk>,
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> writes:

>I am checking a site for accessibility and Dreamweaver suggests
>making sure that the menu is accessible via keyboard as well as
>mouse

Oh dear. This is a hoary old chesnut.

An accessibility checker would likely do the same, since this is
an objective checkpoint in the WAI recommendation.
>(i.e device-independent).

Only if you take character strings like "mouse" or "click" as implying
a particular kind of device. Of course, they *suggest* one, but that's
entirely different. Browsers that work without a mouse can and do
support scripting events in an appropriate manner.

Hmmm. That's a bit of a paradox, since a keyboard action is surely no
more nor less "independent" of an actual device than is a mouse
action.
Indeed. As soon as you start duplicating events in the name of device-
independence, you are really introducing device dependence that wasn't
there before. Or, more likely, you're having no effect except to make
life more complicated for yourself.
Keyboard accessibility is not about providing extra facilities; it's
mainly about not screwing up those which the browser provides as
standard.
Sounds like a fair summary. Occasionally it may be more than that
(e.g. skip-navbar kind of things), but in general that's right.
Accessibility checkers are inclined to tell you to resolve this issue
by adding an "onkeydown" for every "onmousedown", and so on. Even the
W3C does this - Google suggests a look at
IMNSHO that's a misreading of WCAG. And to be fair on W3C, that's just
someone's presentation, not part of the guidelines themselves. Not that
W3C always deserve being fair on ...
The wording is quite important here:
Yes, if an event is merely cosmetic, then an accessible alternative
is likely to be superfluous.
Write a simple page using just HTML (no CSS, script, whatever) and
it will be accessible via the keyboard. Perhaps not very
conveniently if you have a huge number of links, but it's possible.

Indeed. But the issue of number of links is important. Don't produce
a site-wide template that puts lots of links on every page: that makes
the whole thing horribly cumbersome to linear browsers.
I *think* you're saying approximately the same as me, just approaching
the topic from a different angle. But feel free to shout me down if
I'm misunderstanding you.

I think we're (all) in broad agreement, except that I prefer to
ignore some of the blatently silly interpretations of the guidelines.

[ any nonsense in the above - blame it on my finishing that rather nice
bottle of hungarian gewürztraminer ]

--
Nick Kew

Jul 23 '05 #6

Accessibility issue - onKeyDown

This discussion thread is closed

Similar topics