- From: mark novak <menovak@facstaff.wisc.edu>
- Date: Wed, 26 Apr 2000 15:34:05 -0500
- To: schwer@us.ibm.com, Al Gilman <asgilman@iamdigex.net>
- Cc: w3c-wai-ua@w3.org
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