Re: Checkpoint: Forms without user-addressable SUBMIT mechanisms

Aloha, yet again!

During the 18 August 1999 teleconference, (raw minutes of which are
available at (long URI warning):

<http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0137.html>

I was asked to clarify the checkpoint I proposed to the list earlier today,
in which the accessibility issues presented  by forms without a
user-addressable SUBMIT mechanism, is addressed.  Note that what I consider 
optional terminology is demarcated by braces.

PROPOSED CHECKPOINT
  If the submission of a form is achieved via a script or an event 
  handler, prompt the user for confirmation before submitting the form 
  content. [Priority 1]
     NOTE: This checkpoint is intended to extend the user's 
           control over automated submission mechanisms, 
           such as the HTML4 event handler "onchange".
     Refer also to Checkpoint 5.8

TECHNIQUES:
  1. Allow the user to configure the user agent. Choices
  should include:

     1) "Never Allow Automatic Submission of Form Content "
	or "Never Submit {Do Not Prompt}"
     2) "Always Allow Automatic Submission of Form Content"
	or "Always Submit Without Prompting"
     3) "Prompt Before Submitting Form Content"

  The default setting should be: "Prompt before submitting
  form content", so as to allow the user to decide whether
  or not event handling will occur automatically. Choosing 
  "Prompt Before Submitting Form Content" will allow the 
  user to choose whether or not to submit scripted and/or 
  event handled form content on a case-by-case basis.
  
  2. Configuration can be determined by prompting the user
  the first time an event handled or script-driven FORM is
  encountered. Choices should include:

     1) "Submit" {optional verbiage: "This Time Only"}
     2) "Do Not Submit" {optional verbiage: "This Time Only"}
     3) "Always Allow Automatic Submission of Form Content"
	or "Always Submit Without Prompting"
     4) "Never Allow Automatic Submission of Form Content "
	or "Never Submit {Do Not Prompt}"
     5) "Always Prompt Before Submitting Form Content"

  If the user chooses "Prompt Before Submitting Form
  Content", this prompt could be recycled in an abbreviated
  fashion.  The recycled prompt should include

     1) "Submit This Time Only"
     2) "Do Not Submit"
     3) "Always Submit and Do Not Ask/Warn Me Again"
     4) "Never Submit and Do Not Ask/Warn Me Again"

In addition, the Techniques for the proposed checkpoint
should also reference the WCAG's Checkpoint 6.3, which is
P1, and the WCAG Techniques Document's Topic 2.13, the
introduction to which states:

  Content developers must ensure that pages are accessible
  with scripts turned off or in browsers that don't support
  scripts.

In particular, Technique 2.13.2, which deals explicitly
with event handlers.

As for placement, the proposed checkpoint would be added 
to the "Form Control" portion of Guideline 10 and cross-referenced 
under Checkpoint 5.8 (the only checkpoint in the UAGL that I could 
find which addresses scripting directly)

-- END OF PROPOSAL / BEGIN JUSTIFICATION

The following three paragraphs, which were originally part 
of my post on the subject of "Form Controls (Strengthening 
Checkpoint 10.6)", are included here for clarification.  The 
original post is archived at (long URI warning!)
<http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0129.html>

-- begin quote
As a speech user, I am constantly frustrated and 
misdirected by the use of javascript and event handler 
controlled pseudo-forms, wherein the user is presented with
a menu (in the form of a listbox in GUI browsers), and is
redirected to a different viewport upon selection of an
OPTION.

  PROBLEM STATEMENT: The markup behind such
  pseudo-forms is a mix of javascript (in particular the
  "function switchpage(select)" command) and HTML FORM
  controls, which utilize HTML4's event handler script
  attributes (in particular the "onchange" event handler
  attribute has been defined. An example (gleaned from the
  document source for <http://www.pricescan.com> follows:
  
  <SELECT NAME="condition" onchange="switchpage(this)">
  
  When such a menu Is encountered by a websurfer who is
  using speech synthesis in conjunction with a javascript
  enabled user agent, his or her instinctual reaction will
  be to use the UA's navigational mechanism (usually the up
  and down arrows) to review the available OPTIONs.
  However, each time a new OPTION is displayed, the user is
  abruptly taken to a new viewport. Conversely, if one is
  using a user agent that does not support javascript (or
  has javascript support disabled), then the menu is
  displayed, but since there is no SUBMIT mechanism
  associated with it, there is no mechanism by which one
  can use the menu to quickly switch viewports - the
  ostensive purpose of this type of pseudo-form.  And while
  one can avoid having the viewport abruptly changed when
  encountering the menu (at least in the Windows
  environment) by using the ALT-LEFT-ARROW keystroke to
  display the menu in a drop-down list, (a) very few users
  know this keystroke, and (b) when one encounters a
  listbox on a page in an aural environment, one usually
  assumes that he or she is navigating a valid FORM, in
  which there are no unexpected side effects to perusing
  the contents of a SELECT menu using the arrow keys

-- end quote
  
Gregory
--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <oedipus@hicom.net>
   President, WebMaster, & Minister of Propaganda, 
        VICUG NYC <http://www.hicom.net/~oedipus/vicug/>
--------------------------------------------------------

Received on Wednesday, 18 August 1999 15:27:18 UTC