Include node title in "Read more" link for better accessibility and SEO

please provide a real patch
drupal.org/patch

Is there any other approach? This one will generate a big link, that may make the links line wrap when more links are used.

Maybe placing the "read more" stuff in the node contents area? Ala WordPress?

maybe we could change the title-attribute...

How about:

if ($main == 1 && $node->teaser && $node->readmore) {
      $links[] = l(t('read more'), "node/$node->nid", array('title' => t('Read the rest of %post.', array('%post' => htmlspecialchars ($node->title) )), 'class' => 'read-more'));

Please, this is untested, but I can make a patch which will work.. (If appreciated.)

putting the words in the title tag won't help much. They need to be in the link itself.

Sorry, I disagree with that.

Quoting Google guidelines:

Make sure that your TITLE and ALT tags are descriptive and accurate.

I guess that means, at least, Google knows what the title tag is for.

-1 for letting SE decide how we (webmasters) should write links, that are correct. If some SE do not know how to handle the title tag, that is there problem. They won't success, if other SE do their job better.

Also, note that the node title is often a link. That makes the "read more" link kind of redundant for SE, but it serves a purpose for humans, mostly if they are used to visit Drupal based sites. For nodes where there's no teaser or it is equal to the node body, that link doesn't show.

i like the idea of putting it in the title.
here is a patch for it

-1 to this patch. When viewing in a list, The node title is a link anyway, so why do we need to put the title where 'read more' is as well? If you're that obsessed with SEO, and you really want to change this, you can do so in a contrib module with hook_link_alter().

Reopening this issue as it is identical to an issue that I was planning to file for accessibility purposes.

Issue
Links with different URLs and the same link text are confusing to screen-reader users.

W3C web content accessibility guideline 2.0 (WCAG 2.0) success criterion 2.4.4

2.4.4 - The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context,
except where the purpose of the link would be ambiguous to users in general. ( http://www.w3.org/TR/2008/NOTE-UNDERSTANDING-WCAG20-20081211/navigation-... )

Although W3C provides some guidelines of when a links role can be determined based on programmatic context ( http://www.w3.org/TR/2008/NOTE-UNDERSTANDING-WCAG20-20081211/navigation-... ), the determination is still somewhat subjective.

The WebAIM survey of screen-reader users conducted earlier this year reported that 35% of respondents are most likely to navigate through or listen to links when first accessing a new, unfamiliar homepage ( http://webaim.org/projects/screenreadersurvey/ ). Clearly many links with the same link text would be unhelpful to these users.

Using the title attribute to provide additional information to screen-reader users, and other users with disabilities, is not sufficient because browser and assistive technology vendors implement the title attribute poorly (see http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-... ).

Recommendation
1. The node title should be part of the linked text for "Read more".

2. The node title can be displayed visibly, or hidden using the class being created in #473396: Defining System-Wide Approaches to Remove, Make Invisible & Push Content Off-screen with CSS, or possibly #526712: l() does not accept a parameter for supplemental text for screen-readers.

3. It should be determined if the node title is more appropriately placed to the left of the "Read more" text for RTL languages, and if so the patch should accommodate this.

tagging

*puts on her bullet/flameproof suit*

I'm all for putting the article title in read more links (taking the form "read more about [article title]" or "continue reading [article title]") but, depending on the length of the article title, this may be a case of more noise than signal if it immediately follows a link which is comprised of the article title.

Before I get burned at the stake for being an accessibility heretic, bear with me a second and I'll explain.

Typically on a site you'll have one or several [module/widget/blob/whatever](s) which take the following form:

[headline/article title] (we'll call this x, for ease of reference)
[blurb o' text] (y)
[read more link/button] (z)

If the only link to the full article is z, then link text of "read more" could not be considered sufficient under WCAG1.0. It may be concise and unique, but it does not contain all information required to inform the user as to the destination of the link and is unlikely to make sense when taken out of context.

However, there was a change in thinking between WCAG1.0 and WCAG2.0 on this issue.

In the Understanding Success Criterion 2.4.4 documentation (found at http://www.w3.org/TR/2008/NOTE-UNDERSTANDING-WCAG20-20081211/navigation-...) it gives the following examples as sufficient:

A link is preceded by a text description of the information at that URI
A page contains the sentence "Learn more about the Government of Ireland's Commission on Electronic Voting at Go Vote!" where "Go Vote!" is a link.

and

News article summaries
A Web page contains a collection of news articles. The main page lists the first few sentences of each article, followed by a "Read more" link. A screen reader command to read the current paragraph provides the context to interpret the purpose of the link.

These two examples would seem to indicate that it's perfectly acceptable to have a paragraph of text and then a read more link and expect the user to take steps to discern context from surrounding text rather than relying solely on a list of links.

I'm not hugely comfortable with this, but at the same time, I don't want to place a significant additional burden on users by making them read a whole lot of additional information that is, for the most part, duplicating information already in place.

For example, if x is a link to the full article in addition to z, then the link text of z is less critical, as there are two links to the full article, one with link text that would have been considered sufficient under WCAG1.0 and one without. In addition, in a standard list of links, the insufficient link text (read more) would appear directly after the sufficient link text (article title) which provides context within the list of links (although the user will most likely not activate the read more link). If the links list is sorted alphabetically then sure, that context is lost and a bunch of read more links appear together, but this is again not critical as the sufficient link text will appear elsewhere and the user will be able to follow that link and get to the desired article.

It's easy to consider, following the above logic, that the read more link is redundant. However, it's position at the end of the blurb provides a usability boost to users who can see the page as they do not have to move their eyes back up over text they have just read and can activate the link which directly follows on. For screen magnification users, this can be a significant boost in usability, as the article title may not be within their viewpoint by the time they've finished reading the blurb.

So where does that leave us?

Linking the article title = good.
Providing a read more link after the blurb = good.
Linking the article title AND providing a read more link after the blurb = good.

BUT

Including the article title visibly with read more tends to make it quite long which is why most people just use "read more" text or image links so I suspect that most people won't have them appear visibly because it's difficult to implement neatly (especially taking into account what happens when you upsize the text).

This leaves us with the option of including the article within a span which is then moved offscreen. This then has the following issues:

a) the link text can be lengthy
b) screen reader users still have to get past the words "read more about" to get to the unique part of the link, so it doesn't provide much in the way of a real time benefit, especially if it's a duplicate of a link without those three words
c) if the span is moved offscreen it'll create a link of dancing ants which will stretch off the side of the page which might persuade designers to remove the link focus outline which would be to the detriment of the user experience for those who rely on it.

So, all things considered - I think that including the node/article title in the read more link is only an accessibility improvement if there isn't already a link which has sufficient link text.

It might be a benefit for SEO purposes to have the text in two links rather than one, but that's a whole other kettle of fish.

@annmcmeekin

Interesting response... what do screen-reader users think about these links in practice? Clearly the following statistics do not account for user testing of any particular site with any particular grouping of links and blurbs, but they are insightful none-the-less. I would say that if over 40% of screenreader users find repeated links difficult that there is an issue worth addressing here.

(Taken from "WebAIM: Screen Reader Survey Results" - http://webaim.org/projects/screenreadersurvey/ )

How difficult are different links with the same text repeated multiple times on the same page (e.g., "more", "add to cart", "details")?
Response
% of Respondents 
Very easy
20% 
Somewhat easy
25% 
Somewhat difficult
31% 
Very difficult
13% 
I don't know
10%
table end

An almost identical number of respondents found repeated links easy as found them difficult. 69.4% of evaluators found them difficult compared to only 42.6%
of those that always use a screen reader. Those with higher screen reader proficiency naturally found these links easier.

So where are we with adding stuff to Read More? Came up a few times in other posts so thought it might be worth revisiting.

This doesn't work, but in the end is it useful since the Title link contains the same information and this is a duplication (other than the Read More string).

  if ($build_mode == 'teaser') {
    $links['node_readmore'] = array(
      'title' => t('Read more') . '<span class="element-invisible">' . t(' about ') . strip_tags($node->title) . '</span>',
      'href' => 'node/' . $node->nid,
      'attributes' => array('rel' => 'tag', 'title' => strip_tags($node->title))
    );
  }

There's also an angle as to whether it's actually useful and if it helps meet WCAG 2.0 standards.

here's a patch

removing fuzz.. $node->title[FIELD_LANGUAGE_NONE][0]['value']) was added rather than $node->title...

#22: read_more_about_title_v3.patch queued for re-testing.

I've just re-rolled it.

+++ modules/node/node.module	15 Mar 2010 15:32:06 -0000
@@ -1275,7 +1275,7 @@ function node_build_content($node, $view
+      'title' => t('Read more')  . '<span class="element-invisible">' . t(' about ') . strip_tags($node->title) . '</span>',

I definitely think that we should have 'about @node-title' together in the t() to give context, but should we put the entire thing in the t(), including the SPAN? There may well be languages where the extra invisible bit needs to be before the 'read more' part, or even within it?

Could do with input from translation people.

Powered by Dreditor.

adding tag for i18n folks.

It's perfectly fine to have a little HTML in translation strings. Use:

t('Read more <span class="element-invisible">about @node-title</span>', array('@node-title' => $node->title));

That seems best to me too; just wanted i18n confirmation.

Though I would put the space between 'more' and 'about' inside the span.

We need to set HTML = TRUE on the link array too.

Updated patch with both of those changes.

I applied this patch here - http://drupal7.dev.openconcept.ca

It worked nicely and resolved the problems with a11y that were reported by Worldspace.

It also doesn't seem to produce a problem in RTL languages like Hebrew - http://drupal7.dev.openconcept.ca/he

#29: 49428.drupal.read-more-node-title.29.patch queued for re-testing.

Just re-rolling the patch in #29

#33: 49428.drupal.read-more-node-title.33.patch queued for re-testing.

Removed the white space between "Read more" and the span so that only the white space in the span remains. Otherwise the link is shown with an additional space underlined on hover -> not pretty.

And rerolled against current HEAD.

This is a pretty simple piece of code to review. Would be great to have someone mark it RTBC.

It's just a reroll and a spacing change to the patch that in #30 was marked RTBC, so I'm happy to RTBC it again :)

+++ modules/node/node.module	23 Sep 2010 19:31:40 -0000
@@ -1287,9 +1287,10 @@ function node_build_content($node, $view
+      'title' => t('Read more<span class="element-invisible"> about @node-title</span>', array('@node-title' => strip_tags($node->title))),

Since "Read more" links can appear for other entities, too, the t() placeholder should be just @title, so that this string can be re-used and only exists once.

Powered by Dreditor.

Good point.

+++ modules/node/node.module	25 Oct 2010 16:10:34 -0000
@@ -1331,9 +1331,10 @@ function node_build_content($node, $view
+      'title' => t('Read more<span class="element-invisible"> about @title</span>', array('@title' => strip_tags($node->title))),
...
+      'attributes' => array('rel' => 'tag', 'title' => strip_tags($node->title)),

mmm, sorry for only recognizing it now, but the read more link is in the critical performance path, output in node listings. Therefore, I think we should invoke strip_tags() only once.

Powered by Dreditor.

Done.

If anyone wants to bikeshed the variable name, they can reroll themselves :p

Thank you!

+1. The code looks good. This is a big boost for accessibility and SEO.

+1

+1 - Got it in my sandbox and it's working great http://drupal7.dev.openconcept.ca/

I can't see how this would be anything but a benefit to core!

#41: 49428.drupal.read-more-node-title.42.patch queued for re-testing.

I'm a bit nervous go change this since it's so incredibly late. It makes a change to a string that was previously quite sane (maybe we need title_suffix or something in D8) and adds new markup to the page that wasn't there before (albeit invisible markup).

However, since this does improve our WCAG compliance, and has a side-benefit for SEO on all Drupal sites, I think the risk is worth it. Though if we start getting any bug reports about this change by theme authors or whatnot, it's going to have to get rolled back.

Committed to HEAD.

[SOLVED]Teaser Link Not Displaying @title of Article

Fully documented, with screen shots, on my blog:
http://mymanthemaker.blogspot.hk/2017/03/properly-working-teaser-links-i...

Setting the component back again.