Skip to content

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

Merged
merged 1 commit into from
Jul 25, 2019

Conversation

crisbeto
Copy link
Member

@crisbeto crisbeto commented Jul 5, 2019

  • 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.

@crisbeto crisbeto added P2 The issue is important to a large percentage of users, with a workaround pr: merge safe target: patch This PR is targeted for the next patch release labels Jul 5, 2019
@crisbeto crisbeto requested a review from andrewseguin as a code owner July 5, 2019 20:48
@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Jul 5, 2019
@kseamon
Copy link
Collaborator

kseamon commented Jul 6, 2019

Is it possible to continue using keyup? That's more consistent with how things like form submission normally work.

@crisbeto crisbeto force-pushed the popover-edit-focus-management branch from 67aebe4 to 700881e Compare July 7, 2019 07:37
@crisbeto
Copy link
Member Author

crisbeto commented Jul 7, 2019

We can't use keydown, because we'd end up with the problem where closing the overlay with a keyboard "click" (e.g. pressing enter on a cdkEditClose) will reopen the overlay immediately because we've restored focus on a keydown.

@crisbeto crisbeto changed the title fix(popover-edit): unable to close by pressing on enter on some screen readers fix(popover-edit): unable to close by pressing enter on some screen readers Jul 7, 2019
Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kseamon LGTY?

@kseamon
Copy link
Collaborator

kseamon commented Jul 24, 2019

LGTM

@jelbourn jelbourn added pr: lgtm action: merge The PR is ready for merge by the caretaker labels Jul 24, 2019
@jelbourn
Copy link
Member

@crisbeto just needs rebase

@crisbeto
Copy link
Member Author

Rebased.

@crisbeto crisbeto force-pushed the popover-edit-focus-management branch from 700881e to 8c52497 Compare July 25, 2019 04:08
…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.
@crisbeto crisbeto force-pushed the popover-edit-focus-management branch from 8c52497 to 7377a62 Compare July 25, 2019 04:22
@jelbourn jelbourn merged commit 615070a into angular:master Jul 25, 2019
andrewseguin pushed a commit that referenced this pull request Jul 29, 2019
…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.
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement P2 The issue is important to a large percentage of users, with a workaround target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants