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