Re: Access Element is WRONG (was RE: Are we really still talking about Access Keys?)

John and I had some private e-mail after this, and one thing that came 
out of it was the text in the section on access might not be terribly 
clear on what is and is not required.  For the record, there are NO 
REQUIRED ATTRIBUTES on the access element.  You are NOT required to 
specify @key, @targetid, nor @targetrole.  Also, and the examples 
unfortunately do not show this, you can do things with @media and the 
XML Events attributes and elements to dramatically extend the utility of 
the access element.  At its most basic, access is currently just a 
slightly smarter @accesskey.  When used in conjunction with @media and 
XML Events, it becomes much, much smarter.  Of course, it still permits 
the author's nomination of specific keys combinations to specific events 
and elements.  I understand that John's objection to this remains.  I 
just wanted to point out that there is more here than meets the eye 
(right now).

John Foliot - WATS.ca wrote:

>>The
>>basic requirements were:
>>
>>   1. Ensure that our existing user base continues to have a
>>      relatively simple way to map a key press (key combination) to
>>      an element (HTML 4 accesskey mechanism).  Stretch features here
>>      are being able to control what happens when the key is pressed
>>      (focus shifts / element is actuated), and what key modifiers
>>      are used explicitly.  Let's call this a keyboard shortcut.
>>   2. Ensure that the DI and WAI communities can have a reasonable
>>      mechanism to standardize "roles" for areas of a document, and
>>      define what user actions will result in focus being shifted to
>>      elements associated with those roles or in those elements being
>>      actuated.  Let's call this general shortcuts.
>>   3. Ensure that there is a way to define events that are
>>      media-specific, but that can resolve into media-independent
>>      actions.  Let's call this abstract shortcuts.
>>    
>>
>
>It is point 1 that I wish the WG to more vigorously defend.  I understand
>and support the idea that content authors need a simple means to identify
>conceptually important content; why must the content author be the one to
>decide *which* key gets pressed?  Is it not enough to simply state "..this
>bit here is important enough to have a capacity for quick keyboard
>navigation access."?  Provide the hook, but do not specify the 'bait'.
>  
>
Well....  I am not sure how vigorous I can be.  In general, the working 
group attempts to only *remove* features when there is alternate 
facility that provides similar functionality in a more portable, 
scalable, general, or accessible manner.  Sometimes things just get 
removed (e.g., the blink element).  In the case of @accesskey, there was 
no other facility that could provide equivalent functionality, there is 
a segment of the community that uses the feature, and it is not 
perceived to be harmful except in that it was inadequate for solving the 
REAL problem (@role). 

As to the origin of requirement 1, I am afraid it is lost in the mists 
of time.  However, my archives lead me to believe it had to do with 
continuing to support current use.   For content developers who need 
this facility, there is no portable, media and user-agent independent 
alternative.

>No actually I think most of us do care, at least theoretically.  If from a
>technical perspective one way is better than the other, by all means choose
>the better way. That <access> is now an element (a meta element? - I presume
>this, although it does not appear to be explicitly explained) *does* make
>sense to me, if it then can be used to supply attribute information to the
>conceptual marker.  I get that it must be an element so that you can, for
>example, define custom roles via RDF.  
>  
>
What we wanted to do was not have an @key, but rely upon XML Events / 
DOM Events to permit the mapping of specific keys and key modifiers if 
someone really, really needed it.  Unfortunately, DOM Events doesn't 
provide for keys - so that idea was out the window.  A compromise was to 
introduce @key and expect that the underlying facility would be DOM 
Events based once DOM 3 Events gets completed. This also had the benefit 
of making it somewhat easier for content developers to use the facility 
(our initial XML Events approach required an XPath function and was sort 
of ugly). 

As to the access element itself, it is there so that you can associate 
specific event handlers with specific roles (@targetrole) or specific 
elements (@targetid).  The @key is just a shorthand for a specific kind 
of event handler that is not, today, possible to define portably using 
XML Events / DOM Events.  However, none of this really has anything to 
do with defining new roles and RDF.  That is the role attribute.  The 
access element just provides the "connective tissue" between 
(non-standard) roles and events.

