WCAG 2.1 – What challenges face accessibility auditors?

The first WCAG 2.1 draft has finally been released! But what could the current changes mean for people with disabilities and web accessibility auditors? Media Access Australia's Senior Digital Accessibility Analyst, Matthew Putland, investigates.

The Web Accessibility Initiative’s Accessibility Guidelines Working Group (WAI-AGWG) has just released the first public draft of the Web Content Accessibility Guidelines 2.1 (WCAG 2.1). WCAG 2.1 is an official update for WCAG 2.0 that is set to not replace WCAG 2.0, but rather be an extension that bridges the technological gap between WCAG 2.0 and the long-term Project ‘Silver’.

Currently, WCAG 2.1 includes all of WCAG 2.0, and it’s expected that while some WCAG 2.0 Success criteria will change, this will be avoided as much as necessary in order to ensure backwards-compatibility with the old guideline. In the current version of the draft, no WCAG 2.0 success criteria has been changed.

The WCAG 2.1 draft has proposed quite a few new success criteria that will change the way that auditors conduct web accessibility audits. The proposed success criteria are now making use of the current technology of 2017, including the much wider adoption of mobile devices. Let’s take a closer look at some of the new proposals and what they mean for people with disabilities and for those of us who test WCAG 2.1 compliance.

Testing mobile is now a necessary part of every accessibility audit

WCAG 2.0 had little to no consideration for mobile devices, and that left some major gaps in the guideline when a huge array of smartphones and other mobile devices became a mainstream way of viewing web content. WCAG 2.1 will attempt to address some of these problems, and some success criteria even imply that websites will essentially require a responsive design to pass the guideline.

The rise of mobile devices has resulted in two entirely new guidelines proposed for WCAG 2.1, being ‘2.5 Pointer Accessible’ and ‘2.6 Additional Sensor Inputs’. This will be excellent news for the many people with disabilities who now use mobiles as their primary way of viewing and interacting with web content.

1.4.10 Linearization

This proposed guideline states that content must be able to be ‘reflowed’ into a single column. This will change a typical two-dimensional webpage into one dimension, where people will only need to scroll up and down the page to read all of the content. This success criterion is a big win for people with low-vision, as no longer will they struggle to find the dreaded ‘Next’ button in processes once everything is in a single, sequential column. This single-column format is very similar to how websites use responsive design to sort content onto a mobile-sized screen, which essentially means that all websites must now have a mechanism that supports a mobile device screen to pass the current rendition of WCAG 2.1, which is quite significant. While testing this success criterion, auditors will also have to make sure that the order of the content is still in a meaningful sequence.

2.5.1 Target Size

One of the much-needed ideas that originally appeared in the WCAG 2.0 for mobile draft was having a success criterion that addresses the size of buttons and controls. Everyone has experienced the trouble of trying to touch or click a very small control/link on a touch screen or desktop device. With this guideline, buttons on a desktop will need to have a size of at least 22 pixels by 22 pixels, and mobile devices will need their buttons to have a size of at least 44 pixels by 44 pixels. It’s noted that the icon or text in the control doesn’t need to be this size, but just the clickable/touchable field around the button. This success criteria will be easy to test if auditors have an assistive technology that can check the size of controls and links. Google’s Accessibility Scanner for Android devices is one example of a tool that’s already been testing this for a while, but it’s currently testing to a different size recommendation and is primarily designed for apps, not websites.

2.5.3 Touch with Assistive Technology

This one is a long time coming and it’s finally here, the success criterion for ensuring that mobile-based assistive technologies that change control modes (like VoiceOver and TalkBack) will operate on mobile websites. This success criterion is extremely important for the many people with vision-impairments who rely on a mobile screen reader’s touch control to navigate around. For auditors, it means we now have a success criterion that fits well when this issue comes up.

More testing to support low-vision users

While WCAG 2.0 did a fairly good job addressing much of the problems for people who use screen readers, but those with low-vision who didn’t use a screen reader had few success criterions that supported them. As mentioned before, 2.4.10 Linearization is a big win for low-vision users but there’s even more proposed success criteria that can benefit people with low-vision.

1.4.12 Graphics Contrast

One of the three confirmed success criterions to be added to WCAG 2.1 is Graphics Contrast. This expands on 1.4.3 Contrast (Minimum) from WCAG 2.0 – which only tested text and images of text – to also include important graphics that show information in the website. Examples given include testing the colour contrast of a ‘Print’ icon or even the lines on a graph that are being used to display vital information. However, caveats are currently being discussed for this success criterion for instances where the colour contrast is not vital, such as the colour of graph bars not needing to pass colour contrast, if text labels are present in the graph information. This makes testing this success criterion slightly more difficult than its WCAG 2.0 sibling.

