-
Notifications
You must be signed in to change notification settings - Fork 6.8k
fix(popover-edit): unable to close by pressing enter on some screen readers #16466
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
fix(popover-edit): unable to close by pressing enter on some screen readers #16466
Conversation
Is it possible to continue using keyup? That's more consistent with how things like form submission normally work. |
67aebe4
to
700881e
Compare
We can't use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@kseamon LGTY?
LGTM |
@crisbeto just needs rebase |
Rebased. |
700881e
to
8c52497
Compare
…n readers * Fixes not being able to close the overlay by pressing Enter on the close button when using some screen readers (tested on NVDA, but I expect it to work similarly in others). The issue comes from the fact that we keep track of whether the user is pressing Enter through `keyup` and `keydown` events, however screen readers emit fake `click` events on buttons instead of `keyup` and `keydown`. * Fixes not being able to close the overlay by clicking on the close button with a mouse, if the keyboard was used to reach the button (e.g. by tabbing to it). This issue also comes from the fact that we were keeping track of keyboard events and assuming that the user will continue using a keyboard to close the overlay. * Gets rid of a bunch of keyboard event tracking logic. **Disclaimer:** I had to introduce a `setTimeout` when trapping focus inside the overlay, in order to prevent the form inside the overlay from being submitted immediately when opening through a `keydown` on Enter. From what I can tell this shouldn't really have an effect on existing tests since we have other timers that are running at the same time.
8c52497
to
7377a62
Compare
…n readers (#16466) * Fixes not being able to close the overlay by pressing Enter on the close button when using some screen readers (tested on NVDA, but I expect it to work similarly in others). The issue comes from the fact that we keep track of whether the user is pressing Enter through `keyup` and `keydown` events, however screen readers emit fake `click` events on buttons instead of `keyup` and `keydown`. * Fixes not being able to close the overlay by clicking on the close button with a mouse, if the keyboard was used to reach the button (e.g. by tabbing to it). This issue also comes from the fact that we were keeping track of keyboard events and assuming that the user will continue using a keyboard to close the overlay. * Gets rid of a bunch of keyboard event tracking logic. **Disclaimer:** I had to introduce a `setTimeout` when trapping focus inside the overlay, in order to prevent the form inside the overlay from being submitted immediately when opening through a `keydown` on Enter. From what I can tell this shouldn't really have an effect on existing tests since we have other timers that are running at the same time.
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
keyup
andkeydown
events, however screen readers emit fakeclick
events on buttons instead ofkeyup
andkeydown
.Disclaimer: I had to introduce a
setTimeout
when trapping focus inside the overlay, in order to prevent the form inside the overlay from being submitted immediately when opening through akeydown
on Enter. From what I can tell this shouldn't really have an effect on existing tests since we have other timers that are running at the same time.