WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: Help with adding ACCESSKEY statements?


From: Keith Patton
Date: Feb 20, 2004 9:43AM

Thanks John,

Much appreciated, our intentions are in the right place including them in
our site and if/when we do remove them, we'll be sure and post up these
links and the insights i've received from this list even in the short period
i've been a member.

Keith Patton
Technical Director
Ethical Media

-----Original Message-----
From: John Foliot - WATS.ca [mailto: <EMAIL REMOVED> ]
Sent: 20 February 2004 16:30
Subject: RE: Help with adding ACCESSKEY statements?

Hey all,

For regular readers of this list, sorry to sound like a broken record...

For others (and BTW, welcome to new readers), we at WATS.ca have done our
own research and testing regarding accesskeys and now advise people not to
use them. We were instrumental in convincing the Canadian Government to
reverse their use of Accesskeys due to potential conflicts. Rather than
re-parrot all of the facts here, interested parties are invited to read our
articles on our site:

Using Accesskeys - Is it worth it? - http://wats.ca/articles/accesskeys/19
More reasons why we don't use accesskeys -
Accesskeys and Reserved Keystroke Combinations -
Link Relationships as an Alternative to Accesskeys -

The bottom line for us is that due to a) non-standardization, b) real
possibilities of user agent conflicts, and c) effort vs. gain considerations
that Accesskeys be abandoned. However, in every forum in which we
participate, and in our own resources/articles that we post, we are also
very careful to state clearly that:

1. We like the idea behind accesskeys,
2. We find the implementation very problematic
3. We believe that we collectively need to examine the issue and determine
if we need to develop other solutions that better suit the needs of

Dave Shea at mezzoblue (and the driving force behind the Zen CSS Garden)
also makes some good points in favor of *NOT* using Accesskeys in his blog
entry - "I Do Not Use Accesskeys":
http://www.mezzoblue.com/archives/2003/12/29/i_do_not_use/ (Note - there are
also some interesting comments made as "Replies").

Finally, Keith, Accesskeys can create accessibility issues with more than
just screen reading technology, although that is where the greatest "Harm"
can take place, but as Dave Shea points out, even non-handicapped users were
having issues with his site and the Accesskey implementation.

Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca 1.866.932.4878 (North America)

> -----Original Message-----
> From: Keith Patton [mailto: <EMAIL REMOVED> ]
> Sent: Friday, February 20, 2004 6:53 AM
> Subject: RE: Help with adding ACCESSKEY statements?
> Hi,
> I would take issue a little with advice never to use access keys
> (although i
> admit conflicts are possible), as long as a standard is developed and
> followed, this should minimise conflict with screen reader access. The UK
> government for example has established such reserved keys for
> it's sites via
> http://www.e-envoy.gov.uk/Resources/WebHandbookIndex1Article/fs/en
> D=4000092&chk=XHiT3L which we are aiming to follow.
> Also, make sure the link to information on accessing your site
> (which would
> include information on tab indexes and any access keys in use) is made
> prominent on the site near the top, and also provide tab indexing on the
> links using the tabindex attribute to allow keyboard users to
> easily get to
> the link if it is not near the top of the page in terms of number of tabs.
> Keith
> www.ethicalmedia.com
> -----Original Message-----
> From: Jukka K. Korpela [mailto: <EMAIL REMOVED> ]
> Sent: 20 February 2004 11:13
> Subject: Re: Help with adding ACCESSKEY statements?
> On Fri, 20 Feb 2004, Jean-Michel Brevelle wrote:
> > I'm trying to add accesskey definitions to navigational links
> on a new web
> > site. It's my first attempt and I'm not doing so well with it.
> Just don't do it. It's extra burden to you, it complicates the markup
> somewhat, and it does not improve accessibility - rather the opposite.
> In special cases authors might use the accesskey attribute, but they
> should really know what they are doing, and probably do it in closed
> circles (such as intranets where users can be educated) only.
> Most importantly, accesskey attributes mess up _built-in_ accessibility
> features in user agents. For some details, check
> http://www.cs.tut.fi/~jkorpela/forms/accesskey.html
> > I think the problem is a conflict between the accesskey
> statement and the
> > class definition
> No, accesskey attributes and class attributes are not coupled in any way.
> > -- the links are coded in javascript to highlight on
> > mouseover --
> It's useful to people using graphic browsers to highlight a link on
> mouseover, but it's unnecessary to use JavaScript for it. CSS works fine.
> Any use JavaScript makes some people suspicious, and that's good -
> Paranoia is good, as the User's Security Handbook says.
> > Here is a sample statement:<a href="Default.htm" title="Return to this
> web's
> > Home Page" class="inactive" highlight>Home</a>
> I don't see any accesskey attribute there, or any attribute that would
> call JavaScript on mouseover. (Whether the title attribute is useful is
> another thing. What's the point? If you are telling such things, telling
> what "this web" is would probably be more useful.)
> What does the highlight attribute mean? It's surely nonstandard, but which
> browsers recognize it, and what do they do with it>
> > Can anyone help me out with this? If you want to review the rest of the
> > script, just ask and I'll send it.
> What script? I think you should just post the URL if you need help with a
> particular page. But I don't think you should create more problems by
> using accesskey.
> --
> Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
> ----
> To subscribe, unsubscribe, suspend, or view list archives,
> visit http://www.webaim.org/discussion/
> ----
> To subscribe, unsubscribe, suspend, or view list archives,
> visit http://www.webaim.org/discussion/

To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/

To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/