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; }

Repurposing headers

One of the benefits of a proper and consistent heading structure in an HTML page is that they can be repurposed to improve access to the content. For example, the heading structure could be extracted into a Table of Contents or an outline, providing in-page navigation or overview.

Screenreader users have header navigation, which allows them to go through the document on a header by header basis. It’s not perfect, but its very useful to find a piece of information quickly. The screenreader exposes a means of navigation to next or previous headers of a particular level, so a visitor can, for example, jump to the next second-level heading. So far there’s no indication of what header levels are available unless the user enquires.

Barriers in skipping headers

This means that if heading levels are skipped they may not be found by a screen reader user. For example, if a screenreader user is navigating down the second level headings (h2), and finds one that comes close to what he’s looking for, he may elect to navigate through the third level headings(h3). If this level is skipped in the header structure, the user will be informed that there are no third level headings. Without third level headings, the expectation is that there will be no fourth, fifth or sixth level headings there either. So those headings will typically not be found by a screenreader user.

Skipping a header level makes navigating by headers less usable for screenreader users.

It makes sense to inform screenreader users of these forms – particularly login and search, because they form an important part of getting things done on the site, or navigating to a personalised part of the site.

For that reason, preface all of these forms with a header. This allows screenreader users to use headers as a way of navigating all the elements in the page. Make the header text descriptive, for example “Login to your account”, or “Search this site”. It would be better to integrate these headings as part of the design, but they can be hidden by positioning it off-left if needed.

It’s more natural for this heading is placed before the start of the form, outside the opening form tag. That way a screenreader user can find the relevant header in heading navigation mode, and when they switch back to the normal page navigation mode the first thing immediately after the header is the form.

Ensure that the heading level makes sense in the document structure, and don’t skip a heading level. Use an h2 header for forms that appear before the h1 header; there ideally should be only one h1 header per page.

Related info

• YouTube: Importance of HTML headings for accessibility: shows how useful headers can be as a way of navigating a page of content in a screenreader (JAWS), and the difference when headers are not marked up.