(unknown charset) Re: Forms & Screen Readers - repair strategies

Just a couple comments:

What I'd like to experience is a list of the problem fields at the top of
the returned page with each field name being an internal link to the
problem field.  Then I'd still like the full page to review.

What I've found happens sometimnes is that I'm not careful and maybe enter
all of my phone number in one edit box when the page actually wants it in
three.  And of course I didn't double check my entry before submitting.

To me this is also an example where data input checking before submission
can be of value.  Alert the user before he or she has answered 10
questions only to find out that eight were done incorrectly.



On Wed, 15 Aug 2001, Al Gilman wrote:

> 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 20:19:14 UTC