WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: RE: Part 2 - Access Keys - your collective help is urgently reque sted!

for

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

From: Jukka Korpela
Date: Thu, Oct 03 2002 12:52AM
Subject: RE: Part 2 - Access Keys - your collective help is urgently reque sted!
No previous message | Next message →

John Foliot wrote:

> My research shows that currently about the only safe
> combinations still
> "un-reserved" by an adaptive technology or other software are:
> "Alt+/" (accesskey="/"),
> "Alt+" (accesskey=""),
> and "Alt+]" (accesskey="]")

I have some bad news.

No, I don't know any Web browsing related software that has those accesskeys
assigned in its own interface. Though I wouldn't be surprised if someone
found one.

But in any case, two of those accesskeys don't work for me at all, and I'm
pretty sure many people share this problem. On my (standard Finnish)
keyboard, and probably on _most_ keyboard layouts in the world except some
English layouts, the characters "/", "", and "]" do not appear as primary
keys but require extra operations to get produced. For me, "/" is Shift 7,
and Alt Shift 7 actually works (on browsers supporting accesskeys). But ""
and "]" are Alt Gr + and Alt Gr 9 respectively, and I can't make them to
work together with Alt. If I try Alt Alt Gr +, I get just the character
inserted if I'm in a text input field, otherwise nothing happens.

There are lots of different keyboards, and with different settings of
course, in use. This is useful to remember when designing normal user input
too - you should avoid requiring the user to include special characters into
their input. There are some illustrations of the variation of keyboards at
http://www.hermessoft.com/newproject/lang.html
In fact, despite all the technological progress made, the set of characters
that we can expect people to be able to use simply is rather limited. It's
basically the so-called invariant subset of Ascii. The characters "" and
"]" do not belong to that subset, partly because they are - according to the
ISO 639 standard - in positions reserved for eventual "national use".

> The intent is to pair them with "skip nav" functions, which,
> while not a Standard per se, is currently mandated in Section
> 508 and is generally a good recommendation (skip navs) even when 508
> compliancy is not required.

"Skip navigation" is really needed, if there is a largish block of
navigational links at the start of each page. And even WCAG 1.0 says this,
in Checkpoint 13.6, though it's just priority 3, strangely enough.

But whether it needs an accesskey is a different matter. If there is a link
at the start of the page, an accesskey wouldn't improve accessibility that
much even if it were assigned, supported by the browser, and known to the
user.

And I would recommend using nouns, not verbs, in link texts. Instead of
giving instructions, like "Skip navigation", name the thing that the link
points to. It could be preceded by an explanation, like
"Page content: Design of Gruntmaster 6000"
This means that you shouldn't use the _same_ text there on all pages, of
course. Instead it would need to vary with actual page content. But
accessibility can't always be easy. :-) Besides, it would normally be a
reasonable solution to generate it from some data that appears on the page
anyway, like the content of the title element, or the content of the main
heading.

--
Jukka Korpela, senior adviser
TIEKE Finnish Information Society Development Centre
http://www.tieke.fi/
Diffuse Business Guide to Web Accessibility and Design for All:
http://www.diffuse.org/accessibility.html


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


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

From: Glenda Watson Hyatt
Date: Thu, Oct 03 2002 8:40PM
Subject: RE: Part 2 - Access Keys - your collective help is urgently requested!
← Previous message | Next message →

What happens when StickyKeys are used?? I Couldn't access the File and Edit
menus, perhaps I did something wrong??

Cheers,
Glenda

*********
Glenda Watson Hyatt
Soaring Eagle Communications
"Creating freedom and power through accessible communications"
E Mail: mailto: = EMAIL ADDRESS REMOVED =
Website: http://www.eaglecom.bc.ca
Want to know how to make your website accessible to more people?
Subscribe to our FREE newsletter by emailing
mailto: = EMAIL ADDRESS REMOVED =

*********
>
> Test page at: http://www.furtherahead.com/accesskey.php, which contains
> three links (Foo, Bar, and Edit, with F, B and E as accesskeys
> respectively.
>
> When an accesskey is defined and appears to conflict:
> If I hold down ALT and then press F, I get the access key behaviour.
> If I press ALT, release it, and then press F, I invoke the File menu.
>
> When an access key is NOT defined, both key combinations (press and hold
> ALT then F, and press and release ALT then F invoke the File menu)
>
> In essence, if I know the difference in the keystrokes, it doesn't
> matter if there is conflict with intrinsic functionality (although the
> presence of the accesskey might actually confuse a user that is
> expecting the menu to be invoked)
>
> I'm curious to know others experiences with this on other platforms and
> with other browsers, especially AT.
>
> Best regards,
> Derek.
> --
> Derek Featherstone = EMAIL ADDRESS REMOVED =
> Further Ahead Inc.
>
>
> ----
> To subscribe, unsubscribe, or view list archives,
> visit http://www.webaim.org/discussion/
>


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


From: Tim Harshbarger
Date: Fri, Oct 04 2002 5:35AM
Subject: RE: Part 2 - Access Keys - your collective help is urgently reque sted!
← Previous message | No next message


I think what you are observing are different keyboard shortcuts, not the
same one.

Pressing the ALT key (in the situations you mention) sets the system focus
to the menu bar. In fact, pressing F10 will do the same action. Then if
you press the access key associated with the menu bar item, that menu will
appear.

Its just a different way to accomplish the same thing as pressing ALT + F.

Tim
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, October 03, 2002 10:23 PM
To: = EMAIL ADDRESS REMOVED =
Subject: RE: Part 2 - Access Keys - your collective help is urgently
requested!


> John Foliot wrote:
>
> > My research shows that currently about the only safe
> > combinations still
> > "un-reserved" by an adaptive technology or other software are:
> > "Alt+/" (accesskey="/"),
> > "Alt+" (accesskey=""),
> > and "Alt+]" (accesskey="]")

Not sure how much of a monkey wrench this throws into things, but I'm
curious to know how other pieces of software react -- especially
adaptive technology that recognizes accesskeys.

I've only just retested this behaviour I've noticed before. In IE 5+ PC,
Netscape 6+ PC, and Moz PC I can use access keys that are already
assigned to intrinsic commands for the menus -- they just need to be
invoked differently. Sorry, but my Mac and Linux box are both out of
commission right now, so I'd like to hear from other testers.

Test page at: http://www.furtherahead.com/accesskey.php, which contains
three links (Foo, Bar, and Edit, with F, B and E as accesskeys
respectively.

When an accesskey is defined and appears to conflict:
If I hold down ALT and then press F, I get the access key behaviour.
If I press ALT, release it, and then press F, I invoke the File menu.

When an access key is NOT defined, both key combinations (press and hold
ALT then F, and press and release ALT then F invoke the File menu)

In essence, if I know the difference in the keystrokes, it doesn't
matter if there is conflict with intrinsic functionality (although the
presence of the accesskey might actually confuse a user that is
expecting the menu to be invoked)

I'm curious to know others experiences with this on other platforms and
with other browsers, especially AT.

Best regards,
Derek.
--
Derek Featherstone = EMAIL ADDRESS REMOVED =
Further Ahead Inc.