W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2001

[Definition] Explicit user request

From: Ian Jacobs <ij@w3.org>
Date: Wed, 30 May 2001 13:51:08 -0400
Message-ID: <3B15330C.CF2D089A@w3.org>
To: w3c-wai-ua@w3.org
Hello,

I have been struggling to find an adequate definition of
"explicit user request". An explicit user request is one where
the user agent and the user share the same expectation about the
user's intention. We have a number of requirements that only
apply when there has not been an explicit user request.

In the case of native UI controls, you can presume that the user
agent recognizes the role of the control (they are native, after
all). And, if the controls are documented (either in the user
interface directly, in help, etc.) then you can presume (barring
user error) that the user had a similar intention and
understanding.

The case of content is trickier. For instance, consider a link
with "target=new" in HTML. The user agent recognizes the effect
through markup, but the user probably does not. If the link text
is "hey, I open a new viewport", then both the user and the user
agent know, but the user agent doesn't know that the user does! 
So the user agent can't suddenly conclude that this is an
explicit user request to open a viewport. If the user agent
prompts the user to confirm that they want to open the viewport,
then the user agent can presume that the user knows (because
the prompt is a native control).

I examined the checkpoints of the 25 May draft [1] to find out
which ones make requirements related to explicit user requests
that involve the UA user interface, and which involve
content. For ones that involve the UA user interface only, I
think it's reasonable to define "explicit user request."  These
checkpoints are:

  3.2 Toggle audio, video, animated images. 
      Rationale: In this case, the user either interacts
      with a placeholder, a prompt, a configuration setting, 
      or some other mechanism not provided by the author.
  
  3.5 Toggle content refresh. 
      Rationale: Same as for 3.2.

  3.6 Toggle redirects.
      Rationale: Same as for 3.2.

  5.1 No automatic content focus change.
      Rationale: This will be done through the UA's controls.

  5.3 Manual viewport open only.
      Rationale: This will be done through the UA's controls.

  5.7 Manual viewport close only.
      Rationale: This will be done through the UA's controls.

The following checkpoints involve user interactions with content:

  2.4 Allow time-independent interaction.
      Comment: In this case, the note states:

       "The user may explicitly complete input in many different
       ways (e.g., by following a link that replaces the current
       time-sensitive resource with a different resource)."

  5.5 Confirm form submission.
      Comment: This checkpoint already says "an explicit
      user request to activate a form submit control." 

========
PROPOSAL
========

a) Define explicit user request as follows:

   In this document, the term "explicit user request" refers to
   any user interaction with a <a href="#def-control">control</a>
   of the <a href="#def-ua-ui">user agent user interface</a>,
   where the behavior is <a
   href="#def-documentation">documented</a>.

b) Change 5.5 to:

     "Allow configuration to prompt the user to confirm (or
     cancel) any form submission that is not caused by user
     activation of a form submit control."

   Question: What about when the user activates the form control
   programmatically via their assistive technology?  We'd like
   that to be considered explicit, but it's just as programmatic
   as a form submission done through a script.  It might be hard
   to tell the difference.
   
   So, perhaps the best is just to say:

     "Allow configuration to prompt the user to confirm (or
     cancel) any form submission."

   We've already said that this is a sufficient technique for
   satisfying the checkpoint.

   I realize that it may be an extra burden to have to confirm a
   form submission once someone has pushed on a form submit
   button, but that inconvenience is minor compared to the P2
   requirement.

c) No change to 2.4.

Comments welcome,

 - Ian

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 831 457-2842
Cell:                    +1 917 450-8783
Received on Wednesday, 30 May 2001 13:51:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:50 GMT