WCAG 2.1 web accessibility guidelines have landed

WCAG are an internationally established set of guidelines for ensuring that content on the internet is accessible. The guidelines are maintained by W3C, the main standards body for the internet.

Whilst the guidelines partly focus on people with various disabilities, they ultimately ensure that everybody has equal access to the online world, whether they have a permanent, temporary, situational or no disability.

Examples of permanent, temporary and situational disabilities

The current version (WCAG 2.0) was published in 2008 and became an international standard in 2012. Web technology and how people access the internet has changed drastically since 2008 though. An updated version (WCAG 2.1) has just been released with 17 new guidelines which focus on improving accessibility for users who browse websites on smartphones and tablets, and for users with cognitive disabilities.

Each of the guidelines have measurable success criteria divided into the levels of A (lowest), AA and AAA (highest). More A’s mean that a site is more accessible, but it also creates a more challenging design, development and testing process.

What’s covered in WCAG 2.0?

WCAG 2.0 consists of the following 12 principles:

1. Perceivable

1.1. Provide text alternatives for non-text content like images
1.2. Offer captions or text summaries for audio and video
1.3. Structure content to be programmatically identified and write it to be presented in different ways
1.4. Design content to be easy to read and listened to (good contrast, volume control)

2. Operable

2.1. All functionality should be available just using a keyboard
2.2. There should be enough time to read content and perform wanted tasks
2.3. Avoid designing content that might cause seizures
2.4. Help users navigate and find content as much as possible

3. Understandable

3.1. Write easy-to-read text with assistive technologies in mind
3.2. Design content and the interface to behave in predictable ways
3.3. Help users to avoid and correct mistakes when entering input

4. Robust

4.1. Provide maximum compatibility with as many web browsers as possible

What’s new in WCAG 2.1?

WCAG 2.1 is an update to WCAG 2.0, meaning that the previous principles, categories, guidelines, numbering system and success criteria all still apply. The updates are as follows:

1.3.4. Orientation (AA)

Content should not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

Following this guideline will improve accessibility for users who mount their tablets and smartphones to their wheelchairs, or have trouble rotating them due to limited motor skills or because their hands are busy.

1.3.5. Identify input purpose (AA)

The meaning of each input field should be able to be determined programmatically. This means that code should be able to tell what is expected to be entered by a user or what is the meaning of a piece of entered information.

Doing this correctly will make it possible for a user’s browser to autofill input fields based on data previously entered by the user.

Following this guideline will improve accessibility for users with cognitive disabilities who find it challenging to read and enter text. It also improves accessibility for users who can’t read the language of the website.

1.3.6. Identify Purpose (AAA)

The purpose of interface components, icons and certain sections should be able to be identified programmatically. For example, the user should not just understand that a button is a button, but also be able to understand what the button does.

When the HTML is written correctly, assistive technologies should be able to:

  • Identify sections (such as the header, navigation, main content area and so on) for easier navigation
  • Provide alternative descriptions for icons which otherwise can sound weird when being read by a screen reader
  • Differentiate between different subheadings for finding content faster

For example:

<form>
  <fieldset>
    <legend>Name</legend>
    <label for="title">Title</label>
    <select name="title" id="title">
      <option value="Mr">Mr</option>
      <option value="Mrs">Mrs</option>
      ...
    </select>
    <label for="forename">Forename</label>
    <input type="text" name="forename" id="forename">
    <label for="surname">Surname</label>
    <input type="text" name="surname" id="surname">
  </fieldset>
</form>

Following this guideline will improve accessibility for users of assistive technologies, such as screen readers.

1.4.10. Reflow (AA)

Users should be able to browse a website using a 320 pixel wide screen without having to scroll horizontally. It also means that users should be able to zoom up to 400% without a loss of content.

Following this guideline will improve accessibility for all users visiting websites on a smartphone.

1.4.11. Non-text contrast (AA)

A good level of contrast (at least 4.5:1 for normal text and at least 3:1 for large text for AA) should be present for regular text as well as text on interface components and non-text components such as diagrams.

WebAIM’s Colour Contrast Checker is a quick way of checking colours for both AA and AAA success criteria.

WebAIM's Colour Contrast Checker

Following this guideline will improve accessibility for all users with different kinds of visual impairments.

