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 Wednesday, 26 April 2000 16:30:23 UTC