- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 30 May 2001 13:51:08 -0400
- 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 UTC