WCAG 2.1 was published in its final form in June 2018. WCAG 2.1 is an extension to WCAG 2.0 that provides guidance to better address some of the needs of people with disabilities accessing content on mobile devices, people with low vision, and people with cognitive or learning disabilities.

The Web Content Accessibility Guidelines (WCAG) are an initiative of the World Wide Web Consortium (W3C) and define criteria websites must meet to be considered more accessible for people with disabilities.

WCAG 1.0 came out in 1999 and was organised as a set of 14 guidelines that had checkpoints with a priority of 1, 2, or 3. Accessibility could be determined by assessing conformance with the checkpoints.

This was a major step forward for web accessibility, but WCAG 1.0 showed some limitations as web technology, assistive technology and the way web pages were created rapidly evolved.

WCAG 2.0 was released in 2008, and was a complete rewrite, incorporating all the aims of version 1.0 but structured according to four over-arching Principles: that content must be Perceivable, Operable, Understandable and Robust.

Under these principles are 12 Guidelines that provide the basic goals to work toward in order to make web content more accessible to users with different disabilities.

The Guidelines themselves are not testable, but they provide the framework for Success Criteria that are testable.

WCAG 2.1 is an extension of WCAG 2.0, published in its final form in June 2018. It doesn’t replace WCAG 2.0 in the way WCAG 2.0 replaced WCAG 1.0, but it extends it to cover factors affecting accessibility for some users that were not covered in 2.0.

In particular, WCAG 2.1 provides one new Guideline – Input Mechanisms – and 17 new Success Criteria to better address some of the needs of people with disabilities accessing web content on mobile devices, people with low vision, and people with cognitive or learning disabilities.

These additional Guidelines and Success Criteria address the reality that mobile devices are not only more ubiquitous than they were when WCAG 2.0 was released, but are more complex, come with a greater range of differences from device to device, and have become more critical to negotiating daily life.

This is no sudden gap-filler: WCAG 2.1 is part of ongoing research and development to refine WCAG over time.

Importantly, people can implement all the parts of WCAG 2.1 now and indeed, many people – you included – may have already long been implementing the types of accessibility enhancement described in WCAG 2.1.

WCAG 2.1 formalises what is already best accessibility practice. It is backwards compatible with WCAG 2.0 and builds on it, so if your website conforms to 2.1 then it will also conform to 2.0.

The requirements in WCAG 2.1 – like those of WCAG 2.0 before it – are intended to be technology-agnostic, and not tied to particular devices, operating systems, browsers or any other aspect of technological use.

Let’s take a brief look at the 17 new Success Criteria in WCAG 2.1. Their priority level is indicated as A, AA or AAA, where Level A is considered the most urgent, and Level AAA may require more time to implement. Most legislation and official requirements currently focus on reaching Level AA.

See the official document – Web Content Accessibility Guidelines (WCAG) 2.1 (W3C Recommendation 05 June 2018) – for the exact wording for each Success Criterion.

WCAG 2.1 banner showing 5 June 2018 publication date


1.3.4 Orientation (AA)

Don’t lock a display to work only in portrait or landscape mode. Some users can’t rotate their device, and they could be limited to one display mode or the other. You should let a user choose which mode to use.

See 1.3.4 Orientation in WCAG 2.1

1.3.5 Identify Input Purpose (AA)

Make it easier for people to fill in forms correctly by helping them understand and recognize what they need to do, on their own terms. That might include letting people with cognitive impairments use familiar symbols and icons for form inputs, for example, or providing autocomplete functions that help people complete forms.

See 1.3.5 Identify Input Purpose in WCAG 2.1

1.3.6 Identify Purpose (AAA)

People with some kinds of disabilities use systems of symbols and icons to communicate. These are sometimes commercial products that can only be used on one device. Mark up web content so user agents can translate it into symbols and icons that can be understood by those users.

See 1.3.6 Identify Purpose in WCAG 2.1

1.4.10 Reflow (AA)

Ensure that content designed to scroll vertically can be zoomed to 400% without making the user scroll horizontally, and that content designed to scroll horizontally can be zoomed without having to scroll vertically – except where it’s essential or useful, such as on a map. Generally, content should wrap within the available viewport so that it’s always completely visible.

See 1.4.10 Reflow in WCAG 2.1

1.4.11 Non-Text Contrast (AA)

Related to existing SC 1.4.3 (which requires certain levels of contrast when presenting text or images of text), this requires non-text content such boundaries on input fields and icons to have enough colour contrast to allow users to perceive the content. If it helps the user do something, or understand the content, it has to meet minimum contrast requirements so that users with low vision can use it.

See 1.4.11 Non-Text Contrast  in WCAG 2.1

1.4.12 Text Spacing (AA)

Ensure content remains complete and understandable when the user changes the spacing between lines of text, between paragraphs, between words, and between letters. All of these can make text content easier to understand for people with some types of vision or cognitive impairments.

