Dropdown with placeholder - first option automatically selected on focus.

[chrismohr]

Bug Report

• Package version(s): > 6.25.1
• Browser and OS versions: Chrome 67.0.3396.99, OSX 10.12.6

Priorities and help requested:

Are you willing to submit a PR to fix? Yes

Requested priority: Normal

Products/sites affected: Yammer

Describe the issue:

Starting in 6.25.1, the behavior of a Dropdown with a placeholder has changed. Previously clicking to open it would not change the value, now it does.

Actual behavior:

The first value is selected.

Expected behavior:

The placeholder continues to show.

If applicable, please provide a codepen repro:

https://codepen.io/chrismohr/pen/BVgXYv

[cliffkoh]

Hi @chrismohr, this was a by-design change, following W3C Accessibility guidelines for good screen reader experience. What is your scenario that is adversely impacted by this change? Perhaps we can augment some of the methods (e.g onChange) to differentiate between when the Dropdown auto selected an option from a placeholder or if it was a user action.

[chrismohr]

@cliffkoh, in any scenario where completion of the dropdown is optional, it is currently not possible for a keyboard navigation user to tab over the field without selecting a value. It also seems like a negative experience for mouse users who want to click to reveal the available options, but then decide they want to leave the field blank.

I'd be interested to hear more details about the accessibility guidelines that you were meeting with this change, also if you have more specific suggestions for a solution, I can submit an updated PR that meets all of our requirements here.

[chrismohr]

I edited the title of the issue to say 'focus' rather than 'click'.

[BrendanMcK]

Hi @cliffkoh - can you outline the original issue that was fixed here, and which specific WCAG item is being addressed? Generally speaking, focusing a control should not change the input value - this is to allow both keyboard and screenreader users to tab past the control to other controls without affecting it. I'm wondering if in the process of fixing some other issue, this regression was introduced?

As Chris outlines above, as a keyboard or screenreader user, if I tab through this control, it will have the side effect of picking the first value, which IMO should only take place if I select that value intentionally. That's not particularly user-friendly. Imagine if hovering the mouse over the control automatically selected the first value - that's somewhat analogous to what we're doing here.

I'm noticing that the people picker control also has a bug in this area - I'll open a separate issue on that.

[cliffkoh]

So, the W3C accessibility spec recommends, but does not require selecting an option when it gets focus. The problem is that Fabric's Dropdown behaves like an opened Dropdown even when it is closed and in placeholder, in that you can press the arrow keys up and down to change the option. So as such, the Dropdown needs to specify via the aria-size and aria-posInSet attributes to inform the screen reader that despite there only being 1 element in the DOM, it is actually one option out of a larger set of options.

If the first option is not selected on the other hand, I do not know how to communicate organically (without hardcoding a non-localizable string in Fabric) that you can use the arrow keys to change the selected options - or the total number of selectable options.

Welcome suggestions/PRs where we get the best of both worlds :)

[BrendanMcK]

Issue re the people picker control - that one is a bit more severe, as tabbing through can end up selecting additional items each time the user passes through.

#5915

[BrendanMcK]

So, the W3C accessibility spec recommends, but does not require selecting an option when it gets focus

Can you point me towards this specific item?

[BrendanMcK]

the W3C accessibility spec recommends, but does not require selecting an option when it gets focus

FWIW, I'm aware of a suggestion for popup menus for the first item to receive focus when the menu is opened via keyboard; but that's expected since opening is triggered by an explicit user interaction. Focusing would not be expected to trigger this, though.

The problem is that Fabric's Dropdown behaves like an opened Dropdown even when it is closed

So it's sounding like a Fabric internals / implementation issue means that fixing one issue (at least this way) ends up introducing another as an unwanted side-effect, so is not actually by-design? (By design suggests that this is the intended/desired behavior here.)

[cliffkoh]

https://www.w3.org/TR/wai-aria-practices-1.1/#listbox_kbd_interaction

Specifically

When a single-select listbox receives focus:

• If none of the options are selected before the listbox receives focus, the first option receives focus. Optionally, the first option may be automatically selected.
• If an option is selected before the listbox receives focus, focus is set on the selected option.

[cliffkoh]

So I actually mis-spoke. Because the Fabric Dropdown behaves as a Dropdown even when collapsed (you can use the arrow keys to switch between options), focusing on the first option MEANS that the first option gets selected - there is no way to drop focus on the first option otherwise (the first option if not selected is not even rendered in DOM).

In other words, the current exhibited behavior is a requirement of the spec and not just a recommendation...