Accessibility considerations: Visual indicators for keyboard navigation


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.

Link outline example.
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.

Alternative example to link outline styles.
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.

Accessible CSS declaration example
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="'')" (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:

  1. Accessibility considerations: Logical document structures
  2. Considerations for accessible web development
  3. Accessibility: The perils of ignorance.
  4. Accessibility: Pairing with a blind consultant.