Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-autofocused Popover not reachable by keyboard #8702

Open
9 of 10 tasks
rolfsmeds opened this issue Feb 20, 2025 · 5 comments
Open
9 of 10 tasks

Non-autofocused Popover not reachable by keyboard #8702

rolfsmeds opened this issue Feb 20, 2025 · 5 comments
Assignees
Labels
a11y Accessibility issue vaadin-popover

Comments

@rolfsmeds
Copy link
Contributor

What is the problem?

A Popover that is not modal or otherwise configured to automatically steal focus is inherently inaccessible by keyboard (unless some custom means of moving focus to it is provided).

A couple of solution options come to mind:

  • "Tab index emulation": programmatically moving focus to the overlay when tab is pressed on the target element after opening the popover. (And moving it back to the target element after the last tab stop inside the overlay; after returning to the target element, the "tab hijacking" is no longer in effect.)
  • Refactoring Popover (and other overlays) to be based on native popover (and/or <dialog>) and moving them from the dedicated overlay section at the end of the DOM to be immediate siblings of the target element, whereby the overlay's first tab stop will natively follow the target element.

Browsers

  • Chrome
  • Firefox
  • Safari
  • Safari on iOS
  • Edge

Screen Readers

  • None
  • NVDA
  • JAWS
  • VoiceOver on MacOS
  • VoiceOver on iOS
@rolfsmeds rolfsmeds added a11y Accessibility issue vaadin-popover labels Feb 20, 2025
@web-padawan
Copy link
Member

"Tab index emulation": programmatically moving focus to the overlay when tab is pressed on the target element after opening the popover.

Just to clarify: this has been implemented by #7609 according to the specification from #7607.

Especially, instead of "moving it back to the target element after the last tab stop inside the overlay" we move focus to the next element in the DOM that comes after the popover target (and I believe this is how it would also work with native popover).

@rolfsmeds
Copy link
Contributor Author

Ah, indeed, I think the reason I thought it hadn't been is that it doesn't work with the "interactive tooltip" sample in the docs, but I suppose that is because the popover actually closes on blur when you tab onwards from it? (What actually happens there is when tabbing while focus is in the field is that the popover closes but focus doesn't move anywhere – presumably due to this mechanism.)

@web-padawan
Copy link
Member

Yes, I think the problem in that example is that it closes due to the focus trigger. I'll take a look if we can fix that.

@rolfsmeds
Copy link
Contributor Author

I actually already created this ticket: vaadin/docs#4147

@web-padawan
Copy link
Member

Actually, I found a bug with the Tab logic of the popover: it checks isElementFocusable(this.target) and this returns true for the native input but false for vaadin-text-field where we have focusElement as focusable instead.

So this is somewhat similar to #8703 where wrong element is used. I'll work on a fix to also check for focusElement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y Accessibility issue vaadin-popover
Projects
None yet
Development

No branches or pull requests

2 participants