Re: Formal Objection to Checkpoint 9.2

Ian, I would like to make the following proposal and discuss this in
today's UA telecon:

Modify checkpoint 9.2 techniques to say that "Prompting the user to confirm
all form submission, triggered indirectly or directly, will satisfies this
checkpoint. This feature should be a configurable option."

If this were the case I would agree to have this as a P2 and leave the
checkpoint as stated. This leaves it up to the user agent to implement the
more difficult mechanism of determining if the form was submitted
indirectly or to do it in what I think is more reliable way by prompting
the user for any form submission as a configurable feature. This would be
the minimum case to satisfy this checkpoint and preserves the wording of
the current checkpoint.

I submit this in the interest of submitting the guidelines without an IBM
objection to the director as well as to mediate an acceptable solution for
developers as well as users.

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


menovak@facstaff.wisc.edu (mark novak)@w3.org on 04/27/2000 10:51:16 AM

Sent by:  w3c-wai-ua-request@w3.org


To:   Richard Schwerdtfeger/Austin/IBM@IBMUS
cc:   w3c-wai-ua@w3.org
Subject:  Re: Formal Objection to Checkpoint 9.2



At 10:57 AM 4/27/00, <schwer@us.ibm.com> wrote:
>That's ok. I don't agree with yours either.

no problem, just expressing my disagreement as to the
implied degree of difficulty


>
>The approach you talk about is from a JavaScript programmers perspective
>which is not a complex user agent like IE.
>
>The solution needed effects how information about what is activated boils
>down from a variety of scripting engines, programming environments,
>plugins, etc. that are attached to a browser's DOM.   It then has to
>disseminate down to the layers of user agent code that in effect issue a
>post and fire off a message to the user that "you did not know this but
you
>just did a form submit or server function http post." Adding to the
>difficulty is being able to know all the plugin environments that can
>programmatically perform the task of monitoring a DOM and doing
submitions.
>User Agent developers do not have crystal balls.
>
>Correctly determining what was done directly or otherwise is a convoluted
>mess that I would not want to pollute user agents with. Also, the
>determination of what was submitted directly cannot be done at the
>authoring layer so this is a different type of "web programming" than what
>you are talking about.
>
>If I read you correctly perhaps it should be the task of the page author
to
>handle this since the JavaScript effort is so simple.
>
>I thought Al's proposal was much more reasonable.

i don't have the cycles to discuss this point any longer, suffice it to say
i don't agree that this is a technology-limited problem.

as I read checkpoint 9.2, it asks the UA to "prompt the user to confirm
any form submission triggered indirectly....."which I feel is a reasonable
P2 request.


you're very orginal formal objection post asked:

>"Does anyone else agree with this."

and i'm just stating that I disagree, both allowed in the context of this
discussion.

regards,

mark

