Re: Formal Objection to Checkpoint 9.2

aloha, rich!

i may well have, due to the connectivity problems that delayed the 
transmission of the message which was recently posted to the UA mailing 
list, but which was composed immediately following receipt of your first 
iteration of your formal objection...

i will use the mail archive to peruse the thread, and comment if i deem 
that i have anything further to contribute to the discussion...

gregory.

At 03:00 PM 4/27/00 -0400, schwer@us.ibm.com wrote:
>Gregory, did you read my last proposal for 9.2? I think you may have missed
>it.
>
>Rich
>
>"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?

Received on Thursday, 27 April 2000 15:19:37 UTC