- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Wed, 21 Dec 2005 10:59:21 -0500
- To: "John Foliot" <foliot@bytowninternet.com>
- Cc: <wai-xtech@w3.org>
Thank you for the references to the running code. This is indeed a positive development. Let me see if I understand the points where there is general agreement and where there are differences. In http://lists.w3.org/Archives/Public/wai-xtech/2005Dec/0016.html At 9:07 AM -0500 12/20/05, John Foliot wrote: >The cavalier and dismissive responses I am receiving.. What I find, by way of responses, are: <quote cite= "http://hades.mn.aptest.com/cgi-bin/xhtml2-issues/Role?id=7809"> The working group agrees that the end users should be able to override key bindings, ... </quote> <quote cite= "http://lists.w3.org/Archives/Public/www-html-editor/2005OctDec/0037.html"> <John> > 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. </John> <Steven> That is so. </Steven> </quote> Now, Steven's "that is so" is a little premature, because the final Recommendation has a lot of process to go through yet. But you may take it as "the Working Group agrees that this should be so." That is what Steven means when he says he wrote on behalf of the Working Group. I don't find this response 'dismissive' as far as the user's right to get a binding that works for them. I agree with you that the latest public Working Draft is defective in not making this clearly de_rigeur. >... The >above examples illustrate exactly the type of functionality that end >users require, and nowhere within the above is there a need for the >author to supply *any* specific key - rather, the flexibility and >ultimate accessibility of the above is that the end user has total >control; no need to worry which key may be claimed by any particular >user configuration - generally there are _some_ unreserved keys >available to the end user regardless of the configuration. There is a big leap from saying that the consumer *can* configure shortcuts to bind them to keystrokes, and saying that the consumer *will.* It is quite possible that many more consumers will have the benefit of the short-cuts if they have an initial key binding "out of the box" as the web application pages open in the user's browser, and do not wait for the user to configure keys for the shortcut-prone functions specific to this application. We have to appreciate that what we are differing about in access keys is not full access to function but equal access to speed. Access keys are short cuts to functionality that all is available through "long cuts." There is always an alternative, it is usually more laborious. Web application authors may say that they have to have this capability because if they don't use it, they will not be competitive with those who do and the users will use their competitor's websites and they will be out of a job. Fortunately, the competition between web sites today is on usability, not functionality. We have pretty much got past 'clicks' sites with pages that simply don't work. Nowadays, customers have choices and they will migrate to and stick with the sites they can readily use, and use quickly. This competition is, AFAIK, quite sensitive to moderate percentage differences in task completion time. We definitely need to follow up through the remaining process to ensure that, when key bindings fail for one reason or another, the user is afforded effective means to re-establish accelerated or "shortcut" access to the functions the author offers shortcuts for. But if we cut the author entirely out of the loop, we may be incurring a great opportunity cost through all the shortcuts that just never happen. It may be that if the author can't give the user a fully-formed user experience as an on-load condition, they won't commit the effort to identify the shortcut-prone actions at all. Which could be cutting off our nose to spite our face. Al
Received on Wednesday, 21 December 2005 16:04:55 UTC