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">
<!--
function MM_goToURL() { //v3.0
var i, args=MM_goToURL.arguments; document.MM_returnValue = false;
for (i=0; i<(args.length-1); i+=2)
eval(args[i]+".location='"+args[i+1]+"'");
}
//-->
</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>
--
.. 5 2654
Dave Henson wrote: onKeyDown
You'll introduce more accessibility hurdles with these tricks.
--
Google Blogoscoped http://blog.outer-court.com
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/
"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.
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: lolo |
last post by:
Hi,
I know how validate a page for CSS or HTML, but I didn't found how validate
my page for accessibility
Thanx for your help
|
by: Veli-Pekka Tätilä |
last post by:
Hi,
My first post here. I've found some serious accessibility flaws in the
Python 2.4 docs and wish they could be rectified over time. I'm very new to
Python and initially contacted docs at python...
|
by: waltborders |
last post by:
Hi,
Because the blind are unable to use a mouse, keyboard navigation is
key. A major difficulty is that not all windows forms controls are
keyboard 'tab-able' or 'arrow-able' or have "tab...
|
by: Edward Diener |
last post by:
According to the CLS specification, the accessibility of the methods for
adding, removing, and raising an event must be identical. There appear to be
a few problems with this:
1) According to...
|
by: Girish |
last post by:
I have TWO submit buttons of type IMAGE on my asp form. This renders as
<input type="image">.
I need to be able to eble the ENTER button for both buttons. Yes, I know
that for the input type...
|
by: Brian Cryer |
last post by:
I posted this question recently to microsoft.public.dotnet.languages.vb but
didn't get any answer. I'm hoping that someone here will be able to help me.
I'm working on a project using VB.NET...
|
by: JV |
last post by:
This is for anyone who has tackled the accessibility issue on their web site
(and if you haven't, I bet you will in future).
Apparently the asp:button control always renders as '<input...
|
by: cms-hispano.org |
last post by:
i'm building a site about extreme accessibility, i.e.: how (and why)
to get sites to become fully accessible, *beyond* W3C Web
Accessibility Initiative guidelines. it's far from being completed (i...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: Aliciasmith |
last post by:
In an age dominated by smartphones, having a mobile app for your business is no longer an option; it's a necessity. Whether you're a startup or an established enterprise, finding the right mobile app...
|
by: tracyyun |
last post by:
Hello everyone,
I have a question and would like some advice on network connectivity. I have one computer connected to my router via WiFi, but I have two other computers that I want to be able to...
|
by: NeoPa |
last post by:
Hello everyone.
I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report).
I know it can be done by selecting :...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
|
by: Teri B |
last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course.
0ne-to-many. One course many roles.
Then I created a report based on the Course form and...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 1 Nov 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM)
Please note that the UK and Europe revert to winter time on...
|
by: nia12 |
last post by:
Hi there,
I am very new to Access so apologies if any of this is obvious/not clear.
I am creating a data collection tool for health care employees to complete. It consists of a number of...
|
by: isladogs |
last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, Mike...
| |