WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible form errors...bug?

for

From: Sailesh Panchang
Date: Jan 21, 2011 1:00PM

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 REMOVED> > wrote:
> On Tue, Jan 18, 2011 at 11:23 AM, Sailesh Panchang
> < <EMAIL 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
>>