E-mail List Archives

Re: Explicit Form Labels and Positioning Question


From: Sailesh Panchang
Date: Oct 27, 2011 9:27AM

In this particular case, the error text apparently is required to be
placed between visible label text and the form control ... so
suffixing error message to the form label within the label element
may be alright.
But generally I am not a supporter of this approach. Consider:
i. sometimes error text is required to be placed after the form control,
i.e. label text -- form control -- error msg.
The msg may be even on the line before / after the form control line.
ii. In a single form, it is possible that for a few fields a title
attribute has to be used because there is no visible label text
because of form's design.
iii. Regardless of whether label / title is used, the error text can
be styled so that it is immediately obvious visually ... say by color
/ font.
The vision impaired user (including color blind) may be at a disadvantage.
Screen reader users may need to tab through all controls listening to
identify labels with extra text. This is in-equal access.
iv. Displaying error text in title attribute too is not a good idea.
It does not work if form also has label text and user does not make
screen reader access the title routinely.

So I suggest:
i. In situations where the interface allows an error icon to be
placed near the field with error, leverage it to help VI users.
For example, set alt="Error: Zip code" (if zip code field has an error.
When screen reader users realize there is an image next to fields with
error on the particular website, they can use image navigation to
navigate straight to those fields. That is equality of access.
The error text may be placed near the error icon / label / form
control as per UI design. It can be within a span with tabindex=0 so
that it is tab navigable too.
The method can be used regardless of whether form control uses label or title.
ii. If error icon method is not used by the website, encourage the
designers to introduce one.

iii. Some forms only use visual clue to indicate form with error and
when moused over, the error text is displayed.
The error icon method is useful in these situations too. In addition,
ARIA role=tooltip can be used with keyboard events to make the error
display keyboard-operable.
See tooltip example on I-CITA

iv. Of course, another pet suggestion is to suffix the page title
(title element) with brief text to suggest that form submission
failed / errors are present ... in situations where form submission
refreshes form page. Else it could be suffixed to an existing heading
text placed immediately above the form that serves as the form's

Sailesh Panchang
Deque Systems

On 10/27/11, Randy Pope < <EMAIL REMOVED> > wrote:
> 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-----
> [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