- From: Gregory J. Rosmaita <unagi69@concentric.net>
- Date: Tue, 17 Aug 1999 23:57:53 -0400
- To: User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>
- Cc: Al Gilman <asgilman@iamdigex.net>, "Leonard R. Kasday" <kasday@acm.org>, Kelly Ford <kford@teleport.com>, Janina Sajka <janina@whosoeverwill.com>
Aloha, all! Whilst I applaud the intent behind Checkpoint 10.6 (as contained in the 11 August 1999 draft), quote Allow the user to request to be prompted before a form is submitted. [Priority 3] unquote I am troubled by its vagueness, the lack of associated techniques, and by its classification as a P3. The crux of the problem, as I perceive it, is this: A) As a user, I do NOT want to be prompted EACH time I submit a form, provided that I submitted the form by activating its SUBMIT mechanism. If, however, I simply hit the ENTER or the RETURN key from within a FORM control (i.e., rather than explicitly activating the SUBMIT mechanism), I would like the UA to request confirmation before submitting the form content. B) As a user, I do NOT want the form content automatically submitted if I inadvertently press the ENTER or RETURN key. PROBLEM STATEMENT FOR POINT B: Inadvertently pressing the RETURN or ENTER key is quite a prevalent phenomenon amongst users of every level of expertise - especially those who often find it necessary to switch between user agents. Lynx, for example, uses the ENTER key within FORMs as a means of exposing drop-down (or pop-up, depending upon your point of view) SELECT menus. Thus, when one encounters a SELECT menu using Lynx, one: exposes the content of the menu by pressing the ENTER key, and then is able to navigate between OPTIONs using the up and down arrows or via Lynx's text-search feature. When one finds the appropriate OPTION, it is selected by pressing ENTER, which causes the selected item to be displayed in the SELECT menu listbox. The problems posed by the default "submit on enter" feature of most GUI browsers, is not limited to the SELECT menu problem outlined above. Lynx (as well as several other text-based browsers) uses the ENTER/RETURN key as a means of toggling several FORM controls, such as the selection of checkboxes and radio buttons. Moreover, I would like to stress that the "Auto-Submit-On- Enter" feature is not only quite problematic for one operating in an eyes-free environment, but for those unaccustomed to using online forms, and for those unfamiliar with a particular user agent's default key- bindings for forms, as well as those (like myself and countless others) who surf the web using a variety of browsers, often switching from browser to browser -- ALT- TAB-ing from Lynx32 to MSIE to Opera, for example -- in order to better comprehend the contents of a page or whilst attempting to navigate an poorly structured site or a poorly marked-up form C) 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 FOR POINT C: 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 NOTE: I have chosen to address the issue of pseudo-forms in this context, for, although they straddle the boundary between "Form Controls" and Checkpoint 5.8, pseudo-forms rely on FORM elements for activation This issue has been raised in the past, particularly by Chris Kreussling -- consult (long wrapping URI warning!) <http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0276.html> Therefore, I propose the following: PROPOSAL 1. reword Checkpoint 10.6 as follows (note the priority level change): Prompt the user to confirm the submission of form content if the submission mechanism is not directly activated. [Priority 2] NOTE: The issuance of the confirmation prompt should be controlled by a user-configurable schedule. Confirmation of "Submit-on-Enter" need not be the default setting. TECHNIQUE The issuance of the confirmation prompt should be controlled by the user, according to a user- configurable schedule. The default setting should be: "Prompt Each Time Before Submitting Form Content" Other options could include: "Submit Form Content on ENTER for All Forms in this Site" "Submit Form Content on ENTER for All Forms in this Domain" "Submit Form Content on ENTER for All Forms " If possible, the user should also be offered a "Accept this Value and Don't Ask Me Again" option, when the confirmation prompt is first displayed 2. add the following checkpoint to the "Form Control" portion of Guideline 10 and cross-reference it under Checkpoint 5.8 (the only checkpoint I could find which addresses scripting directly) PROPOSED NEW CHECKPOINT (CHECKPOINT 10.x) When there is only one field in a form, or when the form lacks a user-addressable SUBMIT mechanism, prompt the user before automatically submitting the form content. [Priority 1] TECHNIQUE 1 The issuance of the confirmation prompt should be controlled by the user, according to a user- configurable schedule. The default setting should be: "Prompt Each Time Before Submitting Form Content" Other options could include: "Submit Form Content on ENTER for All Forms in this Site" "Submit Form Content on ENTER for All Forms in this Domain" "Submit Form Content on ENTER for All Forms " If possible, the user should also be offered a "Accept this Value and Don't Ask Me Again" option, when the confirmation prompt is first displayed TECHNIQUE 2: If the submission of the single field form is achieved via a script or an HTML4 event handler, such as "onchange", prompt the user for confirmation before submitting the form content. NOTE: I am not quite sure that this new checkpoint (which I have arbitrarily numbered 10.x) quite covers the concerns I outlined in PROBLEM STATEMENT FOR POINT C, above, or Issue #58 on the UA Issues List, and wonder whether what I have identified as TECHNIQUE 2 for Checkpoint 10.x doesn't merit a checkpoint of its own -- or, at least, be included as a NOTE: appended to Checkpoint 10.x. In any event 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. 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 Tuesday, 17 August 1999 23:58:47 UTC