access keys

 
When PF started discussion on access keys I wrote up the following
proposal based on the SWAP methodology. I think it clearly explains and
extends the point...
 
 
 
Summary
 The Semantic Web it takes it possible to enable typical Web content to
be converted to a more accessible, simplified, clearer or symbolic
representation. This conversion would be a form of knowledge processing,
and can be performed by a proxy server or at the user end. 
The Author would be required to add a layer of meaning to the original
content (using Semantic Web annotations) that map terms to concepts that
in turn can be converted into accessibility fetchers at the user end. 
 
It requires the author to better encapsulating knowledge as a pose to
providing an alternate access method. 
 
 
Background to semantic based accessibility.
Semantic based Web accessibility is about encapsulating and capture of
information about a page, that can then be interpreted to create better
accessibility.
 
 A semantic layer of meaning to the site can be added using Semantic
Web annotations or can be incorporated into the page markup itself.
Either way this semantic information is then interpreted by a server
program or the user agent to create any number of accessible
presentational layers or renderings of the page -- so that users can
view the web site and content though a presentation that works with
their scenario.
 
An example - Access keys
 
Access keys are a traditional accessibility technique that allow an
author to associate a key stroke to replace a mouse over or mouse click
event. It enables people who can not use a mouse to trigger events.
 
 
Usercase
 
 
Current usecase
 
The author can associate an access key in place of an alternate access
method in place of a mouse event.
The author needs to do
*	Chouse which links and controls are important enough to receive
a designated access key
*	Decide on what that access key should be
*	Ensure that there are not conflicts of access keys (as often
happens with content management systems.)
 
What the user gets:
The user can now access a control easily using the author designated
keyboard accesskey
 
Sometimes the access key may already be designated by the assistive
technology or user system
Access keys may not always be intuitive.
 
User example:
The contact us link is designated the access key designated of "s"
The site map link, which was considered less important to the _author_
did not get a designated link
The products page is designated an access key of "C"
 
Proposed usecase
 
The author can associate the role of the link or control
 
The author needs to
*	Associate a resource with a role OR associate a control with a
role
*	If no known role exists, a new definition can be created in a
central repository of content types. 
 
For example a single RDF statement that associated a page with the
definition of a site map
 
What the user gets:
The user can now access a control easily using the user designated
keyboard accesskey that is preferred for links or controls of this role 
 
User examples:
Jon has the following user preferences:
*	All contact us links are designated the access key "c"
*	The site map links are designated the access key of "s"
*	Any main menu items get numeric access keys so he can easily
jump to them -in this case the products page is designated an access
key of "3"
*	Alt M always takes Jon to the start of the main content
 
Anna also has user preference for access keys
For her the site map links are designated the access key of "k"
-which is the first letter of site map in Russian (karta saita) That is
because her first language is not English but Russian
 
Tom scenario is very different.
*	Tom prefers symbols to text when possible. He does not use
access keys
*	All contact us links are represented by the same picture of an
email/letter
*	All site map links are rendered as a picture of a map
*	All main menu items are buttons on the top of the page, and side
menu items that do not have any extra role are simply not shown, unless
he select a "show me more" button
Conclusion
Some accessibility is more popular then others - access keys is more
accepted, then adding role information for learning disabilities. Basic
accessibility for physical disabilities is far more important then user
preferences and making 
 
 However with a different approach to capturing the basic accessibility,
for the same amount of work, more accessibility for more user groups can
be made available 
In the discussion on how to approach accessibility, 
 
-----Original Message-----
From: w3c-wai-pf-request@w3.org [mailto:w3c-wai-pf-request@w3.org] On
Behalf Of Becky_Gibson@notesdev.ibm.com
Sent: Wednesday, June 23, 2004 4:58 PM
To: w3c-wai-gl@w3.org
Cc: schwer@us.ibm.com; w3c-html-wg@w3.org; w3c-wai-pf@w3.org
Subject: [w3c-wai-pf] <none>
I'd like to submit this proposal from Rich Schwerdtfeger and the HTML
working group for review and discussion within WCAG. If needed, I will
work with Michael Cooper to get this added as an agenda item to a
Techniques working group meeting. 
Becky Gibson 
IBM Emerging Internet Technologies 
978 399-6101 
gibsonb@us.ibm.com 
The HTML working groups is creating an alternative to access keys to
address the following issues: 
- Access Key does not address device independence resulting in operating
system and user agent collisions. Additionally, some devices may not
have a keyboard. 
- Access Key requires the author to define the actual keys. 
- Access key does not adequately address usability in that the user is
not familiar with access keys and their purpose. 
- We have a separate technique for defining main content which is a
link. While this is very helpful, a comprehensive mechanism to address
other content 
Our proposal is to create an access key alternative called "access"
which will allow the author to specify a standard access key without
being concerned about the device dependencies. It will be up to the user
agent to assign the device specific mapping and also allows assistive
technologies to override the default behavior should they decide to have
their own device mapping. The benefit to the user is that for every site
the go to they will be able to hit the same key to transfer focus to the
main content, cycle focus through portlets, or cycle focus to the submit
buttons, etc. It will also be up to the user agent to allow the user to
define whether the this will also result in an activate. This puts the
decision in the hands of the user whether who may or may not want to
activate a specific element. 
We would like to ask the WCAG working group what the most common
standard access types should be. These are examples. 
- Main content 
- navigation index 
- sitemap 
- portlet 
- back 
- forward 
- tool bar 
- navigation bar 
- top 
- bottom 
- footer 
- submit button 
- help 
Things to consider: Are there other elements that screen reader vendors
provide keys for to improve keyboard navigation which we could define a
standard for? 
Let me know if you need anything more. 
Regards, 
Rich 
Rich Schwerdtfeger
STSM, Software Group Accessibility Strategist/Master Inventor
Emerging Internet Technologies
Chair, IBM Accessibility Architecture Review Board
schwer@us.ibm.com, Phone: 512-838-4593,T/L: 678-4593