See 1.4.12 Text Spacing in WCAG 2.1

1.4.13 Content on Hover or Focus (AA)

Make sure content that appears as the result of a hover or keyboard focus action by the user can be controlled by the user – specifically, that they can perceive the content, and that they can dismiss it. This is distinct from modal popups (which are covered by other Success Criteria) and covers things like tooltips or submenus that appear on hover or when given focus. An example is where a low vision user magnifies a page and triggers a tooltip that obscures the main content – they have to be able to dismiss the tooltip so they can see the main content.

See 1.4.13 Content on Hover or Focus (AA) in WCAG 2.1

2.1.4 Character Key Shortcuts (A)

Single character key shortcuts are good for keyboard users but can be problematic for some other users. Give all users the option to turn off single character key shortcuts, or a way of reconfiguring the shortcuts to suit them.

See 2.1.4 Character Key Shortcuts in WCAG 2.1

2.2.6 Timeouts (AAA)

Give users enough time to complete a required action. People with low vision and people with some cognitive impairments may need more time than others to complete an online form. If there’s a good reason to put a time limit on the action – such as for security reasons – then give people as much time as possible, warn them about how long they have and what happens if they run out of time, and advise them how they can save the data they’ve entered so far.

See 2.2.6 Timeouts in WCAG 2.1

2.3.3 Animation from Interactions (AAA)

Related to SC 2.2.2 (which requires the user to be able to stop, pause or hide any content that moves, blinks or scrolls), this refers specifically to animation that occurs as a result of a user action, such as parallax scrolling (where backgrounds and foregrounds move at a different rate) that animates when the user moves the cursor or scrolls. In some people, this can trigger vestibular disorders ranging from dizziness to nausea and migraines. Give the user controls to turn it off.

See 2.3.3 Animation from Interactions in WCAG 2.1

2.5.1 Pointer Gestures (A)

Touch screens have introduced a whole new set of user interactions: pinching, zooming, double fingered swiping, three finger tapping and other complex gestures that may not be able to be performed by some users. Provide alternate ways for simple gestures to interact with content for those users. An example is an online map that can be zoomed by pinching or moved by swiping, and also by pressing [+] and [-] keys or arrow keys respectively.

See 2.5.1 Pointer Gestures in WCAG 2.1

2.5.2 Pointer Cancellation (A)

When a user clicks on a target, there are two actions: the pressing, or down-event, and the release, or up-event. The same thing applies on a touch screen when pressing or tapping and releasing on a target. People with some kinds of disability might be more likely to accidentally click or press down on a target. Provide a way for the user to cancel an action, by moving their pointer – whether it’s a cursor or a finger – away from the target area. Don’t initiate an action on the down-event. If that’s unavoidable, provide some other way for the user to cancel the action.

See 2.5.2 Pointer Cancellation in WCAG 2.1

2.5.3 Label in Name (A)

Speech input users can navigate by speaking the visible text labels of menus, links and buttons that appear on a webpage. For that reason, this criterion requires that visible labels match or are included in accessible labels, so that users understand where a link will take them. This is even more important considering speech input is used by some people with cognitive impairments – the disconnect between a visible label and its accessible name can be very confusing.

See 2.5.3 Label in Name in WCAG 2.1

2.5.4 Motion Actuation (A)

Mobile devices can activate some functions using sensors that respond directly to motion, for example shaking a phone to turn on its torch. This sensor-based functionality may not be available to people whose phone is kept in a fixed position due to physical disabilities, so the functionality should be made available through some other means, like a keyboard interface.

See 2.5.4 Motion Actuation in WCAG 2.1

2.5.5 Target Size (AAA)

Make targets for action sufficiently large to be activated. The point of this is to ensure that touch screen buttons, for example, are large enough to be pressed by people whose dexterity might be limited. Again, this becomes more critical in the confined space of mobile device screens. Minimum sizes are specified.

See 2.5.5 Target Size in WCAG 2.1

2.5.6 Concurrent Input Mechanisms (AAA)

This aims to ensure that, in most circumstances, a user can choose to interact with web content through an input mechanism other than the default, when the default might be inaccessible to them. An example might be a touchscreen device also accepting input via an attached external keyboard.

See 2.5.6 Concurrent Input Mechanisms in WCAG 2.1

4.1.3 Status Messages (AA)

Give all users access to information conveyed in status messages that provide context for information displayed on a webpage, in a way that can be programmatically determined and conveyed via assistive technologies. An example is when a user conducts a web search: the status message indicating the number of results provided will be immediately evident to a sighted user but may require specific code to be read out by a screen reader.

See 4.1.3 Status Messages in WCAG 2.1

In Conclusion

Once you dig into them, all of the new Success Criteria make good sense, providing web designers, developers and content authors with the means to ensure their web content is available to people with all kinds of disability.

The Web Content Accessibility Guidelines remain a work in progress and will continue to be incrementally refined over time in response to our advancing web technologies and the way people with disabilities use them to access content.