agreement: user disposes; disagreement: author proposes [was: Re: When actions speak louder than words]

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