Re: Formal Objection to Checkpoint 9.2

At 03:00 PM 2000-04-26 -0400, 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.

AG::

Maybe you don't need to know if the actual SUBMIT was from a script
activated by an even on the SUBMIT element.  In the sense that a compliant
User Agent would allow the user to defend herself from that by leaving
scripts off, period.  Also see next...

But I understand that without the Views and Events reform in the DOM, it
could get sticky to figure out where the 'submit now' message came from
when you are down in the bowels of the HTTP implementation.  In this case I
would volunteer to start considering that the option might be to "confirm
all FORM submissions, period."  Then the check could be in the deep layer
and not mess with backtracking through the rest.  Not so hot, but (what do
others think?) still a whole lot better than nothing. 

>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?
>
>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.
>
>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 Wednesday, 26 April 2000 15:25:15 UTC