WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Explicit Form Labels and Positioning Question

for

From: Jared Smith
Date: Oct 26, 2011 7:39PM

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