data error recovery, data persistence, and LD access to forms transactions

At 01:02 PM 2002-01-09 , Lisa Seeman wrote:
>thought on 2.7.
>I have trouble filling out forms when the memory of what has been filled out
>is not maintained though error checking.
>Let me explain that.
>say I have a large form to fill out. I press continue, and I get told that I
>am missing a digit on my zip code. I click on "go back to form"  and
>sometimes have to start from the beginning. This time I spell my password
>wrong in the second box....
>It often takes me five or six attempts, they have not used hidden variables
>to preserve the data.
>Can we require data permanence?
>
>All the best,
>Lisa
>

Thank you for this succinct statement of this dependency we must not overlook,
Lisa.

["and furthermore..." for the record associated rant]

Many disability groups, and LD especially, are subject to higher rates of
data-entry errors than the general public.  So they are more dependent [than
the general public] on how gracefully the technology helps the user recover
from data entry errors.  So this is at least a WCAG1.P3 concern (makes a big
difference), which may at times reach WCAG1.P2 levels of difficulty
(practically useless) and which may be a UAAG1.P1 (really important to fix)
matter for some forms applications.

The current standard practice where the browser refuses to save a
filled-in-form "for your security" is a violation of what should be
fundamental
business rules; that the user always has a right to save what they are
about to
send by way of a business transaction request _first_ under their own control
on their own computing facilities before ever sending to the server (which is
under the control of the other party to the deal).  

This is a disability issue because there are people with visual disabilities
where only digital records of their business activities are practical for them
as personal finance management resources.  Records on paper are P2 useless
unless in OCR font or barcode so as to be paper media digital records. 
Businesses today try to fix the broken customer service by having the server
return a printable transaction record, but the protocol is wrong, the user
deserves the capability to save a record of the filled in form prior to
transmission to the other party, and the printable acknowledgement is not the
same level of information as the form; you can't suck it into a spreadsheet or
personal finance program and have it understood as money, items, etc.

This is a protocol, and hence on PF worry list.  It is not necessarily
recognized as in the Web sphere because it is a UI level protocol which
includes what the browser does.  Part of the WAI job to re-assert "the whole
system that supports the people involved" as the Web sphere and get the
end-to-end usability right for all, finding the problems by caring about where
it is flat out unusable at times for some.

XForms is reported to do better at this.  We should see what we can do to get
examples user-tested with people with learning difficulties to check out that
it delivers the improvement at the bottom line.

Once again, visual disabilities do put a heightened load on the user's
cognitive processing of the process at hand.  So the user-friendliness of
recovery dialogs that deal with data-entry problems is something that is at
least a P3 concern to the visually impaired as well.  At least, this is how I
interpret the vigor with which Gregory pursues user-friendly design of
recovery-from-data-error iteration forms.  

While there are a few technique areas, such as overreliance on text, that tend
to put the visually impaired and learning disabled interests at odds, there is
a massive commonality of interest lurking just below the surface irritants. 
One could call it an undertow of visually impaired as 'ripple' or
curb-cut-effect beneficiaries from anything we can do to reduce cognitive
burdens in Web user processes.

Received on Wednesday, 9 January 2002 11:55:10 UTC