>
>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
>
>
>menovak@facstaff.wisc.edu (mark novak) on 04/26/2000 05:15:35 PM
>
>To:   Richard Schwerdtfeger/Austin/IBM@IBMUS
>cc:   Al Gilman <asgilman@iamdigex.net>, w3c-wai-ua@w3.org
>Subject:  Re: Formal Objection to Checkpoint 9.2
>
>
>
>At 4:35 PM 4/26/00, <schwer@us.ibm.com> wrote:
>>Lets not stop at JavaScript, any extension that accesses the DOM will
fall
>>into this mess: ActiveX objects, VBScript, DirectDOM Weblets, etc.
>
>MN:  sorry, still don't buy your argument, no matter what technology
>you wish to toss at 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
>>
>>
>>menovak@facstaff.wisc.edu (mark novak)@w3.org on 04/26/2000 03:34:05 PM
>>
>>Sent by:  w3c-wai-ua-request@w3.org
>>
>>
>>To:   Richard Schwerdtfeger/Austin/IBM@IBMUS, Al Gilman
>>      <asgilman@iamdigex.net>
>>cc:   w3c-wai-ua@w3.org
>>Subject:  Re: Formal Objection to Checkpoint 9.2
>>
>>
>>
>>see comments at MN below:
>>
>>At 3:00 PM 4/26/00, schwer@us.ibm.com wrote:
>>>>Would you expand a bit on the burden?  I don't yet understand why
either
>>>>inserting a computed SUBMIT element or requiring confirmation [when the
>>>>user exercises this configuration choice] is such a big deal.  Both
>>>options
>>>>are open to you.
>>>
>>>Sure. In a browser the number of layers between the point at which
>>>activation occurred to the point at which the activation is actually
>>>activated at the posting layer is significant. Furthermore this action
>>>likely occured from a JavaScript in which case you need to determine if
>>>this actually was something requested by a submit or not. You also need
>to
>>>know if an actual submit in a form was activated from JavaScript.
>>>
>>>The result is a mess which convolutes the code to make this happen. You
>>>have to somehow pass analysis information down to the layer at which the
>>>submission occurs and then activate a message back in the GUI to ask the
>>>user if this action was something the user really wanted to occur. I am
>>>also in doubt as to the reliability of the analysis made. For example,
>the
>>>press of a next button on a web site may not only bring you to a new
page
>>>but it may also send privacy information back to the host system. This
is
>>>something we may not want either do we stop this from occuring as well
>and
>>>how do we know when to do this or not?
>>
>>MN:  hmnn, having done web software development, including Javascript
>>development, I have to disagree with the implied level of difficulty
>>in this operation.
>>
>>>
>>>Therefore I feel the repair of this "manhole", (good analogy), is the
>>>responsibility of the developer because this is an authoring usability
>>>issue. This problem may also as frustrating to non-disabled users as
>well.
>>>
>>>I am not saying this is a problem but it is a problem for all users and
>it
>>>is a nice feature to have for disabled users as it would be for
>>>non-disabled users. This is why it should be a P3.
>>
>>MN:   agree this is a problem for "all users", but also agree it taps
>>PWD much more seriously, and merits a P2 level.
>>
>>
>>
>>>
>>>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
>>>
>>>
>>>Al Gilman <asgilman@iamdigex.net>@w3.org on 04/25/2000 06:11:16 PM
>>>
>>>Sent by:  w3c-wai-ua-request@w3.org
>>>
>>>
>>>To:   w3c-wai-ua@w3.org
>>>cc:
>>>Subject:  Re: Formal Objection to Checkpoint 9.2
>>>
>>>
>>>
>>>At 02:44 PM 2000-04-25 -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.
>>>
>>>AG::
>>>
>>>Content authoring problem - NOT:
>>>
>>>Neither HTML 4.01 nor WCAG requires the presence of an explicit SUBMIT
or
>>>BUTTON elment in a FORM.
>>>
>>>Nothing in the HTML 4.01 Recommendation discourages or prevents User
>>Agents
>>>from submitting a FORM on <ENTER> when the focus is in the FORM but not
>on
>>>a SUBMIT or BUTTON element.
>>>
>>>General usability issue - NOT:
>>>
>>>Elsewhere in the UAAG we advocate adhering to Operating System
>conventions
>>>for the User Interface.  The short-cut behavior happens to be the
>>Operating
>>>System convention in the UI conventions of the dominant OS.  It is in
>fact
>>>a usability convenience for some users, and especially for some users
>with
>>>motor disabilities.  So eliminating the dangerous behavior is not "just
a
>>>general usability issue."  The ability to suppress the shortcut behavior
>>is
>>>a safety-of-operation issue for a specific disabled user class and the
>>>availity of the shortcut behavior is a P3 usability benefit for another
>>>class.  Hence the requirement that this be under user configuration
>option
>>>control.
>>>
>>>Note:  As a general rule, how much it affects usability for people
>without
>>>disabilities should not really be considered.  Ideally, it is the
>severity
>>>of dysfunction in the person-with-disability use case that sets the
>>>priority level, at least per my rough understanding of the current
common
>>>rating scheme among the three guidelines working groups.
>>>
>>>>User Agents should not be required to correct poor content as a
>>>>disability requirement.
>>>
>>>AG::
>>>
>>>Note:  Stated that flatly, I would have to disagree.  The standard for
>>>content that the User Agent Guidelines assumes should be somewhat lower
>>>than the standard asked for from content providers in the WCAG.  I agree
>>we
>>>need to be _very_ careful how we design the overlap bettween things
fixed
>>>in the author space and things fixed in the browser space, but there
>>>_should be_ an overlap.
>>>
>>>
>>>If you mean because it is a usability issue for non-PWD users, see the
>>>previous comment.
>>>
>>>>This creates an undue burden on user agents.
>>>
>>>Would you expand a bit on the burden?  I don't yet understand why either
>>>inserting a computed SUBMIT element or requiring confirmation [when the
>>>user exercises this configuration choice] is such a big deal.  Both
>>options
>>>are open to you.
>>>
>>>>I do not feel this recommendation should go forward with this as a P2
>>>>requirement.
>>>
>>>I understand you are following through in the way indicated at the F2F
>>>meeting.
>>>
>>>>Does anyone else agree with this[?]
>>>>
>>>
>>>Some mitigating factors -- other things that I think we should explore a
>>>bit more before turning this into a shoving match:
>>>
>>>The 'resolution' link from the issues list does not mention the [I
>believe
>>>consensus] draft rewrite to make it clear that this is a configuration
>>>option, not the only UI business rules that the UA implements.  Have you
>>>fully considered this aspect of the  resolution?  It is clearly true
that
>>>some visual users benefit from the shortcut.  But other less visual
users
>>>get bushwhacked by it.  The shortcut should be configurable _out_.
>>>
>>>Just from my personal experience coaching a few visually impaired web
>>>users, my experience would tend to bear out what Gregory has documented
>as
>>>the severity of this impact.  Of course he has more experience at this
>>than
>>>I.
>>>
>>>There is another dimension to 'impact' that the WAI consensus priority
>>>scheme doesn't address adequately.  This has to do with the intrinsic
>>>severity of the action which gets performed inadvertently.  Form
>>submission
>>>discloses personal information and deducts from your credit card.  This
>is
>>>something that has to be _safer_ than the average web browsing misstep.
>>>Hitting the browser 'back' function doesn't fix it.  That can be a
rather
>>>long process.
>>>
>>>I have to admit that I factor this dimension in, in my personal
>assessment
>>>of this checkpoint.  I know it's not on the books in the official
>>>definitions of the priorities.  But to me it is very real.  Looking at
>web
>>>interaction as a web of transactions, we need to do some "effects and
>>>criticality analysis" to go with our enumeration of "failure modes" to
>see
>>>how strongly protected various failure modes need to be.  This one is an
>>>open manhole cover among the varieties of web perils.
>>>
>>>Al
>>>
>>>>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
>>>>

Received on Thursday, 27 April 2000 12:42:51 UTC