1.4.15 Adapting Text

Adapting text is a success criterion that is long overdue as it tackles some assistive technologies that people with low-vision and also some people with cognitive disabilities use. In this success criterion, it’s required that no loss of content or functionality be caused by changing the font family, line height, or turning on high contrast modes. For auditors testing websites, it means that we will need to change these options on each webpage to ensure that content isn’t lost. Current proposals make it easy for this success criterion to test by only requiring the auditor to change the font family to Verdana and using the white on black high contrast mode, as these options will ensure that 99% of other high contrast modes and font families will work.

1.4.13 Printing

Perhaps one of the most out-of-place success criterions proposed, 1.4.13 checks to ensure that printed webpages will carry over changes that the user has made to the text, such as size and font changes. This success criterion is particularly interesting as currently the way to test this SC is to change the text on the website and print the webpage, and see if the text changes were applied on the printed sheet of paper. If this success criteria makes it into WCAG 2.1, this will be the first success criterion that forces an auditor to make a physical copy of the website.

Cognitive success criteria now found in ‘A’ and ‘AA’ compliance levels

A big notable problem of WCAG 2.0 was the total lack of cognitive-related success criteria in the level A and AA levels of compliance. As the large majority of organisations and governments assessed their websites for accessibility, relatively few tested their website against the ‘AAA’ level compliance, and even fewer made the effort to comply with the ‘AAA’ standard. This made many of the cognitive-related success criterions often ignored, which is one task that WCAG 2.1 has set out to resolve.

3.1.7 Plain Language (Minimum)

This success criterion is like a narrower version of level AAA’s 3.1.5 Reading Level success criteria. Plain Language focuses on instructions, labels, navigational elements and error messages which require a response to continue. This is a much easier success criterion to pass in comparison to a 3.1.5 Reading level, as it only applies to the critical areas of a website that need to be understood by people with a low level of education or individuals with cognitive limitations. For auditors, it means brushing off a few simple English skills to ensure that the important functions of a website are actually using simple, plain English.

3.1.9 Extra Symbols

This is an interesting success criterion that will make it easier for people with cognitive and learning disabilities to understand instructions, error messages or the critical functionality of the website. A symbol, icon or picture will need to be positioned preceding critical services and content with important information. For some cognitive disabilities, having a symbol to show important information alongside text will make content much easier to understand and comprehend. Unfortunately, for a level AA success criterion, I feel that many designers and developers will be reluctant to whole-heartedly adopt this change, even though it makes perfect sense, as it may impact the design of websites a fair bit. However, for auditors to test, this success criterion is not difficult or time consuming at all.

3.3.8 Undo

One of the more welcomed success criterions, Undo ensures that functionality is available on a website to allow people to go back in a process to fix mistakes. Being unable to return to the previous step in a process can be frustrating for all users, but is especially important for those with cognitive and learning disabilities as it will allow them to re-check their answers and reduce the fear of having to start over and/or failing. For auditors, this is a very easy success criterion to test and I’m confident this success criteria will make its way into the final WCAG 2.1 in some form.

More Operable websites

One thing that I wasn’t expecting from the rumours of WCAG 2.1 was the addition of more success criteria to assist people with mobility impairments. Some proposals have been made, with some being mobile-related.

2.1.4 Speech Input

An exciting addition to the WCAG 2.1 draft is a proposal for a speech input success criterion. People with mobility impairments make use of speech input software to navigate around their computer without using their body, and it’s essential for these people to ensure that websites can be navigated through as well without things going wrong. At first, this looks like a huge change of pace for WCAG 2.0 auditors, as now to test WCAG 2.1 they will need to become familiar with speech input software. Thankfully, this is not the case, as testing for this success criteria only involves checking the underlying code of controls in the website to ensure its accessible name is equivalent to the visible label to ensure that speech input users say the correct words.

2.6.2 Orientation

Changing the orientation of a device is a simple task for most – simply turn your screen to the left or right and have screen rotation enabled. Unfortunately for some people with mobility impairments, their orientation is locked in place (such as on their motorised wheelchair) and cannot easily be changed. This can create major problems if a website doesn’t support portrait or landscape orientations. This success criteria will ensure that web developers take the necessary precautions in ensuring that both of these modes work without loss of functionality and content, except in situations where the orientation is essential. For auditors, testing this success criterion is as simple as moving your hand to the left or right.


There are plenty of other proposed success criterions not mentioned here that are worthy of analysing for people with disabilities and accessibility experts/auditors. The Web Accessibility Initiative is looking for feedback for this version of the draft by 31 March, 2017. If you feel that something is missing or if something is simply not feasible or necessary, be sure to get your comments into the ‘raise new requests’ links supplied within the WCAG 2.1 draft.