One thing currently prohibiting me from using this (very useful) library is that it bakes in polyfills for both classList and matches (as of v1.0.1) - both of which I already polyfill elsewhere in many of my projects.

Is there any possibility of offering one file in the dist/ directory that does not include these?

Is there a way to use focus-visible in a React application?

I've installed through yarn and tried the following but cannot access any of the functions:
import * FocusVisible from 'focus-visible';

This seemed to make my day, works great for all my elements... except the checkboxes. I have the actual checkboxes styled away off the screen with labels containing a simulation of a styled checkbox.

I use CSS to show the focus outline on the label when the checkbox itself has focus, but it is showing up whether I use the keyboard or not...

<input type="checkbox" id="foo" class="my-checkbox"/>
<label for="foo" class="my-checkbox-label">
   //... my styled pseudo-checkbox
</label>

.my-checkbox  {
    opacity: 0;
    height: 0;
    position: absolute;
    left: -99999px;
    + label.my-checkbox-label {
        // ... styling for the label itself
    }
    &:focus {
        + label.my-checkbox-label {
            outline-style: auto;
	    outline-width: 1px;
	    outline-color: Highlight;
        }
    }
}

Any thoughts on how I could adapt the polyfill to catch this case?
Thanks!

See #56 for an example. It'd be good if we could have a test suite check for this.

I noticed that the focus-ring polyfill only looks for tab key presses, and not arrow input, which is part of the default behavior for radio buttons.

I've fixed this locally by adding a few lines to the onKeyDown function.

function onKeyDown(e) {
    if (e.altKey || e.ctrlKey || e.metaKey)
      return;

    if (
	e.keyCode != 9 // tab
	&& e.keyCode != 37 // left arrow
	&& e.keyCode != 38 // up arrow
	&& e.keyCode != 39 // right arrow
	&& e.keyCode != 40 // down arrow
	)
      return;

    hadKeyboardEvent = true;
  }

Could we get rid of all this code if mousedown, touchstart, and pointerdown cancel hadKeyboardEvent? https://github.com/WICG/focus-visible/blob/master/src/focus-visible.js#L168-L190

Hi, and thanks for the awesome polyfill! I’m thinking of using it in Uppy file uploading widget http://github.com/transloadit/uppy I’m working on, and was wondering if you think an option to add scope would be a good idea?

1. Option to specify a container element, so that .focus-visible will only be added to elements inside that container; Then .js-focus-visible could also be added to that container.
2. Option to set a custom class name for .focus-visible (and .js-focus-visible maybe), so that I could set it to something like uppy-u-focus-visible to match my CSS guidelines and not risk being overriden by page styles (widgets are included in the page which already has third party CSS).

I can possibly send a PR for this, but wanted to hear your thoughts first. Thanks!

Description

The Focus-ring Polyfill has some issues when used with shadow DOM. The Polyfill is not able to add the focus-ring class to focusable elements within the shadow DOM such as a buttons. This is due to the shadow DOM event model. Events bubble up from shadow DOM but the events are re-targeted. This means that the events look like they come from the host instead of its internal events within the shadow DOM.

Versions & Environment

Focus-ring: v1.0.1

Steps to Reproduce

• Clone repository [email protected]:emilbillberg/focus-ring-shadow-dom.git
• Start a local server such as live-server or similar
• The Polyfill is NOT able to set the focus-ring class on the button element
• Go to the index.html file and change the Polymer Global setting to shady instead of shadow
• The Polyfill is able to set the focus-ring class on the button element

Expected Results

The Polyfill should be able to set the focus-ring class on the button element when using Shadow DOM

Actual Results

The Polyfill sets the focus-ring class on the top custom element. In the example above this will be the custom element my-app.

Isn't it a good idea to rename the init function to a less generic name like initFocusRing?
I have some other scripts with an init function and the focus-ring init overrides my init.

https://github.com/WICG/focus-ring/blob/8150e357e75bf9065a919b115ee9bd930d6a96bc/src/focus-ring.js#L4

