Contemplating “read more” links

July 17, 2014

Topics: Accessibility, Usability, WordPress.

Web accessibility guidelines stipulate that links need to provide context for meaning; but they also stipulate that link text needs to be unique when it leads to a new resource. Under Success Criterion 2.4.4, a read more link after an excerpt of the post would be meaningful, because the context provides information about what the link does.

But when generating a list of links, “read more” links produce a long series of links with the same text and different destinations, making those links useless. Bummer.

The common solution, and the specific solution required in the WordPress theme review guidelines for Accessibility is to insert the post title into the read more link. This ensures that the links list produces a list of links that have value to a screen reader user. Hiding the text from sighted users means that this redundant text isn’t distracting to those users.

But it also means that when the user is navigating through the page, there will be some serious duplication, since the title of the post will be announced so many times. So: is this the best solution? Is there another way we can do this that provides a better experience?

I’m not convinced in any particular direction at this point; but I feel there should be another solution that would work better. A few things that I’ve considered:

  1. Make “read more” links into buttons. This takes the links out of the link list – as a result, you can leave them with plain read more text, but the redundant link doesn’t show up over and over in links lists. But it depends on mis-using the button element, which shouldn’t be used for sending a user to a new location.
  2. Use JavaScript to either a) remove the screen reader text on :focus or b) attach aria-hidden on :focus I’m not sure there’s any actual pluses to this: it doesn’t necessarily help when the screen reader user is just reading the text; and means that the link list is different from the links actually arrived at when tabbing through the links on a page, which could be quite disorienting.
  3. Abbreviate the post title for use in the read more link Could help avoid redundancy and make the navigation process more efficient, but increases cognitive burden in making certain the link references the same article as the title did. It could also increase the labor burden, as automated abbreviations of post titles are unlikely to be reliable.

I like the idea of pulling the read more links out of link lists, as long as there is a link to the post with the title elsewhere — and in the WordPress sphere, that’s almost always available through the post heading. But we still need a contextual means to navigate from the end of the excerpt to the full post; I don’t think it’s fair to expect screen reader users to need to navigate backwards to the title link in order to read further.

I’m not sure that any of these would be a better solution; but since I’m dissatisfied with the solution we have, I want to consider other possibilities. These are just a few concepts, and I’d love to hear any other ideas available.

For now, I’m going to continue to recommend the same thing I have for years; but I’d love to change my mind.

Does anybody have any other thoughts on ways to supplement read more links? Does anybody have anything they particularly love? Something they particularly hate? A dream within a dream?

Have something to contribute?

« Read my Comment Policy

