WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Accessible Form Validation Errors

for

Number of posts in this thread: 20 (In chronological order)

From: Austin, Darrel
Date: Thu, Sep 02 2004 11:59AM
Subject: Accessible Form Validation Errors
No previous message | Next message →

I'm working on getting our contact form for our new web site as accessible
as we can get it to be.

Are there any best practices for creating accessible error messages when the
form is not valid?

For instance, when there's an error, here's what I'm displaying now:

==================================================* There is a problem with your submission. Please check the form below for
any errors (shown in bold red). Please correct the errors and resubmit your
message.

Your Name: * Name Required
[ text field ]
==================================================
I'm displaying a notice at the top stating an error, and then pointing out
the specific errors next to each field. It's a short form (4 fields) but are
there any suggestions as to how to make it a tad more accessible? I was
thinking of using a different error notice at the top that would explicitely
mention the specific fields with errors and link to their anchors directly.
Thoughts?

-Darrel

From: julian.rickards
Date: Thu, Sep 02 2004 12:08PM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

First of all, if you use the bold tag and the tag to produce bold
and red, using a screen reader, there will be no indication of this change
in appearance. Even if you used in place of bold, it wouldn't
really help much. Secondly, along the same lines, one of the WCAG items is
not to refer to color, however it is created (font, styles, graphic) because
it won't always be seen.

One method, although I wonder how usable it is, it to only display the item
that has an error such as the email address if it is not valid. This means
that the backend coding must be configured to "spit out" only problematic
fields. However, this can appear strange and with only 4 fields, it might be
too much effort.

Another suggestion is to add a message right at the top which states, "Your
email address is wrong, please correct it." and then the user knows exactly
what field to correct. You can use bold (strong), and colours but don't
refer to them.

-----------------------------------------------
Julian Rickards
A/Digitial Publications Distribution Coordinator
Publication Services Section,
Ministry of Northern Development and Mines,
Vox: 705-670-5608 / Fax: 705-670-5960


From: Austin, Darrel
Date: Thu, Sep 02 2004 1:39PM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

> First of all, if you use the bold tag and the tag to
> produce bold and red, using a screen reader, there will be no
> indication of this change in appearance.

Right. I'm using STRONG for the bolding. The color is done via CSS, but
that's just an added visual for those that can see it. What's more important
is that the error is there.

Oh...actually, I probably didn't explain that right. I'm not just using
color/strong to indicate the errored-out field. I'm actually placing an
error message in the label of the field that had the error. The error
message, itself, is styled.

> One method, although I wonder how usable it is, it to only display
> the item that has an error such as the email address if it is not
> valid. This means that the backend coding must be configured to "spit
> out" only problematic fields. However, this can appear strange and
> with only 4 fields, it might be too much effort.

Hmm...an interesting thought. I've seen it done that way before. While that
is perhaps a bit more accessible, I do think it is a bit less usable having
the form actually change.

> Another suggestion is to add a message right at the top which states,
> "Your email address is wrong, please correct it." and then the user
> knows exactly what field to correct. You can use bold (strong), and
> colours but don't refer to them.

That's what I was thinking. Again, for this short form, It's probably not a
big deal. But if the form is 20 items, having to tab through each one to
find out which ones errored out would be a pain, so, yea, I think
explicitedly stating the fields with errors at the top is the way to go.
Would adding anchor links be overkill?

-Darrel

From: julian.rickards
Date: Thu, Sep 02 2004 1:51PM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

Actually, that's a great idea: adding a link after the "notification text"
to jump directly to the field in error seems a great idea!

Jules

From: ED COHEN
Date: Thu, Sep 02 2004 2:11PM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

Hi,
What about preforming error checking as one tabs from field to field? An error message could come up immediately. Closing the error message would return the user to the field that needs attention.
Ed
>>> = EMAIL ADDRESS REMOVED = 9/2/04 2:39:22 PM >>>

> First of all, if you use the bold tag and the tag to
> produce bold and red, using a screen reader, there will be no
> indication of this change in appearance.

Right. I'm using STRONG for the bolding. The color is done via CSS, but
that's just an added visual for those that can see it. What's more important
is that the error is there.

Oh...actually, I probably didn't explain that right. I'm not just using
color/strong to indicate the errored-out field. I'm actually placing an
error message in the label of the field that had the error. The error
message, itself, is styled.

> One method, although I wonder how usable it is, it to only display
> the item that has an error such as the email address if it is not
> valid. This means that the backend coding must be configured to "spit
> out" only problematic fields. However, this can appear strange and
> with only 4 fields, it might be too much effort.

Hmm...an interesting thought. I've seen it done that way before. While that
is perhaps a bit more accessible, I do think it is a bit less usable having
the form actually change.

> Another suggestion is to add a message right at the top which states,
> "Your email address is wrong, please correct it." and then the user
> knows exactly what field to correct. You can use bold (strong), and
> colours but don't refer to them.

That's what I was thinking. Again, for this short form, It's probably not a
big deal. But if the form is 20 items, having to tab through each one to
find out which ones errored out would be a pain, so, yea, I think
explicitedly stating the fields with errors at the top is the way to go.
Would adding anchor links be overkill?

-Darrel

----
To subscribe or unsubscribe, visit http://www.webaim.org/discussion/

From: Austin, Darrel
Date: Thu, Sep 02 2004 2:21PM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

> What about preforming error checking as one tabs from field to field?

Client side checking is on our to-do list. We're using .net and .net's built
in client side sripting isn't the most browser agnostic, so we've put that
on hold for later. Good idea, though, and I guess this is a general
accessibility issue...do folks that use assistive devices like screen
readers enable javascipt? There seems to be more annoying use of javascript
these days than good. ;o)

-Darrel

From: julian.rickards
Date: Thu, Sep 02 2004 2:29PM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

Just as much as Windows is popular for sighted users, Windows is popular for
JAWS users too. Furthermore, just as much as IE is popular for sighted
users, IE is popular for JAWS users too. Therefore, most people who need
screen reader technology use JAWS as a layer on top of IE and Windows. It is
my understanding that most JAWS users have not disabled JavaScript in IE
(although it is possible to do) and therefore, most JAWS users encounter
JavaScript. Therefore, it is not the screen readers that enable/disable
JavaScript but the underlying browser.

The question then is, can users of screen readers work with pop-ups and
other JS features. Not always, especially if the JS functions, such as
menus, require the use of a mouse. Pop-up alerts, such as those encountered
during form validation may not be problematic for screen reader users but I
would prefer someone with more experience to comment on that.

Jules

Jules

From: Mike Moore
Date: Fri, Sep 03 2004 8:10AM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

Darrel,

It looks like your error message indicates that the error will be displayed
in bold red. To make this more accessible include something other than just
color to indicate the error. Since you are already using an asterisk to
indicate a required field, there are a couple of things that you can do:
Add a second asterisk or the word error to the lable for the problem input.
An even more helpful solution, assuming programming support would be to
provide a link directly to the field where there is an error.

I am assuming that you are using label tags arround the inputs.

Mike

From: Mike Moore
Date: Fri, Sep 03 2004 8:14AM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

"What about preforming error checking as one tabs from field to field? An
error message could come up immediately. Closing the error message would
return the user to the field that needs attention."

Actually I would discourage this practice - immediate feed back on each
field can be disorienting and frustrating.

Mike

From: Lisa Pappas
Date: Fri, Sep 03 2004 8:18AM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →


Darrel Austin posted: Are there any best practices for creating accessible error messages when the form is not valid?

Darrel, I found the WASP tutorial on accessible forms, advanced portion, extremely helpful in this regard. Visit
http://webstandards.org/learn/tutorials/accessible-forms/03-accessible-forms.html

To be both accessible and usability-friendly, you could try retaining the good data, and presenting only the incorrect fields with links to correct them.

In our web-based software, the applications present a pop-up stating the error; I'm lobbying to get the same form presented, with the error description at the top, and a link to the fields that need attention.

Hope this helps!

-Lisa

===================Lisa Pappas
accessibility analyst
SAS Institute, Inc.
919.531.0980
= EMAIL ADDRESS REMOVED =
==================="The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect."
-- Tim Berners-Lee, W3C Director and inventor of the World Wide Web

From: Mike Moore
Date: Fri, Sep 03 2004 8:31AM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

"The question then is, can users of screen readers work with pop-ups and
other JS features. Not always, especially if the JS functions, such as
menus, require the use of a mouse. Pop-up alerts, such as those encountered
during form validation may not be problematic for screen reader users but I
would prefer someone with more experience to comment on that."

When using java-script it is necessary to make all features keyboard
accessible - not just for those on screen readers but for anyone who must
depend upon keyboard navigation, this includes people with motor/physical
disabilities as well. This is a requirement of both WCAG guidelines and sec
508.

Next turning to the question of pop-ups - unrequested pop-ups are very
disorienting for people using screen readers as well as those with cognative
disabilities. If the error message opens in a new window the user should be
warned that a new window will be opening - difficult to do in the context of
an error message - and then must have an easy method for closing the window.
If the error message "pops up" on the existing page then a screen reader
will start reading the item over again - this behavior is best tested using
a screen reader.

