E-mail List Archives
Number of posts in this thread: 2 (In chronological order)
From: Gerard Corboz
Date: Aug 9, 2005 11:09AM
Subject: Best way to display form errors and explanatory text
No previous message | Next message →
Hi everyone
I'd like to ask some advice from webaim subscribers in regards to the
best way to display errors in an accessible HTML form and also how to
best handle explanatory text.
Many of the clients we deal with are government based and invariably
have a lot of explanatory and other legislative text on the form that
must be read. In many cases the text in question is not a label or
can't be associated with any particular field. Also, in many cases,
between fields there is some text which when tabbing through a form is
skipped. Any suggestions on how to handle this i.e. ensure that all
text is read and text between fields is also read through the process
of filling the form in.
I also wanted some advice on the best way to present errors in an
accessible way i.e. wait until the user submits the form before letting
them know they have committed an error or failed to complete a
question, use pop up menus, dynamically mark the field as incomplete
(inaccessible but just an example of one way to display form errors).
Regards
Gerard Corboz
-----------------------------------------------
PERFORM Information Design Solutions
ph: 6214 0968
fax: 6214 0964
mobile: 0402 236 358
http://www.perform.net.au
Join our mailing list - http://www.perform.net.au/News/
Perpetro Pty Limited ABN 30 112 219 271
-----------------------------------------------
From: Jukka K. Korpela
Date: Aug 9, 2005 11:09AM
Subject: Re: Best way to display form errors and explanatory text
← Previous message | No next message
On Mon, 8 Aug 2005, Gerard Corboz wrote:
> Many of the clients we deal with are government based and invariably have a
> lot of explanatory and other legislative text on the form that must be read.
That's certainly a major inaccessibility. Attempts at trying to
accommodate such features into a web page design and implementation
tend to make the problem worse, since it helps the decision makers to
avoid solving the problem.
Ideas of lots of legalese that "must be read" are simply wrong. I don't
think that even lawyers that write them actually believe that people can
be made to read them; but they think that they can base some case on the
claim that people should have read them.
There is absolutely no way to force people to read such texts. You might
manage to force them to lie they have read them.
> In many cases the text in question is not a label or can't be associated with
> any particular field.
That's not a problem. A form may contain text related to the form as a
whole. Alternatively, it might be preceded by such text. The choice
between the two is not a big issue, but perhaps it is better that the form
is opened (making, for instance, a speech browser say "start of form one")
only when the real interaction with the user is about to begin.
> Also, in many cases, between fields there is some text
> which when tabbing through a form is skipped.
That could indeed be a problem in a nonvisual user interface, but in such
usage, tabbing through a form would hardly work anyway. Instead, the user
needs to let the browser read the form content sequentially, so that form
fields initiate prompting for user input. In a visual browser, tabbing
through a form can be essential, and text between fields can indeed be
skipped - just as a user can skip, consciously or unconsciously, parts of
textual content he is not interested in.
> Any suggestions on how to handle this
Tough question. The real problem is with people who have decided that
bulky texts need to be included. I really cannot tell how to handle them
in each case, or whether the problem can be solved at all in your case.
> i.e. ensure that all text is read and text between fields is also
> read through the process of filling the form in.
It cannot be ensured. Simple as that. The conclusions might be much more
difficult.
It is certainly possible to _try_ to force people to read the bulky texts.
This would create additional accessibility problems. I think we all know
the stamp-size scrolling windows, containing text that amounts to a
booklet, and the button that says "I've read the terms and I accept them".
Of course most people learn to click on the button without reading
anything, since that's the only way to do many things. But for the
first time - and everyone has a first time - it can be a real
challenged. Moreover, there are people with a special kind of disability,
a moral one: an obsession of not lying. The disability also exists in
milder forms, forcing a person spend quite some time in trying to avoid
lying in situations where "everyone else" lies.
> I also wanted some advice on the best way to present errors in an accessible
> way i.e. wait until the user submits the form before letting them know they
> have committed an error or failed to complete a question, use pop up menus,
> dynamically mark the field as incomplete (inaccessible but just an example
> of one way to display form errors).
That contains quite a many separate questions. For one thing, it is not
automatically most accessible to have all errors reported only after
submitting a form. On the contrary, it is normally best to report them as
soon as possible. This is especially important to users with cognitive
disabilities; they may have hard time in trying to figure what an error
message relates to, unless they get it as an immediate response to
doing something "wrong". But there are technical problems with this,
due to the simplistic nature of HTML forms at present.
As a rule, I would say that it improves accessibility to have immediate
error checks, with errors alerted via JavaScript popup windows. Naturally
you need to have the same or stronger checks server-side for several
reasons, including the fact that JavaScript might be disabled in the
browser. This approach creates problems to people who have JavaScript
enabled and who yet get seriously disturbed by the popup windows (either
visually or due to their effect on a speech browser). But what else could
you do?
Sometimes the problem can be avoided by dividing the form into smaller
pieces, so that submitting a form causes the data to be checked
server-side and a new form with additional data presented to the user,
etc. In that case, you can present the error messages as normal content
before the new form. However, this is a mainly a solution to problems with
very large forms. For a normal-size form, such splitting - though it may
solve some problems - would be irritating and distracting to many people
who could fill out the original form easily.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/