W3C home > Mailing lists > Public > public-wsc-wg@w3.org > April 2007

ISSUE-59: challenge and recover are essential; one presentation fits all -NOT (pubic comment)

From: Web Security Context Issue Tracker <dean+cgi@w3.org>
Date: Tue, 17 Apr 2007 12:24:07 +0000 (GMT)
To: public-wsc-wg@w3.org
Message-Id: <20070417122407.31CB647BA3@mojo.w3.org>


ISSUE-59: challenge and recover are essential; one presentation fits all -NOT (pubic comment)

http://www.w3.org/2006/WSC/Group/track/issues/59

Raised by: Bill Doyle
On product: Note: use cases etc.

>From public comments
raised by: Al Gilman Alfred.S.Gilman@ieee.org

http://lists.w3.org/Archives/Public/public-usable-
authentication/2007Apr/0000.html

challenge and recover are essential; one presentation fits all -NOT 
where it says, in 10.1.7 Help users recognize, diagnose, and recover from 
errors
   Error messages should be expressed in plain language (no codes),
   precisely indicate the problem, and constructively suggest a
   solution 
please consider
model the system-driven forward path of the browse dialog and exception- and 
user-initiated digressions in UML/SCXML.  Document recovery path options in 
the model.  Then slice and style what you will for stated nominal conditions.
Why? 
You simply can't do all those things at once for the breadth of the disabled 
population.  The literal codes of the protocol messages are the only way to be 
fully precise.  Plain language is dependent on the language skills of the 
user.   What the author thinks is a constructive suggestion as to a resolution 
is frequently a bad choice when operating through an adapted delivery 
context.  The full model needs to be documented and shared with AT so that 
appropriate decisions can be made about these things.  Yes, the author (and 
WG) *should* propose what they *think* is good presentation and recovery 
paths.  OTOH they need to know that they will be wrong about these decisions 
for some delivery contexts and that more user-centered, use-initiative, AT-
knowlege-based decisions must be enabled in the implementing protocols.
Received on Tuesday, 17 April 2007 12:24:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:46 GMT