18 Comments on “Contemplating “read more” links”

  1. Thanks for the suggestion, George – but it creates a whole knew problem. Adding aria-hidden to a focusable element means that the link will still receive focus, but the content will be hidden. This results in a blank tab stop for screen readers.

    The link needs to receive focus for sighted users, but it now has no text content for screen readers.

    Referencing aria-hidden content via aria-describedby will have highly variable results – while aria-describedby should be able to read hidden content (so that it’s useful for referencing content only needed for screen readers), the predictability of what it will do when used to reference content that is specifically hidden *from* screen readers is low.

  2. This is an old thread but solutions are still varied.
    Here’s a totally different suggestion: Instead of exposing Read-more to screenreaders and tackling all the a11y complications that go with it, how about we hide all that from them (aria-hidden) and just use aria-describedby to tell them about the hidden content instead?

  3. It’s certainly a legitimate strategy. It creates design challenges to make the interface clear, since as you observed, there’s a strong expectation that the title of a post will link to the full text. This should be something that can be overcome, of course!

  4. I came upon your article by googling “accessibility redundant link.” What do you think about keeping the read more link after the excerpt and adding the post title to the link text (however you choose to do it) visible only to screen readers (robots), and then simply removing the post title link before the excerpt and instead making it a heading? This way the links will only show up once on screen reader link lists and you still have the SEO benefit of including your post title in a link to the post content. The only downside is that the post title is no longer a link which may not be expected behavior.

  5. Um. How about just use descriptive link text and if that isn’t an option use aria-label…

  6. SEO Focus keywords certainly could be used in read more links, technically speaking. Whether that would *increase* the accessibility of the link is fairly dubious. The read more link needs to be more accessible because it clearly communicates the target; inserting keywords would probably just create nonsense statements.

  7. Don’t know if my comment saved – was just wondering if SEO focus keywords could be used in Read more links? Might add SEO incentive to make them more accessible (with drawbacks of compatibility with SEO plugins and not everyone does keywords).

  8. Yes, that’s one common method of doing hidden text; which is the standard method of handling read more links. That’s not the preferred method of hiding text for screen readers, especially if you need to support right-to-left languages, but it’s functional in most circumstances.

    But this article is about exploring alternatives to handling these situations – ideas that are outside the “standard” methods, because the standard method has some significant flaws.

  9. [this comment has been edited to remove personal information]

    See example and posts at:

    Provided by Greg Kraus about 3 years ago.

    When there are a bunch of “read more” links on a page, it is usually fairly obvious from visual cues what the “read more” refers to. However, when screen reader users encounter a bunch of “read more” links on a page, it is not always obvious which part of the page each “read more” link refers to. A simple solution is to use a bit more descriptive text than simply “read more” and use CSS (Cascading Style Sheets) to hide the additional text. In this example the following code is used.

    This is the CSS rule.

    .offscreen {


    •The off-screen text needs to be included in the <a> as well, otherwise it won’t be read correctly by screen readers.
    •You cannot use the CSS rule display:none or visibility:hidden as that will make the content invisible to screen reader users.
    •This code is not unique to me. It is the compilation of different examples I have seen in various accessibility forum posts. I just want to put this example in writing for others.

  10. The first two or three words has a lot of potential for repetition if a site uses patterned or sequential post titles, such as “Big long post title: Part 1” or “Weekly Announcement from My Site: March 7, 2014”. But it’s not totally improbable. The button possibility is what I consider to be the best of these options, but I’m still uncomfortable with the idea of using a button to act as a link. Thanks for your thoughts!

  11. Hi,

    How about adding first 2 or 3 words of the post along with Read More?
    In fact, I liked your idea of making it a button and then if we add first 2 or 3 words as button label and hiding the same using CSS (Cascading Style Sheets) or through aria-describedby? What do you say?

  12. Hi Joe

    I prefer using the post title followed by full post or full article , I use this format on all of my Blog sites such as



  13. Sure. To use your own example as a starting point, do this:

    <?php the_content( sprintf( __( '...continue reading<span class="screen-reader-text"> %s </span><span class="meta-nav">&rarr;</span>', 'tinyforge' ) ), get_the_title() ); ?>

    You can also look at my demo theme, Universal, on GitHub as a reference example.

  14. Hi, Joe,

    I’m trying to make my theme accessible and implementing features according to your new guidelines. You gave an example how to extend a “read more” link. It is a good start, but I have difficulty to make it translatable, because you cannot insert PHP (Hypertext PreProcessing) inside translation. Could you provide a version that can be translated? This is an example of a simple string without accessibility feature:

    Thank you!

  15. I’m not sure whether you could practically differentiate between a temporary lack of mouse movement and a total lack of mouse movement – and, of course, that would not actually detect screen readers, just a non-use of a mouse. And, as I’ve written before, I have some serious discomfort with the idea of detecting assistive technology.

    That’s also an interesting suggestion. Like you say, sketchy in application, but intriguing to consider.

  16. Bradford Knowlton; July 17, 2014 at 2:53 pm

    Part 1,

    I have never thought about this until now..

    Detecting screen reader users by lack of mouse movement. This leads to the 2nd question, which is an individual who is using keyboard navigation without a screen reader.

    Part 2,

    This is backwards logic, but this thread is a good place to put it and get some feedback. Why not remove the link on the post title, maybe use a javascript on click instead. Then have the read more be the only anchor link to the article. A screen reader browsing by link will find it easy enough. A screen reader reading the page will hear the excerpt followed by a link to continue reading that article. The mouse user / keyboard navigation user could trigger the onclick event which would redirect them to the article.

    I’m not recommending anyone try this in practice, only to throw it out as a discussion point. As it really violates more guidelines then is solves.

  17. Thanks for that suggestion. It’s an interesting one, but I’m uncertain whether the scroll event would be triggered by screen readers. I think that it would as soon as focus moved below the fold, but it would be possible for a read more link to appear before the scroll, which could cause issues.

    That’s not to say that there aren’t other events that could be used to trigger the same idea, however. First :focus event, for example.

  18. Bradford Knowlton; July 17, 2014 at 1:33 pm

    An idea..

    Add in read more links with jQuery during the 1st scroll event. In theory, screen readers won’t notice the change in the dom, so they won’t get added to the link list. For effect, you could even set a fancy fadeIn, to draw attention to the read more and draw visitors deeper into the site.

    This would be simple enough to test, and would be interesting to see if screen readers pick up the change in dom, or if they trigger the scroll events.