Re: Formal Objection to Checkpoint 9.2

>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?

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.

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 15:01:46 UTC