- From: Gregory J. Rosmaita <unagi69@concentric.net>
- Date: Wed, 18 Aug 1999 15:26:11 -0400
- To: User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>
- Cc: Al Gilman <asgilman@iamdigex.net>, "Leonard R. Kasday" <kasday@acm.org>, Janina Sajka <janina@whosoeverwill.com>, Kelly Ford <kford@teleport.com>
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