Accessible Drupal Teasers

jwilson3's picture

We're running into the adjacent links issue in our custom-themed Drupal teasers where a teaser image (linked) floats left, next to the node title (also linked), a short description text (trimmed body text) and a "Continue reading" (i.e., more link).

The DOM looks roughly like this:

<article class="node__teaser">
  <div class="node__image"><a href="/node/1"><img alt="[node:title]" href="/path/to/image.jpg"></a></div>
  <h2 class="node__title"><a href="/node/1">[node:title]</a></h2>
  <div class="node__description">[node:body:trimmed]</div>
  <div class="node__read-more"><a href="/node/1">Continue reading <span class="element-invisible">[node:title]</span></a></div>

The <a> tags inside node__image and node__title are the two offending adjacent links.

The suggestion from W3C is to join the two items together into one link:

This seems a little messy, and complicated to do with Drupal. Also the outline-on-focus around a link tag that wraps around the floated img and h2 tags is going to look kind of strange. The other alternative that I kind of like more, would be to just wrap the entire teaser in a link tag but what prevents that is the "continue reading" link, where we'd end up with a link inside a link.

Does anyone have any suggestions on how I could resolve this?


One other inclination I had

jwilson3's picture

One other inclination I had would be to

a) wrap the entire teaser in a link tag, removing the link from the img and the node title.
b) also remove the link around the "Continue Reading" but theme it so it still looks like a link. This might be a tricky solution for sighted users too so I'm not entirely sure it is a good one.



jwilson3's picture

I realize this is a hard problem to visualize so here are some pens. The best way to look at this is to render the pen and then focus your browser into the rendered iframe and use the tab key to highlight the link tag.

  1. Version 1

    Assuming that the ideal DOM structure would be:

    <a>Continue Reading</a>

    Version 1 attempts to use flexbox to change the order. However this breaks for the description text, which gets sent below because flexbox ends up creating an unavoidable clearfix, even if you add a float to the img tag.

  2. Version 2

    <a>Continue Reading</a>

    Version 2 attempts to join the h2 and the img tag inside a link tag. What I don't like about this is how the tab-to-focus looks for sighted users.

  3. Version 3

        <div>Continue Reading</div>

    Version 3 removes the "Continue Reading" link and wraps the entire teaser in a link tag. Imagine tabbing through a list of teasers with your keyboard. This is the most elegant solution visually that at the same time technically satisfies the adjacent link problem.

    The downsides are 1) that the description text must not contain any links, 2) the separate "continue reading" more link must be removed or added as plain text but styled to look like a link, and 3) there will be additional styles to reset the paragraph tag inside the link tag so it is not rendered visually to look like a link.

If it were me, I'd go for

lambch's picture

If it were me, I'd go for version 3.

Although, another possible downside is how the link text would now be very long. A screenreader user who opts to listen to the link text would hear the image alt, the title, the description, and a 'Continue Reading'.

With the above noted, you could leave the image alt text null (It's just a repeat of the H2 afterall). Keep the description short (eg. trim to ~140 characters). And also remove the 'Continue reading'.
You really want to cut down on the link verboseness.

If you can not ensure keeping descriptions short (and free of nested links). You may have to go a complete different option:
Link the H2 only.
With only the heading linked, you then may or may-not wish to also include a Continue Reading link after the description.
Not including a Continue Reading link is fine as far as WCAG is concerned, but users are quite accustomed to them.

Just if you do use a Continue Reading, ensure they are added in a way that satisfies WCAC2 2.4.4. In particular the ARIA8, or H78 and H80 techniques.
I aim to have these sorts of links as a child of the description paragraph.

Another option

cehfisher's picture

Have you looked at doing something more like this:

<a href="#" aria-hidden="true" role="presentation" tabindex="-1">
  <img alt="something descriptively awesome"
       role="presentation" src="" /></a>
<h2>Bacon ipsum dolor amet pastrami jowl short loin shoulder</h2>
<p>Beef biltong burgdoggen pork loin. Picanha tenderloin tongue ham pork, jowl pork chop ball tip leberkas spare ribs shank frankfurter meatball hamburger filet mignon. Chicken short loin drumstick jerky. Venison tail alcatra pancetta picanha ground round porchetta kevin ribeye strip steak pastrami hamburger.</p>
<a href="#">Continue Reading</a>

Adapted from

It is never a good idea, even

jfurnas's picture

It is never a good idea, even for sighted users, to style text to 'look like a link' (Even if it is a link). It's just bad practice.

WCAG says that links that point to the same destination, but have different link text is okay, as long as they aren't directly next to each other. In your case, you do not have that, because there is a paragraph in between your article link, and the 'continue reading' link.

Your solution #1 should be sufficient to meet the criteria. If the image is purely decorational though, and doesn't provide context, I would add an empty alt="" to it, or add an aria-hidden="true" attribute to it so that the screen reader won't read it, but will still have the link text from the link for reference.

As to @cehfisher's response, that code is not only messy, but also incomplete. You have an extra closing /a tag after the image. Removing that, according to aria-hidden, the image, as well as the h2 would be hidden from the screen-reader. It looks like you probably meant to put the /a before the h2, and not have the /a after the h2, which would work. I am also not sure that role="presentation" is needed when aria-hidden is used.

Furthermore, looking at the article, the method they use isn't accurate either. Although that helps users who are using screen readers, it doesn't necessarily help people who aren't, but still have visual impairments, as they will tab through the same link twice (Which is what this criteria is trying to avoid).