E-mail List Archives
Thread: Accessible form errors...bug?
Number of posts in this thread: 7 (In chronological order)
From: Jim Allan
Date: Thu, Jan 13 2011 5:24PM
Subject: Accessible form errors...bug?
No previous message | Next message →
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
From: steven
Date: Fri, Jan 14 2011 2:12AM
Subject: Re: Accessible form errors...bug?
← Previous message | Next message →
Hi Jim,
I thought it was good practice to anchor to the label (or generally anything
preceding the form control) so as to be able to read the text prior to
knowing whether or not to fill out it's associated form control!?
By the way, it seems that your input is outside the label. Maybe placing the
within the label might yield better results for you.
Regards,
Steven
From: Lucica Ibanescu
Date: Fri, Jan 14 2011 7:27AM
Subject: Re: Accessible form errors...bug?
← Previous message | Next message →
Hi Jim, I suppose a bit of Javascript magic ( focus() ) is out of the
question?
Lucica
From: Sailesh Panchang
Date: Tue, Jan 18 2011 10:27AM
Subject: Re: Accessible form errors...bug?
← Previous message | Next message →
Jim,
1. Well a h<n> tag placed above the form or list of errors stating
form submission failed is helpful. I also suggest suffixing a
message like "- registration failed; Errors in form" to the page
title (title element) if that is possible.
2. Appending the error message within the label element might work in
some design situations but one should ensure that the original label
text is also retained as-is within the label element. I am not a
strong supporter of listing all violations in a list (of anchors) at
the start of the form. Is one expected to come back to the list in
order to find the next invalid field?
3. Some authors like to place an error-icon (img) next to every field
that fails validation. This is also a workable solution: the alt can
contain the error# and a brief error message. e.g. alt="Error #1: Last
name is absent" or "Error #2: Invalid email address". Else the alt
may contain just the error# and field name and the error message may
be within a span next to it styled distinctively. The error icon (img)
allows users of screen reader software to navigate from one invalid
field to the next and skip fields in between if they choose to.
4. An ARIA-alert with an error message that pops up as one tabs out
of a field that fails validation is another technique that is
useful. Admittedly it works with (some of) the latest assistive
technologies and browser versions only.
Sorry I did not address the differences in browser behavior you referred to.
Rightho,
Sailesh
From: Jim Allan
Date: Wed, Jan 19 2011 3:51PM
Subject: Re: Accessible form errors...bug?
← Previous message | Next message →
On Tue, Jan 18, 2011 at 11:23 AM, Sailesh Panchang
< = EMAIL ADDRESS REMOVED = > wrote:
> Jim,
> 1. Well a h<n> tag placed above the form or list of errors stating
> form submission failed is helpful. I also suggest suffixing a
> message like "- registration failed; Errors in form" to the page
> title (title element) if that is possible.
good idea. I think we can do that.
> 2. Appending the error message within the label element might work in
> some design situations but one should ensure that the original label
> text is also retained as-is within the label element. I am not a
> strong supporter of listing all violations in a list (of anchors) at
> the start of the form. Is one expected to come back to the list in
> order to find the next invalid field?
Right. the linked error message goes at the top of the page. The error
message is also injected into the label for the control in question.
This is server based, so there is a page refresh. I put the heading at
the top so folks with screen readers could easily jump back to the
error list for the next error. Some of the forms can be a bit long.
And it could be tedious to tab through looking for the errors. So we
provided users with many avenues to approach the task.
> 3. Some authors like to place an error-icon (img) next to every field
> that fails validation. This is also a workable solution: the alt can
> contain the error# and a brief error message. e.g. alt="Error #1: Last
> name is absent" or "Error #2: Invalid email address". Else the alt
> may contain just the error# and field name and the error message may
> be within a span next to it styled distinctively. The error icon (img)
> allows users of screen reader software to navigate from one invalid
> field to the next and skip fields in between if they choose to.
Also a good idea. We will talk about this.
> 4. An ARIA-alert with an error message that pops up as one tabs out
> of a field that fails validation is another technique that is
> useful. Admittedly it works with (some of) the latest assistive
> technologies and browser versions only.
>
> Sorry I did not address the differences in browser behavior you referred to.
The inconsistent browser behavior was my biggest concern. The way many
of the materials on the web, including mine, discuss how to handle
form errors do not work.
To me the expected behavior is that an anchor with an 'id' as the href
should take the user directly to the object with the 'id' and give it
focus (if possible).
Do you expect something different?
It's just surprising (though I have been doing this long enough that I
should know better) and disappointing that implementation for
something so simple is so poor across browsers.
Jim
> Rightho,
> Sailesh
>
From: Marco Maertens
Date: Wed, Jan 19 2011 9:42PM
Subject: Re: Accessible form errors...bug?
← Previous message | Next message →
Hi Jim,
This makes me think about the skip-navigation problem. Not sure whether
it's related, but it sounds suspiciously similar, and after all, they're
all anchor links. You might want to check this Communis article I found
via Jim Thatcher's site:
Communis Article: "Skip links: Chrome, Safari and Added WAI-ARIA"
http://www.communis.co.uk/blog/2009-06-02-skip-links-chrome-safari-and-added-wai-aria
Jim Thatcher's source article: "Skip Navigation Links"
http://jimthatcher.com/skipnav.htm
-Marco.
On 1/13/2011 19:25, Jim Allan wrote:
> 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
>
From: Sailesh Panchang
Date: Fri, Jan 21 2011 1:00PM
Subject: Re: Accessible form errors...bug?
← Previous message | No next message
Jim,
I think the href of an anchor cannot be used to set focus to id of an
INPUT control. That id is really meant for explicit association with
its label as you are well aware. Maybe if the href uses JS onclick
with set focus, then the form control will gain focus, and across
browsers too I imagine. The fact that href=id of form control works
in IE is possibly a quirk of IE.
Hope this helps.
Regards,
Sailesh Panchang
1/19/11, Jim Allan < = EMAIL ADDRESS REMOVED = > wrote:
> On Tue, Jan 18, 2011 at 11:23 AM, Sailesh Panchang
> < = EMAIL ADDRESS REMOVED = > wrote:
>> Jim,
>> 1. Well a h<n> tag placed above the form or list of errors stating
>> form submission failed is helpful. I also suggest suffixing a
>> message like "- registration failed; Errors in form" to the page
>> title (title element) if that is possible.
>
> good idea. I think we can do that.
>
>> 2. Appending the error message within the label element might work in
>> some design situations but one should ensure that the original label
>> text is also retained as-is within the label element. I am not a
>> strong supporter of listing all violations in a list (of anchors) at
>> the start of the form. Is one expected to come back to the list in
>> order to find the next invalid field?
>
> Right. the linked error message goes at the top of the page. The error
> message is also injected into the label for the control in question.
> This is server based, so there is a page refresh. I put the heading at
> the top so folks with screen readers could easily jump back to the
> error list for the next error. Some of the forms can be a bit long.
> And it could be tedious to tab through looking for the errors. So we
> provided users with many avenues to approach the task.
>
>> 3. Some authors like to place an error-icon (img) next to every field
>> that fails validation. This is also a workable solution: the alt can
>> contain the error# and a brief error message. e.g. alt="Error #1: Last
>> name is absent" or "Error #2: Invalid email address". Else the alt
>> may contain just the error# and field name and the error message may
>> be within a span next to it styled distinctively. The error icon (img)
>> allows users of screen reader software to navigate from one invalid
>> field to the next and skip fields in between if they choose to.
>
> Also a good idea. We will talk about this.
>
>> 4. An ARIA-alert with an error message that pops up as one tabs out
>> of a field that fails validation is another technique that is
>> useful. Admittedly it works with (some of) the latest assistive
>> technologies and browser versions only.
>>
>> Sorry I did not address the differences in browser behavior you referred
>> to.
>
> The inconsistent browser behavior was my biggest concern. The way many
> of the materials on the web, including mine, discuss how to handle
> form errors do not work.
>
> To me the expected behavior is that an anchor with an 'id' as the href
> should take the user directly to the object with the 'id' and give it
> focus (if possible).
>
> Do you expect something different?
>
> It's just surprising (though I have been doing this long enough that I
> should know better) and disappointing that implementation for
> something so simple is so poor across browsers.
>
> Jim
>
>> Rightho,
>> Sailesh
>>