Summary
Often when a site is designed, developers will set the outline for navigation elements to none, or zero. Effectively this means that when you try to navigate a website using a keyboard, visually you will have no idea where you are on the page which most often than not forces user to use a mouse. This is fine until a user becomes dependent upon the keyboard for navigation – such users, who cannot use a mouse suddenly become severely impacted by the pages inability to highlight what they are currently navigating through. Of course it’s not just an accessibility flaw, some people just like to use the keyboard to quickly navigate items.
Example of a link outline appearing when the user navigates links using their keyboard.
Why do people remove it?
Some people just hate the sight of a link outline. Much like how visited links are often styled to be the same colour as non visited links to the detriment of accessibility and usability, simply to appease a design – the good old link outline can often suffer the same fate.
Interactive elements controlled using Javascript and styled for example as oversized fancy call to actions are often the first to suffer, as 99% of the time these controls are just link anchors styled and controlled using JavaScript to appear all fancy and interactive. If the developer hasn’t already removed the link outline, you can guarantee that when someone sees the outline around their beautiful call to action, a complaint that it doesn’t look very nice will follow. The outline will likely later be removed, without a suitable keyboard accessible alternative put in place.
Applying and removing link outlines
Outline can be applied using the CSS :focus selector on a targeted HTML element like below:
a:focus { outline: 1px dotted; }
selector:pseudo-class { propery:value; }
This declaration essentially says that for all link anchors (a tags) when they have focus, apply the property outline with a width of 1px, dotted.
a:focus { outline: 0; }
The above will have the reverse effect, by removing the link outline for all anchors. This now impacts keyboard accessibility.
So what if I still don’t want to apply a link outline?
Not setting an outline is fine, as long as you can provide an alternative style for it. The main objective is to provide keyboard accessibility here, so as long as you have a suitable alternative accessibility will not be impacted.
Rather than using a link outline, perhaps changing the text colour when the link is in focus would be a suitable alternative.
Example of outline removed with the text colour change replacing it when the link is in focus..
This can be easily achieved with a little tweak to your CSS:
a { text-decoration: none;}
a:focus { outline: 0; text-decoration: underline; color: red;}
So now we are essentially telling anchors which don’t have focus to not underline their text (text decoration = none). Anchors with focus now also have their outline removed and instead have their text underlined and in red. Very simple and design wise and probably an improvement for visual indication of an item in focus.
As long as you maintain a good colour contrast for alternative styles when you choose to not use outline for elements in focus and keep a decent level of consistency in terms of colour choices, then accessibility should not be impacted.
Is that it?
As long as you ensure that all interactive and navigation elements on a page have a focus effect applied for keyboard navigation then you should be fine. A good rule of thumb to use for this would be checking if anything with a hover (mouse over) effect, also has an equivalent keyboard accessible focus effect. Manual inspection would still be required though, to make sure nothing was missed that didn’t have either a hover or focus effect.
Compatibility issues with older browsers
Now is probably a good point to highlight the issues that will arise with solely relying upon the CSS :focus selector to apply highlighting for items in focus. On older versions of Internet Explorer (IE), the :focus selector wasn’t supported, so to get around this we use another selector :active. Active will allow you to style currently active elements on IE6 and 7, but for IE7 it will only work on anchor elements (links).
If you don’t want to be limited in IE7 to anchors, you can make use of a JavaScript library called IE7-js (actually a series of library’s for IE7-9), which will allow you to make use of the: active selector on other elements just by loading the library via a conditional statement in your document. If you want to go one step further and don’t need to support IE6, you can ignore :active and gain support for the :focus selector in IE7 by including IE8.js in your conditional statement.
How do I test for this?
The simplest test would be to check page navigation with the keyboards tab key, to check if an outline or alternative style is applied around the element in focus. If it doesn’t, then this means a style has not been considered for keyboard navigation.
Another quick test would be to open developer tools (F12 on most browsers) while viewing the web page and inspecting the sites style-sheets. A good rule of thumb here, is that any declaration that has :hover set on a selector, should also have both :focus and :active equivalents.
Example of a good declaration, which includes :active and :focus for keyboard navigation styles.
Sometimes though, poor markup implementations affect your ability to target elements for styling. This usually occurs when non standard markup is used for interactive elements in combination with JavaScript event handlers such as onclick to provide some form of interactivity e.g. onclick="window.open('http://www.someurl.com')" (on selection, open in a new browser window this URL). So it is always important to go over navigation elements with a fine comb to weed out anything you may have missed.
The last test is actually an oddity which is rarely done. Sometimes HTML elements on a page which would not normally be included in the keyboard navigation cycle are forced to be included by assigning the tabindex attribute. There may be a good reason for doing so, but I’ve yet to see one. Normally depending upon how your stylesheet has been configure for elements, these items would be excluded from keyboard accessible visual indicators such a outline. Unless you can justify a good reason for them to be included in the tabindex, I would normally suggest removing them. Every browser worth testing these days automatically indexes HTML elements which should be included in the tab order, so taking over its control to include non standard elements often impacts accessibility, so be careful.
Thanks for reading.
Related posts:
Darren,
Thanks for posting this; it is very timely for me because I’m about to start testing a new set of changes to our company websites and I will be using some of your ideas there! Also going to get our web devs to read this…
I trust you and the family are all well.
Stephen
Hi Stephen,
Thanks for the comment, I hope your company find these and what’s to follow useful.
We are all good mate, thanks for asking. Hopefully we’ll get a chance to catch up next time I’m down your neck of the woods.
Thanks,
Darren.
A person who has difficulty holding a mouse may also have other types of disability. How do you keep the balance in designing a page that provides web content accessibility for all types of users? How about people who prefer to switch off CSS stype so they use the site map for navigation? The other important important aspect to keep in mind is that page elements are able to communicate with assistive technology so they function properly. I agree that web content should be accessible with and without a mouse but there are always limitations to satisfy each and every disability criteria. As long as work around is made aware to the user then half the battle is won.
All website shold comply with W3C guidlines and provide keyboord shortcuts for those who can’t or won’t use a mouse. Keyboard shortcuts can reduce wrist strain and help you work in restricted spaces
The other issue is with browser incompatibility that handles JavaScript and CSS style very differently. A similar issue with providing zoom function for font sizes. Some website provide their own handle so as to eliminate Browser reliance. Zomming in may destroy the layout so be careful. Some people use text only browser such as Lynx. Section 508 requires that web pages layout is checked with CSS turned off.
There are no tools out there that can test such functions therefore expensive manual testing is to be carried out. Code should be written for ease of testing, cmplexity leads to all sorts of problems.
Here is a good article to read on Evolution of CSS Layout: 1990s to the Future
Hi Mohinder,
Thanks for the comment. We are venturing outwith the scope of this article, but I’ll try my best to answer your questions.
Balancing accessibility considerations to cater for different types of disabilities is indeed difficult. When you begin to venture into the likes of dyslexia and autism, where subtle choices such as the use of a title tags tool-tip causing user frustrations, then indeed it can seem daunting. Yet when you look further you’ll often see choices that can be made quite easily. In the prior case I recommend not using title attributes at all, due to the impacts they can have on other types of disabilities if misused. The WCAG guidelines are actually really good at helping you gain an understanding both technically and across the impacted user groups. They are guidelines for a reason though, so it always makes sense to follow up on them with a bit more research into the problem areas you are trying to solve.
As for CSS off and text only browsing. I can appreciate your CSS comment as it is important for users to be able to gain their own control via user stylesheets which some do (I even know of some people without disabilities that do this). Text only browsing is a bit old hat if you ask me. I like Karl Groves take on this: Text-only is not accessible. I tend to agree, the days of considering that a website must be accessible for text only browsers has probably had its day. It needs to be accessible full stop, and that can come from a good accessibility strategy and practices when developing sites and content. Just saying something has to work on a text only browser holds no merit for me sadly and is why organisations struggle to take guidelines seriously.
You can produce cross-disability accessible websites – of course you can. Much of that can be done simply by using HTML, CSS and JavaScript in the way it was intended to be used.
Thanks Mohinder. Hopefully we will meet again soon, and we can discuss accessibility further in person.
Darren.
Nothing to do with this post really, but just the most recent thing we talked about.
So, sorry to be off-topic. But here you go.
http://www.boxuk.com/blog/unboxing-meteor
Thanks David, much appreciated!