Anybody with any real world accessibility experience knows that using CSS :focus {outline:none} as recommended in the WHATWG HTML living standard is not a solution to any problem, it only replaces one accessibility issue with another. This why I worked hard to get the advice still present in the ‘living standard’ removed from the W3C HTML5 specification.
killing CSS outlines for mouse users only
Note: I am not advocating removal of CSS outlines, but if you must, do it in a way that does not screw keyboard users
The problem
Some developers/designers/clients do not like the default focus rectangle that is displayed when a user clicks on an interactive element such as a link. Methods to remove it such as onfocus="blur()" result in keyboard users being unable to interact with the link or control. While use of CSS outline:none results in the link or control being focusable but with no visible indication of focus for keyboard users. Neither method provides an accessible user interface.
An accessible solution?
Starting with the page having no CSS outline:none rules applied. Apply CSS outline:none rules using JavaScript ONLY IF mouse user depressesing the mouse button is detected. Remove the rules again IF keyboard interaction is detected.
Example code:
<!DOCTYPE HTML>
<html>
<head>
<style id="poot"></style>
</head>
<body onmousedown="document.getElementById('poot').innerHTML='a{outline:none}';" onkeydown="document.getElementById('poot').innerHTML=''">
<a href="#">test link</a>
</body>
</html>Notes:
- A test page is available
- Example only suppresses outline on links for mouse users.
- Tested with Firefox, IE, Chrome, Opera and Safari on Windows.
- Use of inline event handlers is for demonstration purposes only.
- If you create a more sophisticated script based on this idea please share
- Aireh Glazer has created a Cross-Lib accessible outline removal script
- Lindsay Evans has created outline.js
- If you encounter any issues provide feedback
- how it works with touch based interfaces has not been investigated much:
- using Opera mini and Safari on iPad, the links still show their default activation indicator and the same using webkit on android (feedback from @sideshowbarker), which is the best outcome for usability/accessibility.
The back story
The W3C HTML5 specification now states:
- element .
blur()- Unfocuses the element. Use of this method is discouraged. Focus another element instead.
Do not use this method to hide the focus ring. Do not use any other method that hides the focus ring from keyboard users,in particluar do not use a CSS rule to override the ‘outline’ property. Removal of the focus ring leads to serious accessibility issues for users who navigate and interact with interactive content using the keyboard.
The WHATWG Living Standard makes claims it provides advice on how to remove focus outlines in an ‘accessible manner’:
The W3C HTML specification omits some advice about how to remove focus outlines in an accessible manner (instead only urging authors not to remove them without giving an alternative to address the “they’re ugly” use case), because of a working group chair decision from March 2012.
The WHATWG HTML living standard continues to state:
element . blur()Unfocuses the element. Use of this method is discouraged. Focus another element instead.Do not use this method to hide the focus ring if you find the focus ring unsightly. Instead, use a CSS rule to override the ‘outline’ property. (Be aware, however, that this makes the page significantly less usable for some people, especially those with reduced vision who use focus outlines to help them navigate the page.)For example, to hide the outline from links, you could use::link:focus, :visited:focus { outline: none; }
The WHATWG HTML living standard does not contain advice on how to remove focus outlines in an ‘accessible manner’
By its own admission the ‘living standard’ states the recommended alternative to using .blur() is bad for accessibility:
Be aware, however, that this makes the page significantly less usable for some people, especially those with reduced vision who use focus outlines to help them navigate the page.
Note: This warning also contains a factual innacuracy as use of outline:none makes the page significantly less accessible to any keyboard only user, not only those with reduced vision. Not providing a visible indication of focus makes the user interface unusable for keyboard only users in any circumstance where the page has more than a few focusable elements.
:link:focus, :visited:focus { outline: none; }
Comments
Here’s a cross-lib implementation
Also supports the use of event delegation (for single-class selectors):
https://gist.github.com/2470682
Thanks Arieh, great work! my JS skills are minimal to say the least…
Is there a single person from access-board.gov in the WHATWG. I ask because it seems, more often than not, that the HTML5 people are throwing accessibility under a bus (abbr attribute anyone?) We have to comply with section 508, so it doesn’t help that they are taking away the only tools we have to do that and being deliberately belligerent with advice like “remove the focus ring.”
Beat me to it 😉
I’ve also done a similar version, minus the event delegation stuff:
https://github.com/lindsayevans/outline.js
I’m using ‘mousedown’ instead of ‘mouseover’ – it seemed a bit weird that if you had already focused a link & bumped the mouse that it disappeared – any thoughts?
Thanks, this is a useful article. This needs careful testing… I’ve seen some browser/screen reader combinations fire mouseOver and mouseDown events, which could cause outlines to disappear while using a screen reader. Some sighted or low-vision folks use screen readers, so would be a negative for them (though recoverable with a tab press). Also we would want to test voice-to-text (e.g. Dragon) to see what events get fired there.
Steve said it well: “I am not advocating removal of CSS outlines, but if you must”…
I disable the outline and at the same time theme links so they are visibly interacted with for both keyboard and mouse users.
Do I need to do more? ’cause I am sure not liking the use of javascript to do it.
Hi John, if you provide an alternative indication of focus such as underlining on focus you use on your site then I think that is enough.