1.4.12. Text spacing (AA)

Distances between paragraphs, rows, words and characters should be able to be increased to certain values without leading to loss of functionality or loss of content.

Failing at this could result in pieces of text overlapping, hence becoming unreadable. It could also result in components being moved into places where they can’t be interacted with.

Following this guideline will improve accessibility for users with visual impairments and dyslexia.

1.4.13. Content on hover or focus (AA)

If users trigger content in the form of a modal, tooltip or a similar component, they should be able to:

  • Dismiss the content without moving the mouse cursor or the current keyboard focus, for example by pressing the Esc key
  • Scroll to the content without making the content disappear
  • Dismiss the content solely on their own terms

Following this guideline will improve accessibility for users with visual impairments, especially for users who are likely to zoom in when browsing a website and have to scroll to content which is outside of the viewport.

2.1.4. Character key shortcuts (A)

If a website supports keyboard shortcuts in the form of single characters, one of the following three conditions should be met:

  • The shortcuts can be turned off
  • The shortcuts can be changed to also require pressing another keyboard key, such as Ctrl or Alt
  • A shortcut for a certain element is only active when that element has focus

Following this guideline will improve accessibility for people who use speech input for browsing a website and for users who have hand tremors and easily press wrong keyboard keys.

2.2.6. Timeouts (AAA)

Users should be informed if any period of inactivity could lead to loss of data, except if data is saved for more than 20 hours after their last interaction.

Following this guideline will improve accessibility for users with cognitive disabilities who may need more time to complete wanted tasks.

2.3.3. Animation from interactions (AAA)

Animations triggered by interaction should be able to be turned off, unless the animations are essential for the functionality or the content being presented.

Following this guideline will improve accessibility for users who are susceptible to seizures due to motion.

2.5.1. Pointer gestures (A)

Actions performed using complex gestures, such as pinching and swiping, should also be able to be performed using simpler gestures like single taps, double taps and long presses.

Following this guideline will improve accessibility for users with limited motor skills or not enough fingers for multi-touch gestures.

2.5.2. Pointer Cancellation (A)

When a user interacts with a screen by clicking, tapping or long pressing, at least one of the following statements should be true:

  • The triggered functionality doesn’t happen on the down-event
  • The functionality is triggered on the up-event and it’s possible to either cancel it before the up-event occurs or undo it afterwards
  • The up-event cancels what happened on the down-event
  • Triggering the functionality on the down-event has to occur for an important reason

Following this guideline means that users can cancel actions by dragging away from the component.

2.5.3. Label in name (A)

Text that is shown on interface components, such as buttons, should be able to be:

  • Read to users of assistive technologies like screen readers
  • Triggered by voice commands by users who take advantage of speech recognition software

This can be achieved by adding ARIA labels to buttons which consist solely of an icon. For example:

<button aria-label="Open menu">
  <span class="icon-menu"></span>
</button>

Following this guideline will improve accessibility for people with visual impairments who use screen readers. It will also improve accessibility for users who use speech input for browsing a website.

2.5.4. Motion actuation (A)

Functionality that is triggered by moving the mobile device should also be able to be triggered by interacting with interface components, such as buttons and sliders.

Responses to motion should also be able to be turned off, unless:

  • The motion is supported through an accessible interface
  • The motion is essential for the functionality

Following this guideline will improve accessibility for users who mount their tablets and smartphones to their wheelchairs, or have trouble rotating them due to limited motor skills or because their hands are busy.

2.5.5. Target size (AAA)

A clickable element should have a height and width of at least 44 by 44 pixels, unless:

  • The same functionality can be achieved through another clickable element of 44 by 44 pixels
  • It’s located in a block of text, such as a regular underlined link
  • Its size is determined by the device and browser the user is using
  • It must have this look and size in this particular context in order to make sense

Following this guideline will improve accessibility for people who have hand tremors, large fingers and use mobile devices with one hand.

2.5.6. Concurrent input mechanisms (AAA)

Website should never disallow users to use, switch between or add and remove different mechanisms for input, such as mice, keyboards, styluses, touch input or voice input.

Following this guideline will improve accessibility for people with limited motor skills who prefer or must use a certain input mechanism, such as a keyboard or mouse when operating a tablet.

4.1.3. Status messages (AA)

