Interfaces that have to die - the onchange select box
It is scary how some obviously bad practices refuse to go away and developers jump through hoops to defend them and make them work rather than using simpler alternatives.
My pet peeve is the “chess rules” select box (you touched it, it needs to move):
<select onchange="window.location=this.options[this.selectedIndex].value">
<option value="http://yahoo.co.uk">Yahoo</option>
<option value="http://b3ta.com">B3TA</option>
<option value="http://google.co.uk">Google</option>
</select>This is the most evil permutation of this interface idea. A lesser evil version is part of a large form that will change the rest of the form or - if we venture back into more evil lairs - submits it to reflect these changes.
The arguments for this interface are not many:
- It saves the user one step of pressing a submit button
- The action is immediate
(Ok, these are actually the same argument, comment if you know some.)
The drawbacks of the solution are immense:
- People that use a keyboard will submit the form or leave the page without having selected the right option.
- People that are dependent on using a keyboard for web access will possibly know that you can press the Alt+Arrow Down keys simultaneously to expand the whole dropdown before selecting with arrow up and down and enter.
- Most people won’t know this though and a lot of people use keyboards and tabbing from field to field to fill out forms.
- Forms are a terrible annoyance of our times - nobody likes filling them in. Most of the time we won’t keep our eyes on the screen but actually look up information on papers, our credit card or read up the fine print that - of course - is not on the screen but only in the letter we got sent.
- I have no clue how something like that works with switch access or voice recognition - probably not
- It is scripting dependent - no JavaScript, no service
The latter is actually a reason for some companies for using this from time to time. Too many links on the same page are bad for SEO - Google considers your page not content but a sitemap and ranks it lower. That’s why some companies start offering the first two levels of navigation as links and the rest as a dropdown in this manner.
However, that still doesn’t make them a good solution, it just means that you offer far too many options to your users to begin with.
Here’s what people do to make this work: Aaron Cannon on the WebAim mailing list
A coworker and I recently devised a way to make a slightly more accessible version of the onchange dropdown navigation box. Basically, using javascript, we determine whether they are using their mouse or the keyboard to select each item in the list. If they used the mouse, it works as usual, immediately taking them to the selected page. If however the selection was made by the keyboard, we display a spinner and delay x number of seconds. If the user doesn’t make another selection within that time, they are taken to the page they selected. If they do, the clock is restarted.
I am not attacking Aaron here, he probably was asked to find a solution no matter what and did his best to find a technical way. The big scare in this for me is “determine whether they are using a mouse or keyboard”. My guess is they check for the event type, but assistive technology like voice recognition must simulate clicks without being a mouse. The other danger signal is the timer and the spinner - this complicates the interface even further (”Is this loading?”).
I simply don’t understand why we constantly try to make things work because this is what the design spec says or this is what we saw somewhere else. How about really testing it with users and see what happens then?
Tags: accessibility, interface, scripting, selectboxes, ui, ux, web
July 10th, 2008 at 1:55 pm
I was ready this hoping you’d come up with a genius solution and were going to reveal all at the end ;)
Also, worth mentioning that this works differently on different browsers, Firefox (for example) doesn’t fire the change event until the user tabs out of the field or presses enter, IE fires the change event as you describe.
July 10th, 2008 at 5:09 pm
Another argument I’ve heard for this one is that it saves space in a navigation area by using a compact design element to list many links.
This too, is bogus. There’s no reason that this can not be done with simply enhancing a UL full of links into a drop down list, expandable list, or tree-style menu.
I’m not a fan of drop downs either way, but at the very least, the things that the user clicks on are actually coded as anchor elements that give a clue to their behavior (and don’t act until you actually click on the anchor).
July 10th, 2008 at 5:43 pm
@bugrain, the solution is on a case-by-case basis of course. I’ve done an example for connected select boxes before.
For massive navigations, I’d opt for the main sections as links and a good search autocomplete solution.
July 10th, 2008 at 6:46 pm
Hey Chris, another big issue with the js solutions is related with the differences between the browsers, for example: if you click on a select on safari3, is will display the list but will not fire the onclick event, and so on. Most of the implementations out there are no 100% trustworthy from javascript, and of course will not work without javascript. I’ve been working in a YUI extension to normalize the events in all the major browsers, giving to the developers a hook to set the behaviors for all the form elements in an easy to use unobtrusive way, and without too much javascript coding or none. In the case of the SELECTs, I’ll control the focus and the value, when the element lost the focus, and the value has changed, the system will fire the corresponding behavior on change. From my point of view, this approach is friendly with the “assistive technologies”. What do you think?
July 15th, 2008 at 9:44 am
Marketing people hate ‘ok’ buttons, too.
Here’s one practical case of an application for sellers on the phone: sellers use three select lists in a row. The first populates the second, which when selected in its turn populates the third. All this is done with JS of course.
When we told them that OK buttons had to be added, they told us that people would have to click six times instead of three. Good point, I guess. Productivity should not be hindered by accessibility.
So we had to resolve to doing some kind of reverse thinking on that one: first we have a simple form behaviour with three OK buttons etc; then we insert somewhere around the top of the page an icon that says something along the lines of “I need my OK buttons”, adds
onchangeevent handlers to the selects, and hides the buttons. If we click on the icon then we fall back on the default script: show OK buttons, reactonclick, disableonchangeon the selects.It does work according to spec. I hated the idea of hiding OK buttons, but now everyone seems quite happy with this solution. And if I didn’t propose this solution they would have rejected accessibility as a whole (yeah, I know).
Obviously it is more an application-oriented solution than an all-public solution, as it needs a bit of time getting used to it.
July 15th, 2008 at 9:46 am
PS: of course “if we click” is to be understood loosely, because as many of your readers will know
onclickis also triggered by keyboard through the ‘enter’ key. :)August 9th, 2008 at 11:13 am
Criticising things is easy. Could you provide a solution for the situation where:
There are 2 select controls - one for Country - the second for region. Obviously region displayed will depend on the country selected.
A text box can’t be used for region because it’s unlikely the user will be able to guess the region ( region may not be exact geographical name )
With 2 select controls done using JavaScript this is easy. An accessible ( i.e. suitable for the 0.001% of users who are blind ) is impossible ( but please add a solution if it is possible and I’ll gladly use it)