Re: Formal Objection to Checkpoint 9.2

aloha, rich!

in regards your formal objection to UAAG Checkpoint 9.2, which reads 
(according to the 10 March 2000 draft)

quote
    9.2 Prompt the user to confirm any form submission triggered
           indirectly, that is by any means other than the user activating
           an explicit form submit control. [Priority 2]

           For example, do not submit a form automatically when a menu
           option is selected, when all fields of a form have been filled
           out, or when a mouseover event occurs.
unquote

i believe, as i have stated in past telecons and at the princeton face2face 
meeting that the priority level is too low...

when i originally proposed the checkpoint which evolved into the current 
UAAG 9.2, in a post archived at

(long URI warning!)
<http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0128.html>

i accorded it a P1, and backed my claim with a series of problem 
statements, as well as providing several techniques....  for the record, 
here is my original iteration of the checkpoint:

quote
   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]
unquote

note that the post referred to above was an attempt to address the problems 
posed by both the submit-on-enter functionality common in graphical desktop 
user agents, as well as the problems posed by form controls that lack an 
explicit submission mechanism and which are driven by either HTML4 event 
handlers or some other scripting language that caused the value defined for 
the form control to be submitted OnChange or via a "function 
switchpage(select)" type script -- the infamous "naked list box" 
scenario...  not long after submitting the above-referenced post, i 
concluded that the 2 issues -- while undeniably related -- were 
significantly different to warrant the proposal of a discrete checkpoint 
which addressed the action a user agent performs when it encounters a form 
control (such as the "naked list box") which lacks an explicit submission 
mechanism, and which relies upon a script to automatically submit one of 
the predefined values for that form control in response to user interaction 
with that form control....

(long URI warning!)
<http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0129.html>

the reasoning behind my proposed split was that it is one thing to 
inadvertently submit an incomplete form--due either to an unconscious user 
error or the lack of an orientation mechanism that enables the user to know 
that he or she is only in form control X of Y, when the form is marked up 
so as to visually apportion relative importance to form controls within the 
form, even though an explicit submission mechanism has been 
encountered--and "naked" form controls, which lack an explicit submit 
mechanism, and which rely upon events/scripts to execute an OnChange event...

the working group as a whole, however, determined that the problems posed 
by indirect submission slash auto-submission did not make it *impossible* 
for certain classes of disabled users to use forms or to interact with 
pages that use a pseudo-form in conjunction with either an HTML4 event 
handler or an otherwise scripted OnChange slash function switchpage(select) 
redirection mechanism, but that it did make user agents that support 
indirect submission of form content and scripted pseudo-forms when used in 
conjunction with adaptive technologies extremely difficult, disorienting, 
frustrating, and discouraging, which is why the working group resolved to 
accord checkpoint 9.2 a P2, although i have consistently insisted (and i am 
not the only one to have done so) that this is a  P1 requirement, for in 
the case of the inadvertent submission of form content, it *is* impossible 
to undo the inadvertent submission...  one very real scenario is that, as a 
result of inadvertent submission of form content, a user's experience of a 
site *after* the submission of the form content may be much different than 
it would be if the form had been completely filled out, thereby making it 
impossible for the user to return to, review, or use the original 
content...  moreover, if there is no readily available mechanism for 
resubmitting the requested information, or if the request was a "one-shot" 
event, then it is impossible for the user in question to step back and undo 
what should never have been done in the first place -- submission of form 
content without the user's knowledge or the automatic submission of form 
content simply OnChange...

there is a digest of URIs pertaining to the discussion of this checkpoint 
and the problems it is intended to address located at:

(long URI warning!)
<http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0143.html>

in which i reproposed what was then UAAG 10.6

i still firmly believe that the checkpoint should -- as i originally 
proposed it -- encompass ALL forms, regardless of the authoring practice 
that spawns them...  the vast majority of pseudo-forms aren't difficult to 
detect -- most use either HTML4 event handlers, a "function 
switchpage(select)" type script, an ActiveX object, a VBScript, or a 
DirectDOM Weblet, as all have defined methods to invoke this functionality 
(submit on ENTER, open ActiveX control, execute VBScript, etc.

i also think that it rises to the level of P1, but that's a battle for 
another day...  as for whether or not it is exclusively a page authoring 
problem, that is--to a great extent--a moot point, as far as i am concerned 
(at least for the purposes of this conversation) as it addresses a problem 
that is (a) endemic and (b) will not soon disappear from the 
web...  encouraging page authors to be more responsible and to use standard 
routines is a laudable and necessary effort, but the point of UAAG 1.0 is 
to improve access to the web as it is today, as well as ensuring that, as 
"newer" technologies are implemented, they are exposed to the user in an 
accessible manner and/or that the information contained in the source is 
output to the user in a usable form...

in summation, rich, i'd appreciate your reviewing the problem statements 
included in the archived posts referenced above, and then justify the 
lowering of the priority for checkpoint 9.2?

thanks,
         gregory.

At 02:44 PM 4/25/00 -0400, schwer@us.ibm.com wrote:
>I would like to register an objection to the resolution of Issue 243. I
>believe that checkpoint 9.2 should be a P3 requirement rather than a P2
>requirement because this is a content authoring problem that effects
>usability. User Agents should not be required to correct poor content as a
>disability requirement. This creates an undue burden on user agents. I do
>not feel this recommendation should go forward with this as a P2
>requirement.
>
>Does anyone else agree with this?

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

Received on Thursday, 27 April 2000 14:12:59 UTC