- From: mark novak <menovak@facstaff.wisc.edu>
- Date: Thu, 27 Apr 2000 10:51:16 -0500
- To: <schwer@us.ibm.com>
- Cc: w3c-wai-ua@w3.org
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