February 2nd 2021

Why Accessibility?

Over 7 million people in the UK have a disability that is likely to impact their experience on the internet. Besides the obvious moral obligation to make sure we cater to these requirements (particularly as users are forced online while bricks and mortar stores and high street services are shut during Coronavirus lockdowns), there’s huge commercial benefit many sites are losing out on.

A recent report found that as much as £17.1 billion of online revenue is lost each year due to people with disabilities leaving sites they find difficult to use (or completely unusable!). 

If that’s not enough to make digital marketers pay attention to accessibility, there’s also a legal motivation; as of September 2020, all public sector sites in the UK must meet WCAG AA standard, and there’s increasing legal precedent worldwide for users who are unable to access a service due to accessibility issues. (Check out this case against Domino’s or this one against Nike, to name just a couple of big names).

As more demands are put on user experience (think Google’s Mobile First, Speed and the impending Page Experience updates alone!) we see it becoming an increasingly important part of our SEO strategies.

We know that great accessibility is a cornerstone of great UX, and impacts all users for the better (not just those with disabilities). And yet, the UK Accessibility Benchmark found that almost all of the UK’s most popular sites still fail to deliver on basic accessibility criteria.

Most Common Accessibility Issues

But it’s not all bad news! The benchmark found that the most common accessibility issues were also among the simplest to fix, and generally come down to good housekeeping rather than complex technical changes. Yipee!

1. Low Colour Contrast

By far the most frequently encountered accessibility issue was low colour contrast, with around 35 incidences per page on average! Low colour contrast can make it difficult to discern foreground elements from the background, can make text or CTAs difficult to read, or can make your site more difficult for users with low colour perception to interact with. We’ve found that improving colour contrast, particularly in areas of your site with crucial information, can have huge conversion benefits too.

How to Test

There are loads of ways to test colour contrast. Probably the simplest is to check your common elements (headings, CTAs, buttons, body text etc.) using a tool like the WebAIM Contrast Checker. Most sites should aim for a AA standard, but if your site is providing an essential service or you’re public sector (or you want to aim for the highest standard), you should aim for a AAA rating.

How to Fix

This should be fairly straightforward to fix with some CSS tweaks, but you might find this is indicative of a wider issue if your brand colours don’t meet accessibility standards, as low colour contrast doesn’t just impact users online. POS, Out of Home, signage and paperwork or stationary could also be impacted, so you may need to address this at a brand level.

2. Empty Links

Most often, empty links are flagged where we use an icon in place of text (social links in footers are perfect examples). This can be confusing for screen reader users, (screen readers are used by people with visual impairments) who won’t have any information about the link, or where it goes.

How to Test

If you have linked icons without any HTML text associated with them on your site, the chances are you have empty links that you can pick out fairly easily. If you’d like a more comprehensive insight, you can use the Wave browser extension or you could test your site with a screen reader (ChromeVox is great) to really understand how users experience your site when using screen readers.

How to Fix

Once you’ve identified your empty links, it’s pretty easy to fix with some small HTML and CSS changes. By adding some link text with HTML and add a ‘visually hidden’ CSS class, combined with “aria-hidden”, we can hide the text on the page, but still allow it to be accessed by screen reader users.

<a href=https://facebook.com/example_account>
<i class=”example icon” aria-hidden=”true”></i>
<span class”visually-hidden”>Facebook</span>
</a>

3. Missing Alt Attributes

Not all imagery needs a descriptive alt attribute – if you’ve included an image that is purely decorative in purpose, then having screen readers describe every single bit of functionless stock imagery to users is going to get very annoying (and longwinded) pretty quickly.

How to Test

You can use a combination of tools and manual checks to establish whether or not you have sufficient alt text.

Firstly, you can use a crawling tool like Screaming Frog to identify images and pull out those missing alt text. Next, you need to manually check those images on the site, and judge whether, in that context, they need a description or not. You can also check that images that do have alt text actually need it, and if so, that the alt text is useful in that context.

How to Fix

Hopefully you should now have a list of images on your site that need their alt attributes improving in some way (that may mean it has alt text it doesn’t need, or it doesn’t have alt text it needs).

