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