Re: Forms & Screen Readers - repair strategies

At 01:41 PM 2001-08-15 , Patrick Burke wrote:
>This *usually* works the way you describe. I.e., screen readers can read 
>text in the input fields, status of radio buttons, etc.
>
>The best way to handle form errors is a different topic.
>
>The coolest thing would be to get a page with only the error fields listed. 
>In other words:
>
>"We're sorry, no data was entered in field(s) which is/are required for 
>this form:
>
>Zip Code: _____   "
>
>This would be Much much more efficient for a screen reader user than having 
>to hunt thru the entire form to try to figure out what went wrong.
>
>On the other hand I can think of situations where one might want to read 
>the full form in context. For that situation, maybe the fields with errors 
>could be marked with a unique (text) character or string.
>

I think it is best to provide both the accelerated navigation through the
problem spots and the chance to review the whole deal before committing to it.

Things to look at in this regard would include TABINDEX and CLASS marks
indicating the severity of exceptions thrown by the type checking.  But it is
also possible to do it in legacy friendly code with a tour built using
explicit
internal hyperlinks.  The problem is that the kneejerk reaction would be to do
this with color and icons.  Even if this is done 'semantically' with severity
classes, that doesn't make the hotspots navigable as a tour unless the classes
are standardized (which they aren't).  So until TABINDEX works better or we
have some standard CLASSes for this, the simplest thing is to give a
boiled-down form with just the problems, and be sure to offer [or always give]
a confirmation copy with all the data reiterated as is after all checks
passed.  Either you have a liberal cancellation policy or you do the
confirmation step before committing the transaction.  There has to be a
Conventional Wisdom on this in the eRetail industry, even if it isn't talked
about.

Yet another approach is that the form returned for the repairs has the fields
that passed checking as document contents but not as form controls.  This
means
that tabbing through the form controls will do the tour of the problem items
and only those items.  Of course, this means that you have to offer the user a
DoIt submit button and a different MoreChanges submit button in the end. 
That's clunky for the visual user.  Go figure.  

The problem Patrick posed is a good one.  I don't presume to have the answer. 
But the above ideas give you a rough of the vicinity in which to look for a
solution.

Al

>Patrick
>
>At 10:06 AM 8/15/01, Brooke Dine wrote:
>>Hello All:
>>
>>Can screen readesrs read inputted text that users insert into online 
>>forms?  Specifically, once someone has entered information (personal, etc) 
>>into the form, hit "Submit" and had the form returned with a "You haven't 
>>filled out all of the required fields."  Would the screen reader read both 
>>the field names and the text within the fields as the person scrolled 
>>through the form to determine what is missing?
>

Received on Wednesday, 15 August 2001 14:28:37 UTC