WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Form labels when the field is labeled by another field

for

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

From: Jeremy Echols
Date: Mon, Oct 23 2017 10:19AM
Subject: Form labels when the field is labeled by another field
No previous message | Next message →

If you visit the UO library page (https://library.uoregon.edu/), in the "LibrarySearch" area we have a field (dropdown including "Keyword", "Title", "Author", and "Subject") which is essentially acting as a label for the search text input. We've put hidden labels in so that we aren't violating WCAG, but I'm wondering if there is a better approach.

We browsed a few sites which do something similar in terms of having a dropdown that acts as a label, but it seemed like in those cases the site author simply opted not to have a label at all (no "label" element, no title, no aria-label, etc.). I feel like there would be enough context if we just fixed our tab order (a different problem entirely), but I'm not sure if that satisfies WCAG 2.0 3.3.2 ("Labels or instructions are provided when content requires user input").

Barring that, we could also set aria-labelledby to point to the dropdown element, which seems like it works in NVDA and Firefox. But I'm not sure if that approach is just going to make the form worse, having a field which gets relabeled. Is that helpful or just confusing?

From: Patrick H. Lauke
Date: Mon, Oct 23 2017 10:33AM
Subject: Re: Form labels when the field is labeled by another field
← Previous message | Next message →

On 23/10/2017 17:19, Jeremy Echols wrote:
> If you visit the UO library page (https://library.uoregon.edu/), in the "LibrarySearch" area we have a field (dropdown including "Keyword", "Title", "Author", and "Subject") which is essentially acting as a label for the search text input. We've put hidden labels in so that we aren't violating WCAG, but I'm wondering if there is a better approach.
>
> We browsed a few sites which do something similar in terms of having a dropdown that acts as a label, but it seemed like in those cases the site author simply opted not to have a label at all (no "label" element, no title, no aria-label, etc.). I feel like there would be enough context if we just fixed our tab order (a different problem entirely), but I'm not sure if that satisfies WCAG 2.0 3.3.2 ("Labels or instructions are provided when content requires user input").
>
> Barring that, we could also set aria-labelledby to point to the dropdown element, which seems like it works in NVDA and Firefox. But I'm not sure if that approach is just going to make the form worse, having a field which gets relabeled. Is that helpful or just confusing?

Conceptually, what you have there are three fields:

- search for
- search term
- search in

As long as their labels (visible, hidden, aria-label, etc) reflect this,
I'd say that's the bare minimum needed to understand and operate the search.

You *could* dynamically change the label (not sure if your proposed
approach of pointing aria-labelledby to the <select> works in all
browser/AT combos, but my alternative gut feeling idea would be using
aria-label and rewriting its content with JS whenever the first dropdown
changes (so instead of "search for..." it could be changed to "author
name" when "Author" was selected), but you're right this may well end up
being more confusing than anything else to users (as the form will
appear to "morph" and change). I'd say keep it simple, to be honest.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Jeremy Echols
Date: Mon, Oct 23 2017 1:41PM
Subject: Re: Form labels when the field is labeled by another field
← Previous message | No next message

Thanks! I think we'll leave it as-is for now, then.

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Patrick H. Lauke
Sent: Monday, October 23, 2017 9:33 AM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Form labels when the field is labeled by another field

On 23/10/2017 17:19, Jeremy Echols wrote:
> If you visit the UO library page (https://library.uoregon.edu/), in the "LibrarySearch" area we have a field (dropdown including "Keyword", "Title", "Author", and "Subject") which is essentially acting as a label for the search text input. We've put hidden labels in so that we aren't violating WCAG, but I'm wondering if there is a better approach.
>
> We browsed a few sites which do something similar in terms of having a dropdown that acts as a label, but it seemed like in those cases the site author simply opted not to have a label at all (no "label" element, no title, no aria-label, etc.). I feel like there would be enough context if we just fixed our tab order (a different problem entirely), but I'm not sure if that satisfies WCAG 2.0 3.3.2 ("Labels or instructions are provided when content requires user input").
>
> Barring that, we could also set aria-labelledby to point to the dropdown element, which seems like it works in NVDA and Firefox. But I'm not sure if that approach is just going to make the form worse, having a field which gets relabeled. Is that helpful or just confusing?

Conceptually, what you have there are three fields:

- search for
- search term
- search in

As long as their labels (visible, hidden, aria-label, etc) reflect this, I'd say that's the bare minimum needed to understand and operate the search.

You *could* dynamically change the label (not sure if your proposed approach of pointing aria-labelledby to the <select> works in all browser/AT combos, but my alternative gut feeling idea would be using aria-label and rewriting its content with JS whenever the first dropdown changes (so instead of "search for..." it could be changed to "author name" when "Author" was selected), but you're right this may well end up being more confusing than anything else to users (as the form will appear to "morph" and change). I'd say keep it simple, to be honest.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke