WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Explicit Form Labels and Positioning Question

for

From: Randy Pope
Date: Oct 27, 2011 7:54AM

Jared and all,

I too thank you for this comment. Is there any kind of updated resources on
using the Aria approach? I using an outdated html editor that doesn't
address this approach.

With Warm Regards,
Randy Pope


-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Jared Smith
Sent: Wednesday, October 26, 2011 9:39 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Explicit Form Labels and Positioning Question

On Wed, Oct 26, 2011 at 3:16 PM, Elle wrote:

> The error messaging
> method that the team chose to use is to place all of the error
> messaging content in an external file so that it doesn't populate on
> initial page load (Section 508, §1194.22 (d)).

This is probably a bit overkill. The 508 requirement is that the content be
"readable". Certainly the error messages would be readable if they were
included originally in the page content. Practically nobody browses the web
with all styles disabled anyway. Your error processing requires JavaScript
which should be of much more concern than requiring CSS for optimal
presentation.

> The error I'm receiving when doing an automated scan is "Label is not
> positioned properly."  Referring to W3C Checkpoint Guidelines, I see
> the following instructions:
> (http://www.w3.org/WAI/wcag-curric/chk11-0.htm)

This is 13 year old WCAG 1.0. Are you still using this? I hope not.
Everything on that page can generally be ignored because, as I like to say,
"user agents do."

> *10.2 - Until user agents support explicit associations between labels
> and form controls <http://www.w3.org/WAI/wcag-curric/sam78-0.htm>;, for
> all form controls with implicitly associated labels, ensure that the
> label is properly positioned.  - Priority 2*

User agents do support explicit labeling and have done so for about a
decade. You're not using implicit labeling anyway, so this doesn't apply to
this markup in any way.

> So, I'm not sure whether it's a nesting issue, a "no markup allowed in
> between label and form element" issue, or something else.

It's an evaluation tool issue. The tool is checking an outdated requirement
and indicating an error where this is none - well, at least the error it is
flagging isn't present in your code.

> .... code snippet follows ....

Man do I hate ASP.net code. That could be done in about 1/10th that amount
of markup, but that's a separate issue. A few comments:

- The use of the definition list is inappropriate. "Close" is not the
definition of "Drug Name is a required field." There's no list or definition
here, yet a screen reader might identify it as a list of items. There's also
an empty <dd> element in there that should be removed (as well as a couple
spare <span>s, redundant title attribute values, etc., etc.). Use <div> or
<span> or something else instead.

- It's a bit difficult to understand what is going with the error message.
You indicate that when the error message displays, that focus is set to the
label. The label, however, doesn't seem marked up to receive keyboard focus.
Why is "Drug Name is a required field" a link?
I assume that this would also set focus back to the form label, which,
again, can't receive that focus.

- "Close" should probably be a link, not a button. It does not submit form
data. Again, I'm struggling to envision what is being closed here. What
happens when the user activates "Close"? If it closes the error message, why
would the user do this rather than just fix the error.

- The big issue is that the error message should almost certainly be
presented within the form label. Focus should probably be set directly to
the form control when the error displays. When focus is set to the text box,
the label will be read, which contains the input's description and the
relevant error message.

Something like:

<label for="rxdrug">Rx Drug: *
<div class="error">Drug Name is a required field</div> </label> <input
type="text" id="rxdrug" name="rxdrug">

You could do a few additional enhancements to better indicate to screen
reader users that the input field is required, and after the error appears,
that it needs to be fixed:

<input type="text" id="rxdrug" name="rxdrug" aria-required="true"
aria-invalid="true">

The code you presented seems to be taking a sledgehammer approach to
something that can be quite simple.

Jared Smith
WebAIM.org