Digital Design System

Links

Many in-paragraph links do not need additional accessibility information. For example, consider the following sentence:

My favorite websites is Google Search, followed by the BBC News page.

There are two hyperlinks in that sentence, but the context of the sentence provides good information about where the user will go if they choose to click the hyperlink. There’s no mystery; if they click the first link, they’ll go to Google Search. If they click the second, they’ll go to the BBC News page. There is no need to add any accessibility attributes to the above links, and this accounts for most of our content.

Additionally, lists of articles (for instance, five articles listed in an unordered list) won’t need any additional accessibility attributes. The hyperlinked text provides specific context. Example:

All of the above hyperlinks are clear: the user knows where they’ll go if they click.

Now consider these links:

As a user, if I click here, where am I going to go? What am I logging in to? What am I registering for? Although the visual display of the website provides context for sighted users, there is a complete disconnect when the screenreader processes the information. All the screen readers will process is the linked text.  (Read this article “Don’t use click here” for more information)

  • Click here – this term should never be used. There’s no reason to tell a user that they should click a link; intuitively, based on design, our website’s links are obviously clickable and distinguished from the rest of the text. Do not use this term on any form of link, on a website, e-mail, or other digital piece.
  • Log in – the proper thing to do would be to apply an aria-label to that button so that it has context about where the user will be able to log into, e.g. “Log in to your account” – More on this below.
  • Register – Same as log in. What will I be registering for if I click this? “Register for the Beyond Data Newsletter” is much more explicit.
  • Read the article – What article? Where will I go if I click this?

Links, Buttons, and aria-label

The aria-label attribute is used to define a string that labels the current element. Use it in cases where a text label is not visible on the screen.

Example – Standard hyperlink

The link below uses “Learn more” and does not provide enough textual context about where the link goes. 

<a href="https://www.willistowerswatson.com/en/insights/2019/01/willis-re-1st-view-january-2019">Learn more</a>

Therefore, we add an aria-label to make the connection. The format we will use at WTW is derived from Google Developer’s Accessibility guidelines, and is:

[HTML item], [Content type], Click to read [Article / Page name]
Link, Article, Click to read Willis Re 1st View January 2019

And the result for our hyperlink, when coded, is:

<a href="https://www.willistowerswatson.com/en/insights/2019/01/willis-re-1st-view-january-2019" 
aria-label="Link, Article, Click to read Willis Re 1st View January 2019">
Learn more
</a>


Example – Button

What if we had a button – such as our “log in” button on our call-to-action module?

Here, we need to capture more information about what will happen if the user clicks the login button. Remember, this is for non-sighted users, and we need to consider that they are not visually associating the content on the left with the button on the right. Our accessibility implementation is the following:

<button aria-label="Button, click to log in to Wills Towers Watson Product Name" class="btn btn-lg btn-outline-light w-100" type="button" name="button">
Log In 
<i class="material-symbols-outlined" aria-hidden="true">keyboard_arrow_right</i>
</button>




Note also that aria-hidden="true" was applied to the right arrow icon so that the screen reader will not read “keyboard arrow right” aloud. That information is decorative and does not need to be conveyed / processed by the screen reader.

There may be times when a content editor should consider adding aria-hidden="true" to an icon, but usually this is taken care of within the front-end of the website.

 

Example – People & Bios

For the example below, seen in the People & Bios component, we want to provide context for the links and what they do. For instance, for a screen reader, we want to distinguish that the hyperlinked name takes you to content by Moira Queen, whereas the other links e-mail Moira, or call Moira. Otherwise, the screen reader would just read the mailto value and the phone number (and this wouldn’t necessarily connect for the user that this was part of Moira’s biography).

<div class="media-body">
  <div class="font-mono font-weight-semibold">
  <a aria-label="Click to see all content by Moira Queen" href="moira-content.html">Moira Queen</a>
  </div>
  <div class="font-p-small">Senior Cyber Specialist</div>
  <div class="font-p-small">
    <a aria-label="Click to e-mail Moira 
      Queen" href="mailto:example@email.com" class="font-weight- 
      bold">Email</a> | <a aria-label="Call Moira Queen at 1 973 829 2920" 
      href="" class="">Call +1 973 829 2920</a>
  </div>
  </div>
</div>