WebAIM - Web Accessibility In Mind

E-mail List Archives

Accessible form errors...bug?

for

From: Jim Allan
Date: Jan 13, 2011 5:24PM

We have been using the following code to notify users of form errors
and help them navigate to the appropriate field (as per WebAim
http://webaim.org/techniques/formvalidation/#error, and Treasury Board
of Canada http://www.tbs-sct.gc.ca/clf2-nsi2/tb-bo/td-dt/ead-eca-eng.asp#cn_5.0_afwcie
among others)

essentially a heading is placed on the page stating from errors, and a
list of errors is generated with anchors that point to the form
control id.

<a href="#dob">Please enter the Birth Date.</a>
...
<label for="dob">
<acronym title="Date of Birth">DOB</acronym> (MM/dd/yyyy) : </label>
<input id="dob" name="displayBirthDate" type="text" value="" size="10" />

The problem:
this works in IE (6+) click on the link, the form control gets focus.
This works with screen readers (in IE). I have not tested with NVDA.

this does not work in Opera, Chrome, or Firefox. (which is a concern
as most of our users have vision).

Scenario:
The user clicks (or hits enter) when the anchor has focus. The screen
moves so the form control is at the top of the browser window, but the
control does not get focus. There is no cursor in the input box. I am
not sure where the focus is sitting. If I hit tab the focus jumps to
the next form control. if I hit shift-tab the focus jumps to the
previous control.
I turned on cursor browser (F7) to see if I can see where the cursor
lands when I follow the anchor to the form control id. The cursor
seems to be floating above the form control. When I follow the anchor,
the screen jumps, but there is no cursor on the screen. If I hit
left-arrow 2 times the cursor will appear in front of the form
control. If I hit right-arrow 1 time the cursor will appear at the
back of the form control.

Is this a bug in Opera, Chrome, and Firefox, or a bug in IE. Seems to
me IE has it right.
What do others think?

I tried some hackery, just to see what is going on. To me any of these
options is ugly.

1. <a href="#dob"><label for="dob">Please enter the Birth
Date.</label></a> - works in IE, Chrome, and Jaws (with IE)

2. <label for="dob"><a href="#dob">Please enter the Birth Date.</a>
</label> - works in IE, Chrome, Opera, and Jaws (with IE)

3. <label for="dob">Please enter the Birth Date.</label>
- works for all of the browsers. With a bit of styling to make the
error labels look like a link, users will know that they can click on
it and jump to the appropriate form control. It just seems wrong.
And, there are problems with Jaws, the screen reader. It announces the
text but not that it is clickable. So the user doesn't know there is
something to activate to take them to the error in question. A link is
announced by Jaws (and other screen readers) and has a visual
indication for all other users. If a Jaws user gets a list of form
controls, the labels listed at the top of the page (in the error list)
do not appear in the list. Only the last instance of a label that is
associated with an 'id' appears in the form control list. So, the
screen reader user has an additional burden. Anchors seem the best
solution for screen readers.

I have 4 partial solutions. Anchors do not work in FireFox. Labels
only are problematic for JAWS.

Anyone have a work around?

I LOVE consistent browser implementation and behaviors ;(

Jim Allan, Webmaster
Texas School for the Blind and Visually Impaired