Access key background information

Becky,
Is this something along the lines  you were  thinking? See mail reproduced from archive:
Sailesh
From: "Tom Croucher" <tcroucher@netalleynetworks.com>
To: "'Maurizio Boscarol'" <maurizio@usabile.it>; "'Charles Oppermann'" <charles@coppersoftware.com>; <w3c-wai-gl@w3.org>
Subject: RE: Accesskey: there are "techniques"?
Date: Friday, September 26, 2003 7:41 AM

Taken directly from the,
Guidelines for UK government websites: Framework for senior managers,
document
"Appendix C: UK government accesskeys standard
Webmasters who have used hypertext mark up language (HTML) 4.0 or above
in marking up their sites can introduce the use of the accesskey
attribute. This is designed to assist users who have difficulties using
a mouse or who prefer to use keyboard shortcuts. Some government
websites have already implemented accesskeys. Because there is no
accepted standard, these accesskeys are not consistent across UK
government sites.
We recommend a core of 10 links assigned to numerical values rather than
letters. This will avoid conflict with other software. Webmasters should
also provide a menu of accesskeys on their site and the information they
link to. Webmasters can of course extend this system by attributing
appropriate letters from the remaining 25 alphabetic characters to pages
within their website.
Listed below is the suggested standard:
S skip navigation
1 home page
2 what's new page
3 site map
4 to the search facility on the site
5 frequently asked questions (F A Qs)
6 help page/facility
7 complaints procedure
8 terms and conditions (including privacy statement)
9 feedback page
0 the menu page of accesskeys detailing the accesskeys are being used
within the website and the information or services they link to."
As some of you may know I a developer for the open source Plone content
management system. I have spent a lot of time trying to make it
accessible and part of that was having i18n accesskeys. Although not all
our supported generally languages have had the access done I would like
to talk about the approach we used. We started by using the English
accesskeys (devised by myself and our UI guy) and using them as a
template. These are necessarily complete and I will probably change them
at the end of this discussion after seeing all the good ideas.
t Tabs
l Login
n Navigation menu
s Search
b Breadcrumb items
u Personal Bar
c Folder contents
v View Item
e Edit Item
p Item Properties
w Change Item's State
There are three things that are important to be noted in this
implementation. Firstly the items are contextual, not all pages will
have all of the accesskeys, obviously depending on which widgets are
present. Secondly we used accesskeys in groups, so for example as user
could press "s" repeatedly to choose first the search box and then the
search button. Or "n" repeatedly would go cycle through the navigation
items list sequentially". Finally the accesskeys were also designed to
act as shortcuts to commonly used items such as "edit" for all users,
although this was not a primary concern we did not feel it infringed on
the needs of PwDs.
When translating these accesskeys into other languages we asked the
translators to translate the concepts not the keys. So we prioritised
search as an important concept. In English this meant it would have "s"
no matter what other concepts might start with that letter. We asked
translators to apply these priorities to their translation. So for
example in German login is anmelden and view is anzeigen, so we
prioritised view and gave it "a". This is different to the English, and
we are proud of handling different languages and cultures properly.
If anyone has any thoughts on this system I would love to hear them, we
are always striving to make Plone better, that's what open source is all
about.

Tom
Co-founder Netalley Networks
(http://www.netalleynetworks.com),
BSc(Hons) Computing Student / Information Services Staff University of
Sunderland
(http://www.sunderland.ac.uk),
Accessibility Co-ordinator Plone CMS
(http://www.plone.org)
Sometimes, however, I do use letters for accesskeys, especially in complex
forms. I then assign the first letter of each label as an accesskey (and
make it so that each label has a different first letter). Using CSS, I give
the first letter of the labels a different appearance. These accesskeys are
once again explained in the help section of the website.
You could even make it so that a list of accesskeys is inserted into the
page from CSS if the page is accessed by a non-visual browser. This is a
CSS2-only feature which is not widely supported yet by assistive
technologies. (In fact I don't know any that support this but am not too
familiar with all the AT's out there).
Yvette Hoitink
Surely this is user agents issue rather than an accesskey issue. Opera
uses an accesskey mode which turns off its default shortcuts while in
that mode. Since you can toggle the mode on and off you know exactly
what you are getting. It seems to me that developers shouldn't feel
hamstrung by any implementation (however large the IE market slice is)
of accesskeys in UAs, there are 36 keys to use and we should use them.
On complex sites having an intuitive letter for the accesskeys can make
a big difference.
My two pence.
Tom
Also see
http://www.cs.tut.fi/~jkorpela/forms/accesskey.html#assign
To second what Tom is saying - in my view the problem with access keys
conflicting with browser accelerator keys is a user agent problem. The
problem is that the same modifer key is used to activate keys that are in
separate "namespaces", the browser namespace and the document namespace. The
solution is to use a different accelerator key for the access keys defined
in HTML, then the entire set of keys is available. I believe Opera does
handle access keys in this way and we're just waiting for other browsers to
catch up. The issue of discoverability remains but is a separate issue.
While we need to log user agent issues with our techniques, I think we
should avoid coming up with recommendations that will hopefully become
invalid at some time in the near future. Michael Cooper
There are also browseers that interfere with numbers, and numbers are not
very memorable. If a page is in italian, I would expect "Aiuto" and not
"Help", so accesskey="A" makes more sense.
For things that are standard across sites (home, next, first, help, etc -
full list at
http://www.w3.org/TR/html4/types.html#type-links
which I
recommend as reading) there is the rel attribute. This is a better technique
since in a given browser it provides the same activation method for all
sites.
Charles


		
---------------------------------
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.