When Do Elements Take the Focus?

Do elements take the focus when you click them with the mouse? Do they show focus indication, like a dotted-border or focus-ring? The answer always used to be yes — and in my view, it certainly should be — however browser behavior has changed in recent years, in both subtle and significant ways. Now if you do a quick search for ways of suppressing focus outlines, you’ll get thousands of results. How do I get rid of that ugly dotted border that’s spoiling my beautiful design? comes the cry. The web industry has always overflowed with people who seem to think that’s okay — who think that their arbitrary aesthetics are more important than accessibility; who don’t just want to remove visual indication of the focus, but to prevent links and form-fields from taking the focus altogether. A significant number of developers don’t even understand the difference, so I suppose I can be sympathetic with those who are sold solutions like this:

<a onfocus="this.blur()">

When all they really wanted was this:

a:focus { outline:none; }

Both of those are accessibility disasters, but the latter is understandable from a design perspective; or at least, it’s understandable where mouse-triggered focus is concerned. Let me be clear — you should never prevent elements from taking the focus, nor should you remove focus indication when the user Tabs to an element (unless of course you replace it with something else). But even I’ve been tempted by solutions like this:

a:focus:not(:hover) { outline:none; }

So is it okay to prevent focus indication when the user clicks with the mouse? Browser vendors increasingly seem to think so, and many no longer add a native outline in that situation. In fact in some cases, they don’t focus the element at all. To try to get some clarity on this, I’ve done a bunch of tests. Here are the headlines:

• In Firefox, links don’t show a native focus outline when clicked with the mouse, unless you’ve already used the Tab key during the current page-view.
• In Opera and IE10, links never show a native focus outline when clicked with the mouse.
• In Chrome and Safari, links don’t take the focus at all when clicked with the mouse, unless they have tabindex.
• In Firefox for Mac, Chrome and Safari, some types of form field don’t take the focus at all when clicked with the mouse; this behavior is limited to fields which have no typed input, such as radios, checkboxes, buttons, color-pickers and sliders.

There’s also something interesting to note with elements like <span> , which are not normally focusable, but have been made so by the addition of tabindex. Remember that elements with tabindex="0" are added to the tab-order just like links and form-fields, whereas elements with tabindex="-1" can only be programatically focused. Except, that isn’t true:

• In all browsers, elements with negative tabindex can be focused by clicking them with the mouse, they’re just not in the tab-order.

I find that the most curious anomaly of them all — keyboard-accesible elements can’t be focused with the mouse, yet mouse-focused elements aren’t accessible to the keyboard! So what to make of all this? Well frankly, it’s hard to be sure. These behaviors are not exactly new, but they are fairly recent. For example, if we go back to Firefox 3.6 we find that none of the noted caveats apply — all focusable elements take the focus when you click them with the mouse, and all show native focus indication. Perhaps we can put this into some kind of context if we look at platform conventions . In Mac dialogs for example, text-boxes and menus take the focus when you click them with the mouse, however buttons, radios and sliders do not. This corresponds with behavior we noted earlier, in Firefox for Mac, Chrome and Safari. We didn’t see that behavior in Firefox for Windows, and indeed, all dialog widgets in Windows do take the focus when you click them. Yet in Chrome for Windows we get the same behavior as for Mac, so Chrome can’t claim to be honoring platform conventions, as Firefox can. But how important are platform conventions to web applications anyway? The web has its own conventions, and I don’t think it’s a good idea to force platform conventions onto it. It’s hard enough to get developers to care about accessibility, without having to think about it in platform-specific terms! Personally, I don’t think any of this is a good thing. I think all focusable elements should take the focus by any means of interaction, and should always show a native focus outline when they do (except for elements with tabindex="-1" which should not be user-focusable at all, because that’s what it’s for). But I’m not naive to designers’ wishes either, and I do have a certain sympathy for how focus can jar with a design. Nevertheless, the most important thing is users’ needs, and users’ accessibility needs rank highest of all. Have any of us, ever, had complaints from users, saying they don’t like those dotted lines or bright-blue rings? Users aren’t precious about this stuff like we are, they just want it to work.

Frequently Asked Questions (FAQs) about Elements Focus in Web Development