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 11:49:28 UTC