Making links more accessible

At least 1 in 5 people in the UK have a long term illness, impairment or disability. Many more have a temporary disability.

— gov.uk website - Understanding accessibility

There are 16 million people in the UK ☍ who have a long term disability, many more with a temporary disability. Any one of us, at any given time, could experience an injury or illness that results in some form of disability with mobility, hearing, vision, or other potential impairments.

To cover issues with visual impairments, I will focus on screen readers and how they interpret links on a web page.

Testing pages with a screen reader is relatively easy if you’re on windows you can grab a free copy of NVDA. NVDA documentation provides a list of shortcuts to navigate a website (see here for a full list ☍).

If you have not used a screen reader to navigate a web page, the amount of information fed back to you can be overwhelming. It can be a bit like visiting one of those busy old websites from the 90s, with flashing gifs, tickers, rainbows, etc. There is too much noise.

One thing I’ve learned is the need for manually testing components with a screen reader during development. In the context of delivering information concisely to the user, the main objective is to provide an experience that is both minimalistic and tranquil so that the user does not feel overwhelmed, does not waste time and gets the information they are looking for. It’s worth noting that automated methods such as UI or unit testing were less effective in attaining this goal. I’m not yet aware of any automated testing software that help in this regard.

Building a web component that provides concise information

Below is an example of a very simple web component that provides too much information (for what it is conveying) and another example with improvements.

The below HTML represents a navigation list item with a link and an image. The link is wrapped around the image and the image has an alt tag. The link is also wrapped around a heading tag and a time tag.

<li>
  <a href="https://example.com">
    <img
      src="/posts/manonbeach.jpg"
      alt="A man stands on the edge of a cliff looking out to a rough sea."
    />
  </a>
  <div>
    <div>
      <a href="https://example.com">
        War a real threat and Europe not ready, warns Poland's PM
      </a>
    </div>
    <time>01/02/24</time>
  </div>
</li>

This is what NVDA will read out aloud from the component on the left:

And this is part of a list so it is worth considering that if there are many more items it could potentially overwhelm users relying on screen readers.

Improving the component

Changing the previous block to the following and using a neat little trick I nicked from the BBC website you can cut down the chatter to a single line:

Looks the same but the HTML is slightly different (see below). Essentially the image has an empty content pseudo element that is absolutely positioned over the image which is the trick to prevent the screen reader from reading out everything, it will read the essential lines of the headline and not announce headings or image alt text.

HTML
<ul>
  <li class="article-block">
    <p class="order-2">
      <a href="https://example.com">War a real threat and Europe not ready, warns Poland's PM</a>
      <time>01/02/24</time>
    </p>
    <img
      src="https://example.com/source.png"
      alt="A man stands on the edge of a cliff looking out to a rough sea"
    />
  </li>
</ul>
 
<style>
  .article-block {
    display: flex;
    position: relative;
  }
 
  .article-block a:after {
    content: "";
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    left: 0;
    z-index: 2;
  }
</style>

From the above HTML, now only a single line is read out to the listener, all other (perhaps/perhaps not irrelevant) information is no longer presented. It’s up to you to decide if this is a good thing or not in terms of the content that you wish to present to your users, but it does illustrate the importance of considering the semantics of your HTML structure, but also considering when it does look correct that the screen reader might not interpret it in the same way which is a key takeaway for me.