@key - XHTML Role Access Module still flawed

To: The Draft Editors of XHTML 2

Reference: http://hades.mn.aptest.com/cgi-bin/xhtml2-issues/Role?id=7809

With Due Respect.

I find the current response to my initial comment unacceptable,
unsubstantiated and currently undefendable.  I continue to maintain
that, as currently presented, one of the fundamental flaws of ACCESSKEY
will be carried through to this new Element and attribute so long as the
@key attribute remains.  While I come to this discussion primarily as an
Accessibility Advocate, I believe the issues will in fact impact upon
all users to some extent.  

I will attempt to break down my concerns into concise and annotated
points. I have raised all of these points repeatedly on different fora,
and so if it seems like a broken record to some, I apologize.  Each
point will contain specific and pointed questions to the Draft Editors,
and it is my hope that any further response(s) will address these
questions specifically, both individually and overall.

1) XHTML Purity / Division of "Responsibility":

One of the intended goals of XHTML 2, implied if not articulated, but
consistent with the Semantic Web's goal of "provid[ing] a common
framework that allows data to be shared and reused across application,
enterprise, and community boundaries[1]", is to return XHTML 2 to a
"purer" form, removing any presentational or behavioral characteristics
from the Recommendation.  It is generally held today that modern
development techniques employ a three-legged approach: 

	Semantic markup (XHTML), 
	Presentation (CSS), 
	and Behaviors/Scripting (DOM). 

To quote the Current Draft: "XHTML 2 is a general-purpose markup
language...IT DOES NOT ATTEMPT TO BE ALL THINGS TO ALL PEOPLE (emphasis
mine), supplying every possible markup idiom, but to supply a generally
useful set of elements."[2]

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?

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


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?  I have asked this before[5], and have never
received a definitive response, except for the  following: "...As to the
origin of [the] requirement... 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."[3]. 

What current use?  

Today's Adaptive Technology tools clearly do not need it - they have
long since developed their own binding requirements and  mechanisms that
completely sidestep the need for author declared bindings.  The majority
of web sites and web content on the internet today does not deploy
ACCESSKEY, and those that do generally have existing user conflicts at
some level (see below: Conflict Resolution). None use ACCESS as it is a
new element. I'm sorry, this rings hollow, the "We need it because we
need it" argument does not hold much credence. 

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.

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. 


3) Key Availability and Internationalization issues: 

This one is so simple as to be painful.  There are currently few if any
real options left for universal key assignments - meaning that more
often than not a content author will specify a key-binding that will not
be acceptable/functional for some  of even many users.  My chart of
previously "claimed" key-bindings[6] has been publicly posted since
2003, and is one of  the most referenced documents at WATS.ca.  In a
response to one of my emails on this subject[7], Richard Schwerdtfeger
(Chair, IBM Accessibility Architecture Review Board) wrote: 

"You have {to} ask yourself:

 - Do all cell phones have a keyboard?
 - Will the same keys be available on Linux and the Mac as on Windows?
 - Can I use the same keys in IE and Firefox?"

...which is exactly the point.  If XHTML 2 is supposed to be the
"general-purpose markup language" that can be used on  multiple
platforms using a variety of user agents, then why is the specification
allowing for a tool/function/method that could  be so fundamentally
misused?  If a ROLE is defined with an @key mapping of "S", what of
Richard's cell phone above?   The Editors response to my initial
comment, "...A good example is a mobile application where links need to
be mapped to  numeric keys."[4] ...is both dumb, wrong and actually
defends my point - if you permit the content author to (ignorantly) map
to a letter, then any perceived benefit or increased functionality is
lost to said mobile device. Declare the intent (@role) and leave the
binding assignment to the end user.

Then there is the issue of Internationalization - you may choose "S" for
search, but I choose "Q"(for Query), and Manuel  chooses "B" for
Búsqueda.  The end user then has no idea which is 'right' or correct.
Plus, not every keyboard (or rather,  input device) out there has an "S"
key or a "Q" key or a "B" key.  What then?  

Allowing a "simple mechanism" for content authors to declare
key-bindings opens the door for misuse and broken functionality. 

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


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

	<snip>
	Check our <a accesskey="f" href="http://answers.firstgov.gov"
title="frequently asked questions">frequently asked questions</a>, <a
accesskey="f"
href="http://answers.firstgov.gov/cgi-bin/gsa_ict.cfg/php/enduser/ask.ph
p" title="email FirstGov">email FirstGov</a>,...
	<snip>

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

[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...)
 
	Site Index: [S] {conflict exists - plus many others use this for
"Search"}
	New Visitors (title="Help for new visitors"): [N] {conflict
exists}
	About W3C: [B] {MAJOR conflict exists}
	Join W3C: [J] {conflict exists}
	Contact W3C: [C] {conflict exists}
	Unknown: [E] (it actually puts the focus into the search text
input) {MAJOR conflict exists}
	Go: [G]

... Do I really need to continue? 

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.  

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.
THIS POINT IS CRITICAL AND SHOULD BE OF THE HIGHEST PRIORITY.  If you
must  leave the door open for conflict, then you must also provide a
specific and definitive means for conflict resolution - this must  not
slip through the cracks, as apparently happened to Conflict Resolution
in the SMIL 2 Recommendation.

5) A way out?:

Since I began this process, I have encountered some legitimate reasoning
for specific use-cases where author supplied  "hints" might be
appropriate[9].  These generally are attached to new or custom ROLES
that are being defined by the content author, and referenced via the RDF
mechanism provided within the ACCESS element.[10]

The current Draft reads: "The RDF definition can be used [to] define
what the object is, HOW YOU WOULD INTERACT  WITH IT {emphasis mine}, how
it relates to other elements, and what other objects it is like or sub
classes."[see note]   Based upon this statement, I honestly believe that
this is where your author supplied key-mapping should reside: how the
@role relates to other elements and how you would interact with it
(keypress)

What we will have then is a scenario where:
	
	1) Standard ROLES are declared by the W3C as part of the
Recommendation.  Users and User-agents can be  permanently mapped to
USER CHOICE settings to these common roles - consistent across all
sites, predictable across all  sites, and without the need for
intervention of the content authors (and the attendant potential for
"muddling"); state the  intent and leave the rest to the end user.  This
is consistent with the earliest intentions and principles of HTML, where
concepts such as <blockquote> were declared, but left to the end
user-agent to render.  It also preserves the "purity" of  XHTML 2 as a
mark-up language devoid of behavioral aspects.

	2) Custom ROLES are defined by content authors, who must also
provide the RDF component for these  Custom ROLES.  Custom Key-mapping
"hints" can reside here (as currently defined in the existing Draft
Recommendation), where they are more appropriate.  Intelligent
user-agents that can retrieve and use the RDF @role  definitions can
also supply the ability for the custom mapping.  This addresses the
(perceived but currently  unsubstantiated) high-level need for author
declared bindings in Customization circumstances.

	3) A specific Conflict Resolution process exists to address
issues between the RDF supplied "hints" and  existing user / user-agent
settings, ensuring the end user is, AND WILL REMAIN, the final decision
maker when it  comes to keystroke navigation.

... And all without the need of @key.


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.

I would like to thank the Draft Editors for taking the time to read this
rather lengthy note. I wish to re-state that I support  and desire a
method for content authors to allow for effective keyboard navigation -
I have said so many times, and will  continue to say so as XHTML 2
continues though it's process to the next Official W3C Recommendation.

I also thank you in advance for a more detailed response to this note
than was originally received to my initial comment.  I  believe that the
issues raised are serious enough, given the fact that you are in effect
writing the next generation markup  language upon which the next 10+
years of Internet Development will be based, that they cannot be simply
swept under the carpet with the current 2 sentence dismissive response.

Sincerely,
John Foliot
--
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  



[1] http://www.w3.org/2001/sw/ 
[2] http://www.w3.org/TR/2005/WD-xhtml2-20050527/
[3] http://lists.w3.org/Archives/Public/www-html/2005Jun/0096.html
[4] http://hades.mn.aptest.com/cgi-bin/xhtml2-issues/Role?id=7809
[5] http://lists.w3.org/Archives/Public/www-html/2005Jun/0081.html
[6] http://wats.ca/resources/accesskeysandkeystrokes/38
[7] http://lists.w3.org/Archives/Public/www-html/2005Jun/0125.html
[8] http://lists.w3.org/Archives/Public/www-html/2005Jun/0078.html
[9] http://hades.mn.aptest.com/cgi-bin/xhtml2-issues/Role?id=7816
[10] http://lists.w3.org/Archives/Public/www-html/2005Jun/0080.html
[11] http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#col_Role

[see note] attention Editors, typographical issue with missing "to"

Received on Thursday, 17 November 2005 20:48:42 UTC