The next step is to add these into your CMS. Most solutions offer this as standard, but if your CMS doesn’t allow you to add alt attributes to images (or you’re using a custom solution that doesn’t have this capability), you may need to talk to your developer and ask them to add a field in the CMS that allows you to add alt text to images.

If you have images that don’t need describing (most sites do) you can set the alt text to “null”.

4. Image Links Missing Alt Text

It’s ok to use images to link to other areas of your site, but there are some considerations we need to make for screen reader users.

It goes without saying that users with visual impairments may have trouble understanding images without alt text.  It’s likely to be really annoying when the image is supporting or explaining something referenced your text (e.g. a diagram), but if that image is being used for navigation (e.g. a banner image with embedded text, or an image that looks like a button) it can be a real headache for screen reader users (not to mention the SEO benefits you’re missing out on!). This is because if an image is linked but has no alt text, most screen readers will just tell the users that it’s an image with a link. Not particularly useful.

How to Test

Similar to any other image missing alt text, you can use a number of tools to identify linked images without alt text, or that have unhelpful or undescriptive alt text. Screaming Frog and WAVE are excellent places to start, or test your navigation with a screen reader like ChromeVox to see how useful your alt text is in-situ.

Note: If your linked image doesn’t have alt text, but you do have text within the link, you don’t need to add alt text too (see example below). Screen readers will read the link text out loud, which makes the alt text surplus to requirements.

<a href=www.linkexample.com><img src=”/media/photo.jpeg” alt=”” />Link Destination</a>

How to Fix

There are two ways you could fix this issue; adding and alt text description or adding some text to the link.

Alt Text:

<a href=www.linkexample.com><img src=”/media/photo.jpeg” alt=”Link Destination” /> </a>

Link Text:

<a href=www.linkexample.com><img src=”/media/photo.jpeg” alt=”” />Link Destination</a>

5. Missing Labels

Missing labels most commonly affect forms like newsletter subscriptions or search bars. Let’s take a typical newsletter signup form like this:

<form method="post" action="#">
<label for="email">Email: </label>
<input type="text" name="email" id="email">
</form>  

If you’re sighted, it’s quite easy to see that the label for the form field is ‘Email’, so you’d know to enter your email address in the box. However, if you’re using a screen reader, you have to rely on the screen reader being able to understand the association between the form field and the text label above it (especially where we have a list of different fields). This means we need to use labels in our HTML to explain the relationship between a label and its field.

How to Test

Like most of our other accessibility issues, there are two ways to test this; tools like the WAVE Chrome extension can identify elements that are missing labels, or you could manually test your site with a screen reader to see if it reads out your form labels correctly.  

How to Fix

Let’s take an email subscription:

<form method="post" action="#">
<H3>Email:</>
<input type="text" name="email" id="email">
</form>  

There are 2 ways we can fix this; we can wrap the label (‘Email:’) in a label attribute, or we can use the aria-label attribute.

Label:

<form method="post" action="#">
<label for=”email”> <H3>Email:</></label>
<input type="text" name="email" id="email">
</form>

Aria-label: (Use this method with care, and only when accompanied by a visual description of the form field)

<form method="post" action="#">
<H3>Email:</>
<input type="text" name="email" id="email" aria-label=”email”>
</form>

6. Empty Buttons

Empty buttons are most typically buttons or interactive UI elements that don’t have a visible and accessible name. Dropdown toggles to sort content are a great example. These often have a visual clue or indicator of what the element should do (sometimes an arrow, or some placeholder text), which makes them easy for sighted users to interact with, but can be difficult for screen reader users, as they will simply be announced as ‘button’ (they can also be tricky for some users with cognitive disabilities).  

How to Test

The easiest way to identify empty buttons on a page is to use the WAVE chrome extension, or another accessibility tool. Lighthouse, Google’s speed auditing tool includes button name accessibility in its automated checks.

You could also use a Screaming Frog custom extraction to crawl your whole site and extracting all of your buttons, before checking them for button text.  

How to Fix

There are two ways you can fix empty buttons; adding button text is the simplest and most straightforward (and is useful for all users, not just screen reader users), or alternatively you can use the aria-label attribute.

