E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: Elle
Date: Wed, Oct 26 2011 3:15PM
Subject: Explicit Form Labels and Positioning Question
No previous message | Next message →

Good afternoon!

I'm combing through and testing some recently developed pages, and I came
across an error that I'm unsure what recommendations to give on how to
correct it. I have pasted the source code snippet at the bottom of this
post, but here is the general issue I'm facing:

We have a complex ASP.NET 3.5 form page with validation. 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)). To do this, we've created an empty <DIV>
element and a definition list that gets populated when an error is
triggered. This markup exists in between the label and the input field in
the source order. Visually, the label text and the text input field are
directly adjacent to one another. When a user clicks "Search" without
entering information, that area expands, the focus goes to the label with
the error <DIV> element in the tab order directly in between label and input
field.

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)
*
*
*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*

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. Additionally (and
please don't burn me in effigy, but I do need to be pragmatic and win the
war here - this is a huge site), I need to know how serious this error is.
Does it always fail with screen reader users, or does it depend on AT
settings, browser/AT combinations, versions, etc? Can screen reader users
weigh in on this so I know what the issue is in the wild?

We have many more issues to fix, but I appreciate your help on this part!
~Elle

.... code snippet follows ....


<div id="search">
<span class="label">
<div id="ctl00_PageContentPlaceholder_RXSearchControl_divSearchByName" class
="greybg">
<span>
*<label id="
ctl00_PageContentPlaceholder_RXSearchControl_RxDrugNameCustomLabel" class="
label" style="width:55px;" for="
ctl00_PageContentPlaceholder_RXSearchControl_RxDrugSearchByNameTextBox">* Rx
Drug:</label>*
<div id="
ctl00_PageContentPlaceholder_RXSearchControl_DrugNameErrorControl_ErrorContainer
" class="ShowError" style="left: 26.85px; top: 176.5px; z-index: 1001;">
<dl class="balloon" title="Error">
<dt>
<a id="
ctl00_PageContentPlaceholder_RXSearchControl_DrugNameErrorControl_ErrorMessageLabel
" class="ErrorMessageLabel" href="
javascript:__doPostBack('ctl00$PageContentPlaceholder$RXSearchControl$DrugNameErrorControl$ErrorMessageLabel',')
" title="Error Occured" onclick="return false;">Drug Name is a required
field.</a>
</dt>
<dd class="close" title="Close">
<input id="
ctl00_PageContentPlaceholder_RXSearchControl_DrugNameErrorControl_CloseImage
" type="image" style="border-width:0px;"
onclick="javascript:CloseErrorMessage('ctl00_PageContentPlaceholder_RXSearchControl_DrugNameErrorControl_ErrorContainer');ValidateErrorCount();return
false;" src="../Images/Buttons/button.png"
onkeydown="javascript:CloseKeyPressed(event,'ctl00_PageContentPlaceholder_RXSearchControl_DrugNameErrorControl_ErrorContainer');return
false;" alt="Close" name="
ctl00$PageContentPlaceholder$RXSearchControl$DrugNameErrorControl$CloseImage
">
</dd>
<dd> </dd>
</dl>
</div>
*<input id="
ctl00_PageContentPlaceholder_RXSearchControl_RxDrugSearchByNameTextBox"
class="RxSeachByDrugNameText MandatoryItem" type="text" onkeypress="
TypeAheadAndAutoHighlight();" aria-hidden="false" name="
ctl00$PageContentPlaceholder$RXSearchControl$RxDrugSearchByNameTextBox"
autocomplete="off">*
<span id="ctl00_PageContentPlaceholder_RXSearchControl_RxDrugNameValidator"
style="color:Red;display:none;"></span>
</span>
</div>

From: Jared Smith
Date: Wed, Oct 26 2011 7:39PM
Subject: Re: Explicit Form Labels and Positioning Question
← Previous message | Next message →

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

From: Elle
Date: Thu, Oct 27 2011 5:30AM
Subject: Re: Explicit Form Labels and Positioning Question
← Previous message | Next message →

Thanks very much, Jared.

I knew the markup challenges that you mention, but having your input helps
me make the case for cleaner, more elegant code. The "close" feature of the
error messaging is for a "bubble" like error display. It's been my
recommendation to remove it, because it seems to require an inordinate
amount of effort to use this method with really unpredictable browser
displays. On other pages, I've won the battle to get errors placed within
the label tags.

Regarding the overkill and the outdated requirement, I will happily take
that and move forward in tackling the bigger issues with error handling and
semantic markup.

Much appreciated,
Elle

From: Randy Pope
Date: Thu, Oct 27 2011 7:54AM
Subject: Re: Explicit Form Labels and Positioning Question
← Previous message | Next message →

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

From: Jared Smith
Date: Thu, Oct 27 2011 9:00AM
Subject: Re: Explicit Form Labels and Positioning Question
← Previous message | Next message →

On Thu, Oct 27, 2011 at 5:31 AM, Elle < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks very much, Jared.
>
> I knew the markup challenges that you mention, but having your input helps
> me make the case for cleaner, more elegant code.

My comments on the code were probably a bit overly critical. My
primary concern would be the use of a tool that is evaluating against
WCAG 1.0 and referring you to its outdated documentation.

This article might be of some help -
http://webaim.org/techniques/formvalidation/ I need to update it with
some functioning examples and ARIA.

Jared

From: Sailesh Panchang
Date: Thu, Oct 27 2011 9:27AM
Subject: Re: Explicit Form Labels and Positioning Question
← Previous message | Next message →

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
http://test.cita.illinois.edu/aria/tooltip/tooltip2.php

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
title.

Sailesh Panchang
Deque Systems





On 10/27/11, Randy Pope < = EMAIL ADDRESS 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
>
>
>

From: Elle
Date: Thu, Oct 27 2011 10:18AM
Subject: Re: Explicit Form Labels and Positioning Question
← Previous message | Next message →

Thanks, both, for your input.

On Thu, Oct 27, 2011 at 11:24 AM, Sailesh Panchang <
= EMAIL ADDRESS REMOVED = > wrote:


> 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.
>

I have considered this, and I appreciate the insight. It's helpful when
defining why a solution might be unusable.

>
>
> 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.
>

We also use an exclamation point icon with the alternate text of "Error" for
errors. Do you recommend placing this within the <label> element? I think
that was my intention for future recommendations for these pages.

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
> title.
>
> Sailesh Panchang
> Deque Systems


Still working on that suggestion, Sailesh! :)