I noticed a few lines that use matches()
https://github.com/WICG/focus-ring/blob/gh-pages/src/focus-ring.js#L47

But elsewhere the code tries to determine if matches is available:
https://github.com/WICG/focus-ring/blob/gh-pages/src/focus-ring.js#L13

Would it make sense to just use the MDN matches polyfill and patch the Element.prototype?
https://developer.mozilla.org/en-US/docs/Web/API/Element/matches#Polyfill

should [contenteditable], video[controls], audio[controls] also be white listed?

I'm using the current version of focus-visible in a demo together with the video.js framework. I reference the focus-visible.js script from my HTML, but I need to add the example CSS from README.md manually:

/*
  This will hide the focus indicator if the element receives focus via the mouse,
  but it will still show up on keyboard focus.
*/
.js-focus-visible :focus:not(.focus-visible) {
  outline: none;
}

Could this be added to the repo as a focus-visible.css file, and then added to the package, so that it can be used in multiple places? Or is it not part of the core of the polyfil? In that case, could it be placed in the demo folder? Just seems like it would be helpful to have it as part of the bundle.

Filing up as a followup from the discussion in issue #33 pertaining to the need for the data-focus-ring-added attribute. As of 8d00580 this polyfill supports persistence of instances of an author-defined focus-ring class. I would argue this should be removed on the premise that:

1. This polyfill shouldn't give authors abilities they won't have with the actual :focus-ring psuedo. Therefore, once actual support for :focus-ring lands in browsers the only change authors need to make to their CSS is changing their rules from .focus-ring to :focus-ring. Hence, more with the grain.

2. Should authors wish to ensure specific instances of UI always show focus they can leveraging the natural cascade and/or specificity rules in CSS:

// hide focus by default
:focus {
  outline: none;
}
// focus ring for keyboard navigation
.focus-ring {
  outline: solid 2px blue;
}

// always show focus outline around a specifc control
button.default-action:focus {
  outline: solid 2px blue;
}

https://drafts.csswg.org/selectors-4/#the-focusring-pseudo

Looks like some naming might need to be updated as a result of this change?

If you switch browser tabs, with the mouse or keyboard. The JS will add a focus-visible class and data-focus-visible attribute.

To me and our users, this is unexpected behaviour. What do you think?

Replicate by clicking the div with tabindex="0" on the demo page. Now, no focus-ring is visible. Switch browser tabs. And when you switch back, the focus-ring is visible.

Thx

According to:
https://drafts.csswg.org/selectors-4/#the-focusring-pseudo

The pseudo class focus-ring should always be applied on focus to input elements to indicate a where the user should enter text.
However, it should applied if I select e.g. a link / button element using the keyboard (tab button).
However, if I do so with the mouse it shouldn't be applied. The reason is that if I tab through links using the keyboard I need to know WHERE I am but I don't need that information if I click on the element.
Of course, it depends on the corresponding browser's heuristics but that part is mentioned as example there.

Tested on https://wicg.github.io/focus-ring/demo/

Using safari: when the address bar has the focus, pressing tab moves focus to the first input field but it does not receive focus styling. Pressing alt+tab moves focus to the last input field but it does not receive focus styling.

Using chrome: when the address bar has the focus, pressing alt+tab moves focus to the last input field but it does not receive focus styling.

In both cases, if I press shift after navigating, it does add the styling. I assume there's a problem with catching the keyboard events from outside the web content?

If you open up the demo, you'll see the focus-ring class is being applied if the user focuses an element using the mouse.

The [Selectors 4 specification] doesn’t mention a corresponding JS event for :focus, so I understand that it might also not mention a corresponding JS event for :focus-ring.

Is that something to ask here? Feel free to close this if it is outside the bounds of this project.

When going through the demo at https://wicg.github.io/focus-ring/demo/ with the tab-key, the focus styling is not visible on the element with role="textbox", the <div>'s with tabindex=0, and the <select>'s with a set size.

Hi :)

