Design & UX
By James Edwards

When Do Elements Take the Focus?

By James Edwards

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.

  • You didn’t test this on every version of Firefox?? Great research, James. Thank you.

  • Not every version no :-) I started with v22, then I tested v3.6 for comparison. After that I just wanted to know when the change happened, so I tested v14 then v8 and finally v4. All those versions behaved the same as v22 therefore v4 is when is changed, which is not surprising in hindsight — a lot of stuff changed Firefox 4, and that’s also when the version number bloat began (there were 6 years between v1 and v4, yet only 3 years between v4 and the current pre-alpha v25)

    • How are you managing to run so many versions of Firefox? …

      • Opera and Firefox (unlike Chrome, Safari and IE) are easy to run in multiple versions. You just create a new installation folder each time you install a new version (rather than allowing Firefox to use the same folder every time, as it will be default). They all use the same profile folder, but everything else is separate (although you could create separate profiles I suppose, but I can’t see there would be much point)

        You do have to disable automatic updates to do this, otherwise each older version will upgrade itself to the latest one in the background.
        And of course you can only run one at once, and each time you start a different version it will try to validate all your extensions; in fact bootstrapped extensions like Firebug will uninstall themselves when you start a Firefox version older than the one it was designed for, so that’s a bit of a PITA, but I only use Firefox for testing anyway, so it doesn’t bother me.

    • Mats Svensson

      Regarding having several Firefox installed and running:
      (I cant reply in the right level of this thread)

      I find the portable version makes life a lot easier.

      Also great for quickly making trow-away test-copies of the whole Firefox setup, by just copying the whole folder.

      And if you add “AllowMultipleInstances=true” to the “FirefoxPortable.ini”-file, you can even run multiple copies of the same setup.

  • ralph.m

    > Have any of us, ever, had complaints from users, saying they don’t like those dotted lines or bright-blue rings?

    It’s worth pointing out that you don’t have to put up with these default styles. Whenever I style a link, input etc. I include focus styles. So instead of a blue border or dotted line, you can set something else instead—like a font color, border or outline color. Are there any accessibility problems with removing the outline and using some other style?

    • No there are no problems with that — I tend to do the same, styling them so they’re much more obvious than the defaults. (But remember not to rely on colour alone, e.g. a change in border-color wouldn’t be enough on its own, but supplementing that with a change in border-style, from solid to dashed or dotted, would be.)

      Despite the variation in the appearance of a native outline, my testing indicated that, when :focus rules are used, all browsers apply them in all circumstances (ie. there’s no discrepancy between focus events and the :focus pseudo-state, so if the browser focuses an element at all, it will also apply focus styling, even if it doesn’t apply a native outline).

      The only exception to that is browsers that don’t support :focus at all, but you’d have to go back to IE7 before that’s an issue.

      Thanks for bringing that up.

      • ralph.m

        > remember not to rely on colour alone, e.g. a change in border-color wouldn’t be enough on its own

        Yes, good to point out. My language was a bit sloppy. :-)

    • Oh I should also mention that there’s a new vendor pseudo in Firefox, “:-moz-focusring”. I haven’t actually tested it myself, but from the documentation it seems to mean: if the browser would apply a native focus outline, then this pseudo-class applies.

      The implementation of that came from a long-running “bug” in Firefox that eventually gave rise to the changes in focus behaviour this article talks about. You can read all about it at However I think that entire discussion proceeds from the false assumption that mouse interaction should follow platform conventions; this assumption is barely questioned (nor is the convention itself), so it’s obvious what Firefox developers think!

      (In fact I’m also considering writing a Firefox extension to restore the old focus behaviour! I would submit a bug report that contradicts these changes, but I know there’s no point, it would just be marked as invalid straight away.)

  • Stomme poes

    I remember back in the day when we had focus styles for things like showing some hidden image onscreen… for anchors who could also be clicked to go somewhere. There were two browsers who didn’t leave the focus after a click: (webkits) and Opera. Meaning, if we clicked a link, went to another page, then hit the back button, in those two engines we would not see a leftover focus ring and would not necessarily even see where on the page we were (if the page were a long list of links).

    I kind of miss that, being way down on long page, going forward, then hitting the Back button and being right were I was. I use 4 browsers regularly all day so I’m not sure anymore who brings me back and who I have to scroll back down with, but it’s certainly not consistent.

    I remember on the DuckDuckGo talking area a focus ring was suggested, and briefly implemented. Other users, especially users of Chrome and Safari complained as the focus ring there was always very obvious. Outline:none was put back in.

    Even with an article on the likes of SitePoint, you’ll never convince the majority of web developers that there are even enough users without mice to bother worrying about. To them, everyone has a large screen, the latest browsers and a mouse. I have yet to convince anyone at my place of work for example, and we do e-commerce.

    • Yeah right, and even simpler things like being able to click something in order to move the focus there — many power users navigate with a combination of keyboard and mouse, and shouldn’t have to keep manually tabbing just to keep them in sync.

      As accessible application developers, what this means I think, is that we’re going to have to make more effort to manipulate the focus, e.g. by programatically focussing a button when it receives a click event.

      Increasingly in the last few years, I’ve been seeing oddities in browser behaviour that have led me to solutions like that, but I never really followed it up, just fixed each thing as it happened. It’s only recently that it’s happened enough times to make me stop and think, WTF, hence this article!

    • Hang on — you said that you had Chrome and Safari users complaining about the focus ring? Was that ordinary users, or other developers?

      • Stomme poes

        Sorry for the delay, didn’t see this.
        It was probably developers, but not sure: it was the DuckDuckGo community platform where interested people (who are most likely developers and probably also some designers… and frankly most users of DDG are probably on the nerdier side of things) could point out bugs, make suggestions and whatnot. This was on an announcement by Gabriel (i think) about a revamped top-level menu on an inner search page.

      • Stomme poes

        I found the discussion:
        it’s old

Get the latest in Design, once a week, for free.