All client side error checking must be backed up with server side
verification. I prefer to complete error checking, client and server side,
once the form is completed and the submit button is activated. I then
provide the user feedback that indicates either successfull submission, or
an indication of specific errors which must be corrected prior to
resubmission. This provides a clear flow of action without any surprises to
the user. Testing with users using a variety of assistive technologies has
indicated that this method works well for everyone.

Mike

From: julian.rickards
Date: Fri, Sep 03 2004 11:00AM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

"When using java-script it is necessary to make all features keyboard
accessible - not just for those on screen readers but for anyone who must
depend upon keyboard navigation, this includes people with motor/physical
disabilities as well. This is a requirement of both WCAG guidelines and sec
508."

--

Agreed.

------

"If the error message opens in a new window the user should be
warned that a new window will be opening - difficult to do in the context of
an error message - and then must have an easy method for closing the window.
If the error message "pops up" on the existing page then a screen reader
will start reading the item over again - this behavior is best tested using
a screen reader."

--

Is there a distinction between JS alert pop-ups and new window pop-ups? In
many cases, some form of message may be provided to the user regarding the
opening of a new window but I don't think a warning is possible for JS alert
messages? I believe alert messages are keyboard accessible because the
OK/Cancel/Close buttons may be closed using a keyboard.

Jules

-----------------------------------------------
Julian Rickards
A/Digitial Publications Distribution Coordinator
Publication Services Section,
Ministry of Northern Development and Mines,
Vox: 705-670-5608 / Fax: 705-670-5960

From: Mary Martinson Grossnickle, Martinson Training
Date: Fri, Sep 03 2004 2:28PM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

"Next turning to the question of pop-ups - unrequested pop-ups are very
disorienting for people using screen readers as well as those with cognative
disabilities."

Another issue is for people using screen magnifiers. When a pop-up error
window occurs, it's usually not in the visible portion of the screen that a
person with a screen magnifier is seeing. In my experience doing usability
testing, the user tries to do something, and hears the beep indicating that
they can't go on. Sometimes the person knows this means an error window has
appeared somewhere on the screen; then the search begins to find the error
window. Sometimes the user doesn't realize what the beeping means, and often
will just close the browser and start over.
Mary


----
To subscribe or unsubscribe, visit http://www.webaim.org/discussion/

From: Hoffman, David
Date: Wed, Sep 08 2004 1:49PM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

My colleagues and I have developed a guideline document for handling
accessible and usable form validation errors. Lisa Battle and I even
discussed it as part of our UPA 2004 presentation: "Design Patterns and
Guidelines for Usable and Accessible Web Applications" -- by Lisa Battle and
David Hoffman. The guidelines use a diverse variety of techniques for
ensuring that different types of users will be aware of the existence and
number of errors, be able to easily navigate to the errors, and have easy
access to all associated directions and cues. The outline of the document is
as follows:

Description
Guidelines for Use
Preventing Errors
Ensuring that Users are Aware of the Existence and Number of Errors
Ensuring that Users Can Find Errors Easily
Providing Explicit Information and Helpful Wording for Error
Messages
Presenting Errors that Involve Conflicts Across Pages
Interaction Requirements
Standard Approach
Alternative Approach
Other Accessibility Requirements
Keyboard Navigation
Coding Tips
Related or Associated Controls

The following are a sampling of some of the interaction requirements:

Title Bar Message: An error message is added to the page title (displayed in
the Windows title bar) prior to any other title bar text. The message
wording makes the user aware of the existence and number of errors (for
example, "1 error on page", "2 errors on page"). If there are no errors on
the page, no message is included in the title bar. Including this
information in the page title ensures that blind users will hear the message
when the page is loaded and on-demand, whenever they choose to confirm their
location.

Error Summary Message: An error message is added to the screen immediately
below the page heading. The message uses a specially defined error message
style. The error message style is attention-getting, and uses red because
red is associated with errors. An optional graphic may be displayed to the
left of the message, but the message itself is text to ensure that low
vision users can read it. The message wording makes the user aware of the
existence and number of errors, using a complete sentence (for example,
"There is 1 error on this page.", "There are 2 errors on this page."). If
there are no errors on the page, no error summary is displayed. There is a
tab stop on this message so that a user can tab to it.

List of Errors: A bulleted list of errors appears immediately below the
error summary message. There is one list item for each error.

Error Links: Each item in the list of errors is a hyperlink. Selecting the
link takes the user directly to the field where the error occurred.
----------

If there is interest, we would consider preparing an article to offer to
WebAIM on the topic.

Take Care,
David

From: Hall, Kevin (K.M.)
Date: Wed, Sep 08 2004 3:26PM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

David,

