I recently rebuilt this site using WordPress 3.0, which was a lot of fun. Part of the fun was developing my own theme to try and make greater use of HTML5 and to improve accessibility. I did this by making changes to the various template files that come with the default Twenty Ten theme. One of the changes I made deals with the "Continue reading" links that follow blog post excerpts on the main blog and archive pages.
When necessary, the default theme adds a "Continue reading →" link at the end of the post excerpt's paragraph, providing a link to the full blog post. This is a basic usability feature that helps most users. The link text ends with a rightwards arrow, →, added using the character entity reference →.
I had two main issues with the default implementation. One, on a page displaying multiple excerpts, there would be multiple "Continue reading" links with different targets. This has a potentially negative impact on accessibility for certain users.
In most cases, the fact that the "Continue reading" link is visually contiguous with the relevant excerpt's text should make the link's target clear enough to sighted users. But for visually impaired users, and in particular screen reader users, determining the link's purpose means knowing or investigating its surrounding context, namely its association with the relevant excerpt. This is its "programmatically determined link context", and following WCAG 2.0 Success Criterion 2.4.4, is considered accessible as long as the link is found in the same paragraph as the excerpt itself. Placing the "Continue reading" link in its own paragraph, for instance, would constitute a failure of SC 2.4.4.
Most screen reader users are also able to call up a special window that presents a list of all the links on a web page. Such a list would contain a number of "Continue reading" links that are more difficult to distinguish since they are removed from their context in the page and are all named the same. This is where Success Criterion 2.4.9 comes in. Whereas SC 2.4.4 is a Level A criterion, SC 2.4.9 is Level AAA, and serves to maximise the accessibility of links in terms of identifying their purpose or target. That is, in accordance with SC 2.4.9, each link's purpose or target should be clear from its link text alone, even when the link is removed from its original context.
The solution is obviously to include the blog post title in the "Continue reading" link's text, for example, "Continue reading Animals of the Serengeti." The concern, however, is that this introduces unnecessary visual noise or repetition, and, depending on the post's title, such links can get rather long, potentially disrupting the page's visual layout. The well-known accommodation to this concern is to include the blog post title in the link, but wrap the title in a span element that is visually hidden while still available to assistive technologies. (Typically, this has been done a number of ways using CSS, most often by absolutely positioning the element far outside the browser viewport. More recently, though, a promising technique using the clip property to hide content has surfaced.) In this way, sighted users still just see the link text as "Continue reading," while, as far as screen reader users are concerned, the link text is "Continue reading Animals of the Serengeti," whether the link is read from the page or from the list of links provided by the screen reader.
My second concern with the default theme's implementation of the "Continue reading" links has to do with the inclusion of the rightwards arrow character as part of the link text. I understand it to be serving as a visual icon or prompt to sighted users to help them identify or grasp the point of the link. As such, I think it is better added using CSS. It, or another character or icon could be added as a background image, but deciding to keep the rightwards arrow, I chose to add it as generated content, i.e., a.continue:after {content: " →";}. This keeps the arrow out of the DOM tree. (Note: Character entity and numeric references won't work with the content property, so you must use the appropriate Unicode hexadecimal value, e.g., "\2192" for a rightwards arrow. Just using the actual character itself also seems to work, but this is, I assume, because the CSS file is encoded as UTF-8.) Of course, since they don't support CSS generated content, Internet Explorer 7 and below won't render the arrow, but I'm willing to live with this, since I feel it is a relatively minor enhancement. If one feels differently, using a CSS background-image would be the way to go. The added benefit of using the content property, however, is that the arrow resizes nicely when the browser text size is increased.
I'm also willing to admit that this is a rather finicky concern to begin with, especially since screen readers, or at least JAWS, Window-Eyes, and NVDA, do not announce the rightwards arrow in any case. Window-Eyes will say the word "question" when the virtual cursor is moved over the character itself, but reading the individual character like this is probably an edge case, since most users will read the link text as a whole. Still, I prefer to keep actual content separate from what I consider visual or presentational support.
Putting it all together, here's how it is implemented in my WordPress theme.
/**
* Returns a "Continue Reading" link
**/
function my_continue_reading_link() {
return '<a class="continue" href="'.get_permalink().'">'
.__('Continue reading<span> '.get_the_title($post).'</span>')
.'</a>';
}
/**
* Replaces the "..." appended to automatically
* generated excerpts with an ellipsis and
* adds a custom "Continue reading" link
**/
function my_auto_excerpt_more($more) {
return '…'.my_continue_reading_link();
}
add_filter('excerpt_more', 'my_auto_excerpt_more');
/**
* Adds custom "Continue Reading" link
* to custom post excerpts
**/
function my_custom_excerpt_more($output) {
if (has_excerpt() && !is_attachment()) {
$output.=my_continue_reading_link();
}
return $output;
}
add_filter('get_the_excerpt', 'my_custom_excerpt_more' );
Basically, I just renamed and modified the function, already present in the default theme's functions.php template file, that returns the "Continue reading" link. Then I updated the two relevant filters to call this modified function instead of the original.