Comment - 25. XHTML Role Access Module

If-You-Snooze-You-Lose Department:

In the previous Draft (20040722), the attribute of "access" was introduced,
in effect, to replace the dysfunctional accesskey attribute
(http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-hyperAttributes.html#adef_
hyperAttributes_access).  The Draft stated:

"The invocation of access shortcuts, and the assignment of key or other
bindings to them is not further defined here. A user agent should allow the
user to access the user agent's list of recognized access points, to add to
them, and to specify bindings for them."

In the latest Draft however, I note that 1) access has been made an element
(as opposed to an attribute) and that one of the allowed attributes would be
"key" (http://www.w3.org/TR/xhtml2/mod-role.html#s_rolemodule).

PLEASE, NO!	

Allowing page authors to map explicit keystrokes to elements will render the
access element as useless and flawed as the current accesskey attribute.
Technology has come too far; Adaptive technologies have already effectively
used up most of the standard accesskeys currently available in HTML 4/ XHTML
1.  Conflict resolution is a mess, the evolution of "widgets" such as
Firefox extensions are further muddying the waters as authors of these
"tools" are further staking out similar keystroke combinations, etc. etc.
(For example, I currently have 2 or 3 Firefox extensions which all want to
use "Alt+S" as a "hotkey" keystroke, which conflicts with the UK
government's "Standard" for accesskeys which makes "Alt+S" (or Cmd+S, etc.)
the accesskey for Search.)

Please, please, please.  Remove the "key" attribute of this new element and
consider returning to the concept of allowing the end user/user agent to map
the user's preferred keystroke combination to roles (pre-defined or other).
Allow the end user, not the content author, to decide which keystroke
mappings suit's *their* needs and user configuration (there is already some
precedent in user agents providing this type of functionality, as witnessed
in browsers such as Opera).  To do otherwise will continue to do a
dis-service to many of the end users this element seeks to assist, is
counter to web accessibility principles, and will leave this new element in
the similar dustbin of time that thankfully accesskey seems to be headed
towards.

Thank you

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-267-1983 / 1-866-932-4878 (North America)

Received on Friday, 3 June 2005 06:31:29 UTC