Content that is updated dynamically should be notified to users of assistive technologies without getting visual focus.

A great way to solve this for users of screen readers is to use ARIA live regions. For example:

<div role="status" aria-live="off">When this text is updated, users with screen readers will not be notified at all</div>
<div role="status" aria-live="polite">When this text is updated, users with screen readers will be notified if they aren't doing anything else</div>
<div role="status" aria-live="assertive">When this text is updated, users with screen readers will be notified immediately regardless of what they're doing</div>

Following this guideline will improve accessibility for users of assistive technologies, such as screen readers.

4 comments

Chris Kenst

I’ve been looking into these guidelines recently and the less clear thing to me (at this point) is to what sites should these guidelines be applied? It’s not enough to say EVERYONE or EVERY SITE should make these changes unless there are known rules or laws that are directly applicable as this increases the risk to the business or user and makes it more of a priority! For example do each of us with a blog have to worry about these things or are they nice to haves? Do larger commercial websites, eCommerce sites, etc.?

Also as a side note, have you found good tools for identifying accessibility issues or bugs?

Peter Gould

Thanks for a really interesting comment, Chris!

First and foremost, I believe that website accessibility is a moral obligation. You wouldn’t discriminate against users with disabilities in the real world, so why would you knowingly make it so they can’t use your website?

Accessibility goes much further than users with disabilities though. If your website is accessible, it is more likely to have a clearer structure and content. This makes it easier and more enjoyable for everyone to use, including users with temporary disabilities, situational disabilities and even search engines.

If you’re interested in the legal side of things, there isn’t an explicit law for website accessibility in the UK. However, there are a couple of relevant pieces of relevant legislation:
– The Equality Act 2010 requires everybody providing a service in the private, public or voluntary sector to “take such steps as it is reasonable to ensure an equal experience for people with disabilities as compared to those without”
– The Statutory Code of Practice published by the Equality and Human Rights Commission requires everybody providing a service in the private, public or voluntary sector to “take positive steps to ensure that disabled people can access services”

The latter is interesting because it goes beyond avoiding discrimination — instead it requires service providers to anticipate the needs of potential disabled customers and make adjustments for them.

The problem is that the laws don’t state what it “reasonable”. It is up to a judge to decide whether the steps you took to make your website accessible were “reasonable”.

The government requires their services to be WCAG 2.0 AA compliant and will soon be required to prove their compliance. Being WCAG 2.1 AAA compliant would be incredible, but it would create a more challenging design, development and testing process.

A few unnamed companies have faced legal action by RNIB, however these cases were settled before court. Many believe that there will eventually be a high-profile case against a named company to solidify UK web accessibility law though.

In conclusion, nobody really knows how accessible your website needs to be. The more accessible, the better. I’m sorry that that’s not a very helpful answer!

There are a number of tools which I use for identifying some potential accessibility bugs. The main ones I use are as follows:
Chrome colour picker and accessibility paneColour Contrast AnalyserFunkifyWAVE

Whilst the above tools are good, nothing is a replacement for getting out there and testing functionality on users with a range of disabilities. There are companies out there who can help with user testing, however I have found that local charities are more than happy to help in return for fundraising and volunteering.

If you’d like to talk more about accessibility, please drop me a line 🙂

Christopher Lampert

Really great post. I have been seen as a bit of an accessibility champion in my workplace so it is good to see other people flying the same flag and with similar passion. Love the breakdown of some of the new requirements and can already think of areas where that may be currently problematic for us so thank you for that.

I like how you are saying it is a moral obligation – great use of language btw – to implement accessibility requirements. I also think law does come into it because the general consensus has been that the EQAs reference to “provision of service” has heavy implications towards use of web services .

I have(at least tried to) framed the conversation around making the web a better place for everyone but ensuring we are mindful of the fact that there are potential legal ramifications if we totally ignore these considerations.

Once again great post. Happy to chat about accessibility with you any time, should you want to 🙂

Peter Gould

Thanks Christopher — it’s great to hear from another accessibility champion who has a similar passion.

I’m going to keep blogging about driving accessibility within my role, so keep checking for more posts in the future.

If you’d like to bounce ideas off each other on how we can get accessibility baked into the development process, I’d love to chat more 🙂

Leave a Reply