Bug: calcite-popover - trap focus inside

[AdelheidF]

All 3 sub-issues here a related, so I added them into the same issue.

(1) (fixed with the use of `calcite-list`)

Add an option to value list to not allow selection of the text, only `action-end`.

This is a lists of values in the filter component, clicking on a value name does not call an action. Only action-end matters here.

This is a list of detailed information inside a popover. Nothing should happen when you click on the text, only action-end matters here as well.

(2) (fixed with the use of `calcite-list`)

Navigating in this value list is a bit weird. Initially only the first row, first text then action-end, can be selected. If you then tab again it leaves the list. You need to use the down arrow to navigate inside the list, but the down arrow only works on the text, not on action-end. Same with `calcite-pick-list`.

(3) Focus gets lost if there if no other focusable item after the value-list when using tab key after action-end is selected. This is a problem for keyboard only users in the popover case above. How can I catch the focus (or know when the focus leaves value-list) and redirect it back to the close icon of the popover? I tried onBlur but that didn't work. Scenario: popover opens with close button on focus. Then I tab my way through the list. After the last focusable item in the list is active and I hit tab the focus gets lost.

---

New list component https://github.com/Esri/calcite-components/issues/2117

Actual Behavior

Expected Behavior

Reproduction Steps or Sample

Relevant Info

Version: @esri/calcite-components@<version>

• [ ] CDN
• [ ] NPM package

[TheBlueDog]

Follow

[AdelheidF]

(1) and (2) are fixed with the use of the new calcite-list. (3) is still valid. Changed the title.

[macandcheese]

@AdelheidF can you put together a codepen that illustrates this bug? Thanks!

[AdelheidF]

https://codepen.io/afreitag/pen/LYjmaWv?editors=1000

Click on the button to open the popover. Wait until focus sits on close button, now tab 4 times, all good. Now tab one more time, the focus should go back to the close button. How can I know that the focus left the list to set it back to the close button? A keyboard-only user would be lost now.

[macandcheese]

Is this specific to list? Looking at it now it just seems like we don't trap focus inside a popover. That seems like a reasonable thing to have support though.

[AdelheidF]

Is this specific to list?

not really, trap focus inside a popover when only using tab key is the better description for what I need probably.

[AdelheidF]

another use case:

This popover has 2 focusable elements. I tab once to get to the button If I tab one more time the focus is lost from the popover and here on my browser page.

[macandcheese]

Yeah, in that case the behavior could be more like a modal. If we add focus trapping to popover, do we need to offer disableEscape and related options from modal? cc @geospatialem

[geospatialem]

Yeah, in that case the behavior could be more like a modal.

We got similar feedback from a screen reader user earlier this summer, as they were expecting functionality similar to a modal. Would be a great feature to add to the component.

do we need to offer disableEscape and related options from modal?

Ideally we'd like to always allow escape as an option for closing, as it is an expected behavior for keyboard users when open.

It looks like tooltip closes with the escape key, and there is no disableEscape property. Perhaps we could follow suit in this case as opposed to modal? We'd also need to add functionality to allow the escape key for closing the component, as its not currently built in.

[AdelheidF]

I think calcite-modal has the same issue.

We just got an issue from the accessibility testing group about this too.

Violation
Ensure that keyboard focus remains within modal dialogs

[driskull]

@jcfranco should we use this npm package for this? https://www.npmjs.com/package/focus-trap

We could update the modal to use this package too.

[github-actions[bot]]

Installed and assigned for verification.

[geospatialem]

Verified on next.639