That sounds like something that would be very valuable. There are many points in the ongoing debate about best practices for handling form submission errors that could use thorough analysis. I hope that your coding tips will include details on how to create scripts that will help users fill out forms easily while degrading gracefully in browsers that do not support JavaScript.

I'm also very interested in your take on the placement of error messages and handling the problem of long forms with many errors. If the list of errors is listed above a long form what is a good balance for indicating errors at the appropriate form element without being too redundant? Should there be one or more links back to the error list from the form? I've seen a number of conflicting ideas on all of these and it would be great to see how you have addressed this tough issue.

Regards,
-Kevin Hall

From: Strange, Lainie
Date: Thu, Sep 09 2004 7:37AM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →


I think there would be a lot of interest on this list. I would
definitely vote for an article to be put together. Thanks, David, for
offering.

Lainie

From: liza.zamboglou
Date: Thu, Sep 09 2004 7:54AM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

*******************************************************************************************************************************************************
This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed.
*******************************************************************************************************************************************************

I also would be very interested in reading this article !!
Thanks
Liza

From: Randy Pearson
Date: Fri, Sep 10 2004 10:19AM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

> > One method, although I wonder how usable it is, it to only display
> > the item that has an error such as the email address if it is not
> > valid. This means that the backend coding must be
> configured to "spit
> > out" only problematic fields. However, this can appear strange and
> > with only 4 fields, it might be too much effort.
>
> Hmm...an interesting thought. I've seen it done that way
> before. While that
> is perhaps a bit more accessible, I do think it is a bit less
> usable having
> the form actually change.

I agree. We believe strongly in re-rendering the whole form, but using
styles and other techniques (mentioned in this thread) to draw attention to
the validation issues.

Consider a simple example like where you miss the required "City" field
while filling out your address. Perhaps you "missed" it because there was an
"Address Line 2" field into which you accidentally entered your city. If all
that gets re-displayed is the City field, you can't really fix the entire
problem. Plus you may not even realize what happened if all the fields are
not redisplayed, and think "I know I just typed my city, now why did this
(stupid) site not retain it?".

-- Randy

From: Randy Pearson
Date: Fri, Sep 10 2004 10:19AM
Subject: Re: Accessible Form Validation Errors
← Previous message | Next message →

+1 on that. We would love to see such an article, whether a finished product
or for peer review.

-- Randy

> From: lainie.strange [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, September 09, 2004 9:37 AM
>
> I think there would be a lot of interest on this list. I would
> definitely vote for an article to be put together. Thanks, David, for
> offering.
>
> Lainie
> ----------
> From: = EMAIL ADDRESS REMOVED =
> Date: Wed, 8 Sep 2004 13:49:33 -0600
>
> My colleagues and I have developed a guideline document for handling
> accessible and usable form validation errors. Lisa Battle and I even
> discussed it as part of our UPA 2004 presentation: "Design
> Patterns and
> Guidelines for Usable and Accessible Web Applications" -- by
> Lisa Battle
> and David Hoffman. The guidelines use a diverse variety of techniques
> for ensuring that different types of users will be aware of the
> existence and number of errors, be able to easily navigate to the
> errors, and have easy access to all associated directions and
> cues. The
> outline of the document is as follows:
> snip...
> ----------
>
> If there is interest, we would consider preparing an article
> to offer to
> WebAIM on the topic.
>
> Take Care,
> David

From: Austin, Darrel
Date: Fri, Sep 17 2004 8:36AM
Subject: Re: Accessible Form Validation Errors
← Previous message | No next message

I'd like to thank everyone for their advice/feedback on the accessible form
errors issue. Lots of good ideas. Here's what we came up with:

http://www.courts.state.mn.us/contact/?pageID=151

(If you want to play with this, please select the 'Webmaster' email contact
so you're not sending messages to random folks here ;o)

What I did was the following:

- left the entire form displayed if there are errors
- added the error message to the individual form element
LABELS.
- added an error summary at the top of the form that lists
each error and links to the field in question
- explicitely labeled each field as 'required' or 'optional'
with text in the LABEL
- note that the page does have SKIP TO CONTENT links at the
very top (hidden with CSS unless you explicitely decide
to see them using the ACCESSIBILITY page option)

Things that I thought were great ideas but haven't implemented yet:

- listing the number of errors in the TITLE (GREAT idea!)
- putting the error message at the very top of the page
(if I did that, I'm thinking I'd duplicate the error
summary and place it off screen via css ...so screen
readers would see it)

If anyone wants to take a look at point out any other improvements, feel
free to do so.

Also, please note that the site, overall, may still need some accessibility
tweaking (namely in older browsers). We just launched and now I'm going in
and polishing evertying up so I'm sure you'll be hearing from me some more
in the near future.

Again, thanks for the great discussion on this topic.

-Darrel