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 Tuesday, 25 April 2000 18:06:15 UTC