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

John Foliot - WATS.ca wrote:

>Richard Schwerdtfeger wrote:
>  
>
>>The key bindings provided were from a request by others for
>>backward compatability shortcuts. 
>>    
>>
>
>Could you kindly point us to the W3C archived entry of this request (single
>posting, or better yet, the thread where this was discussed, debated and
>resolved)?
>  
>
Unfortunately, this particular debate took place in the HTML Working 
Group private archives, and mostly was resolved in face to face meetings 
and many teleconferences.  The thread is not terribly clear.  However, 
since I summarized the initial requirements in an e-mail I feel I can 
reproduce that text here without violating confidentiality rules.  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.

The strategy for addressing these requirements changed a few times 
between October 2004 and March 2005, so depending upon which internal 
draft you look at, you can see different approaches.  In the end, the 
working group settled on something that is likely less flexible than we 
would have liked.  Primarily this is because XML Events / DOM Events are 
not quite sufficient to support the simple mapping of modifier keys.... 
but you don't care about that. 

Your issue seems to be centered around requirement 2 above.  You also 
have indicated that you would prefer to see requirement 1 removed.  
Requirement 3 has not shown up in this discussion thread, but I assume 
that you would be okay with different media-related author-initiated 
mappings that were consistent with requirement 2. 

There is a large community of content developers out there that uses 
facilities in HTML to help make their applications keyboard shortcut 
friendly.  The HTML Working Group should not disenfranchise those people 
lightly.  Is the facility abused?  Sure it is.  Is it misunderstood by 
the vast majority of content developers?  Of course.  However, that 
doesn't mean you remove it.  What you do is improve it. (ooh - nice 
sound byte there). 

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.  However, we cannot mandate certain semantic roles be 
used for certain content (semantic conformance - that old chestnut), or 
even the ways in which those roles are mapped.   The W3C and the HTML 
Working Group would almost certainly get it wrong.  And we know that.  
The solution that we design might be right for some, but would be 
inconvenient for others, and outright wrong for the rest.  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.

And yes, we are aware that some government bodies have mistakenly 
attempted to mandate certain mappings, and that if we were to dispose of 
the key attribute they would have more trouble doing that.  That's sort 
of a separate debate.  No matter what the HTML Working Group does in 
this space, regulatory bodies are going to continue to do stupid things.

>I too am an "other", and as we are still dealing with a Draft document, I am
>requesting that it be re-addressed, as in my opinion it is still wrong.  I
>have written for what seems like hours now on this topic over the past 3
>days, and have submitted a formal request for this to be reviewed to
>www-html-editor@w3.org.
>  
>
And thanks for that. 

>>If you feel compelled to
>>create your own personal key bindings then use xml events.
>>    
>>
>
>Actually, in the current draft, I do not need to. As an author, <access
>key="C" targetid="copyright"> has just created my own personal binding (as
>by my reading this is perfectly valid according to the latest draft).  That
>it may not work for thousands (millions?) apparently is of little concern.
>(Oh wait... Go into Tools>> Options>> Settings>> Access Key over-ride>> "To
>over-ride author written access keys, check here, indicate which key(s) you
>wish to change and provide alternatives.  To ensure that this applies only
>to the current site, as the next author may decide that the same function
>has access key="P", check here.  You will need to re-start your browser for
>this change to take effect." ...Yes, I can see it now...)
>  
>
Nice sarcasm.  Seriously, you are right, and I suspect that Richard was 
thinking of an earlier draft where you did indeed need to use XML Events 
to achieve what is now done with @key.  @key was introduced to help 
address requirement 1 above.  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.  
All we can do is create a mechanism that supports it and make it easy 
for content authors to take advantage of it.

>>Unfortunately, there was a request from wcag to have the keys
>>provided. We did not have the keys initially.
>>    
>>
>
>Then unfortunately WCAG still has it wrong.  That the initial WCAG is now 6
>years old and full of other "issues" shall not be addressed.  That WCAG 2 is
>still in draft (making it non-normative) also cannot come into play.  That
>both will always be Guidelines instead of Recommendations is also a factor.
>This seems to me to be a cop-out; "...it's not our fault, another group told
>us to do it". 
>  
>
Fair enough, and you can think that if you like.  But the fact remains 
that W3C groups have specific domains of operation that are spelled out 
by their charter.  The HTML Working Group should never, for example, 
define style stuff.  That's the domain of the CSS working group.  
Similarly, the WAI folks would never define a new HTML markup language - 
they ask the HTML Working Group to incorporate features that meet their 
requirements.

>I know you did not initially have 'keys' there (back when access was still
>an attribute), we reported that fact and cheered in August of 2004:
>http://wats.ca/articles/thefutureofaccesskeys/66.  The path from attribute
>to element appears murky at best to me, and I am questioning it here now.\
>  
>
Well - more on this.  The reason it is an element instead of an 
attribute is threefold:  As an attribute it was difficult to support the 
abstraction we were trying to achieve (indirect relationship between 
mappings, roles, and elements - support for multiple elements that have 
the same mapping so you can cycle those elements); As an element the way 
to bind event handlers to access elements is clearer (see XML Events); 
As an element, it is possible to use @media to create different mappings 
(or abstract mappings) for different target devices.  I could spend a 
lot of time explaining each of these topics, but it is Sunday and there 
is baseball on television.  If people are curious, send a follow up and 
I will do more on Monday.

>>Since, they are not required, I do not see this as a serious issue.
>>    
>>
>
>Since an author can create the bindings (thus forcing potential end users to
>have to "undo" the author's work and re-create something that works for
>them) it *is* an issue.  
>
I appreciate that some content authors might define mappings that you 
won't like.  I ask you to consider the possibility that *you* and *I* 
are in the minority of people who actually use keyboard accelerators.  
While I do not have hard data on this, I suspect that (statistically 
speaking) no-one even knows such things exist.  But, for those of us who 
do, and develop web applications, it is critical that we have 
appropriate control over the interface.  I cannot create an application 
that has random user experience and expect it to be successful in the 
marketplace.  I need to be able to document what features exist in my 
application, and how those features are accessed.  My users, some of 
whom are power users, expect no less.

On the other hand, using specific key mappings for specific  features in 
my application could make it difficult for users with disabilities.  For 
those users, and indeed for users who would rather use a mouse than 
remember keyboard accelerators,  I need to ensure the features are 
available through more conventional methods.  Using XHTML 2, I can at 
least assign @role to each feature so that it would be possible for 
alternate user agent technologies to expose the features in ways that 
are user friendly.  Consider something like a table of contents (note to 
self:  example in current XHTML 2 draft says role is toc, not 
contentinfo).  I might have markup like:

    <access key="C" targetrole="contentinfo" media="screen" />
    <access key="*" targetrole="contentinfo" media="mobile" />
    ....
    <div class="ToC" role="contentinfo">
    my table of contents
    </div>

My user agent might expose the control as Alt-C.  It might also have a 
standard control for the XHTML 2 contentinfo role, and expose it that 
way (it should, IMHO).  In fact, it should really be doing autodiscovery 
of role attributes, looking for things that are XHTML 2 standard, that 
are from other, well-known role collections, or that are defined in some 
new namespace but have some sort of RDF definition.  Good user agents 
will do this.  That will be nice. 

>If the WG (or PF or whomever) feels that it is imperative for the author to
>have the ability to force their mappings to the end user, where sir is the
>standard, guideline or techniques for dispute resolution to address the
>above?  How does the W3C see the above peacefully co-existing, without
>placing undue burden on the end user, and yet still provide the
>functionality desired?
>  
>
Well - first of all, as I suggest above, for the vast majority of end 
users, I maintain that there is no burden.  They won't know or care that 
these features are available.  My father, a fairly typical net-savvy 
person, has no clue that there are keyboard accelerators on some pages.  
There are millions and millions like him. Sad, but true.

However, for those of us who do know and care, I think that there are 
several things that could be done to address your concerns.  First, user 
agents should really provide the ability for users to control default 
mappings for well known roles (much as a user can have a personal 
stylesheet in some user agents today).  I would even be open to 
mandating that in the recommendation, although I can't imagine the 
browser vendors liking it very much.  Second, ensure that the precedence 
rules in XHTML 2 are clear - including the fact that local user settings 
always take precedence over document settings. Third,  we could 
encourage user agent developers to include a user setting that would 
disable @key processing altogether, although I am not sure what that 
would accomplish.

This facility is not perfect, and the examples are sort of lame.  I will 
attempt to improve those for the next draft, and include some examples 
that have XML Events triggers to show more of the power of the 
abstraction.  I would appreciate feedback from those of you who are 
interested in this on the ideas proposed in the paragraph above.

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

Received on Sunday, 5 June 2005 19:51:00 UTC