Hiding the Browsers Focus Borders. Should I, Or Shouldn’t I?
I’m not sure how this will jive with the accessibility minded folks, but I must admit I am just sick and tired of those pesky dotted borders. The dotted visual clutters up the presentation. I know, when using a keyboard instead of a mouse this dotted indicator is useful in order to visually tab select linked elements in a webpage. However, I’m convinced that with certain layouts and CSS trickery (Image replacement techniques) it can become rather confusing to have the dotted borders appearing. To a certain extend, I think it can even effect the user experience.
For instances, things really get bad in some browsers when you use the popular image replacement technique from Mike Rundle to hide text by moving it off the screen with a negative text indent. When this technique is used a dotted box appears around not only the visible image, but also the text that is indented. This will often cause (Mozilla) a gigantic dotted box to appear over the content as it attempts to focus the indented text. The focused element gets lost. So, in this scenario it would seem the borders used to show browser focus become useless. Don’t get me wrong, I’m not saying the image replacement technique is rotten. Heck, I’ve use this technique for some time now. It’s great! What I am saying is those pesky borders can cause visual confusing, instead of help the user determine visual focus.
Another example of the unwanted borders showing up is when you fire an event that does not refresh the webpage. This is pretty common nowadays with all the transparent calls to the server happening (AJAX). Without a page refresh, the browsers focus remains on the elements that fire browser events. For example those little icons used to expand and contract (plus and minus icons) hidden content will receive focus until the user fires another event. These borders can often change the visual appearance of icons and images. This might be a little nit-picky but it just bugs the heck out of my when the visual layer changes without my consent.
So, because I’m such a control freak when it comes to the visual layer I have decided to eliminate the dotted borders when possible. With Mozilla based browsers this is pretty simple. In your global CSS file simply place the following declarations.
:focus { -moz-outline-style: none; }In IE, it’s of course not as simple as adding a CSS declaration. To hide the borders in IE you’re going to have to add the following attribute and value to link elements that you don’t want to receive the dotted borders.
<a href="" onfocus="this.hideFocus=true;">link</a>Now if you’re like me, adding an attribute to each and every link sounds very unpleasant, for many reasons. Most of all, it makes maintaining client side code more complicated. With this in mind I decided that it would be simpler to write some Javascript that would add this attribute and value to all the links in a html document. You can check out my working example, or preview the Javascript below.
//Find all link elements and add an onfocus attribute and value
function hideFocusBorders(){
var theahrefs = document.getElementsByTagName("a");
if (!theahrefs){return;}
for(var x=0;x!=theahrefs.length;x++){
theahrefs[x].onfocus = function stopLinkFocus(){this.hideFocus=true;};
}
}
If the mouse pointer changes to a hand when you roll-over an image associated with a story the image upon clicking either links to enlarged version of the image or a website associated with the image.
I think that accessibility-wise, it should be just fine, but I’ll leave that for others to decide. I just wanted to chime in and say you should have a generic browser compatibility check at the beginning…
if (!document.getElementsByTagName) return false;That way on incompatible browsers, it won’t throw an error alert.
Nathan, very true. Thanks for chiming in.
It seems that only Internet Explorer requires the JavaScript so, it should be possible to supply it and only it with the javaScript in question by using conditional compilation; for example:
/*@cc_on @*/
var theahrefs = document.getElementsByTagName(‘a’);
for(var x=0;x!=theahrefs.length;x++){
theahrefs[x].onfocus = function stopLinkFocus(){this.hideFocus=true;};
}
/*@end @*/
just a thought…
@frequency decoder – I have never seen this conditional compilation before. Excellent point and thanks for the tip.
With image replacement and text-indent the easiest way to confine the focused border is to use overflow:hidden
This way the focused border only appears to wrap the specified dimenssions.
Krik – Good call, I’m not too proud to admit when I see a simpler solution. And well, your solution is much simpler. Thanks for speaking up. The overflow didn’t even cross my mind.
You can hide the borders using standard css, no need for ‘hacks/javascript’ even in IE.
http://www.cssplay.co.uk/menus/jigsaw.html
This also allows non rectangular links.
Stu – I can’t really figure out how your jigsaw is working at all but beyond that… will your technique work for text (not image) links?
This article was there exactly when I needed it! Thank you so much!!
Great thinking and thanks for posting this article or I would have never figured out what the ‘active/focus border’ was called.
As others have mentioned though, the both the javascript and the css approaches mentioned in this article are definately the HARD way of approaching it.
The solution is simple, and you’re going to slap yourself in the forehead when you finally figure out what that a:active CSS psuedo-class is for!
CSSPlay has a great article that outlines this specifically (that jigsaw link above must have been the wrong one):
http://www.cssplay.co.uk/menu/nodots.html#nogo5
And yes, the CSS solution is a simple one-liner that works in all browsers.
FINAL Note: Hiding the selection box is terrible accessibility practice. Instead, try offering the user another type of visual queue such as a different color when links are active. This will help those who can’t use a mouse for whatever reason.
In my case, I decided that rather than a silly dotted outline it should look more like highlighted/selected text; that just seems to make more sense, and it looks great… especially when you combine it with Mozilla’s ability to customize the background and color attributes of highlighted text:
a:focus, a:active { -moz-outline:none; background:#cff; color:#06c }
::-moz-selection { background:#cff; color:#06c }
Your sentence “To a certain extend, I think it can even effect the user experience” should be spelled like this: “To a certain extenT, I think it can even Affect the user experience.” Spell checker alone won’t do the whole job right.
Another tip:
In tags of the CSS it places the following one:
a { outline:0; }
IE7 doesn’t show the dotted borders by default. A massive improvement! :P
Well IE7 does show me the outlined border. And that’s what I’m used to around the company and what I consider totally OK as being the default setting.
But in case you really need to get rid of the outline please don’t do such stupid things like looping through the complete DOM to set the hidefocus attribute.
CSS helps you way better instead. Use the :active pseudo-class as is actually works like :focus selector on links. Use this trigger in combination with expressions to set the hideFocus attribute value.
Play nice and provide a valid attribute first, like:
a:active { text-decoration:expression(hideFocus=‘true’); }
Just to make this clear: I used text-decoration to show you that it doesn’t really matter which attribute you use.
To keep it nice and clean one should of course go with the outline attribute:
a { outline:expression(hideFocus=‘true’); outline:0; }
Doesn’t validate anymore but is easy on the other browsers and: it does what one would expect looking at this code for the first time.