The dotted outline on links is the main visual cue to where the current keyboard focus is on a page at any one time. By tabbing or shift-tabbing through the document the focus is set on the next or previous focusable elements.

This focus rectangle is removed because it makes things look unsightly, but they serve a very useful purpose. And that purpose is critical for a keyboard user to find their way through a page.

So it is essential that there is a clear focus indicator, both on links and form fields. Clear enough that a visitor looking at the page for the first time can spot where the keyboard focus is as quickly as possible.

We do this though CSS’ :focus pseudo-class on the target element. For example, to change the background colour of a link when it receives focus we use the following:

a:focus {
    background-color: #aaf;
}

We can do the same with input fields:

input:focus {
    background-color: #aaf;
}

In each case, the background colour of the focusable element changes colour when it received focus, and that background colour changes back when the element loses focus. By making this background color change enough it is possible for a visitor to find the focused region of the page.

The same argument can also apply to when links are active, using the :active pseudo-class. An active link is one that is in the process of being clicked, so for example when the mouse-button is being held down when over a link and just about to be lifted, this link is seen to be active. Using this active pseudo-class to style an element that is active provides a visible cue about what is going to happen.

a:active { color: red; }

And, we often overlook the usefulness of setting a visited link colour (with the :visited pseudo-class). This proves very helpful in distinguishing destinations a visitor has already been to, thus simplifying the choice of which link to try next.

a:visited { color: purple; }

A common pitfall is that certain browsers need these pseudo-classes in a specific order so as not to have one pseudo-class override the styles of another. The safest pseudo-class order is :link, :visited, :hover, :focus and then :active:

a:link { color: blue; }
a:visited { color: purple; }
a:hover { color: magenta; }
a:focus { color: magenta; }
a:active { color: red; }

The attribute itself is meant to supply optional supplementary information. The most beneficial example is in conjunction with the abbr element, providing the knowing user with an expansion of an abbreviation. A second practical example is using it with forms to provide additional relevant information. (We also looked at using titles with form fields.)

But there are many examples of a title attribute being used to provide the same information that’s already available and accessible. The most common example is links, especially in navigation you see the following piece of markup:

<a href="/sitemap/" title="Visit our sitemap">Sitemap</a>

Here the title attribute is just a plain duplication of the link text. Sure, it may have two extra words of Visit our which don’t appear elsewhere, but this explains what a link does, and is just as redundant and irrelevant to site visitors. Most of them would need to have understood what a hypertext link is and what it does before even arriving at your site. Its just not necessary.

The extra text is a variant of the click here problem, it explains about how to activate a text link rather than succinctly describing the destination.

Some users have their screenreaders configured to read out both the link text and the title attribute. In this case, the above link would read out “Sitemap visit our sitemap”, and either prefix that with the word “Link”, or switch to a different voice to indicate the presence of a link. The duplication slows down the reading of the page, and is an unnecessary hiccup.

There is very little benefit to the title attribute in this code example. It is better, accessibility wise, to just drop the title attribute altogether in this instance.

Creating barriers for screen magnifiers

Screen magnifiers have the tendancy to make all title attributes appear when they have a titled element within the view of the magnifier. Any title, be it on a div, or a header, or a paragraph or a link, will appear in a tooltip like fashion. A significant use of titles may distract a screen magnifier user, even prevent them from seeing a particular piece of content because it has been obstructed by a tooltip.

There’s just no positive accessibility benefit to using a title attribute to duplicate existing content. The title attribute. when it offers no extra value, hinders more than it helps.

Image links

A common mistake is to correctly determine that the text equivalent for the image is already present on the screen, in the form of the story title, and go from there to inserting a null alt attribute (alt="") for the image. When that image is the sole child of an anchor we are left with an anchor with no link text. And that’s an accessibility barrier.

The screenreader fallback when there is no link text for an image link is to extract something from the image’s src attribute – a URL – and this typically results in something unintelligble being read out by a screenreader.

What we need to do here instead is to populate the alt attribute with something that can be used as link text. In the case where the only appropriate (and succinct) text is the story title, it is fine to use that.

Redundant links

Its true that having two links with the same perceived link text linking to the same page is a redundancy, but this is much less of an evil than a text-less link. And much less of an accessibility barrier too.