- From: <Becky_Gibson@notesdev.ibm.com>
- Date: Wed, 23 Jun 2004 09:57:34 -0400
- To: w3c-wai-gl@w3.org
- Cc: schwer@us.ibm.com, w3c-html-wg@w3.org, w3c-wai-pf@w3.org
- Message-ID: <OF4EDA2CE4.5DE2593F-ON85256EBC.0049886A-85256EBC.004CE02B@notesdev.ibm.com>
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
Received on Wednesday, 23 June 2004 09:58:25 UTC