[EuiDataGrid] cell focus is broken when only one focusable child

[myasonik]

When there is only one focusable child in a cell, focus should move directly to that element.

This is especially bad because there's no way to focus onto that element to it if that column's details popover is also disabled.

[myasonik]

This is a blocker for Discover's DataGrid reimplementation (elastic/kibana#51531)

[chandlerprall]

Discussion

What is the best way to handle this?

I think the main complication here is how to keep a predictable UX while some cells expand while others do not. In a grid without cell expansion, the rules would be simple: when there is one interactive element then focus on it, for two or more keep cell-level focus until enter or f2 is pressed to toggle into a focus trap wrapping the elements.

What I'm thinking is treat the expansion button as an interactive item within the cell (because it is), and:

• No focusable elements (+ is not expandable): focus cell, no interaction
• Only one focusable element (not expandable): shift focus to the element
• Only one focusable element (the expansion button): outline cell, focus on expansion button
• 2+ focusable elements (not expandable): focus cell, enter/f2 enters focus trap

The tricky situation is the remaining:

• 2+ focusable elements (expansion button and 1+ custom elements)

I have some thoughts, but want to make sure we reach an agreement on the rest before diving in.

[snide]

I agree on your list. 👍

[chandlerprall]

That was 19 days ago? :eek:

In the latter case, 2+ focusable elements (expansion button and 1+ custom elements), I feel we're stuck with a decision between some variant of

• as with the other 2+ elements case, focus on cell, enable enter/f2 to enter a focus trap, and user can tab to the expansion button
• act as if there isn't an interactive element in the cell and auto-focus the expansion button - this is probably a terrible idea for accessibility as no one will test for it

I think there's a weird interaction lingering with enter+expansion here. For non-expandable cells, we'd be treating enter and f2 separately. Maybe this needs a step back? Open to any & all thoughts here.

/cc @snide and @myasonik to force a mention :)

[myasonik]

I'm actually ok with either interaction I think...

I think a strict adherence to the spec would push us towards the first option. This option is nice because it seems consistent across the board. It's less cases to keep track of both for users and in our code.

Though, I can see an argument being made that the second option is actually the better UX because it seems like our "recommended" interaction pattern with interactive content within a cell is to interact with it within the popover which is what this option pushes you to. And I think all the content is still accessible for screen reader (sighted or not) and keyboard-only users.

---

this is probably a terrible idea for accessibility as no one will test for it

What do you mean by "no one will test for it"? Maybe I'm missing something. Do you mean that a user won't know to "open" the cell because it seems like there's no interactive content? That's fair and a good thought... I think if we provided some screen reader only content (e.g., "This cell contains interactive content within its popover." (that's too wordy, don't use those words)) that would cover our bases pretty well. (Sighted users would be able to see the interactive content and hopefully our slightly inconsistent focusing-scheme would be simpler in practice than it is to try to explain it...

[snide]

When 2 items are in there I would just focus the cell (which is the expansion) and not the inner elements. They can always open the popover and interact with the content there with a keyboard. Mouseclickers are fine either way.

The reasoning is that truncation means it is not always apparent there are multiple items in there.

It's also really simple and covers our needs.

[chandlerprall]

Do you mean that a user won't know to "open" the cell because it seems like there's no interactive content?

They can always open the popover and interact with the content there with a keyboard. Mouseclickers are fine either way.

Same answer for both of these -I think there's concern if popover doesn't include the actions, for some reason. In that case the only way to interact with the items is with a mouse, and I wouldn't expect devs to always remember that is the case (what I meant by "as no one will test for it").

I'll put a PR together to explore these options.

[snide]

Just so this doesn't go down a rabbit hole, I'll mention that last concern can be mostly solved by good docs and guidelines.