Popover support for trigger events such as click (`Enter`) and hover (`:focus`)

[geospatialem]

Description

The ArcGIS Urban team needs the following kinds of non-modal components (using tooltips/popovers):

• [x] Displays on hover (and on focus for keyboard accessibility compliance) and contains a simple text → tooltip
• [x] Displays on click (and on Enter key press, for accessibility compliance as well) contains more complex content such as links, Checkbox, Input Date Picker, Button etc. → popover
• [ ] Displays on :hover (and :focus) only and contains more complex content → popover (refer to the acceptance criteria below)

Acceptance Criteria

Open popover with different types of trigger events like in type in dropdown with the following options:

• Click and the Enter key or
• Hover and when focused
  • If this option is selected there should be a way that the click and enter key events do not toggle the component's open prop.

Use case screenshots:

Relevant Info

Would be similar in functionality to the type in Dropdown.

Accessibility and documentation around its accessibility will need to be considered to ensure the popover contents are provided to assistive technologies. In the [following example] the popover contents are only provided to assistive technologies when in focus (not while hovered, which could be provided via an aria-live prop.

Which Component

popover

Example Use Case

The following Codepen serves as a hacky example but disables the focus trap using the focusTrapDisabled property, which is the expected behavior for assistive technologies. It also still includes the ability to open the component with a click or Enter key event.

Esri team

ArcGIS Urban

[Anastasiia-Boleiko]

Hello,

Could you please clarify what is the approximate time for having this feature in the Calcite release?

Thank you.

[geospatialem]

Hello,

Could you please clarify what is the approximate time for having this feature in the Calcite release?

Thank you.

Thanks for re-pinging this issue, @Anastasiia-Boleiko. It looks like the description was removed with one of our automations so this one got lost in the shuttle. We'll be taking a look/sign-off on design in the near future.

[github-actions[bot]]

cc @geospatialem, @brittneytewks

[geospatialem]

Check into the autofocus on hover with dropdown for accessibility considerations.

[geospatialem]

The functionality looks okay when animations are disabled (Windows) or reduced (Mac) when coupled with other elements on the page and focus shifts on hover.

There do not appear to be any accessibility concerns in scoping with the request.

[driskull]

Check into the autofocus on hover with dropdown for accessibility considerations.

Yeah that might be weird if a dialog role (popover) is automatically opened and focused when a reference element is hovered.

[driskull]

I'm not sure this is a valid use case. When hovering or focusing a reference element and having the popover automatically open it would automatically focus and trap on the popover. I don't think that is a good experience when someone is tabbing through the document to have their focus automatically taken away.

[Anastasiia-Boleiko]

I'm not sure this is a valid use case.

@driskull I understand your concerns. However, have you considered whether the following user interface is a valid use case? When user focuses a tool button:

• a popover with help info and a link is displayed
• the focus is moved to the More how link (the first component in the popover)
• and there is no focus trap. Under the focus trap, in this case, I mean allowing a user to use "Tab" key to navigate to the next interactive element, which is the next tool button in this specific case.

P.s.: Click does not work in this case since it activates the tool.

Also, in case, a popover has auto-close property, I would consider having no trap. This means that when the popover is opened and there are no interactive elements inside, or the user has focused the last interactive element within the popover, pressing "Tab" moves the focus to the next interactive element outside of the popover. In this example, when the popover is open, the user should be able to move on to the next interactive element, such as "Button 2," without having to close the popover. What is your opinion on this?

[driskull]

I'm not sure if thats a valid use case, its hard to say since that comparison is adobe photoshop and not a web browser.

Also, in case, a popover has auto-close property, I would consider having no trap. This means that when the popover is opened and there are no interactive elements inside, or the user has focused the last interactive element within the popover, pressing "Tab" moves the focus to the next interactive element outside of the popover.

I think in this case a tooltip would work, right?

[geospatialem]

Reassigning to November as a research spike effort for additional efforts.

[Anastasiia-Boleiko]

I think in this case a tooltip would work, right?

It would work, but only for mouse users. When navigating using the keyboard, the link provided in the tooltip is not accessible.

Additional info and thoughts

I saw the recommendation of this pattern in the Tooltip Guidelines article by Nielsen Norman Group. They provided an example on the web: https://en.wikipedia.org/wiki/Aristotle

However, it also seems to be not compliant with a11y requirements since I couldn't get inside the tooltip to get to the "View similar pages" link when navigating using the keyboard.

And, yes, I see your concerns, but I couldn't find a good and accessible solution for our use case. To sum up:

• onHover solution (Calcite Tooltip) was created for text-based content according to the Tooltip / Overview docs and it does not "support" interactive components inside (from the a11y perspective) since focus does not move inside the tooltip. In the docs: "To support interactive content, consider Popover."

• onClick solution (Calcite Popover) wouldn't work for us since this click is preserved for activating a tool in the toolbar. And we do not consider simultaneous activating of a tool and popover display. A user is assumed to get more info about the tool from the popover (on hover) and in case they would like to use it, they would activate it (on click).

I'll try to throw 3 ideas, they're not ideal, but would partially serve the described use case and will be relatively compliant.

Imagine the horizontal toolbar. Each tool has a tooltip/popover with text content and a Learn more link.

Idea 1:

Here is no role="toolbar" applied, a user navigates using the Tab key. A change to the Calcite Popover is needed: popover should be triggered with :hover.

When user hovers/focuses (with Tab) a tool button (which is a popover trigger) => a Calcite Popover appears and focus moves to the 1st interactive component. Next element in the focus order is the next tool in a row. It's not ideal, since activating the tool that has a popover displayed requires pressing Shift+Tab to return to the tool button.

Idea 2:

Here is no role="toolbar" applied, a user navigates using the Tab key. A change to the Calcite Popover is needed: focus is not automatically moved to the 1st element inside the popover.

When user hovers/focuses (with Tab) a tool button which is a popover trigger => a Calcite Popover appears and focus does not move to the 1st interactive component Next element in the focus order is the Learn more link in a row. And the next element in the focus order is the next tool in a row. It's more convenient if a user wants to activate a tool rather than read info about it, but it's not compliant with a11y requirement (focus does not move to the 1st element in the dialog programmatically).

Idea 3:

Here is role="toolbar" applied, a user navigates using arrow keys ← →. No change to the Calcite Popover is needed, a Calcite Tooltip is used instead: focus is not moved inside the tooltip at all.

When user hovers/focuses (with arrow) a tool button which is tooltip trigger => a Calcite Tooltip appears and focus does not move to the 1st interactive component. The link inside is not accessible from the keyboard. Next element in the focus order (with arrow) is the next tool in a row. The toolbar pattern has a correct keyboard interaction (navigated with arrows), but it's not compliant with a11y requirements (the link is not accessible for keyboard users).

Idea 4:

No matter if role="toolbar" is applied or not, a user navigates either using Tab or arrow keys ← →. A change to the Calcite Popover is needed: popover should be triggered with :hover, and arrow keystroke (for example, down arrow ↓).

When user hovers a tool button which is popover trigger => a Calcite Popover appears Alternative for keyboard users: When user focuses a tool button which is popover trigger => a Calcite Popover does not appear, but pressing ↓ keystroke displays the popover and moves focus to the 1st interactive component inside the popover (ex.: Learn more link). Next element in the focus order (with Tab) is the next tool in a row. This behavior seems to be compliant with a11y requirements (the link is accessible for keyboard users), but not an explicit and not intuitive because of using the arrow keystroke.

[driskull]

I think we could enhance the tooltip to have arrow key support to select focusable elements. We would just not promote this approach because there are currently no a11y guidelines for this. However, it would work for both mouse and keyboard users if we do this. We could still keep our doc guidelines that no interactive elements should be in a tooltip but if they are we can make them work. Would this work?

[Anastasiia-Boleiko]

I think yes, this should work. Thanks a lot for your response!👍

[github-actions[bot]]

cc @geospatialem, @brittneytewks

[github-actions[bot]]

Installed and assigned for verification.

[DitwanP]

🍡 Verified on 2.12.0-next.6 https://codepen.io/Ditwan-Price/pen/QWXgrJX?editors=100