Accessibility issue - onKeyDown

**Philipp Lenssen** · Jul 23 '05, 10:42 PM

Re: Accessibility issue - onKeyDown

Dave Henson wrote:
[color=blue]
> onKeyDown[/color]

You'll introduce more accessibility hurdles with these tricks.

--
Google Blogoscoped

http://blog.outer-court.com

**Stephen Poley** · Jul 23 '05, 10:42 PM

Re: Accessibility issue - onKeyDown

On Mon, 15 Nov 2004 13:53:03 -0000, "Dave Henson"
<novamedia1999@ hotmail.com> wrote:
[color=blue]
>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.[/color]

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

Web Matters - Main Page

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

**Harlan Messinger** · Jul 23 '05, 10:42 PM

Re: Accessibility issue - onKeyDown

"Dave Henson" <novamedia1999@ hotmail.com> wrote in message
news:2vrqloF2o3 karU1@uni-berlin.de...[color=blue]
> Hi
>
> I am checking a site for accessibility and Dreamweaver suggests making[/color]
sure[color=blue]
> 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[/color]
with[color=blue]
> my lack of understanding of how a user might interact with a web site
> without using a mouse.[/color]

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.

**Alan J. Flavell** · Jul 23 '05, 10:42 PM

Re: Accessibility issue - onKeyDown

On Mon, 15 Nov 2004, Stephen Poley wrote:
[color=blue]
> On Mon, 15 Nov 2004 13:53:03 -0000, "Dave Henson"
> <novamedia1999@ hotmail.com> wrote:
>[color=green]
> >I am checking a site for accessibility and Dreamweaver suggests
> >making sure that the menu is accessible via keyboard as well as
> >mouse[/color][/color]

An accessibility checker would likely do the same, since this is
an objective checkpoint in the WAI recommendation.
[color=blue][color=green]
> >(i.e device-independent).[/color][/color]

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

Stephen responded:
[color=blue]
> You've missed the point.[/color]

"You might say that; I couldn't possibly comment"(SCNR)
[color=blue]
> Keyboard accessibility is not about providing extra facilities; it's
> mainly about not screwing up those which the browser provides as
> standard.[/color]

Accessibility checkers are inclined to tell you to resolve this issue
by adding an "onkeydown" for every "onmousedow n", and so on. Even the
W3C does this - Google suggests a look at

Examples: WAI Web Content Accessibility Curriculum - slide "9.3 - For scripts, specify logical event handlers rather than device-dependent event handlers."

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.)
[color=blue]
> 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.[/color]

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 misunderstandin g you.

cheers

**Nick Kew** · Jul 23 '05, 10:42 PM

Re: Accessibility issue - onKeyDown

In article <Pine.LNX.4.61. 0411151614090.1 691@ppepc56.ph. gla.ac.uk>,
"Alan J. Flavell" <flavell@ph.gla .ac.uk> writes:
[color=blue][color=green][color=darkred]
>> >I am checking a site for accessibility and Dreamweaver suggests
>> >making sure that the menu is accessible via keyboard as well as
>> >mouse[/color][/color][/color]

Oh dear. This is a hoary old chesnut.
[color=blue]
> An accessibility checker would likely do the same, since this is
> an objective checkpoint in the WAI recommendation.
>[color=green][color=darkred]
>> >(i.e device-independent).[/color][/color][/color]

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.
[color=blue]
> Hmmm. That's a bit of a paradox, since a keyboard action is surely no
> more nor less "independen t" of an actual device than is a mouse
> action.[/color]

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.
[color=blue][color=green]
>> Keyboard accessibility is not about providing extra facilities; it's
>> mainly about not screwing up those which the browser provides as
>> standard.[/color][/color]

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.
[color=blue]
> Accessibility checkers are inclined to tell you to resolve this issue
> by adding an "onkeydown" for every "onmousedow n", and so on. Even the
> W3C does this - Google suggests a look at[/color]

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 ...
[color=blue]
> The wording is quite important here:[/color]

Yes, if an event is merely cosmetic, then an accessible alternative
is likely to be superfluous.
[color=blue][color=green]
>> 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.[/color][/color]

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.
[color=blue]
> 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 misunderstandin g you.[/color]

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

Accessibility issue - onKeyDown

Accessibility issue - onKeyDown

Comment

Comment

Comment

Comment

Comment