6

I have a very specific case where the <select/> elements in a browser interface are replaced with a custom HTML structure while styling is added via CSS and functionality is added via JavaScript. However, this question applies to these situations in general:

What are the advantages and disadvantages of replacing predefined HTML elements with customized solutions 

<div class="select">
    <span>Absolute</span>
    <ul>
        <li>Absolute</li>
        <li>Percent</li>
        <li>Minutes</li>
        <li>Seconds</li>
    </ul>
</div>

I am not a fan of this, but I want my argument against it to be more then just a subjective one but instead back it with actual UX-focused best practices and facts.

Pros

  • Consistent design across browsers

Cons

  • Advanced interaction/shortcuts not possible or require even more JavaScript (Up and down arrows, typing the first letters to jump to option, using the scrollwheel to run through options, etc.)
  • Too many edge cases, breaks more often then not (Latest bug: Options change completely, but <span> didn't and therefor shows non-existent entry)
  • Fails on devices with touch interface

I believe there are more and I'd like to present this issue as thought-out as possible. And I think this is an issue that doesn't just apply to the mentioned <select>.

What are additional arguments and how would you approach this?

Improve this question
4
  • Is the <select> replaced via javascript with this, or is this HTML what is rendered before any javascript is run?
    – Charles Boyung
    May 23, 2011 at 19:55
  • No <select/> is ever rendered in the first place. JavaScript is only used to added functionality to the markup.
    – Jörg
    May 24, 2011 at 7:58
  • All the cons you have listed are all design flaws, not issues with the concept. Everything including accessibility and touch issues can be solved with a well designed version. Jquery Mobile and extJS Mobile both have these kind of touch controls. Or a simple work around is when detecting a mobile browser, pass the click onto the actual select which will bring up the spinner, or just don't replace the select in that case.
    – Chris Janssen
    Nov 17, 2011 at 20:56
  • For the record 'consistent across browsers' is rarely something that matters. People aren't usually using more than one browser at a time.
    – DA01
    Apr 3, 2015 at 5:21

2 Answers 2

Reset to default
3

The example that you have given would probably fail a basic accessibility test.

Read about the forms mode of screen readers here: http://www.pws-ltd.com/sections/articles/2008/accessible_forms.html

most screen reader users tabbing from one form field to the next in forms mode won't hear any content contained in non-form elements such as paragraphs or headings.

This means that most likely screen reader users would not be able to complete the form. Depending on your country this may fall foul of disability discrimination laws, making this not just a usability issue.

All the problems (apart from Javascript not being available) are theoretically fixable with Javascript. However the cost and time involved in creating and testing the Javascript to an acceptable level are likely to be prohibitive (unless you're using an already well used library).

Edit: the library listed bellow by Chris Janssen looks interesting and seems to address many of my concerns.

Improve this answer
3
  • This is actually a pretty good idea since the software "we're" building is scheduled to be submitted to some sort of official test at some point so we can promote the product better by saying "Successfully passed Test X". Right now, the product would most likely fail such a test.
    – Jörg
    May 24, 2011 at 8:00
  • 1
    I think this is a red herring. You can make the described solution accessible as well. Putting it in the tab order correctly, using aria and other methods to have it readable to a screen reader as well. Example: filamentgroup.com/lab/…
    – Chris Janssen
    Nov 17, 2011 at 20:52
  • Nice example. Looks like a fairly solid solution. It's nice to see Aria being used properly - I need to stay more aware of it. I'll adjust my answer a bit to take out the suggestion that the accessibility problems can't be fixed.
    – edeverett
    Nov 17, 2011 at 23:06
-1

I don't think it is useful to replace actual selects in actual forms. It has its uses though when adding menus on the site that are not forms but more like lists of links. Then it is a technique that allows graceful degradation: users without javascript (using text browsers or screen readers) and also search engines have access to the menus without interaction.

However - that technique was used to replace the use of select on non-forms. And the search engine and text browser argument has been a bit outdated. (Although I still think links are better coded as links than as selects.) The point on touch interfaces is interesting. I am not sure how they handle mouseover menus at the moment. On actual forms that are used as forms for getting user info, there is a reason for the select-element and I would most definitely use that.

Improve this answer
1
  • Why do you not think it is useful? The most basic "useful reason" being I want the visual design to look a certain way. The graceful Degradation is an important factor to consider however as you mentioned. Though most sites nowadays require javascript to function so the "they may have javascript turned off" argument is slowly falling to the wayside.
    – Chris Janssen
    Nov 17, 2011 at 20:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.