[WATS.ca Archived]

July 2, 2013

ACCESS + KEY still = ACCESSKEY – The XHTML Role Access Module still flawed



Back in the early 2000′s, my colleague and friend Derek Featherstone and I launched a joint consultancy group in Ottawa, Canada that focused on the issues of on-line accessibility, and the emergent techniques and requirements of this (at the time) new aspect of web development. Derek and I wrapped up WATS.ca somewhere around 2006 as we moved on to other projects, but we both remain active in the field today.

We jointly published a number of articles on our web-site that often became go-to references then, and it seems a shame that they be lost to the vagaries of time; the original site long since gone. I have created an Archive section of this site to preserve those postings, and the following article from that time is one such. Please note that some of the information in this or other similar articles may be dated, or superseded by events in time: I am making no attempt to update these articles and am simply posting them as they existed when they were first written.

By: John Foliot | Posted: November 17, 2005

The following article is a re-print of an Official Comment made to the Editors of the XHTMLTM 2 Draft Recommendation. It is presented here in a more open form to hopefully stimulate discussion and debate. If you believe, as I do, that the @key attribute has no place in XHTMLTM 2, I urge you to say so to the Draft Editors: www-html@w3.org

A Letter to the Draft Editors of XHTMLTM 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.

XHTML Purity / Division of “Responsibility”

One of the intended goals of XHTMLTM 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 XHTMLTM 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:

“XHTMLTM 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 XHTMLTM 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 XHTMLTM 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…?

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

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

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:

[a] at the US.gov site, they’ve fouled up, in that accesskey=”f” has actually been assigned to two separate hyperlinks!!!

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

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 XHTMLTM 2)[9], it was indicated that perhaps what is required is a specific conflict resolution process as part of the final XHTMLTM 2 Recommendation. It was suggested that a “hierarchical” 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 XHTMLTM 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.

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


I believe I have put forth valid and legitimate reasons why the @key attribute should be removed from the Draft XHTMLTM 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 XHTMLTM 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.

John Foliot

CC BY-NC-SA 4.0 ACCESS + KEY still = ACCESSKEY – The XHTML Role Access Module still flawed by John Foliot is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Posted by John

I am a 16 year veteran of Web Accessibility, living and working in Austin, Texas. Currently Principal Accessibility Strategist at Deque Systems Inc., I have previously held accessibility related positions at JPMorgan Chase and Stanford University. I am also actively involved with the W3C - the international internet standards body - where I attempt to stir the pot, fight hard for accessibility on the web, and am currently co-chairing a subcommittee on the accessibility of media elements in HTML5.

View more posts from this author

Leave a Reply