这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@robdodson
Copy link
Collaborator

This might need more testing but it seemed to pass all of our local and sauce tests.

@robdodson robdodson requested a review from alice June 19, 2018 21:12
@robdodson
Copy link
Collaborator Author

Assigning to @alice to take a look when she gets back from vacation.


if (hadKeyboardEvent || focusTriggersKeyboardModality(e.target)) {
addFocusVisibleClass(e.target);
hadKeyboardEvent = false;
Copy link
Member

Choose a reason for hiding this comment

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

Why this change?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In my testing, it seemed like the screen reader swallowed keydown events. Instead, focus would just move to an element, which would then hit the line above and set hadKeyboardEvent to false. Meaning the next time the screen reader moved focus, it would seem as if it came from a mouse.

Copy link
Collaborator Author

@robdodson robdodson Jun 27, 2018

Choose a reason for hiding this comment

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

Blargh. I hate that GitHub now submits comments when I hit shift-enter.

Continuing from the above...

The polyfill currently starts with hadKeyboardEvent set to true. And if we ever detect any mouse event, we set it to false (https://github.com/WICG/focus-visible/blob/master/src/focus-visible.js#L116).

So removing this line makes the keydown-swallowing-screen-reader scenario work. And it doesn't seem to break anything because onPointerDown should handle turning hadKeyboardEvent off if the user ever switches to mouse.

Copy link
Member

Choose a reason for hiding this comment

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

Does this result in being permanently stuck in focus-visible mode once any key is pressed?

Copy link
Member

Choose a reason for hiding this comment

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

Apologies for the crossed comment trajectories.

Makes sense - this would probably also mean that a keypress that causes a modal to open would also stay in focus-visible mode.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sorta. It's like it's "on" until we detect any sort of pointer down, in which case it's "off". And it stays "off" until we hear another keyboard event.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

No worries :) I'm typing this on bus wifi so my comments are just showing up in random order :P

Makes sense - this would probably also mean that a keypress that causes a modal to open would also stay in focus-visible mode.

Yeah I think so

@robdodson robdodson merged commit e62d59c into master Jun 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants