- From: John Foliot - WATS.ca <foliot@wats.ca>
- Date: Sat, 4 Jun 2005 20:58:39 -0400
- To: "'Richard Schwerdtfeger'" <schwer@us.ibm.com>
- Cc: "'Al Gilman'" <Alfred.S.Gilman@IEEE.org>, <w3c-wai-ig@w3.org>, <wai-xtech@w3.org>, <wai-xtech-request@w3.org>, <www-html@w3.org>
Richard Schwerdtfeger wrote: > Hi John, > > The key bindings are left to the end user if they wish. They are not > required. Please re-read my numerous postings. I have specifically suggested that they *NOT* be required (further, not allowed!) by the author, as it perpetuates one of the basic issues/problems that accesskey produced, chiefly being that lack of standardization. If end users cannot be assured that the bindings are the same on each site they visit, they become less than useful. You may choose "S" for search, but I choose "Q" (based upon 'query', as "S" is currently over-ridden by IBM HPR and my Sage News Reader extension in Firefox), and Manuel chooses "B" for Búsqueda. The end user then has no idea which is 'right' or correct. This also can be an issue of concern for internationalization, as not every keyboard out there has an "S" key or a "Q" key or a "B" key. What then? > Additionally, the author may not wish to do the key > assignment and in these cases they may be left to the browser. You > have 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? Exactly. So stop declaring the bindings! Declare the intent and leave the binding assignment to the end user. I'm not sure if you have understood my point, as all of these possibilities lead to other reasons why specific bindings (as declared by the author) are foolish at best, harmful in extremes, and useless as often as not. Removing the authors ability to do so does not cause any "harm" that I can see (or that has been adequately defended). > > The cost of requiring the user to predict what key to use on every > device is not acceptible. XHTML 2 will be used for other environments > than just the desktop. Right - this is exactly what I am saying. The current suggestion that users be allowed to "over-ride" author specified bindings is arse forward. As the Al Gilman posting re-counted: <q>The user has better knowledge of what works for them and what does not than an author trying to prepare an experience for multiple users. {plus} Users quite generally prefer not to change the author's presentation or UI design, and to change it as little as possible where necessary. Most of the people using something other than the default presentation or input binding the author offered are people who need to use something different. {and finally} When there are many settings associated with adapting a user interface, the user may not be able to navigate the interface state to an optimum.</q> (http://lists.w3.org/Archives/Public/www-archive/2001Nov/0069.html) The tail is wagging the dog! > > As to why it is an element vs. an attribute: Access key, as it is > today is non-deterministic. The author now has the ability to define > which event gets generated (focus or activate) as an example. We also > wanted to allow for role based navigation. We wanted to provide a > title attribute to describe the action. There are only so many things > you can attach to a single attribute. Good sir, have you not read my suggested solution? It addresses role ('standardized' or user defined), role based navigation (extensibly), title attribute, and more. I have asked *why* this way forward would not address the concerns and intent that all are striving for. Again, for the record: A) W3C has a 'standard' list of common roles (as per Draft 20050505) B) Custom 'roles' are defined via RDF C) "Access" becomes simply a meta element (akin to link) so that when defining custom 'roles' it can be auto-discovered by user-agents. This type of function already exists in "auto-discovery" RSS feeds. <access role="disclaimer" rdf.resource="">. Admittedly, this is the weakest link in my proposal, however I do not think this outside the realm of possibility. D) "Role", as an attribute, becomes the intent declaration. Like other attributes (lang, title, class, etc.) role can then be applied to any semantic construct: <p role="disclaimer">. Good UI's will then "announce" when a custom role is present and allow the user to bind (or ignore) on a case-by-case basis. (perhaps the "title" attribute would also be required to give the role a human readable identifier?) E) Binding is left to individual user-agents / user preferences. This does not preclude any user-agent from providing a "default" key binding within their UI to the list of 'standard' roles defined and published by the W3C. I will point specifically to Opera as a tool that demonstrates this type of function, allows this, and allows end users-to re-map via the UI directly (not by fiddling with alternate style sheets, userJS, or other arcane, "geeky" methods). As has already been pointed out, this is not realistic either. The net effect here is that, by and large, those developers that you are seeking to "carrot" get their functionality without having to "guess" at appropriate keystrokes, the majority of end-users have a stable, learnable, reliable and CONSISTENT method of invoking keyboard navigation, yet customization of key-bindings is left directly with the minority of end users if and when required. The content author never had a say in it. > > In short, the original access key was designed with very little > foresight as to where the industry would go. The new access element > is designed to address semantics navigation, device independence, and > flexibility on behalf of the author while providing a degree of > backward compatability. With due respect and humility, you are preaching here to the converted. A quick review of the WAI-IG archives will show you that I have screamed, ranted and bemoaned this fact for years now, both on the WAI-IG list as well as other accessibility discussion lists (WebAIM, GAWDS). My associate and I have written extensively on the subject - start here: http://wats.ca/articles/accesskeys/19. I honestly do not think that the current proposal in XHTML 2 Draft 20050505 adequately addresses the primary issue of 'behaviour vs. intent'. > > Hopefully, this addresses the issues you raise. Sadly, not in the least. I have argued that the author must not have control over the end user's behavior norms, and allowing the content author to bind *their* idea of what is 'best' is wrong; it flys in the face of numerous other ideals and precedents, all of which I have referenced in my last posting. Nothing you have replied with addresses this concern, nor even attempts to adequately refute my alternate proposal. Sincerely, JF -- 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
Received on Sunday, 5 June 2005 01:12:15 UTC