E-mail List Archives
Thread: Form input label question
Number of posts in this thread: 9 (In chronological order)
From: Keith Parks
Date: Tue, Dec 01 2009 4:55PM
Subject: Form input label question
No previous message | Next message →
Hi folks.
I have a group of pages that are failing a couple of automated
accessibility scans, but passing a couple of others, and I'm trying to
figure out why.
The issue is with a Label element. The Label is correctly associated
with an input through the "for" value, but the input it is tied to is
a *hidden* input. I assume that hidden inputs do not need Labels, right?
The WebAIM WAVE tester flags it as an orphaned Label.
The HiSoftware Compliance Sheriff also fails the page because of that
label.
BUT, the "Cynthia Says 508 tester" and the HiSoftware AccVerify
program both give the page a PASS.
So... I assume that hidden inputs do not *require* Labels, but is it
an actual error for a hidden input does have a Label?
Thanks,
Keith
note: I don't own the pages, I'm only checking the accessibility, so I
want to be able to pass on a definitive recommendation and
justification about any necessary modifications. The simple answer
would seem to be just to remove the Label, but since it does pass some
automated scans, I want to make sure the error is not in the tester.
******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.sa.sdsu.edu/communications
http://kparks.deviantart.com/gallery
----------------------------------------------------------
World Peace through Cascading Style Sheets.
From: Jared Smith
Date: Tue, Dec 01 2009 5:25PM
Subject: Re: Form input label question
← Previous message | Next message →
On Tue, Dec 1, 2009 at 4:53 PM, Keith Parks < = EMAIL ADDRESS REMOVED = > wrote:
> The issue is with a Label element. The Label is correctly associated
> with an input through the "for" value, but the input it is tied to is
> a *hidden* input. I assume that hidden inputs do not need Labels, right?
>
> The WebAIM WAVE tester flags it as an orphaned Label.
I am going to assume that by "hidden" you mean <input type="hidden">
and not another input type that is hidden from view.
You are correct - hidden inputs do not need and have no benefit from
being assigned labels. I can't imagine why one would want to. Because
the hidden form element cannot be navigated to, the label will not be
read in association with that element. Instead, the label will only
read as the page is read by a screen reader in browse mode, which
could be confusing depending on what the text is. Additionally, if you
hover your mouse over the visible label text within the page, the
mouse cursor may indicate a clickable element which could also be
confusing.
Is this an accessibility error? It probably depends on what the label
text is, but I wouldn't consider this a serious issue. Certainly no
accessibility guidelines address this. The logic in WAVE identifies
labels that are not properly associated with a form element type that
typically should have labels - and hidden inputs rarely do and don't
need them anyway.
Jared Smith
WebAIM
From: Steve Green
Date: Tue, Dec 01 2009 5:35PM
Subject: Re: Form input label question
← Previous message | Next message →
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jared Smith
Sent: 02 December 2009 00:21
To: WebAIM Discussion List
Subject: Re: [WebAIM] Form input label question
On Tue, Dec 1, 2009 at 4:53 PM, Keith Parks < = EMAIL ADDRESS REMOVED = > wrote:
> The issue is with a Label element. The Label is correctly associated
> with an input through the "for" value, but the input it is tied to is
> a *hidden* input. I assume that hidden inputs do not need Labels, right?
>
> The WebAIM WAVE tester flags it as an orphaned Label.
I am going to assume that by "hidden" you mean <input type="hidden"> and not
another input type that is hidden from view.
You are correct - hidden inputs do not need and have no benefit from being
assigned labels. I can't imagine why one would want to. Because the hidden
form element cannot be navigated to, the label will not be read in
association with that element. Instead, the label will only read as the page
is read by a screen reader in browse mode, which could be confusing
depending on what the text is. Additionally, if you hover your mouse over
the visible label text within the page, the mouse cursor may indicate a
clickable element which could also be confusing.
Is this an accessibility error? It probably depends on what the label text
is, but I wouldn't consider this a serious issue. Certainly no accessibility
guidelines address this. The logic in WAVE identifies labels that are not
properly associated with a form element type that typically should have
labels - and hidden inputs rarely do and don't need them anyway.
Jared Smith
WebAIM
-------
Not only do the WCAG not address the issue, but the HTML specification does
not either.
This is yet another example of automated tools inventing 'rules' that don't
actually exist. The 'rule' in question may or may not be good practice in
some circumstances, but these tools really should differentiate between
genuine non-compliances and their made-up rules.
Steve Green
Director
Test Partners Ltd
From: Keith Parks
Date: Tue, Dec 01 2009 5:40PM
Subject: Re: Form input label question
← Previous message | Next message →
On Dec 1, 2009, at 4:21 PM, Jared Smith wrote:
> I am going to assume that by "hidden" you mean <input type="hidden">
> and not another input type that is hidden from view.
Yes, that's what I meant. Should have been more specific.
> You are correct - hidden inputs do not need and have no benefit from
> being assigned labels. I can't imagine why one would want to.
> [snip...]
I couldn't figure why this label is there either. Since it's not
needed (from either a code or a user standpoint), and causes the page
to fail our automated scan, I'll recommend they just remove it.
Thanks for the clarification, Jared.
******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.sa.sdsu.edu/communications
http://kparks.deviantart.com/gallery
----------------------------------------------------------
(Objects on your screen may be closer than they appear)
From: Keith Parks
Date: Tue, Dec 01 2009 5:50PM
Subject: Re: Form input label question
← Previous message | Next message →
On Dec 1, 2009, at 4:35 PM, Steve Green wrote:
> This is yet another example of automated tools inventing 'rules'
> that don't
> actually exist. The 'rule' in question may or may not be good
> practice in
> some circumstances, but these tools really should differentiate
> between
> genuine non-compliances and their made-up rules.
It's part of that ongoing push/pull between "doing the right thing",
and doing what makes your bosses happy, which in this case is getting
that little green "Pass" check mark next to all of our sites on our
next internal audit.
They rarely want to hear the ins and outs of "evolving best
practices", or disagreements within the Web accessibility community,
or how "pass/fail" is not really the proper way to look at
accessibility issues.
******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.sa.sdsu.edu/communications
http://kparks.deviantart.com/gallery
----------------------------------------------------------
Putting the "no" in "Innovation" since 1988.
From: Jared Smith
Date: Tue, Dec 01 2009 6:10PM
Subject: Re: Form input label question
← Previous message | Next message →
On Tue, Dec 1, 2009 at 5:35 PM, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> This is yet another example of automated tools inventing 'rules' that don't
> actually exist. The 'rule' in question may or may not be good practice in
> some circumstances, but these tools really should differentiate between
> genuine non-compliances and their made-up rules.
I'm curious what you mean. You certainly wouldn't want tools
implementing extreme views or additional elements into reports that
indicate compliance with guidelines. How can you be sure if the tool
is reporting compliance or someone's interpretation of compliance? Our
approach with WAVE is to ignore compliance and to focus on
accessibility - to show you everything we can about accessibility
issues and let you determine what that means for your site's
compliance. There are many things that WAVE detects that impact
accessibility but that are not in any accessibility guidelines. Are
you suggesting that tools should ignore important accessibility issues
that are not part of accessibility guidelines?
Jared Smith
WebAIM
From: Andrew Kirkpatrick
Date: Tue, Dec 01 2009 6:50PM
Subject: Re: Form input label question
← Previous message | Next message →
> This is yet another example of automated tools inventing 'rules' that don't
> actually exist. The 'rule' in question may or may not be good practice in
> some circumstances, but these tools really should differentiate between
> genuine non-compliances and their made-up rules.
Seems that an evaluation tool that claims that an input with type="hidden" needs a label is not implementing sufficiently intelligent rules. I know that this has been a problem in the past with some tools, but am not sure how much of an issue it is now.
It might make sense to check for input elements with type="hidden" that do have labels and fire a warning. The risk is that there is extraneous text on the page that may affect the way the page is read. I'd say that WCAG 2.0's 1.3.2 (meaningful sequence) could come into play here, but that might be a stretch.
AWK
From: Jared Smith
Date: Tue, Dec 01 2009 7:10PM
Subject: Re: Form input label question
← Previous message | Next message →
On Tue, Dec 1, 2009 at 6:49 PM, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
> Seems that an evaluation tool that claims that an input with type="hidden" needs a label is not implementing sufficiently intelligent rules.
You mean kinda like when Dreamweaver prompts for a label when you
insert buttons or image fields? Do these not create an identical
issue?
It is "Pick on Adobe Month" on the WebAIM list, isn't it? ;-)
Any tool that indicates a failure for a hidden input without a label
is absolutely wrong. If it indicates a WCAG error if a hidden input
does have a label, this is a pretty far stretch - I don't see where
any guidelines restrict this. If it simply indicates that this is an
accessibility issue (as WAVE does), then it's up to you to determine
whether it really is an issue and/or a conformance error.
Jared
From: Andrew Kirkpatrick
Date: Tue, Dec 01 2009 8:10PM
Subject: Re: Form input label question
← Previous message | No next message
You mean kinda like when Dreamweaver prompts for a label when you
insert buttons or image fields? Do these not create an identical
issue?
Kind of walked into that one, didn't I? :)
It is "Pick on Adobe Month" on the WebAIM list, isn't it? ;-)
Are we limiting it to a specific month now?
Seriously, my response to your comment is that DW should make this easier, but the dialog that is invoked does allow you to set other attributes that are potentially useful for accessibility, not just adding a form label. However, I would prefer to see the options to add labels to buttons or image fields completely grayed out in these cases.
I will also note that for hidden inputs, the dialog does not appear.
As an aside, if you know of issues with DW or other products that you want fixed, please tell me and we'll make sure to log a bug and get the issues addressed.
AWK