labeling a select box
| Code: |
| <h2><label for="Text1">Search</label></h2>
<select id="Select1" name="searcharea" title="Search Area" style="width:150px;" > <option value="all">All Areas</option> <option value="occ">Occupations</option> <option value="pos">Programs</option> <option value="col">Colleges/Schools</option> <option value="emp">Employers</option> </select> <input type="text" id="Text1" name="substring" maxlength="40" size="13" title="Search" style="width:146px;" /> |
I am confused on how to properly label the select box. The select box determines which section of the site to search in. I was just wondering how you would label the select box.
Share: 
Sadly HTML4 doesn't allow a space-separated list in the for attribute. If it allowed a list, you could do this:
| Code: |
| <h2><label for="Select1 Text1">Search</label></h2>
<select id="Select1" name="searcharea" title="Search Area" style="width:150px;" > <option value="all">All Areas</option> <option value="occ">Occupations</option> <option value="pos">Programs</option> <option value="col">Colleges/Schools</option> <option value="emp">Employers</option> </select> <input type="text" id="Text1" name="substring" maxlength="40" size="13" title="Search" style="width:146px;" /> |
For now, you'd either need 2 <label> elements, like this:
| Code: |
| <h2><label for="area">Search in area:</label></h2>
<select id="area" name="area"> <option value="all">All Areas</option> <option value="occ">Occupations</option> <option value="pos">Programs</option> <option value="col">Colleges/Schools</option> <option value="emp">Employers</option> </select> <label for="find">Find this:</label> <input type="text" id="find" name="find" maxlength="40" size="13" /> |
Or you could make clever use of the <fieldset> and <legend> elements, like this:
| Code: |
| <fieldset>
<legend>Search</legend> <select name="area"> <option value="all">All Areas</option> <option value="occ">Occupations</option> <option value="pos">Programs</option> <option value="col">Colleges/Schools</option> <option value="emp">Employers</option> </select> <input type="text" name="find" maxlength="40" size="13" /> </fieldset> |
The title attributes in your sample are not useful. The style attributes are likely to cause problems with text sizing. Making the id values different from the name causes unnecessary work. Especially as you used capital letters. The name values didn't seem very logical to me, either.
I'm pretty sure the dropdown is an unnecessary complexity. If a user wants to find a specific type of thing, the keywords they enter will make clear what that is. For example, a search for "School Jobs" should prioritise results from the "Occupations" area rather than the "Colleges/Schools" area. Don't make the user think. Let the machines do the work!
| Code: |
| <h2><label for="find">Find this:</label></h2>
<input type="text" id="find" name="find" maxlength="40" size="13" /> |
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Last edited by Ben Millard on 10 May 2008 05:25 pm; edited 1 time in total
Share:
| Cerbera wrote: | ||
Sadly HTML4 doesn't allow a space-separated list in the for attribute. If it allowed a list, you could do this:
|
I'm not sure that I see the benefits of such a feature.
What problem do you see such a feature as 'fixing'?
Would it default to the first referenced item in the markup* or would the order of values in the for attribute serve to set priority/precedence like a form of tab order?
* i.e. If you clicked the label text, would it focus the select menu?
If so, what functional difference would their be compared to a fieldset, wherein a user would click the select's label, use it, then tab to the accompanying text input?
On the surface, it seems as though it might only serve to muddy the relationship between label text and form control items.
What benefits would your approach offer over the current approach?
(honest questions)
| Quote: |
| I'm pretty sure the dropdown is an unnecessary complexity. If a user wants to find a specific type of thing, the keywords they enter will make clear what that is. For example, a search for "School Jobs" should prioritise results from the "Occupations" area rather than the "Colleges/Schools" area. Don't make the user think. Let the machines do the work! |
I disagree.
Search narrowing/filtering has proven to be a popular feature throughout the web, whether it's geo-localised Google searches, searching for a current affairs programme on the BBC site or searching for a particular brand of DVD player on Amazon.
Search narrowing/filtering is not what I or, more relevantly, the big dogs on the web, consider overly or unnecessarily challenging and can help users reach their intended destination more directly.
Of course, not all sites or all sizes will really benefit from search filtering, but imo, it's certainly not something which should be discarded so easily.
It's simpler to let the user filter their search results than it is to write an algo which can accurately guess precisely what the user is after every time.
Rather than seeing it as an unnecessary layer of complexity which challenges the user, think of it as a way for you to help them help themselves.
(Steve Krug has a lot to answer for, imo, though I suspect that his mantra is often misapplied.)
Share:
| Cerbera wrote: |
| ...Can you link us to the page you are doing this on, or to a demo page? Seeing the issue in context may reveal an even better solution...
|
http://wiscareers.wisc.edu/...
There is a link to the page in question. Excuse the table layouts and bad coding conventions as this site is almost 10 years old.
I think I will use the fieldset/legend method.
Share:
Bill, in TomK's sample there is one <label> but two form controls. HTML4 lets <label for> be associated with only one control. So TomK's sample ends up with an unlabelled form control. This is the problem.
A sighted user without text-to-speech or voice recognition and with 2-dimensional random access (such as via a mouse, trackball, joystick, eyetracking, stylus and so forth) can understand and interact with the form thanks to its layout and styling. Any other user would need both inputs to be labelled for the form to be usable.
If HTML5 allows <label for> to be associated with multiple controls, both controls would be labelled. This would solve the problem without altering the design. It barely changes the markup, too.
Giving focus to the first control listed by for when <label for> is clicked seems a neat way to handle that case, I agree.
| Bill Posters wrote: |
| If so, what functional difference would their be compared to a fieldset, wherein a user would click the select's label, use it, then tab to the accompanying text input? |
| Bill Posters wrote: |
| It's simpler to let the user filter their search results than it is to write an algo which can accurately guess precisely what the user is after every time. |
TomK, thanks for the link. The <fieldset> with <legend> approach is a good choice if you keep the dropdown. But I really think removing the dropdown would be worthwhile: search is only useful if it's simple.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| Cerbera wrote: |
| Bill, in TomK's sample there is one <label> but two form controls. HTML4 lets <label for> be associated with only one control. So TomK's sample ends up with an unlabelled form control. This is the problem. |
It's certainly a problem if you're marking things up that way.
| Quote: |
| A sighted user without text-to-speech or voice recognition and with 2-dimensional random access (such as via a mouse, trackball, joystick, eyetracking, stylus and so forth) can understand and interact with the form thanks to its layout and styling. Any other user would need both inputs to be labelled for the form to be usable.
If HTML5 allows <label for> to be associated with multiple controls, both controls would be labelled. This would solve the problem without altering the design. |
And creates another one, by breaking the usability convention which allows users to click upon the label to activate/focus its corresponding form control.
Imo, your idea about multiple for values is a solution looking for a problem (where one doesn't exist).
| Quote: |
| Giving focus to the first control listed by for when <label for> is clicked seems a neat way to handle that case, I agree. |
It would possibly be the neatest application of what is, imo, an unintuitive, counter-conventional (and consequently, undesirable) solution.
| Quote: | ||
|
Give the select menu its own label and, if necessary, wrap both in a fieldset w/ legend to denote their combined purpose.
What's so wrong about this…?
| Code: |
| <form …>
<fieldset> <legend>Search<legend> <label for="search-area">Where to search</label> <select id="search-area" name="search-area"> <option value="all">All Areas</option> <option value="occ">Occupations</option> <option value="pos">Programs</option> <option value="col">Colleges/Schools</option> <option value="emp">Employers</option> </select> <label for="search-terms">What to search for</label> <input type="text" id="search-terms" name="search-terms" /> <input type="submit" id="start-search" value="Search" /> </fieldset> </form> |
(The choice of label text could possibly benefit from tweaking, but it's the labelling principle which I'm asking about. Labels could be offset in an AT-friendly way as the convention of having a section marked 'Search' which has a select menu defaulting to 'All areas', followed by a text input field, followed by a button marked Search is sufficient to communicate the purpose of each part to a visual user. Given the presence of the 'Search' button, it's possible also to hide the legend whilst maintaining sufficient understanding of the form controls and their combined purpose.
However, semantically, the form and its controls should, imo, be marked up as above.)
I don't see a problem with having two labels as both form controls fulfill different purposes. Their purposes are combined to work together, which imo, makes them ideal candidates for a fieldset.
| Quote: | ||
|
Searches which offer category-focused searches typically default to 'all areas'. This in no way limits users or breaks with whatever mental model they may have - at least, no more than not providing filtering at all.
| Quote: |
| I really think removing the dropdown would be worthwhile: search is only useful if it's simple. |
Fwiw, I disagree with the notion that search which offers category filtering can't be simple.
I would have thought that the success of the major e-commerce sites, in fact pretty much all large, content-heavy sites, which typically offer the option to search specific categories, would be all the evidence required to make that point.
I suspect that we'd be hard-pressed to find a major site which doesn't provide users with the means to filter their searches by category at the time of the search.
It has been noted before in a usability study referring to another misguided usability concept, namely the so-called '3 click rule', that users are generally content so long as they feel they're moving forward to their target. I can easily imagine how category filtering provides this assurance, primarily because it generally lets them know that their search results are going to be more relevant.
Imo, and presumably the opinions of those behind the many large sites which typically provide the option to filter search results, it ain't broken.
Now, I know you're mentally invested in HTML5, but as said, I think the solution you suggested has flaws in that it breaks one intuitive usability model and replaces it with a less intuitive model.
Unfortunately, this is seemingly the sort of counter-intuitive thinking which lays behind some of the WG's more contentious plans.
If it reached the right ears, it wouldn't surprise me for it to go in.
And that would be a bad thing, imo.
Of course, if you have some information (studies, articles, etc…) which points to site searches which offer category filtering being less usable, less widely used or less effective than wholly-unfiltered search results (post-filtered via algo weighting), then I'd genuinely be interested to see it.
Additionally, if you also have some information which also suggests that the model you're proposing is an improvement, then I'd also be genuinely interested to see that.
[edit]
Fwiw, this popped up on my feeds this morning.
Thought it worth posting, if only as a design pattern.
http://www.domscripting.com/...
…though, I already consider the wealth of circumstantial evidence in favour of offering pre-filtering to have already driven the point home.
Share:
Ah, same old Bull. Sorry, I mean Bill. 
"Here's my verbose and speculative opinion. Now show me exhaustive evidence showing it to be wrong. Which I'll then combat by using an exponentially larger amount of speculative sliminess." Hmm...
I suggested a double-labelled approach earlier. My understanding is this wouldn't fit in TomK's design, so it wasn't a contender. When a design allows one <label> for each control, that's obviously what should be used. Multiple values in for is just an idea for improving the other cases.
TomK adopted my <fieldset> with <legend> example. It's more or less the same as both controls sharing one <label> but conforms to HTML4. Dropdown lists and textboxes are big enough to be clicked directly. Sighted mouse users don't lose out.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| Cerbera wrote: |
| Ah, same old Bull. Sorry, I mean Bill. "Here's my verbose and speculative opinion. Now show me exhaustive evidence showing it to be wrong. Which I'll then combat by using an exponentially larger amount of speculative sliminess." Hmm, let me try something... |
You really don't like it when people challenge or openly dislike your opinions, do you?
(That's a rhetorical question, of course)
I freely admit that I too can get a little to easily antagonised by some of your statements, but then there's no love lost in either direction, right.
In this instance, I found it a little presumptuous that you describe the lack of multiple for values as a problem in need of a "fix" merely because, in your opinion (and with little, if any, to substantiate it), it was.
(I guess you also got caught in my cynicism towards HTML5, which I consider to be pushing to introduce some rather questionable practices into markup, backed up by what I consider to be some dubious thinking.)
But, hey ho.
Apologies on my part.
As for my statement being my opinion…
As said, I consider the wealth of circumstantial evidence available on t'interweb and the lack of any voiced or published problems with that model to be a convincing argument that, far from being broken, it's actually a model which is ideally suited to the task.
| Quote: |
| I already suggested a double-labelled approach. My understanding is this wouldn't fit in TomK's design, so it wasn't a contender.
When a design allows one <label> for each control, that's obviously what should be used. Multiple values in for is just an idea for solving the cases where that isn't the case. |
CSS? The markup doesn't have to be apparent in the visuals.
I mentioned how the form could be verbosely marked-up without impacting on its visual appearance.
The design shouldn't dictate the markup and, thanks to CSS, the markup doesn't need to dictate the design.
| Quote: |
| TomK has adopted my <fieldset> with <legend> example. It's more or less the same as both controls sharing one <label>. Dropdown lists and textboxes are big enough to be clicked directly. |
Imo, being able to click on a label to activate/focus a form control has value as a convention which goes beyond size considerations of the form controls in question. As such, I feel it's worth employing regardless of the size of the form control in question - which is to say that I feel that any visible label text should be clickable as a means to activate/focus its respective form control.
Conventions become more useful the more frequently they are encountered.
That, you'll be glad to hear, is my admittedly unsubstantiated opinion - though obviously one which I feel to be reasoned.
I'd be interested to hear how your response to what I've described as the problems inherent in your suggestion, particularly relating to the ideal of consistency in UI design.
Simply put (too late for that
) I consider your suggested idea of the for attribute to be less ideal than the existing possibilities made available by currently available form controls and attributes.
It introduces complexity, not only where it's not needed, but also in situations which don't readily seem to benefit from it.
As for verbose, that's just my way.
Why use one word, when 10 will do?
Share:
| Bill Posters wrote: | ||
|
It also means sighted mouse users have no <label> to click. Which is one of the things you say makes multiple for a non-starter. So multiple <label> elements, with one or more positioned off-screen, is a non-starter by your own reasoning. Same old Bull Posters!
| Bill Posters wrote: |
| [...] I consider your suggested idea of the for attribute to be less ideal than the existing possibilities made available by currently available form controls and attributes.
It introduces complexity, not only where it's not needed, but also in situations which don't readily seem to benefit from it. |
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| Cerbera wrote: | ||||
|
Does that make things worse than not having them at all?
Also, imo, if voice activation software can't handle those things which even other ATs have managed to handle, then that's a failing of the software, not the site - and consequently something which should be addressed by the software developer, rather than prevent an otherwise useful technique.
(Out of curiosity, [it's unlikely to effect the way I code] is this a problem with labels only or does it effect any off-screen positioned element, such as Image-Replaced headings or accessibility links which shift back on-screen when focussed?)
| Quote: |
| It also means sighted mouse users have no <label> to click. Which is one of the things you say makes multiple for a non-starter. |
The problem I have with multiple for values is that it breaks the conventional model in two ways:
1) By failing to provide a label in the structural markup which corresponds to a specific form control.
2) By establishing a new, shared connection between a label and a form control to which it doesn't most directly relate.
i.e. Labels should be paired with a single form control.
| Quote: |
| So multiple <label> elements, with one or more positioned off-screen, is non-starter by your own reasoning. Same old Bull Posters! |
You're mistaken. There's nothing inconsistent about the suggestions I've made. Perhaps I failed to explain it clearly.
As said, the visual design shouldn't dictate the markup, so forget about the visual design for a moment. Forget about what's on-screen and what's off-screen. Think of it in purely structural terms.
To my mind, the verbosely marked-up option posted earlier is the most correct option.
CSS can be employed to offset the labels for those form controls which have inate instructions or for which the purpose can be assumed from the context. Select menus which default to "Entire Site" can reasonably be assumed to convey their purpose in the context of a search form which uses Search as a legend or which is followed/preceded by a text input field and followed by a button marked 'Search'.
It's not rocket-science. It's design.
| Quote: | ||
|
Can you describe a situation where it would help, compared to the options made available by the current array of standardised elements and attributes?
I can't (possibly a failing on my part).
You honestly sounded like you'd already given it a fair amount of thought, particularly when you spoke of broaching the idea to those in a position to discuss it with a view to potentially introducing it into HTML5.
As a future development, it may have some legs, but imo, in its current form, it doesn't.
(Btw, I tried to make nice in my last post, so enough of the juvenile interjections, eh?)
Share:
Page 1 of 1
All times are GMT
You cannot post new topics in this forumYou cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum