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

Shane McCarron wrote:

> 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.   

Thank you for this.  At least we can understand how we got to where we are
today, if not comment on the process in particular.

> 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'.

> 
> 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.

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.  

At it's most narrow, my complaint is with it's capacity to have an attribute
of 'key'.  If it is there due to a technical obligation, then I cannot
proceed further.  If it is there due to some form of 'legacy' thinking
("...but we need it!"), then my protestation continues.

> 
> 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.

Yes and no.  First, as an accessibility advocate, I look for means to aid
*all* communities, not just some.  My issue is in the way that all 3
requirements above are linked to author control.  By specifically allowing
the author to declare a keypress mapping, you have given that person the
capacity to make errors (conscious or not) that may impact one or more
user-groups.  The *need* to give the author that much control has not been
adequately justified or explained.  The best I have heard to date is that
"somebody else" requested it.

> 
> 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). 

"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..

> 
> 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.

> 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.

    <!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.

> 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"?

> 
> 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.

Right, so let the W3C give them something that they *can* reasonably ask
for/demand, that is scalable, useful, and reasoned.  The current draft has
listed a collection of common roles.  Entities can mandate that these roles
*must* be addressed in each document.  They can even make up new roles and
provide the 'home' for the RDF declaration(s), and then mandate that they be
used as well.  None of these proactive actions (in the name of what-ever
cause) has impacted upon specific end user-agent behaviours, but *has*
provided a semantic framework for keyboard navigation.

<snip>
 
> Nice sarcasm. 

Sorry about that... My frustration boiled to the top for a second there...

> 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.  

Which I maintain has not been adequately defended or justified.

> 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.

> All we can do is create a mechanism that supports it and make it easy
> for content authors to take advantage of it.

<more sarcasm>
"The safety institute recommends that chain-saws not be given to children
aged 7 or under, but defends the right for anyone to do so regardless."
</more sarcasm>

If you provide the capacity for abuse, it will happen.  If you remove that
capacity, it won't.  That may seem simplistic, but it does not make it any
less true.

> 
<major snip>

>> 
> I appreciate that some content authors might define mappings that you
> won't like. 

Not "like" Shane, ones which can possibly cause conflicts.

> 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. 

Uhm... Yes and no. Appropriate, yes, absolute, no.  This does not give you
the right to control font sizes does it? (They should be scalable)  It does
not give you the right to ignore certain groups (images must have
appropriate alt text supplied - right?).  

I'm not saying don't provide the capacity for keyboard navigation, any more
than I am suggesting to not provide images.  *BUT*, do so in a way that does
not intrude upon the user's configuration.  Adding 'key' to the mix does
this.

> I cannot create an
> application that has random user experience and expect it to be
> successful in the marketplace. 

Exactly!  The letter "S"!!!  I illustrated some major web-sites that each
appropriated key "S" for different purposes (one did so twice -
inadvertently I'm sure, but it just adds more weight to my point...) Because
of this, I cannot expect a consistent user experience.  The "random" factor
has been introduced... By the content author!

> 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. 

You have just defended my position!

> 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>
> 

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.  

I do not understand why you need to map a keypress to a media declaration if
both of these platforms are pre-configured to handle the standard roles.
Further, each configuration can also have internal resolution mechanisms for
custom roles.  Why do they need to be declared in the document?  If <access>
is used to define a custom role, then the RDF declaration should address the
reasoning/definition, and again the user-agent/platform A) auto-discovers
the custom declaration, and B) allows the end user to configure or ignore as
they choose.  I still do not understand why the content author need be
involved in this process.


> 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.

Right.  Now you and I are saying the same thing.  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"

By allowing the author to get in the middle, you introduce that "random"
factor - the author is over-riding default behaviours. For things to "work",
the end user may in fact have to go and make adjustments to the author's
declaration - putting the onus on the end user (your and my dad) to have to
work harder to get the functionality.  Why? 

Would not the following be better:

A) If no keypress is defined, refer to default for each common role, as
determined/defined by the user-agent
else
B) Use user-defined keypress

-coupled with-
"Custom roles should be announced so that end user may map an appropriate
keypress combination to end user needs and configuration"

In both scenarios, the author has defined the important bit ("contentinfo"),
but because the element will not allow him to map it, it shifts the burden
to the user and that user's tool.  Is this not more consistent with overall
W3C philosophy? (Develop to the spec, not the user-agent)

>> 
> 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.

I would suggest that this is due, in part, to the fact that <accesskey>
is/was so broken that few developers choose to implement them (and I've
argued and urged them not to - I'm sure you are aware of our writings).
Those that do, often (usually?) mess it up - witness the letter "S".  But if
your dad's next-gen browser had a new feature that allowed him to setup a
keypress combination (either a default upon installation, or customizable
once for all sites) so that he could *always* hit Alt+Shift+C and go to the
"Contents"... Yes, this is what we need and want.  But if some goofball
author decides that he wants it to be Alt+Z... (Pardon for Windows-centric
examples, concept remains same for other Oses)

> 
> 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).

Yes, and browsers like Opera are already there in principle.

> I would even be open to
> mandating that in the recommendation, although I can't imagine the
> browser vendors liking it very much. 

Well yes, I could see that spinning off into a whole other debate.  I tend
to be a free-market kind of thinker, smart user-agents (and their creators)
will avail themselves to this power - I wouldn't be surprised to see a
Firefox extension written to take advantage of this within weeks of it's
being published as a Recommendation - perhaps even before that, as a
proof-of-concept, (Jon Gunderson's Firefox extension for example).  Software
vendors such as GW Micro (WindowEyes) and Freedom Scientific (JAWS) would
probably jump on this quickly too, as both screen readers rely exclusively
on keyboard navigation.  But if these tools can also consistently rely on an
un-encumbered "hook", then they can consistently apply a keypress event to
that hook within their tools default installation.

> Second, ensure that the
> precedence rules in XHTML 2 are clear - including the fact that local
> user settings
> always take precedence over document settings. 

And this could work for the common roles quite easily.  Not sure about the
custom roles defined via RDF.  If the author assigns a key, then the random
factor emerges; if the user-agent employs some form of auto-discovery then
it would also require the ability to custom map or allow for user-edit on
the fly.  This might be tricky.

> 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. 

Well, in concert with #2, for those users who may experience severe or
serious hardship if/when an author assigned keypress conflicted with a base
operation ("ALT+S" in IBM HPR), it would be a fool-proof means of confirming
end user rights.  However, if you removed the capacity for author assigned
keys, then it would remove this requirement as well.

> 
> 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.

I thank you for taking the time to listen, and I commit to continue
commenting so long as you care to listen.

JF
--
John Foliot  foliot@wats.ca
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca   
Phone: 1-613-482-7053

Received on Monday, 6 June 2005 14:13:40 UTC