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

Al Gilman wrote:
> Thank you for the references to the running code.  This is indeed a 
> positive development.
> 

Yup.  Al, if you are not too aware of GAWDS, you should be.  There is a
fair bit of working talent there, in that they are developing on a daily
basis, and are fighting the battle in the trenches.  Good Group! (They
are now discussing what "hooks" should be standardized - a discussion
which has relevance vis-à-vis the common collection of @roles)

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

The types of responses I am referring to are comments such as insisting
there is a "need" within un-named "communities" (I have pointedly and
repeatedly asked for names or documents to support any claim of "need" -
I could suggest a community that needs the return of <blink>, but
without proof it would be rapidly and soundly rejected), and the "mists
of time" comment of way back.  Suggesting that JAWS must somehow be to
blame when the W3C web-guy "brilliantly" maps to ALT+T, overriding one
of the more common keystroke actions on Windows systems - "Tools"
(remember, those guys who "need" accesskeys...), or expansive and
detailed responses such as:

> <Steven>
> That is so.
> </Steven>
> 

I also take objection to the statement that the Editors will not be
"removing" anything.  They have already removed something - ACCESSKEY -
and have instead introduced a new element - ACCESS - and a newly
proposed attribute of @key.  Both of these concepts are new to the
current Draft Recommendation - neither were present in the previous
Draft Document [http://www.w3.org/TR/2004/WD-xhtml2-20040722/]
(although, at that writing, ACCESS was proposed as an attribute).  To
claim otherwise, publicly or privately, is simply false.

****

Now to get down to business.

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

And this is fair.  The problem is that the editors somehow attach this
"connect" to a specific key, when in reality they want to connect to is
a "thought": Search, Help, Skip Nav, etc.  @role (or even targetid) will
allow us to semantically bind that idea to the location/function.
That's enough.  The "out-of-the-box" presets will come from the
technology, not the page author.  Presuming that the Common collection
of @roles remains (or is improved upon), then, for the most part, real
applications (the user agents and other AT that end users use, not web
content) will come pre-mapped to search out those "thoughts".  However,
different configurations may choose to come pre-wired with different
actual keys; already, the default binding for "Favorites" in IE is ALT+A
but in Firefox "Bookmarks" is ALT+B - who cares, it's the same idea
(they just call them differently) and the keystroke (although different
too) is consistent within the *Users* purview, where it belongs.
  
> 
> 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.

Al, the "web applications" you refer to are more accurately web based
APIs.  So long as the "hook" is provided for, the "other" application
that interacts with the API (your user agent) [not the authors BTW] can
access the functionality.  Crying for a "key" is a bit of a red herring.
The GAWDS experiment supports this now, although crudely.  The author is
preparing the hooks, but the end user sets the keys and the information
is stored in a cookie (for return visits).  In the future, sophisticated
user applications (UAs, AT tools, etc.) will ship with key bindings
hard-wired to a common or standard collection.  Where the Editors (and
WAI) should be focusing their efforts is on what hook declarations
*really* should be in the common collection - a discussion that I have
already mentioned is on-going at GAWDS.  
 
> 
> 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.   

Absolutely, which is why this needs to get done right.  

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

...and to vigilantly stand guard to ensure that the Conflict Resolution
process is firmly entrenched.
  
> 
> 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.

But Al, you are not cutting the author out of the process, you are
simply giving him some ground rules.  What it *will* do is force the
user agent people into accepting some responsibility, but given the
feeding frenzy that is Firefox, and the committed and informed
development from companies like Opera, this should be readily and
rapidly embraced.

Authors will continue to be able to author intent, just not an actual
key-binding (which more often than not will not be available, either
because of User declared over-rides, or software over-rides, per the
proposed Conflict Resolution).  Why set up the author for a fall?  It
would be pointless to then, as part of any "user guide" for your web
applications, to definitively declare that ALT+ anything will achieve
the desired result, because it probably won't.  Simply declare the
intent, and hand off the rendering to the user agent.  I've compared it
to <q> a number of times: we don't tell the browsers *how* to render
<q>, only that it must in such a way, as to indicate that it is an
in-line quote.

Your subject line alludes to the right idea, it's the methodology I
argue: the author will continue to propose, only what the author
proposes is an outcome, not a method.  Reference back to the work being
done at GAWDS:  The developer establishes in an array the ideas, and
encodes those idea hooks into the document, so that if the user chooses,
they can bind to the "hooks" - "...so, which key would you like to
use?".  I am so excited about what these guys have done, because it
fully supports what I have been saying all along.  They, as authors are
declaring the "idea", the "thought", the outcome; they don't need to
declare the key!  And it's working.


My good friend Chaals states:

> Having said that, there is still value in the author making a 
> suggestion
> of a key. Where we have no role information available, or have already

> assigned a primary key for a function (e.g. search the website, and
there  
> is also "search the 'subsite'") then having an author suggestion does
no  
> harm and gives us a hint about how to make something that is at least

> internally consistent. 

However, if the author is concocting a new @role within any given
API/web application, then do they not also have to generate an RDF
declaration of what, exactly, they are talking about?  That's where the
key hint goes.  It's linked to the "idea", not hard coded into it.  This
also (not to re-direct) preserves the "purity" of the XHTML layer.

Chaals, could not the user agent simply inform the user that it has
"discovered" additional hooks within the document/site, and ask the end
user if they want to choose from a list of unclaimed keys (and have the
UA echo back keys available), and then provide the means of mapping?
Opera demonstrates a similar functionality now with the Mouse Gestures
feature - the first time you perform a Mouse Gesture the Help dialogue
appears.

> We would expect power browser users to configure
> something that suits them, and power site users to learn the model  
> proposed by the site author, perhaps even configuring their activation

> methods in the browser to match the default suggestions of their
favourite  
> site.

But again, what if the power user visits more than one power site?  Site
"A" proposes that key "1" takes you to the Home Page (UK "standard" -
http://www.cabinetoffice.gov.uk/e-government/resources/handbook/html/2-4
.asp), yet another proposes key "2" (Australian "standard" -
http://www.qld.gov.au/access/keys.html).  One of the two will need to be
rejected if the end user is the person who decides which key is mapped
to the "idea" of Home Page.  In this specific case, one of the two
authors is at best, wasting their time, and potentially worse, telling
visitors that to get to the "Home Page", use an accelerator key that
will be non-functioning.  Yet, if both power sites include "hooks" to
the Home Page link - that should be (*IS*) enough.

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

And this is the crux of the argument.  I maintain that there is no need
to specifically state a key binding, presenting the hooks is enough - it
is fully formed at that point.  Declaring a specific key has a very real
chance of giving the user a mal-formed user experience, as what the
author tells me is a feature is broken, or in my set up produces a
different result.  From the usability perspective this is a poor result,
and from an accessibility perspective may have an impact on users with
cognitive deficiencies (you tell them something will happen when they
perform an action, and it either doesn't, or worse still, something
different happens).

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 Thursday, 22 December 2005 14:18:01 UTC