Dropdown should only focus item when keyboard is pressed

[jquense]

from #1213. CC @rstormsf

I didn't realize that the menu focusing was happening on mouse clicks as well, that is probably not the proper behavior but ARIA stuff only really covers keyboard interaction. Baring someone informing us otherwise I think we should limit the "open and focus first" to keyboard triggers.

[mtscout6]

In #1213 @stubbornella pointed out that she's not a fan of divergent behavior between keyboard and mouse users. While I can agree to a point I think these are vastly different concerns. I think it can be assumed that if a user used the mouse they will continue to do so, thus negating the need to display focus.

One example from some accessibility guidelines describe an invisible "skip to main content" link prior to site navigation. You can see such an example on the WebAIM page. After the page load and before you click on anything hit the TAB key. You'll notice a new button show up that is specific for keyboard users. I know this is not the same as Dropdowns, but it does highlight that sometimes it makes sense to have varying behavior for keyboard vs. mouse users.

[jquense]

So having just checked some implementations I am starting to lean a bit the other way. jquery UI has our current behavior (focus on open), and it is highly respected in its a11y work. As a counter point kendo ui does not, though i would go with jquery ui over kendo in terms of trusting a11y work

[taion]

Is it worth documenting that we're explicitly not matching upstream TWBS here: http://getbootstrap.com/components/#btn-dropdowns-single? My a11y knowledge is too limited to comment on which is more correct - it seems fine to not match TWBS for the purpose of improved a11y, but we should probably document it more clearly.

[rstormsf]

jquery ui, makes it focused, but they don't have native browser focused behavior(overriden styling)(blue one with Chrome) which makes it looks nice.
so if you want to go that route, it would be great not to have ugly blue highlight in menu in my case with Chrome.

[trevorbernard]

Is there any way to override this functionality? If no, should there be a way to?

[taion]

Looking at this a bit more, it does seem really weird to put focus on an item where the cursor isn't. I think we do have a really good reason here to make mouse behavior different in that the user is actively still focusing the button with the mouse, whereas that's not the case if the mouse is not being used.

[rstormsf]

Thank you @trevorbernard @taion for understanding

[jquense]

hmm I don't actually find the shifting of focus from the cursor odd. since most complex inputs do this, like comboboxes/datepickers keeping focus in the input vs the dropdown button, or native selects. even react bootstrap modals have essentially this behavior, shifting focus from the trigger to the modal content.

it seems like folks problem here is mostly visual not functional. If ppl don't like the look of focused items then they can style them however they want but I wouldn't make something less accessible bc folks think the default focus outline is ugly. (which is not to say that I know it would be less accessible)

[rstormsf]

We don't have any problem with functionality, as you said. It's only visual appearance.
Sure, we can just override it with our own styles.

[jquense]

Also some context for why bootstrap doesn't do anything about focus styling on its elements, generally. twbs/bootstrap#15983

[taion]

@jquense

In the case of the modal, I do think it's semantic - since the modal is up, you can't focus e.g. the button you clicked on to show toe modal any more.

It makes semantic sense to think of e.g. a datepicker button as being part of the input, so the focus move on click makes sense. On the other hand, it'd be very weird if focus moved to something in the datepicker's calendar.

For a menu example, consider e.g. native menus - they always keep focus on the menu element on click, rather than move focus to the first entry in the menu. I think the comparison to native really makes this feel semantically jarring, because I consider the position of my mouse to (somewhat) indicate my intent for what I want to focus, and it's not even going to e.g. a text input where I'd want to switch to keyboard to type something in.

The next interaction in general is going to look like moving the mouse down into the menu to select an item anyway, so you're not really helping the mouse user at all by pre-focusing the first entry.

[taion]

Following up here - @jquense @mtscout6 @stubbornella: do we specifically want dropdowns to focus the first element on a click on the dropdown button, instead of just a keyboard interaction?

[mtscout6]

I personally do not want it to focus when using mouse click.

[jquense]

my vote is to match the jquery-ui behavior, focus on both keyboard and mouse. I don't feel that strongly about it tho, thought it might actually be a bit harder to fix now with my recent changes...

It would be nice to get some feedback from someone with real a11y experience tho. I will post in the a11y slack

[trevorbernard]

TBH, I don't care what the default behaviour is only that I have a supported way to turn it on or off.

[cipater]

it seems like folks problem here is mostly visual not functional.

I feel the issue is functional from a UX perspective. My experience here is that the first menu item is highlighted, and remains highlighted while the mouse hovers over the other menu items.

What does it mean to have both the first item AND the item I'm currently hovering over highlighted? I find it confusing and expect my users to have the same reaction.

It's suggested that I can style the :focus background, but then wouldn't I be losing the highlight for keyboard users?

