It’s not unusual to stumble upon ambiguous link phrases on web pages (phrases such as, “Click here”, “More”, and so on). Some screen readers allow users to gather a list of links from a page, but these types of link phrases are usually meaningless when read out of context. This article demonstrates a technique that allows ambiguous link phrases to be rendered visually in a page, whilst making sense to screen readers, and other non-graphical devices, that might render the links out of context.
Ambiguous Link Phrases
Checkpoint 13.1 of WCAG 1.0, a priority 2 checkpoint, requires that authors clearly identify the target of each link.
Link text should be meaningful enough to make sense when read out of context — either on its own or as part of a sequence of links. Link text should also be terse. For example, in HTML, write “Information about version 4.3″ instead of “click here”. In addition to clear link text, content developers may further clarify the target of a link with an informative link title (e.g., in HTML, the
titleattribute).
The purpose of this checkpoint is to ensure that the visitor clearly understands the purpose and destination of each link in a document. This is particularly useful to screen reader users that may read link phrases out of context. Visually, ambiguous link phrases, such as, “click here”, “Read more”, and so on, might make sense when rendered visually in a graphical browser. However, the same ambiguous link phrases don’t make any sense whatsoever when read out of context. For example, JAWS has an option to display a list of links on the page with Insert + F7. Along with the JAWS keystroke to list all headings on a page (Insert + F6), gathering a list of links is a popular way for JAWS users to orientate themselves and quickly discover what they’re looking for in a document.
Although checkpoint 13.1 specifically mentions using the title attribute, the title attribute has very poor accessibility support with current user agents. By default, it isn’t announced automatically by most screen readers, and has poor keyboard support from major browsers. It is possible to access the content of the title in some major browsers, but the discoverability isn’t obvious. Fortunately, Cascading Style Sheets (CSS) offer a far better method to help developers provide context for non-visual user agents.
Some people argue that the content of a document isn’t intended to be read out of context, and they do have a point. However, ambiguous link phrases can be difficult to understand by all users, including screen reader users, even when they are read in context. As ambiguous link phrases can be difficult to comprehend by everyone, and given the fact that some screen readers offer their users the ability to extract links from a document to determine what links they have available, best practice is to ensure that all link phrases make sense when read out of context.
The following image illustrates what a JAWS user might be faced with from ambiguous link phrases in a typical blog:
Image may be NSFW.
Clik here to view.
The link phrases in this example are meaningless, and there is no way that a typical screen reader user could reliably make sense of these link phrases, even though they might make perfect sense when rendered visually. The link phrases in this example might seem contrived, but they are taken from a popular website that advocates web standards, and quite typical of most blogs.
Uniform Design Patterns
Sometimes, a design may require a uniform pattern, such as repetitive “Read More” link phrases, being visually rendered in the document. This is perfectly acceptable, but doesn’t mean that link phrases shouldn’t make sense when read out of context.
For many years, developers have been using techniques to position content outside the visual viewport. The technique involves absolutely positioning the content outside of the viewport using CSS, so that those using graphical user agents that support CSS see the visual design as it was intended, and those using non-visual user agents receive the content including the parts that should be hidden visually. The following example demonstrates the technique with a class that is applied to a span element that is included in the content to provide context for non-visual user agents. The content of the span is moved outside of the viewport in graphical browsers that support CSS, but is available for all other user agents.
A CSS class to provide context
span.context
{
position: absolute;
left: -999em;
width: 0.1em;
overflow: hidden;
}Any span element that is assigned this class is positioned absolutely outside of the main viewport. The content of the span is very slim with its overflow property set to hidden to help ensure that the content doesn’t bleed into the main viewport.
Markup demonstrating the use of the context class
The following markup demonstrates how the context class might be used to provide context with a span element within a link phrase, without effecting how it is rendered visually in a graphical browser.
<a href="dest.html" href="dest.html">Read more
<span class="context"> about the origins of lemons</span></a>
This example would result in graphical browsers with CSS support displaying a link phrase of, “Read more”, whilst providing a link phrase of, “Read more about the origins of lemons”, which makes perfect sense when read out of context for all other user agents. The following image shows what is presented to a JAWS user using the above example:
Image may be NSFW.
Clik here to view.
General Context
This technique isn’t just limited to providing context for link phrases. It can also be used to provide context for any element that, for whatever reason, is not intended to be rendered visually. For example, a design might not include headings, but headings are essential for screen users to understand the structure of a document. The context class can be applied to hidden heading elements, but the selector would have to be renamed from span.context to either *.context or just plain .context so that the class may be used by any element.
Structure isn’t just useful to screen reader users, but can also be essential for other users. For example, heading text can be helpful for people with cognitive impairments to understand the structure of a document. In these cases, hiding context should be the last option.