Re: @key - XHTML Role Access Module still flawed (PR#7845)

John,

Thanks for your (long!) comment.

First let me say that XHTML2 is being designed with direct contact with  
the accessibility groups at W3C and Richard Schwerdtfeger is on the HTML  
WG himself.

Let me try to address your points one by one.

> 1) XHTML Purity / Division of "Responsibility":
[...]
> In my current reading of the Draft Recommendation, all of the proposed
> Elements and Attributes (be they unchanged, reworked or brand new) all
> strive for this "division of responsibility" save one: @key.  Why is
> this?  If the intended and  stated goal is to make XHTML 2 a "pure"
> markup language, why are the Draft Editors insisting on maintaining a
> behavioral effect in the specification?  Should not this type of
> functionality be relegated to DOM scripting, where it belongs?  Would
> this not then allow and foster greater device independence?

It is not an aim to get rid of all behavioural markup in the language. On
the contrary, where there are clear needs identified by current use of
scripting (in HTML4/XHTML1), then we have introduced declarative markup to
cover that case. Navigation lists are a good example of this.

> In a public response to my earlier questioning, Shane McCarron (one of
> the Editors) wrote:  "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."[3]  Am I to then understand that because the existing
> DOM Events Spec is currently  flawed or lacking, that moving forward
> XHTML 2 will be less than "pure", continuing to mix semantic logic and
> behavior at the same  document level?  Does this then not contradict the
> intended goal of creating a "...general-purpose markup language...[that]
> does not attempt to be all things to all people..."?

We did indeed attempt a solution to the requirements we had to that used a
DOM-based declarative markup, but with the lack of sufficient
architectural support, we fell back to the current design.

> 2) Need - Real or Imagined?:
>
> In the current response to my comment, it is written: "Author-defined
> key bindings are a requirement of many members of  our user
> community."[4]  With the greatest respect to the Editors, can I be
> pointed to one document, email, request or other communication  which
> supports this assertion?

There are two communities who have expressed to us a need for
author-supplied key bindings, and with which we have had discussions. One
is the accessibility community, the other is the mobile community. There
is also a third, the HTML community, who want to be able to continue to do
what they do in existing versions of the language.

I think that the community that uses it the most is the mobile community
for binding keys (0-9*#) to menu entries.

> Let me be very clear: A METHOD TO ALLOW CONTENT AUTHORS TO ATTACH
> NAVIGATIONAL INTENT TO THEIR  CONTENT IS AN IMPORTANT AND VALUABLE
> REQUIREMENT, and one that I fully support.  I am not advocating the
> removal of ACCESS or @role, simply that of @key.
>
> Perhaps the response I received is only half correct, what you mean is:
>
> "Author defined ROLE bindings are a requirement of many members of our
> user community." This would be, I believe, more accurate.  I further
> concede that in instances  where custom roles are defined, a method of
> "hinting" a suggested key-binding should exist (more on that below).  At
> it's  base however, if the developer community has a "standardized" list
> of basic roles, as currently suggested in the XHTML 2 Draft, and User
> Agents are developed that internally map to these standardized roles
> (using exactly the same process that  Adaptive Technology or User Agents
> such as Opera employ today), then there should be no need for content
> authors to try  and guess or suggest a specific mapping key - it has
> been addressed by the user and their user agent.

We agree with all of this, and in a way @key is the hint, albeit a strong
one, that you are suggesting. However, in non-accessibility environments,
such as in mobile use, there is still a perceived need to be able to
specify a key.

> I have been told that "The key bindings are left to the end user if they
> wish. They are not required."  However, if content  authors can continue
> to apply their own custom mappings in an easy manner (using @key), then
> we know that they  probably will, if for no other reason than they can,
> perpetuating the current Tower of Babel problems we presently have with
> ACCESSKEY.

The intention is that user bindings override author supplied bindings (see
below).

> 3) Key Availability and Internationalization issues:

