RE: Prompts

heather commented upon jan's screen shot:

quote
According to the definition of prompt ("requires author response") this 
bitmap does not comply, it is informing the user of an error as opposed to 
prompting them to input information.
unquote

but if the user was offered a configuration setting that allowed the tool 
to prevent him or her from saving until the errors were fixed, provided a 
"Fix Now" mechanism, or simply displayed the warning, it _WOULD_ pass 
(provided, of course, that -- in the last instance -- when the file was 
opened again for editing, the user was prompted to fix the invalid and 
inaccessible markup, with the options: "Remind Me Later" or "Fix Now" 
(which could invoke a repair wizard);

if the tool offers HTTP PUT, then i would argue that it absolutely MUST 
explicitly warn the author that he or she is about to put 
inaccessible/invalid source on the web, and provide him or her with a "Fix 
It First" option...  the tool should still allow the author to ignore the 
warning and put the inaccessible slash invalid content on the web, but you, 
as the developer, would have forced the author to make a decision and 
perform an explicit over-ride action in order for him or her to put 
inaccessible content on the web, so like Pilate, you could then wash your 
hands of that particular author's conscious decision to disregard the 
prompt, and justly claim conformance...  yes, this is a final line of 
defense strategy, and it sort of smacks of Willie Wonka's "no... 
don't...  come back..." warnings to the children who wandered off from the 
tour of his chocolate factory, but fact remains that there are instances 
where a user MUST be prompted, and this is one of them...

heather, as william and i argued today (and have been arguing for the past 
year) the issue is really one of configurability -- if the user has a 
choice (warn me, prompt me, physically assault me), then the checkpoint is 
satisfied -- as long as one of the range of choices is a prompt that 
requires user reaction...

as for "out-of-the-box" prompts and alerts, the user could choose/set the 
level of prompting during the installation routine, provided that -- if the 
user chooses "No Prompts or Alerts", he or she is presented with a "Readme" 
type dialog box/application window, before the installation process ends, 
in which (a) the benefits of checking for accessibility, (b) the means of 
checking for accessibility available through the tool, and (c) how to turn 
them on, off, and configure them are explained _in full_ to the user...  i 
would also argue that in order to comply, you would have to provide a 
warning and a "more information" button when the user who has turned off 
all accessibility checking issues the "Save" command, as well as a "Fix It 
Now" mechanism (which i would prefer to "see" on the dialog that pops up 
when the user who has disabled all of the accessibility 
checking/prompting/alerting features of the tool off, rather than as part 
of the "More Information" interface, but that is, i suppose an 
implementation decision...

one of microsoft's strong suits is configurability -- Word, IE, and a host 
of other MS products allow for extensive configurability -- why not its 
authoring tools?

gregory
------------------------------------------------
The optimist thinks that this is the best of all
possible worlds; the pessimist knows it is.
------------------------------------------------
Gregory J. Rosmaita     <unagi69@concentric.net>
       Webmaster & Minister of Propaganda
The Visually Impaired Computer Users' Group of
the New York City Metropolitan Area (VICUG NYC)
      <http://www.hicom.net/~oedipus/vicug/>
------------------------------------------------

Received on Tuesday, 2 May 2000 20:01:06 UTC