suggestions on a different implementation for access keys

Hi Becky,
Where as I agree whole heartedly with the direction, I would suggest the
following changes to the implementations 
 
Suggestion 1 -the tag name
The tag name should be more semantic descriptive of what the content is,
just one form of possible usage. 
 
I would suggest something more descriptive the the term "access"- such
as role, or  type. Swap uses the term  ContentType . Then it is more
likely to be used by people who don't care about accessibility, but want
to use it for a different application, such as what Microsoft are doing
for RSS feeds on a page. If people are using it for different
applications and provide state of the art accessibility as a by product
- that is a big win in my book.
 
Suggestion 2 - forget the list of types
 
Yes there are types missed out, but more to the point there always will
be, That is why  this should be done to be programmatically extendible
in a meaningful way. (One of the advantages in being dyslexic is I
anticipate making mistakes :)
 
<jargon summary = "we can do this">
 
The way we are handling this is to  describe the cases or types of
content in RDF, and make programmatically explicit the relationship
between different classes and types of content.
 
In making a description for each type obligatory (using OWL) we allow
for anyone to access - in plain English (or French Spanish, Dutch...)
-what the content type is meant to represent.
 
</jargon>
 
It is just as easy for the content provider to use in the XHTML.
<jargon> They simply reference the type of content  using a  Qname
</jargon>
 
the author would simply write:
 
ContentType="UB:siteMap"
 
which is not so much harder then saying
 
access="sitemap"
 
Content authors do not need to know how the types are encapsulated.
 
However special verticals or communities can have there own, derived
content types. Such as for educational content may have :
tutor, help, glossary, back, up, next
 
If the user agent is only familiar with the base classes, then it can
handle a derived class the same way it would handle it's parent. However
educational tools would have a special features for a derived schema
created by the IMS educational content consortium.
 
Another example would be Web Blogers. I actually am not a blogger and
have no idea of the conventions of this community,  but let us assume
that as net cultures spring up they have there own anticipated web
content types
 
Some hack can derive them, (not to mention any names -Matt) and everyone
can use them.
 
I think I sent Rich a sample schema a week or two ago, so you can have a
look at it.
 
 
Keep well
 
Lisa Seeman

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-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-gl] <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