Re: Formal Objection to Checkpoint 9.2

Gregory, did you read my last proposal for 9.2? I think you may have missed
it.

Rich


Rich Schwerdtfeger
Lead Architect, IBM Special Needs Systems
EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost


"Gregory J. Rosmaita" <unagi69@concentric.net> on 04/27/2000 01:15:56 PM

To:   Richard Schwerdtfeger/Austin/IBM@IBMUS, w3c-wai-ua@w3.org
cc:   User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>
Subject:  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 15:00:22 UTC