1) If you have no keyboard, the keybindings are moot.
2) Likewise if you don't have a key with the required character (such as
'~' on an Italian keyboard).
3) However, the <access> elements are still available, and a user agent can
still offer them to the user via other means (such as via a menu).

> 	MANTRA: Declare the intent and leave the binding assignment to
> the end user.

A good tenet, but not a reason in itself for disallowing explicit bindings.

> 4) Conflict Resolution (Who's the Boss?):
>
> One of the most serious problems with the existing ACCESSKEY attribute
> today, and the greatest fear I have for  perpetuating Author declared
> mappings with the @key attribute, is in the area of conflict resolution=
> .=
>
> I have listed the following two examples of real and serious issues in
> the past, and they bear repeating here:
>
> 	www.us.gov [a]
> 	www.w3c.org [b]
>
> [a] at the US.gov site, they've fouled up, in that accesskey="f" has
> actually been assigned to two separate hyperlinks!!!

Because people make mistakes is not a reason in itself to disallow a
feature.

> Also, (and perhaps more importantly) it should be noted that the
> keystroke combination of ALT+F (and yes, I know that this is a Windows
> only instruction, but let's move on...) is also used virtually
> everywhere to open the "File menu"... BUT, if you try and do that at the
> us.gov site, it takes you to the "Ask your Question" page...

On one browser. The HTML4 spec doesn't define what the final binding is to
the key. Other browsers use other combinations of keys.

> [b] at the W3C, they (you?) currently use the following accesskeys:
>
> 	Activities: [A] - except in IE 5.5/6, plus adaptive technologies
> that use the IE browser or engine (JAWS,  WindowEyes, IBM HPR) this
> *should* open your favorites folder, except at the W3C site - Oops...
>
> 	Technical Reports: [T] - In most mainstream browsers, this is
> supposed to open the "Tools" dialogue, in  HomePageReader it is the
> shortcut for Table Navigation, and in the laptop configuration for JAWS,
> it is supposed to "Speak the Title of the Current Window" - except at
> the W3C site of course (Oops again...)

I don't understand why this is this a bug in HTML4 or W3C, and not in
Jaws. I would complain to Jaws personally. Althought the HTML4 spec
doesn't disallow using the same key combinations as the chrome, it doesn't
require it either; it seems like a bad choice for a browser to use
it.

Perhaps you mean to suggest that the spec should require user agents to
use a different key combination to that used by the chrome.

> In a private email from Shane McCarron I received in June 2005 (and
> further recorded as an Official Comment to XHTML 2)[9], it was indicated
> that perhaps what is required is a specific conflict resolution process
> as part of the final XHTML 2 Recommendation.  It was suggested that a
> "hierarchal" style resolution exist, something along the lines of:
>
> 	User settings over-ride all user-agent mappings and author
> declared bindings. (Highest Priority)
> 	User-agent mappings over-ride author declared mappings. (Second
> Highest Priority)
> 	Author declared mappings be exposed/honored. (Lowest Priority)
>
> While this is still a less-than-perfect solution to me, I believe it to
> be an acceptable compromise to address some of the concerns raised.

Good.

> If by persuasion and argument @key is not abandoned and the Draft
> Editors insist on maintaining the author's ability to apply keystroke
> mapping within XHTML 2, then there needs to be an insistence that a
> Conflict Resolution mechanism be part of the final Recommendation.

That is so.

> CONCLUSION
>
> I believe I have put forth valid and legitimate reasons why the @key
> attribute should be removed from the Draft XHTML 2 Recommendation.
> While acknowledging the very real need for a method of providing
> keystroke navigation to documents exists, I fear that the current
> proposed solution fails in more areas than it succeeds.  There must be a
> better way than as is currently provided.

Please send us your design. Since there are communities that would not be
happy if we removed @key, we will not do so, but if you can come up with
something that you consider a better design, we'd be happy to see it.

Best wishes,

Steven Pemberton
For the HTML Working Group

Received on Wednesday, 7 December 2005 20:06:38 UTC