[Discuss] Interaction spec for input+popover form-like components

[thompsongl]

EUI has a good number of components composed of an input and a popover, either extending or simulating a form control.

• EuiInputPopover
• EuiComboBox
• EuiSuperSelect
• EuiColorPicker
• EuiDatePicker
• EuiSuggest
• EuiFilterGroup
• Others?

See the latest discussion below, but each of these has a slightly different interaction paradigm in regards to focus, popover open/close, and a11y more generally. I'd like to decide on an interaction spec and align each to the outcome.

Notable:

• Does the popover open on focus?
• Does the input indicate that a popover attachable (e.g., down arrow icon)? Is that indicator interactive (e.g., EuiComboBox has a button)?
• What keys do what? esc is clear, but tab and arrow down are less-so.
• Do the popovers trap focus? This will likely depend on the component and that variance is ok.

---

2. Tabbing into the input should automatically open the popover

This is unchanged from the current behavior and different from the what happens in EuiColorPicker. I think the idea is that a user would be able to tab through the form without opening (and tabbing through) the popover if desired.

I think this brings up a good candidate for discussion. Without a screen reader, there's nothing telling keyboard users to press down to open the popover. We should probably discuss and nail down this type of behavior for all inputs with dropdowns.

The usual solution to this is:

• focus on control opens whatever it needs (in this case, focus on input opens the DatePicker)
• tab moves focus into the popover
• esc closes the popover and puts focus on the input with the popover closed
• tab moves focus to the next tabbable element on the page

Next time a user lands on the control (e.g., input), it starts over at the top where the popover opens. This does have the downside of after pressing esc the only way to open the popover is to tab out and back into the control but that's not often a dealbreaker.

We can explore other strategies (e.g., using a modifier to open the popover, adding a button to open the popover, etc) but starting with the usual solution might be a good immediate fix even while we discuss others.

Originally posted by @myasonik in #4243 (comment)

[myasonik]

A few misc notes:

• There's also the broad EuiInputPopover should probably be in this discussion though how general it is might make it difficult to nail anything down for it.

• There's also EuiFilterGroup but I think that's built up from other components so it might get brought inline as others are.

• Why is EuiSuggest to a lesser degree? I think EuiSuperSelect, EuiSuggest, EuiCombobox should all work effectively the same way, each just building on the other. (And all 3 should be built on top of EuiSelectable.)

I'd like to decide on an interaction spec and align each to the outcome.

+1 Yes please!

[cchaos]

💯 I agree with all this.

The original intent of EuiSelectable was always to end up replacing any "list" style components with a single source. I've even started building the Figma components in this manner.

I've added a line item to our 2021 roadmap to work this into. #4054

[cchaos]

Just making note here about an open-source "fully" accessible auto-complete component we can inspect when fixing up EuiSelectable. https://github.com/alphagov/accessible-autocomplete

[github-actions]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[cee-chen]

Closing in favor of #5813 - we're going the route of ensuring different popover-adjacent components have clear SR instructions rather than attempting to homogenously ensure all components are the same.

[daveyholler]

Closing in favor of this work: #6589