-
Notifications
You must be signed in to change notification settings - Fork 124
Fixes #152. Show :focus-visible if screen reader is running. #153
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
Conversation
|
Assigning to @alice to take a look when she gets back from vacation. |
|
|
||
| if (hadKeyboardEvent || focusTriggersKeyboardModality(e.target)) { | ||
| addFocusVisibleClass(e.target); | ||
| hadKeyboardEvent = false; |
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.
Why this change?
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.
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.
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.
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.
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.
Does this result in being permanently stuck in focus-visible mode once any key is pressed?
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.
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.
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.
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.
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.
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
This might need more testing but it seemed to pass all of our local and sauce tests.