Tooltip: Focus tooltipped item when tooltip is active, allow tooltip to be dismissed on Esc key

[austinoneil]

Description

Focus tooltipped item when tooltip is active, allow tooltip to be dismissed on escape

References #2177

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

How Has This Been Tested?

End to end tests, manual test using the following html:

    <modus-tooltip text="Tooltip text..." position="right">
      <modus-button tabindex="3">Button</modus-button>
      <modus-button>Button2</modus-button>
    </modus-tooltip>

Also tried without tabindex on first button.

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings

[netlify]

✅ Deploy Preview for moduswebcomponents ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	a470a2b
🔍 Latest deploy log	https://app.netlify.com/sites/moduswebcomponents/deploys/6636e33b184fe100080fe6e3
😎 Deploy Preview	https://deploy-preview-2380--moduswebcomponents.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 27 (🟢 up 1 from production) Accessibility: 98 (no change from production) Best Practices: 92 (no change from production) SEO: 92 (no change from production) PWA: - View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[austinoneil]

Focusing for two reasons:

1. According to ARIA standards, focus stays on the triggering element while the tooltip is displayed.
2. Keyboard interaction is done on focused item only.

[austinoneil]

Adding tabindex to make item focusable. Feel free to suggest alternatives.

[cjwinsor]

@austinoneil Is it possible that this could be simplied to just adding something like

  @Listen('keyup')
  escapeKeyHandler(event: KeyboardEvent) {
    if (event.code === 'Escape') {
      this.hide();
    }
  }

The idea being that @Listen will listen for the keyup event on the Host, so esc won't affect tooltip element unless the focus was on an item within the tooltip and bubbled up.

This avoids tabIndex handling, which I always try to avoid. Let me know if I am overlooking some scenario.

Also I used keyup instead of keydown as it would fire once at the end, while keydown will continue to fire over and over again if held. It occurs to me now that many, if not all, of our other components might be needing this consideration in the future.

FYI @coliff

[austinoneil]

@austinoneil Is it possible that this could be simplied to just adding something like

  @Listen('keyup')
  escapeKeyHandler(event: KeyboardEvent) {
    if (event.code === 'Escape') {
      this.hide();
    }
  }

The idea being that @Listen will listen for the keyup event on the Host, so esc won't affect tooltip element unless the focus was on an item within the tooltip and bubbled up.

This avoids tabIndex handling, which I always try to avoid. Let me know if I am overlooking some scenario.

Also I used keyup instead of keydown as it would fire once at the end, while keydown will continue to fire over and over again if held. It occurs to me now that many, if not all, of our other components might be needing this consideration in the future.

FYI @coliff

The issue with this is that keyevents only occur on the focused element, which needs a non-negative tabindex. The reasoning for this requirement is that having more than one element with the same keyevent listener can cause issues (imagine hitting "enter" and suddenly, every button were triggered.)

I'll file an issue for replacing keydown events with keyup events. I see the issue with using keydown.

[prashanth-offcl]

@austinoneil I tested the implementation with multiple buttons with tooltips locally and have a few observations:

• I need to press the tab key twice to navigate between buttons with tooltips.
• Remove listener in cleanupPopper fn.

I understand the issue with using @Listen since you have to specify the target as document, body, or window because the tooltip is not focusable. Since you are adding the listener to the specific focusable element, the problem of all tooltip instance listeners triggering should not occur. Therefore I believe we should be able to remove the tabIndex logic, can you try it?