Per the documentation, I'm really struggling with the blanket :focus { outline: none; } code recommendation. I want to be on board with this awesome feature but feel like we could come up with something better.

It is very bold to say hey.. attention all browsers - kill all outlines on focusable elements and then rely on JS to fill the gaps or when implemented only supporting browsers will overwrite that rule. Many older browsers support :focus {} but will not support :focus-ring ever.

Some ideas

Here are some ideas instead of just a global :focus { outline: none; }

1. For the spec: lean on fault tolerance so browsers that don't understand skip it?:

:not(:focus-ring) :focus { outline: none; }

2. For the Polyfill have JS add a class to html tag and descend from that:

.focus-ring-polyfill :focus:not(.focus-ring) { outline: none; }

This would mean JS is probably present, loaded, no errors, and the Polyfill should work.

I don't want to be a stick in the mud but we are working hard out here trying to get folks to stop killing outlines for many different accessibility-related reasons.

Consider these personas:

Lisa: I use my Dell laptop I'm a mouse user, touch user, and a keyboard user. I have a cognitive related disability that affects my memory and have low-vision it's important for me to have an understanding of where I am in the interface -- and yes even right after I click on something. I don't always use a screen reader. I may start a web form using a keyboard and then click on something and I get confused when the focus ring is removed from the UI.

Paul: I turn JavaScript off because it ensures my browsing experience does not have too much animation. I'm epileptic, have low vision, and very sensitive to animation and flashing. I'm also a keyboard user and mouse user. Because of this I turn the brightness down on my screen. I have difficulty getting around a site when they don't have focus states.

assuming the iframe is running the polyfill, only the second focusable element will receive the focus-ring class, since the keydown event occurred outside the iframe

https://github.com/WICG/focus-ring/blob/f70c271888db99b6427ee77571e8fcaff085d196/src/focus-ring.js#L82

Can this const not be a var like all the other variables?

Browsers act a little different than OS controls in other contexts, such as in system dialogs. With Full Keyboard Access, you can tab to any control and it will show the focus ring. But if you have clicked in a text field and then click on a radio button, for instance, it is not just that the radio button doesn't get the focus ring: It doesn't get the focus either. You can still type in the field.

This is a nice thing on the Mac, and the real reason why you don't normally see focus rings on non-text-editable controls on Mac. It is something that Windows got wrong when they copied the Mac UI.

My point: Ideally, instead of just hiding the focus ring on non-text-editable controls that are clicked on (instead of tabbed to, or voiced to), we should be throwing the focus back to the previously focused text field (or to the window/iframe, if there isn't one).

All that aside, I do like what you've created here.

I noticed a bug related to this chunk of code https://github.com/WICG/focus-ring/blob/master/src/focus-ring.js#L125-L128

Here's a jsbin to help reproduce.

1. Click on the button with a mouse
2. Click in the white space above the button
3. Press Tab to focus the button
4. Click on the white space above the button
5. Click on the button with a mouse, notice the focus-ring class is added.

The :focus-ring pseudo class seems to be renamed to :focus-visible https://drafts.csswg.org/selectors-4/#the-focusring-pseudo
w3c/csswg-drafts#2104

I think this plugin should be updated on this way.

I have found your library and first off, its AMAZING! Thank you so much, I would like to propose adding support however for other keystrokes such as arrow and spacebar keys so that the interactions work as expected via all input element in a complex form. Is this part of the spec that was proposed? If so I would be more than happy to add handlers for these events in a PR.

To preserve user agent outline styles, I recommend you promote styling outline-width instead of outline:

:focus:not(.focus-ring) {
    outline-width: none;
}

This allows overrides to restore user agent styles:

.override:focus {
    outline-width: medium;
}

Just wanted to put down some feedback we've received while discussing :focus-ring with other implementors. We were having these discussions over email but I realized it'd be better if they were here on GitHub so there's a record. Maybe we should add this to the explainer at some point? Anyway, here's a brief recap:

Mozilla

They mentioned that they already have :focus-ring in the form of :moz-focusring which they could unprefix at any point.

Safari

No word on feelings toward :focus-ring. Though they did mention that Apple.com uses a technique to differentiate between mouse and keyboard focus and selectively apply a class (similar to what the polyfill does). So I imagine they could replace that with :focus-ring if it existed.

Edge

Wondered if developers would need more fine grained control in order to support different modalities (eye gaze, voice input, etc). Mentioned MQL4 'pointer' query. Alice suggested that those modalities could still fall into the bucket of matching :focus-ring. It'd be up to the browser to decide.

Edge also mentioned :hover and :active might also want to provide different behavior depending on input modality. Wondered if there was a missing primitive possibly around detecting input modality.

Were concerned that if authors already disable :focus, what would stop them from also disabling :focus-ring? Alice mentioned that we think most folks disable :focus because it shows focus indicators indiscriminately, and if they had more control (via :focus-ring), this would resolve that issue.

cc @boggydigital, @travisleithead, @dbolter, @cookiecrook, @alice to make sure I captured everyone's positions accurately. BTW thank you all for taking the time to discuss this with us 😊

Currently we model the behaviour of <button>, which (in Chrome) shows a focus ring when it receives focus after a keyboard event, or when a key is pressed while it is focused.

Another option would be to show a focus ring only when focus is received from a keyboard event. This would be a break from existing behaviour, but may be input into browsers' eventual decision of what behaviour to model.

That would be fantastic, as that is a very common pattern and one the main reasons why many people disable the outline on focusing-rings. Also want to be able to style it with CSS transitions as well...

...I suppose an example would be every CSS framework ever?... ;-P

Adding a todo for myself.

It would be useful to have a page with as many focusable elements as we can get on it so we can easily look at the expected focus ring behavior in different browsers. Some users mentioned that removing the focus ring when a user clicks a button on windows would actually change the expected behavior (apparently windows leaves the ring in place for mouse clicks?)

Could maybe repurpose the demo page for this.

When a user closes a modal, focus is programmatically returned to the previously focused element. For example, this is the case when using react-modal.

In this case, should :focus-ring apply to the focussed element or not?

I guess the same question applies to anytime when an element is focussed programmatically.

My guess is that, if the element that focus is returning to had :focus-ring when it was initially focussed, it should also have :focus-ring when focus is returned.

Unable to get property 'contains' of undefined or null reference

on line if (document.activeElement.classList.contains('focus-ring')) {

Using version 2.0.

I don't think we currently have a way to handle calling .focus() on an element that should self apply focus-ring

Hello :) Great work on this!

I'm wondering if you'd be interested in including another example in the demo/docs that demonstrated a progressive enhancement approach where we 'detect' JS and if it is 'present' we kill outlines.

If JS fails or there is an error, no elements will have focus rings.

I've created an example of this for review.

Hi, I noticed that on Chrome and Firefox at least, the focus-visible class gets added to textarea and input fields even when the user uses the mouse to get focus.
Is this expected behaviour? I would've thought not but I may have missed something.

(It happens on the demo page: https://wicg.github.io/focus-visible/demo/)

To repro:

1. Use the keyboard to focus a button and apply .focus-ring to it.
2. Switch a different tab/window.
3. Return to the original tab/window.

Expect: Since the originally button still has focus, and the focus was obtained via the keyboard, the focus ring should be reapplied to it. This is what happens when focus-ring.js isn't used.

Actual: The focus ring is lost.

As a general rule, an element's focus ring is dropped if the window itself loses focus, but restored if/when the window regains focus. In the repro sequence above, a standard button (without using focus-ring.js) will end up showing a focus ring at the end of step #3.

This useful behavior helps keyboard users reacquire the focused element when returning to a previously-used window.

For projects that are just standalone libraries/components, it might be beneficial to be able to scope the focus-ring JS to just a specific DOM node rather than the entire body. This would allow these components to use focus-ring without inadvertently modifying other parts of the parent application.

If the team thinks that this is worth doing, I'd be happy to submit a PR.

I just put this into production on unsplash.com and noticed that we're getting thousands of client-side exceptions reported due to A DOM Element reference is required. The offending line is here https://github.com/WICG/focus-ring/blob/0e9f086bbc59ca84a2a932e89df0b71bce18b643/dist/focus-ring.js#L25

I haven't been able to reproduce this locally. Do you have any ideas why this might be happening? Have you seen it before?

Thanks!

This repo has two branches, master and gh-pages. I'm assuming gh-pages is the correct one to use as this is the 'default' in the GH interface.

Hit an issue with this setup when sticking the bare repo URL into bower. This clones the master rather than the gh-pages branch.. and the master branch seems to have issues, notably the naming of isHandlingKeyboardThrottle / keyboardThrottleTimeoutID.

Error in browser: Uncaught ReferenceError: isHandlingKeyboardThrottle is not defined at HTMLBodyElement.onKeyDown (focus-ring.js:87)

See https://github.com/WICG/focus-ring/blob/7ff067a8164f4d2db8ebbb0da5c5d3cdb005096d/src/focus-ring.js#L86

For example. Today if you mouse click on a <button> then press the shift key, it will suddenly show a focus ring.

Just curious why capture mode is used when binding the keydown event listener? (e.g. document.body.addEventListener('keydown', onKeyDown, true);). Makes sense for the focus and blur events as those do not bubble, but keydown does.

Currently they're set to .skip() cuz they rely on weird sleep timers that don't work well on Travis.

We know we need a way to opt an element in to always (or never?) getting a focus ring. Let's talk about strategies for doing this.

First of all, thank you for all the work you are doing! It is so nice to see work being put into making the creation of accessible user interfaces more accessible!

I have stumbled upon an issue with the demo in Chrome (Version 61.0.3163.100 (Official Build) (64-bit) on OSX).

The problem

The demo currently leaves the multi-select and the select with a size attribute without any visual focus clues in Chrome. When tabbing to the elements no outline is visible.

The focus works in Firefox and Safari on OSX. Firefox uses the subtle dotted focus around the first item in the select and Safari uses the regular (although slightly thinner) outline around the entire select.

Potential cause

The current implementation relies on outline-width: 0 instead of outline: none. This seems to have some nice benefits in terms of what needs to be handled by the polyfill (e.g. buttons, selects and radio arrow keys all just work since the outline-width: 0 doesn't affect them for some reason). However for select elements with a multiple or a size attribute the outline is all of a sudden removed (See http://jsbin.com/motuhiwoye/edit?html,css,output).

Possible solution

One possible solution could be to handle all focusable elements the same by adding .focus-ring explicitly. This way outline: none could be used instead of outline-width: 0. That would of course make it impossible to recover the initial browser outline styling, but that might be okay since users can always design their own escape hatches. Also that would then add the need for handling more situations (key navigation and more elements) but I can see those scenarios are already being discussed in other issues (#54).

I hope this is helpful. Please let me know if there is anything else I need to do (add examples, create a PR, etc...). Once again thank you for the great work!

Having different focus indicators for mouse and keyboard users is going to be very confusing. More specifically for users with low vision or cognitive impairments or learning disabilities. It is very problematic. Focus indicators need to be presented in a consistent way.

I think there are several usability and accessibility issues with most of the demoed options here.

Common WCAG 2.0 AA failures include:
Common Failures for SC 2.4.7
F55: 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received.
F78: Failure of Success Criterion 2.4.7 due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator

I am using this polyfill on a project with a couple of modal dialogs that can be triggered from different parts of the app. Whenever I close such a dialog via the Enter or Escape key focus is reset to the original place manually via .focus().

Unfortunately the .focus-ring class does not seem to be added, because only the Tab key is considered when setting the hadKeyboardEvent.

Would it make sense to add more keys like Enter, Escape and Space and Arrows?
I already tried this in my project and it seems to be fine.

I can create a PR for this.