Within the accessibility community, it is well-understood that visually indicating focus is a crucial step in ensuring access for sighted users who rely on their keyboard when interacting with the web. After all, it is explicitly listed in WCAG 2.0 as Success Criterion 2.4.7, [a]ny keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
But it has also been addressed repeatedly over the years by different people. For example, Mike Cherim recognised it as an issue in 2007. Jared Smith addressed it in 2008. And Roger Johansson took it up again in 2009. And people continue to Tweet about it now and then, sometimes identifying sites that don't provide visible keyboard focus, sometimes simply reminding their followers of this best practice. Lately, in fact, Tweets about it seem to have been a bit more frequent than usual.
Yet, providing visible keyboard focus is still not as widespread a practice as it should be. At least one contributing factor is the seemingly common æsthetic decision by designers to remove the dotted focus rectangle that appears around links, without replacing it with any other visible indicator. Just for fun, try Googling "ugly dotted border" or "annoying dotted border". I even recently found the following comment in a site's CSS file, just preceding the declaration that removed the focus rectangle from the site's main navigation elements: Remove annoying border on navigation elements.
I am not at all a designer, but I do appreciate that in some cases the default focus rectangle might be seen to detract from a web page's visual design. Still, the focus rectangle is there in the first place to serve an important purpose, and without it or an equivalent accommodation, the experience just gets worse for certain users. Jared noted how it is exacerbated by the increased use of CSS reset files that explicitly set the outline property to 0 or none for the :focus pseudo-class. Of course, using such a reset file is not in itself the problem, but neglecting to compensate for the removal of the default focus rectangle certainly is.
Recently, however, there's been some quite positive activity on this with the HTML5 Reset from Monkey Do and the HTML5 Boilerplate by Paul Irish and Divya Manian. The HTML5 Reset adds the focus rectangle by default using :focus {outline: 1;}, and the HTML5 Boilerplate uses a couple of rules following some work by Patrick Lauke to both maintain the default visual indicator for keyboard accessibility while dealing with an issue related to outline on image-replaced links.
Whether or not the default focus rectangle on links is removed using outline:none; or outline:0;, I think it's almost always a good idea to give keyboard users the same visual effect when they set focus to a link that mouse users get when they hover over a link with their cursor. Further, depending on the page's visual design, the default focus rectangle by itself may not be adequately visible to many users, in which case it should be supplemented with some additional effect. To make this happen, duplicate your mouse :hover effect with both the :focus pseudo-class, as well as the :active pseudo-class to support Internet Explorer 7 and below. For example, if you're adding a light yellow background colour to your links with :hover, provide the same effect for keyboard users as follows:
a:hover, a:focus, a:active {
background-color: #ff9;
}
If you prefer to specify a custom :active state for links when they are clicked or activated, you'll want to omit the a:active selector from the previous CSS rule. But in that case, keyboard users in IE7 and below will instead see your custom :active state, as opposed to the :focus state, when they set focus to a link, which may or may not be suitable.
However you end up addressing it all, the crucial matter is to consider keyboard users who need to see where focus is currently set on the page. Depending on your site's design, it may well be that the default outline serves just fine as a visible indication of focus, in which case you are probably good to go.
And while we're at it, if your web page includes JavaScript that uses mouseover and mouseout events, in most cases you should make sure to duplicate these with their equivalent device-independent events, namely focus and blur, respectively. James Edwards wrote a good SitePoint article on keyboard accessible JavaScript, offering the same advice, back in 2006.
Such a relatively small thing can have a significant and positive impact for many people. Quite fortunately, it is simple to implement.