You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, thanks for this polyfill. It's great, and is working for most of our needs.
Summary
Our app is an ionic/capacitor app which manipulates the focus for the benefit of screen readers. We noticed when the polyfill is installed, focus-visible is applied to one of the elements we're focusing on app start. This scenario does not match any of the specs for the polyfill standard: we're not coming off a previous focus-visible element, there is no user setting, there's no keyboard navigation, etc.
Root Cause
Upon digging into the code, we found this:
function onFocus(e) {
// Prevent IE from focusing the document or HTML element.
if (!isValidFocusTarget(e.target)) {
return;
}
if (hadKeyboardEvent || focusTriggersKeyboardModality(e.target)) {
addFocusVisibleClass(e.target);
}
}
The trigger ended up being hadKeyboardEvent = true. Which I assume is because:
function applyFocusVisiblePolyfill(scope) {
var hadKeyboardEvent = true;
// AND
/**
* When the polfyill first loads, assume the user is in keyboard modality.
* If any event is received from a pointing device (e.g. mouse, pointer,
* touch), turn off keyboard modality.
* This accounts for situations where focus enters the page from the URL bar.
* @param {Event} e
*/
function onInitialPointerMove(e) {
Question
My question is: is there a way to have hadKeyboardEvent = false in scenarios where we're not coming directly from the url bar, like in the case of our native web app?
The text was updated successfully, but these errors were encountered:
cpyle0819
changed the title
Absence of interaction events causes outline to display by default on focus.
Default to polyfill off in Web Native cases?
May 27, 2021
Thank you
First, thanks for this polyfill. It's great, and is working for most of our needs.
Summary
Our app is an ionic/capacitor app which manipulates the
focus
for the benefit of screen readers. We noticed when the polyfill is installed,focus-visible
is applied to one of the elements we're focusing on app start. This scenario does not match any of the specs for the polyfill standard: we're not coming off a previousfocus-visible
element, there is no user setting, there's no keyboard navigation, etc.Root Cause
Upon digging into the code, we found this:
The trigger ended up being
hadKeyboardEvent = true
. Which I assume is because:Question
My question is: is there a way to have
hadKeyboardEvent = false
in scenarios where we're not coming directly from the url bar, like in the case of our native web app?The text was updated successfully, but these errors were encountered: