Skip to main content

Accessibility basics part 1 – an introduction to WCAG 2.1

Jon MaskreyUX engineer
1 min read30 October 2020

In this series of articles we're going to take a look at the basics of website accessibility. Why it's so important, who benefits from it, and how we can ensure the sites we build don't just adhere to the guidelines, but actually work well for abled and disabled users alike.

We'll go through setting up strong foundations in HTML to give users the best experience with the least development overhead, how to write informative alternative text, and how to thoroughly test a site for accessibility issues.

Why make websites accessible?

Regardless of legal reasons (more on that in a bit), why should you ensure your website is accessible? It's a lot of effort for a small minority right? Who actually benefits from a website being accessible?

At least 1 in 5 people have a long term illness, impairment or disability.

According to the DWP Family Resources Survey (2018 to 19) at least 1 in 5 people have a long term illness, impairment or disability. That's a lot of people:

  • 14.1 million disabled people in the UK
  • 8% of children are disabled
  • 19% of working age adults are disabled
  • 44% of pension age adults are disabled

On top of those figures, many more people have a temporary or situational disability. Let's take a look at the different reasons that you may have to rely on a keyboard for navigating a website. It may be that you have a permanent disability that affects motor control and means you can't use a mouse properly. You could have a temporary injury, like a broken arm, that again means you can't use a mouse effectively. Or you could be in a situation where you have to rely on a keyboard to navigate a site. If you've ever had your mouse run out of batteries, you've probably experienced this.

Microsoft's Inclusive design toolkit is a great resource and gives further examples of permanent, temporary, and situational disabilities:

An illustration of permanent, temporary, and situational disabilities showing someone with one arm, someone wearing a sling, and a new parent holding a baby.
From Microsoft's inclusive toolkit –

I can certainly relate to this. I'm lucky, I've been healthy most of my life and don't have a permanent disability, but looking back there have been times where accessible websites have benefitted me.

I once broke my collar bone on my dominant side, which left me needing to use a keyboard to navigate. I've also had a leaking blood vessel in my eye. This made it hard to see low contrast and small text and to differentiate greens from grays. And, at times, I've wanted to watch a video on my phone without disturbing people around me, so I've turned captions on.

The point is, creating accessible sites benefits a wide range of people – it’s not just an afterthought for a minority of the population.

UK law

UK public sector websites need to meet WCAG 2.1 AA guidelines.

These accessibility regulations came into force for public sector bodies on 23 September 2018 for new websites. Sites that already existed had more time to be updated and needed to comply by 23 September 2020. have published a guide to understanding accessibility requirements for public sector bodies.

All UK public sector bodies websites now have minimum accessibility standards they must adhere to.

Additionally, public sector websites have to publish an accessibility statement that explains how accessible their site is. have a handy sample accessibility statement you can use to help write for your own site.

Web Content Accessibility Guidelines (WCAG 2.1)

Let's take a look at the Web Content Accessibility Guidelines that are now a legal requirement for UK public sector sites. WCAG is an internationally recognised set of recommendations for improving web accessibility. They are based on 4 principles, that websites should be:

  • Perceivable
  • Operable
  • Understandable
  • Robust


Can users recognize and use the site with the senses they have available to them?

  • Can visually impaired users understand non-text content?
  • Is it easy to navigate and use with a screen reader?
  • Can the user easily increase the text size without breaking the layout?


Can users find and use the content regardless of how they choose to access it?

  • Can keyboard users navigate the site without getting stuck?
  • Is it obvious to screen reader users where links go?
  • Can keyboard users see what element is currently focused?


Can users understand the site’s content?

  • Is the content understandable to the target audience?
  • If abbreviations are used are they explained?
  • Can screen reader users understand what the form fields are for?


Can the content be interpreted by a variety of technologies such as browsers and screen readers?

  • Can screen readers understand the content?
  • Do screen readers know if a status has changed?
  • Do screen readers know what components do and what state they are in, such as whether a modal is opened or closed?

Levels of compliance

Each guideline has a set of testable success criteria. There are 3 levels of compliance – A, AA, and AAA. Single A is the most basic and can be viewed as the bare minimum or essential level. Double A is a higher level of support that covers most users' needs but without placing undue burden on the site owner. Triple A is the most strict or specialised level of support.

Double A is the minimum level of compliance according to UK law. To attain that, a site needs to meet both A and AA levels. That doesn't mean you have to stop there though – this is the minimum you should be striving for, so if you can make the experience better for disabled users, you really should.

The WCAG website has a quick reference section to help steer you through the guidelines. This is a fantastic resource but it’s not the easiest read, especially if you’re new to accessibility.

WCAG quick reference website screenshot.

It's well worth using the filters on the left side of the rules to help break the content down into more manageable chunks. You can set it to show only the single A criteria first and then, when you've had a read, add in the double A criteria.

There are a lot of guidelines to go through and not all of them will apply to your particular website. It's still worth having a read through, but there are easier ways to get to know the guidelines that we'll have a look at later in this series.


There is a lot of information on the page and it's not all in the most easy to understand language. Fortunately, each rule has a link to further information. These pages go into more detail and provide two categories of techniques – those that are sufficient to meet the success criteria and those that are advisory. The advisory techniques go beyond what is required to just "tick-off" that guideline and can make a better experience for users.

It's worth noting that adherence to these guidelines doesn't guarantee barriers are removed for all users and your site is completely accessible. This is acknowledged in the guidelines:

Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community.

0.2 WCAG 2 Layers of Guidance

Coming up in part 2

So, now we know more about why accessible websites are important, what the UK law has to say about it, and where to find the guidelines that we need to adhere to. In part 2 of this series (coming soon), we'll go through how you can combine automated and manual accessibility testing to highlight any areas that need fixing in your website. We'll also have a look at some tools to help with auditing accessibility and how you can test with disabled users to gain valuable insight into the issues they can face.

Jon MaskreyUX engineer

As a UX designer and front-end developer, Jon works with the Contensis product team to build a great user experience that is accessible, easy to use and fast. He has extensive experience in front-end development and Contensis integration.

Ready to get started?

Contensis supports modern development practices. And it works with your preferred tools – from VS Code to Git. Browse the documentation to get started.

Request a demo