Inconsistent behavior when clicking a label

[jamesplease]

Version: 1.3.0

Browser: Chrome 40.0.2214.111 (64-bit)

Type: bug maybe

Description: Clicking the label of a multiselect opens the options, whereas clicking the label of a single select only focuses the field.

Example: The examples page

[koenpunt]

Not sure what we want with this. I think the problem is that a single select has a clear purpose, and is recognizable for everyone, so they know they can press the arrow key to reveal the options.
But the multiselect isn't that clear, so if we don't show the options on focus, users might don't know what to do with it.

[samjewell]

Good practice for Accessibility is to always focus an input when its label is clicked:

https://webaim.org/techniques/forms/controls

Another benefit of using labels is that the user can click on the label itself to set focus to the form element. This is useful to some with motor disabilities, particularly when selecting small checkboxes and radio buttons. You can try this by clicking on the word "Name:" above to see focus set to the text box. Clicking adjacent labels provides an easy way to check for proper form labeling.

For that reason we'd like the single select to be focused the same way as the multiselect when the label is clicked.

---

Additionally this change would make the components (single- and multi-select) more consistent with one another. In our case this makes it easier for us to write helpers for our Capybara-Rails app:

TestHelper.rb for multi-select looks like:

  def select_from_multi_chosen(label_text, *options)
    label = find("label", text: label_text)

    options.each do |option|
      label.click
      find("li", text: option).click
    end
  end

We'd like to write something similar for the single-select, but we can't right now.

[samjewell]

EDIT:
My colleague points out that clicking the label does focus the input, but just doesn't show the list of options, which I had misunderstood. We were missing a CSS style for the focused state on our repo, so I couldn't even see that the text-input was being focused.

I do still think this behaviour should change though: [I believe that] behaviour when focusing an element (in this case the single-select) should always match the behaviour when clicking that element. I challenge you to find a counter example, where focusing an element has different behaviour to clicking, in any modern browser or mature framework such as Bootstrap.

So, [in my opinion] we should also follow the rule:

• focusing should have the same behaviour as clicking [the single-select]
  • so focusing the single-select should open the list of options, as clicking currently does.

[tjschuck]

@samjewell

I do still think this behaviour should change though: [I believe that] behaviour when focusing an element (in this case the single-select) should always match the behaviour when clicking that element. I challenge you to find a counter example, where focusing an element has different behaviour to clicking, in any modern browser or mature framework such as Bootstrap.

The perfect counter example: an actual single select. For a native select, clicking the label just focuses, but does not expand. See https://jsfiddle.net/msh0pnkv/

---

The actual potential bug here is just that single and multi selects in Chosen behave differently — single just focuses (same as a native single select), while multiple expands (while a native multiple select "just" focuses). However, a native multiple select has no notion of "expanding" — it always shows the multiple options. Arguably, Chosen's final visual state upon "focusing" is similar to a native multiple select's, i.e. showing the options.

This one's pretty hair-splitty, and my inclination is that the current behavior is as correct as any other, particularly in the light of our typical mantra, which is "when in doubt, behave as a native select does".

I'm going to go ahead and close this as something we won't change, but I'm still willing to be persuaded! If anyone else can think of a good justification for changing the current behavior, feel free to weigh in and we may reopen this issue.