Adding Button Text:

 If you have an empty button, such as the following:

<button></button>

You can simply add text within the tags:

<button>Submit</button>

Adding Aria-label:

If you’re using an icon in place of button text, you can use the aria-label attribute:

<button aria-label=”Submit”></button>

7. Aria Reference Broken

For more complex forms, you may need to use an ARIA attribute to reference descriptions or instructions elsewhere on the page (such as password requirements). You can use the aria-describedby or aria-labelledby to instruct screen readers to announce the correct instructions or description (or the correct label), by directing them to the element on the page that contains the instruction (or label). When it references an element that doesn’t exist, the instruction or label won’t be announced by screen readers.

How to Test

Testing for broken ARIA references can be done quickly and easily using the WAVE Chrome extension.

How to Fix

Usually broken references occur because the element ID that was originally used to label/describe your object has been changed, or the label/description has been moved and now has a different ID, or isn’t there at all.

This means that once you’ve identified your broken ARIA reference, it’s usually pretty easy to fix.

If you can still see the description or label that you want to use to describe your object on the page, you can find out its ID and then correct your ARIA reference. For example:

<div aria-labelledby=”label” aria-describedby=”instruction”>
<div id=”label”>Password</div>
<p id=”password-instructions”>Your password should have 8-12 characters including letters and numbers</p>
</div>

In this example, your text in the paragraph with the ID “password-instructions” contains the text you’d like screen readers to announce as your password description, but we can see that this text no longer has the ID referenced in the aria-describedby attribute (or perhaps it never did), so screen readers would not announce the description as you’d like.

You can simply update the aria-describedby attribute to reference the correct ID:

<div aria-labelledby=”label” aria-describedby=”password-instructions”>
<div id=”label”>Password </div>
<p id=”password-instructions”>Your password should have 8-12 characters including letters and numbers</p>
</div>

If your description or label isn’t visible on the page, the best course of action is to add it in and make sure the ARIA reference references its ID, as this will likely benefit all users, rather than just catering to screen reader users. If your object is described or labelled visually (e.g. an icon or diagram) and you don’t want to also include a text—based label or description, you can remove the ARIA reference attribute altogether and use a more appropriate solution (for example, a form label).

8. Empty Headings

Empty headings are heading elements that are missing accessible content. This could be due to a logo being wrapped in an H1, or some plugins will create heading elements on your page regardless of whether there’s content within them or not.

Headings are often used to get a sense of the overall structure of a page, and to help users scan the page to find the information they want. In the same way a sighted user can scan a page for a heading that seems relevant, a screen reader user can use headings to skim a page and navigate to the part they’re after. While sighted users won’t see empty headings, having poor (unhelpful, undescriptive) or empty headings can make this process more difficult for some browser/screen reader combinations.

How to Test

Empty headings can be identified easily using the WAVE tool. If you want to be able to find all of the empty headings across your site, you can use a ScreamingFrog custom extraction to extract the text in all of your heading tags (h1 through to h6). Then you’ll be able to easily pick out any empty heading tags.

How to Fix

The best approach to fixing empty headings will depend on why the empty headings are there in the first place, but there are essentially three options; remove the empty heading tags, populate the empty heading tags with a useful heading, or hide the empty heading tags from screen readers.

If you’ve got a logo in your header wrapped in an H1 tag (I see this fairly often), the best approach is to remove your H1 tag from your logo altogether. You should have another H1 on the page anyway, which will act as its primary title. If you don’t, make sure you add one so you’re using properly nested headings.

If there’s simply an empty heading tag left on a page or page template in error, you can ask your developer to remove it, or if it’s been left in as a placeholder in case that heading is required (some plugins and widgets do this), you can ask them to create a rule that only displays the heading tag when it’s populated with text.

If you feel that your users would benefit from having a heading where your empty heading tag is currently sat, you could populate it with something useful.

Finally, if you don’t need a heading where you have your empty heading tag, and you cannot remove it, you can hide it from screen readers so it doesn’t get announced at all. To do this, you can add the attribute ‘aria-hidden=”true”:

<h2 aria-hidden=”true”></h2>

NOTE: Make sure to remove the aria-hidden attribute if you decide to populate the heading tag in the future, so your heading isn’t hidden from screen readers.

9. Label Empty

As described in number 5, ‘Missing Labels’, labels are used to create an association between a form field or object and its text label that screen readers can use to announce a form field correctly. The impact of having empty labels is similar to having no label at all; a form field or input will not have this useful information announced to the user.

How to Test

You can manually test your forms and input fields (e.g. search bars) using a screen reader like the ChromeVox Chrome extension, or Voice Over on iOS, to see if they announce your labels correctly. But bear in mind that different browser/screen reader combinations may yield different results.

Using the WAVE Chrome extension or tool is useful on a page-by-page basis, or you could use the API to identify empty labels across your whole site.

How to Fix

Usually this is easy to fix using some small HTML tweaks. If you simply have an empty label attribute, the easiest fix is to fill it. Take this example:

<h2>First Name</h2>
<label for="firstname"></label>
<input id="firstname" title="First Name" type="text" name="firstname">

The syntax is technically correct, but we can see that the label tag does not contain any content (and the title attribute isn’t reliably picked up by assistive technology). The solution is to simply add some content to the label tag. In this case the desired label is already visible on the page, so we simply place it inside the label tags:

<label for="firstname"><h2>First Name</h2></label>
<input id="firstname" title="First Name" type="text" name="firstname">

You could also use the ‘aria-labelledby’ attribute to reference the element containing your label like this:

<input type=”text” name=”submit” aria-labelledby=”submitbutton”>
<button id=”submitbutton” type=”submit”>Submit</button>

10. Multiple Labels

There are lots of ways form elements can end up with multiple labels; including multiple explicitly associated labels:

<label for="firstname"><h2>First Name</h2></label>
<label for="firstname"><h2>Last Name</h2></label>
<input id="firstname" title="First Name" type="text" name="firstname">

A combination of implicit and explicitly associated labels:

<label for="firstname"><h2>First Name</h2></label>
<label>Last Name
<input id="firstname" title="First Name" type="text" name="firstname">
</label>

Surplus ‘aria-labelledby’ attributes:

<label for="firstname"><h2>First Name</h2></label>
<h2 id=”lastname”>Last Name</h2>
<input id="firstname" title="First Name" type="text" name="firstname" aria-labelledby=”lastname”>

Multiple nested labels:

<label>First Name
<label>Last Name
<input id="firstname" title="First Name" type="text" name="firstname">
</label>
</label>

How to Test

Identifying form fields with multiple labels can be difficult and longwinded manually. The simplest way is to use an accessibility tool like the Wave Chrome plugin.

How to Fix

As there are so many ways that this error can be triggered, there is no single fix that will work for all cases. Therefore, the most important step is to identify the multiple labels for the element that’s triggering the error. Once you know where your multiple labels are coming from, it should be relatively straightforward to select the most appropriate one to take forward. The following tips should help you find the most appropriate labelling solution:

  • If your label is visible on the page, you can wrap the visible label in <label> tags or use the aria-labelledby attribute. You do not need to do both.
  • You can include a visibly hidden label if it’s not necessary for sighted users, or you can use the aria-label attribute.
  • If you have multiple form fields with the same label, you can use aria-labelledby to refer to a single, visible label.
  • IDs should be unique across the entire page – if you have multiple form fields with the same ID, it could trigger a multiple form labels error (e.g. If you have a login/registration page with two forms; one for logging in and another for registration, the ‘Username’ field on each form should have a unique ID).

Accessibility can be a complex, technical challenge. The good news is that simple changes like not embedding text in images, improving colour contrast between text and its background, and paying close attention to writing great copy that’s easy for all users to understand can make a huge difference to how accessible a website is, and take relatively little time and effort to implement.

Accessibility tools are a fantastic place to start, but they aren’t a substitute for thorough, manual testing across a range of device and browser combinations. Automated audits and tools tend to focus on technical issues and can’t always accurately replicate a real user’s experience (particularly with such a vast array of assistive technologies available). It’s also difficult to automate checks for writing style, layout, or other non-technical criteria, so bare this in mind when you start auditing your site’s accessibility.