Personally, I feel it's a mistake and bad UX to mix the usage of :focus and :hover within the same context. For a dropdown menu opened by a mouse click, :focus is meaningless on anything other than the element that was initially clicked.

At best, the current behavior is a visual annoyance (still bad UI), and at worst, it could cause unintended user behavior if they start drawing their own conclusions about why the first item stays highlighted.

[mtscout6]

TBH, I don't care what the default behaviour is only that I have a supported way to turn it on or off.

I agree that the ability to customize what you want is a great option.

I feel the issue is functional from a UX perspective. My experience here is that the first menu item is highlighted, and remains highlighted while the mouse hovers over the other menu items.

This is why I think it should be turned off by default. Accessibility is a matter of UX, which is partly why we think about it so those with disabilities have a great user experience. Though making that experience detract from a visual mouse user's experience is contrary to UX since it is degrading the user's experience.

I don't have the time to address the issue myself, but I have changed the labels to reflect that we would entertain a PR that would allow you to toggle the option you wish to use. With that said, I still think the default option should be not to focus when using the mouse. The default option I'm proposing seams to be the one desired by the majority of those using the library.

[taion]

@jquense Did you ever hear back from the a11y Slack?

[vikynandha-zz]

Sorry for joining the discussion so late. Given that this library is just a React port of Bootstrap's components, isn't it better to keep the behavior consistent with that of Bootstrap?

[taion]

In general, we'd prefer to do so. However, when TWBS directly contradicts accessibility best practices, it's a tradeoff between which we follow. We're not going to get rid of the focus behavior on keyboard interaction. For mouse, see #1373.

[vikynandha-zz]

I don't think bootstrap's behavior contradicts accessibility. In bootstrap, activating a dropdown via keyboard keeps the focus on the dropdown-toggle, but you can press down arrow or TAB to move the focus down the list. I think this is natural.

This behavior is consistent with menu bars in desktop apps as well. For example, when you press Alt+F, it activates File menu in most applications, and it does NOT focus the first or any item by default. Only pressing an arrow key focus the focus down to the first menu item.

Screenshot from Ubuntu's native File explorer (nautilus):

[vikynandha-zz]

One more example from Gmail: When you open the More dropdown via keyboard (by pressing .), the focus remains on the More button, and you use down arrow to focus a menu item.

[taion]

This is straight from http://www.w3.org/TR/wai-aria-practices/#menu:

• If a menu bar item has focus and the menu is not open, then:
  • Enter, Space, and the up down arrow keys opens the menu and places focus on the first menu item in the opened menu or child menu bar.

[vikynandha-zz]

@taion Thanks for the link. However, the same article clearly distinguishes between a menu bar and a menu button - http://www.w3.org/TR/wai-aria-practices/#menubutton:

• Space or Enter - With focus on the button pressing Space or Enter will toggle the display of the drop-down menu. Focus remains on the button.
• Down Arrow -
  • With focus on the button and no drop-down menu displayed, pressing Down Arrow will open the drop-down menu and move focus into the menu and onto the first menu item.
  • With focus on the button and the drop-down menu open, pressing Down Arrow will move focus into the menu onto the first menu item.

Though the Dropdown component could be used both in a nav and as a button dropdown, I guess a button dropdown is more common in a web app, than a navbar dropdown. Wouldn't it be better to air on the side of button dropdown, like Bootstrap did?

[jquense]

it's better to err on the side of more complete behavior than less here. even if the behavior is a bit over zealous in the one case. at least that's what I've heard from folks that know more about this area than me.

we have a PR to set the be fault to no focus on click which should address folks original concerns.

[taion]

Wait, hold on, I think I messed up. @vikynandha I think you're correct in that menu button is the applicable one here - I'll submit another PR to not focus the first item on space/enter.

[vikynandha-zz]

Thanks @taion :)

[jquense]

so menu button is probably not applicable in the case of a navbar or nav dropdown which would constitute a menu bar. do we want to try an have different behavior for each case?

[taion]

That's funny though - even the examples at http://www.w3.org/TR/wai-aria-practices/#menu don't do the right thing for space/enter. We also don't implement any of the other menu-related behavior. That said, this gives me enough to clean up what I have a bit.

[jquense]

what other menu behavior? it seems like we implement all the keyboard interactions?

I really hate focus stuff its always such a pain to work with :P

[taion]

Left or right arrow keys move focus to the adjacent menu bar item.

[jquense]

fair enough, tho I would hope we get to that one, but thats more of a Nav/Navbar enhancement

[taion]

Yup. That's also more of an optional thing I think - e.g. if you have a navbar with 3 normal buttons and 1 dropdown, it's not obvious to me that the dropdown has the role of a menu item inside a menu bar, v. being a menu button. But regardless, seems clean enough just to hook off role.