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 Wednesday, 26 April 2000 18:13:05 UTC