>
Thanks,
Elle

From: Sailesh Panchang
Date: Thu, Oct 27 2011 10:45AM
Subject: Re: Explicit Form Labels and Positioning Question
← Previous message | Next message →

The "labels not being positioned correctly" error does not appear to
be out of place when error text (that is not within label) is placed
between label text and form control.
This could adversely impact some users including seniors / users with
cognitive impairments / low vision users.
Visually too one expects labels to be positioned right next to / above
the form control.

Whether to place error icon inside LABEL: What if a control uses title
and not a label? Then a different method will be needed. The icon can
be consistently be placed at a point that makes sense- a uniform and a
standardized method for all form controls across the site. Easy for
programmers too.
Sailesh Panchang
Deque Systems




On 10/27/11, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> On Thu, Oct 27, 2011 at 5:31 AM, Elle < = EMAIL ADDRESS REMOVED = > wrote:
>> Thanks very much, Jared.
>>
>> I knew the markup challenges that you mention, but having your input helps
>> me make the case for cleaner, more elegant code.
>
> My comments on the code were probably a bit overly critical. My
> primary concern would be the use of a tool that is evaluating against
> WCAG 1.0 and referring you to its outdated documentation.
>
> This article might be of some help -
> http://webaim.org/techniques/formvalidation/ I need to update it with
> some functioning examples and ARIA.
>
> Jared
>

From: Elle
Date: Thu, Oct 27 2011 11:27AM
Subject: Re: Explicit Form Labels and Positioning Question
← Previous message | No next message

As for visual placement, in this particular case, the label appears directly
before the input field, so that's not an issue. I will look at the title
attribute issue you mentioned and see if we can find another, standardized
method for displaying the icon. Usually, however, when we use a title
attribute, there's a <legend> element before the input fields (ex. date of
birth), so that might be our standard.

Thanks!
~Elle


On Thu, Oct 27, 2011 at 12:47 PM, Sailesh Panchang <
= EMAIL ADDRESS REMOVED = > wrote:

> The "labels not being positioned correctly" error does not appear to
> be out of place when error text (that is not within label) is placed
> between label text and form control.
> This could adversely impact some users including seniors / users with
> cognitive impairments / low vision users.
> Visually too one expects labels to be positioned right next to / above
> the form control.
>
> Whether to place error icon inside LABEL: What if a control uses title
> and not a label? Then a different method will be needed. The icon can
> be consistently be placed at a point that makes sense- a uniform and a
> standardized method for all form controls across the site. Easy for
> programmers too.
> Sailesh Panchang
> Deque Systems
>
>
>
>
>