>"This discussion is brought to you by the letter "S""
>
>Shane, in one of my other postings
>(http://lists.w3.org/Archives/Public/w3c-wai-ig/2005AprJun/0376), I detailed
>problems that the current capacity produced, using the 'key' of "S".  By
>continuing to allow authors to map a key, this type of problem will continue
>to emerge, rendering the functionality useless, as problems will continue to
>arise - conflict resolution, lack of specific key availability (either due
>to internationalization issues, or user agents that lack keyboards
>altogether), etc., etc..
>  
>
Of course, and we understand that. 

>>The improvement that we have proposed is a way for content
>>authors who
>>care about accessibility to define their access points in a portable
>>manner that the user agent can then map into something
>>appropriate for
>>its current user.  
>>    
>>
>
>Yes, the 'role' attribute.  I support that idea 100%.  *WHY* must it be
>associated to a specific key?  The concept is clear, clearly marked, and
>extensible to boot via RDF.  This should be sufficient.  Leave the rest to
>users and user-agents.
>  
>
It does NOT have to be associated with a specific key.  Let me say that 
again.  IT DOES NOT HAVE TO BE ASSOCIATED WITH A SPECIFIC KEY.  A 
content author may choose to associate a role with any sort of event, or 
with none.  A user agent may choose to expose standard role values in 
standard ways.  It may choose to give users the ability to define 
mappings for standard roles, or indeed for other roles through 
auto-discovery.   That's the utility of @role, and has nothing to do 
with the access element, per se.

>    <!important>
>  
>
>>The solution that we design might be right for some, but would be
>>inconvenient for others, and outright wrong for the rest. 
>>    
>>
>    </!important>
>
>Please re-read what you just wrote.  How then can you assume that the
>content author might get it right?  Why are you giving her the means to mess
>it up in the first place?  The 'key' attribute contradicts what you have
>just observed.
>  
>
Because the content author is the ultimate authority.  They get it right 
*by definition*.  It's their content.  You might not like what they do, 
or what they think is right.  I usually don't. But that doesn't matter. 

>>Each
>>different content developer or developer group has to *decide* to make
>>their content accessible, and has to *decide* what content is
>>interesting.  There is no way any standards body could do that right.
>>    
>>
>
>Yet your current implementation presumes that the author might get it right,
>and assign the right 'key'.  If a standards body with the ability to look at
>something from numerous perspectives/angles cannot get it right 100% of the
>time, how can the lowly content author be expected to do so?  Would not the
>only person guaranteed to get it right for each end user not be "that end
>user"?
>  
>
By your argument, end users should be able to define the keyboard 
shortcuts in every application.  The application I am using right now, 
for example, uses Alt-F to bring up the file menu.  Are you suggesting 
that I should prevail upon the developer to allow that to be Alt-Ctrl-F 
or Ctrl-mouse to the left?  Its the same thing.  Really it is.  Web 
content is an application.  Sometimes simple, sometimes complex.  True, 
it is exposed to its user through yet *another* application, but that 
user agent is not there to get in the way of the portable web 
application.  It is there to facilitate it.

And, again, there is no requirement that any web application map any key 
to anything.  It is an option, not a requirement.  If I am defining new 
role QNames (and the associated RDF definition) as a navigation 
convenience for my users, who is the HTML Working Group to tell me I 
can't specify what key should be bound to that new QName by default?

>>However, there is no requirement that
>>anyone use @key.  Indeed, I think that WAI should mandate that
>>accessible documents NOT use it, instead requiring the use of their
>>defined collection of roles, and creating a recommendation for how
>>various types of user agents connect to elements with those roles on
>>various media.  Unfortunately, that is outside of the scope
>>of XHTML.
>>    
>>
>
>Wait a second... It's not "their" roles that are declared in the draft, it
>is the HTML WG's roles, as this is your document, not the WAI's.  I don't
>disagree with the idea behind what you have said, but based upon the rest of
>your argument, and other statements made, let's be clear.
>  
>
Actually, and I am sorry if this is not clear, those @role values all 
came from the WAI folks, as far as I know.  I will check to be certain, 
but all that text originated with the WAI group and their liaison to the 
HTML Working Group.  I think there are likely other good collections of 
roles out in the wild that we should incorporate, but this was a decent 
first cut.

>>I appreciate that some content authors might define mappings that you
>>won't like. 
>>    
>>
>
>Not "like" Shane, ones which can possibly cause conflicts.
>  
>
I understood your example.  However, I guess I am missing something.  
They can't cause a conflict really.  They can be inconsistent among 
various web applications, just as they are inconsistent among Windows 
applications.  But within a specific domain (web application, web page, 
XHTML document) they are whatever the author and you say they are.  In 
any user agent worth its salt, your settings are going to take 
precedence anyway (user preference trumps document preferences, just as 
in CSS.  I will ensure this is clear in the draft). 

I cut out your example below, but thinking about the 'S' key:  If a web 
application indicates that 'S' should map to save (as in save the 
content of this wiki entry I am composing), that's important.   If the 
user agent had some default mapping for the 'S' key (e.g., the 
File->Send operation for a page) that should get overridden by the web 
application I am using.  If, however, the user specified some setting 
for the 'S' key (launch external mp3 player), then that should take 
precedence.  Just as in CSS.

>OK, but how would this:
> 
>     .... <div class="ToC" role="contentinfo">
>     my table of contents
>     </div>
>(sans <access> declarations)
>
>...be any less useful to intelligent user-agents, especially if that
>particular 'role' is pre-defined.  
>  
>
It wouldn't.  That's a good example of where access is not necessary.  
However, consider this (using old forms, 'cause I don't speak XForms well):

    <access key='S' targetid="saveEntry" ev:event="DOMActivate"
    @media="screen" />
    <access key='&softkey1;' targetid="saveEntry" ev:event="DOMActivate"
    @media="mobile" />

    ....
    <form action="wikiupdate.cgi" id="myform">
    ...
    <input id="saveEntry" type="submit" value="Save" />
    </form>

(Note:  I made up &softkey1; - there is some special key that means the 
first softkey on a mobile device in WAP / WML, but I can't remember it)

In this model, I have readily mapped S on my screen device to saveEntry, 
and on my mobile device softkey 1.

>But here's my concern, or
>at least my understanding of the current draft:
>
>A) If no keypress is defined, refer to default for each common role, as
>determined/defined by the user-agent
>else
>B) Use author defined keypress
>else
>C) Use user-defined keypress
>
>-coupled with-
>"For custom roles, use keypress defined by author.  For conflict resolution,
>responsibility lies with end user"
>  
>
No.  See above.  However, in general don't confuse role handling with 
access @key mappings.  @role values and (default or user specified) key 
mappings for those values should just work if a user agent supports 
them.  I am not certain what the working group's position on this is, 
but my position would be that if there is an @key associated with an 
@role value, that would only be effective if there were no local 
setting.  (I have submitted a formal issue about precedence rules of 
@key in conjunction with @targetrole to the working group).

>By allowing the author to get in the middle, you introduce that "random"
>factor - the author is over-riding default behaviours. 
>
No.  Or rather, I think *no*.  More on this in the near future.

Thanks for your comments.  This is a good dialog, and has brought a few 
new issues to light.

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Tuesday, 7 June 2005 15:53:49 UTC