What you need to know about WCAG 2.1

The latest update to the Web Content Accessibility Guidelines (WCAG) has now been launched and version 2.1 is now the ‘recommended’ version as of 5th June 2018. The official W3C blog post goes into lots of detail about how it came about, what it covers and where it can go from here.

We have been using the new guidelines in day-to-day work for a few months, so I’d like to take a different approach and look at the practical testing and impact on teams using it.

What’s new?

The first thing to say is that WCAG 2.1 is an update to 2.0, so everything from WCAG 2.0 is just the same but there are 17 new “criteria” added (content requirements). That takes it to a total of 78, of which 51 are now at level A or AA.

The new guidelines are sourced primarily from three sub-groups (task forces) of the Accessibility Guidelines working group: Cognitive, Low Vision and Mobile. Although there is some overlap in who benefits from each criterion, I’ll use those groupings below.

Please note, many of the links below go to more extensive documentation about each success criteria, so if you aren’t sure about something, follow the link.

Cognitive and Learning Disabilities

The “COGA” task force have done a huge amount of research and work on requirements for people with Cognitive and Learning disabilities (see the Gap Analysis), however, the requirements were the most difficult to fit into the WCAG 2.x model.

A lot of the requirements were aimed at supporting personalisation and the two criteria related to that which were include are “Identify Input Purpose” (AA) and “Identify Purpose” (AAA). For most teams aiming for WCAG 2.1 AA, this means you need to be aware of the common input purposes for things like name, email, and various addresses and include code to convey them.

For example, if you have a field for the user to add their name (not someone else’s name), you could add the autocomplete attribute like this:

autocomplete="name" id="id-23423" required>

That hint lets the browser or plugin know what the purpose of the field is and, if the user allows it to, fill that information in with no need to remember or type it in. This is very helpful for people with memory or language issues, especially for things like postal-codes and credit cards.

The general ‘identify purpose’ (AAA) criteria is aimed at allowing users who rely on icons to use their own icons for links, form controls, icons and regions.

There is also a new criteria called “Timeouts” (AAA), where, if the user could lose data due to inactivity, they are warned in advance.

Low Vision

The Low Vision Task Force also brought quite a few requirements to the table, but after some refinement four were agreed for inclusion. For two of them it is easiest to consider them with a 2.0 criterion as a group:

• Reflow (AA) – Ensure content works when zoomed into 320px of width)
• Text-spacing (AA) – Ensure that making adjustments to characters, words and lines doesn’t prevent people from reading content
• Resize-text (AA from WCAG 2.0) – Allow people to make the text larger by at least 200%

If your website was created as a mobile-first, responsive site that considered internationalisation you will probably have nothing to do. As a relatively simple test procedure for all three criteria, try this on your pages:

1. Use a desktop browser set to 1280px wide
2. Zoom in to 400% (possible on Chrome and Edge by default, Firefox with some fiddling, not Safari)
3. As you zoom in, check that the text increases to at least 200% at some point
4. Check that all the content and functionality is available, even if it is hidden behind a menu or on a separate page
5. Use a bookmarklet to apply text spacing
6. Gradually un-zoom and check that text doesn’t overlap or disappear through the different breakpoints (variations) of the page

If nothing is lost in that process, you have passed. If it isn’t perfect, then you might need to dig into the criteria to work out how to fulfil them in another way.

Non-text contrast

A new requirement called “Non-text contrast” is plugging a hole in WCAG 2.0 where contrast requirements were only for text. It is one of the more complex ones to apply, which is unfortunate, but if it were too simple then it would be trying to outlaw several types of design approach. Human perception is complex, interfaces are complex, so the rules for having contrasting graphics are somewhat complex. To try and state it simply:

• If graphics are required to understand a component (e.g. a button) or content (e.g. an infographic), then those aspects should have at least a 3:1 contrast ratio
• If you have (contrasting) text for something, then the graphic isn’t required to understand that content/control, but it is worth reading through the understanding document for “Non-text contrast” as it has many examples

Hover or Focus Pop-overs/ups

People who use a magnified view tend to rely heavily on the mouse to control their view of a page, so when mouse-over triggers a pop-up it can completely obscure their view, and even make it impossible to get to certain content.

The new “Content on Hover or Focus” says that if you trigger extra content via mouse-over or keyboard-focus, then the user should be able to dismiss it without moving the hover or focus (e.g. press ‘esc’ key), move the pointer over the extra content without losing it.

If you’re designing for mobile and/or touch-screen usage (which has no concept of mouse-over) then this is unlikely to come up, but there are many interfaces that still use this type of interaction.

Mobile

The Mobile Task Force had quite a few requirements, some of which were related to mobile devices, but there were also some to do with varying input mechanisms (such as voice-input). The new requirements are:

• Orientation (AA) – Allows pages to be used in either orientation (landscape or portrait), as some people cannot rotate the device.
  For testing orientation you need to either use a mobile device, or look for certain media query statements.
• Character Key Shortcuts (A) – If you implement keyboard short cuts (e.g. “J” for next), allow users to turn them off or remap them.
  When using voice input this kind of shortcuts can accidentally be activated by talking, E.g. “Hey Kim” activates “Y”, “K”, “M”, which could really play havoc with an email interface.
• Pointer Gestures (A) – Anything you do by swiping (or anything that isn’t a simple tap) should be achievable in another way, such as an on-screen button. This is relatively rare, but watch out for things like carousels that you swipe through. You can still do that, but as assistive technology uses swipe gestures there should be another way.
• Pointer Cancellation (A) – Avoid activating things on the ‘down’ event, e.g. touch-start or mouse-down. There are some exceptions, but the normal events like ‘onclick’ activate on the ‘up’ event, so you can move your finger off the control to cancel the action.
• Label in name (A) – As voice-input uses the ‘label’ of a control to select it (generally the text included in the control), the visible text needs to be included. For example, if you have an image-link which says “15% off shoes”, but the alt-text says, “Best offers”, using voice-input to say “click 15% off shoes” will simply fail. Also watch out when using aria-label, as that changes the computed label.
• Motion Actuation (A) – If functionality uses movement of the device (or person in front of the device) as an input, it needs to have another method as well, otherwise someone using it in a stand on a wheelchair (for example) will not be able to use it, or someone with hand tremors may accidentally activate something.
• Target Size (AAA) – This is the flat-pack furniture of the new criteria: It looks like it should be simple to implement but then takes a huge amount of effort! (This is why it’s at level AAA, as it is quite difficult to implement in practice). Interactive elements should be at least 44×44 pixels, but with quite a few exceptions.
• Concurrent Input Mechanisms (AAA) – To allow people to switch between input mechanisms such as touch screen and keyboard. It is phrased as “content does not restrict use of input modalities”, so be careful about assuming that people with a small or touch-screen device don’t use a mouse and keyboard (or vice versa).

Miscellaneous

There were also a couple of requirements added by working group members based on gaps we’d noticed, these were:

• Animation from Interactions (AAA), there was already a criteria about animations caused by the page, but there was a gap for animations triggered on scroll or other user-interactions. This is especially important for people with vestibular disorders who can be hugely impacted by things like parallax scrolling.
• Status messages (AA), when people using assistive tech (such as screenreaders) take an action (such as adding something to a basket), this is a requirement to make that type of status message available using something like aria-live.

Another aspect that was not explicit previously was that WCAG applies across all breakpoints in a page that uses media-queries. In the conformance section there is now a note saying:

“A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.”

In practice that means people need to test at each breakpoint. To keep it manageable, it helps to look for what changes and find specific things to test. For example:

• If a full size menu is replaced by a ‘hamburger’ menu (without a text label) that needs to fulfil the non-text contrast criteria.
• Things which are shown/hidden at different screensizes should affect whether they are keyboard-focusable, don’t leave a 100 item menu in the page that people using a keyboard can’t see.
• If content / functionality is removed completely at some breakpoints that will probably fail Resize-text or Reflow, as if you need to zoom to read then everything should be available.
• If colours change, then contrast (text and/or graphics) will need checking.
• If the structure changes, “Info and relationships” needs checking.

The only exception is that where zoom and media queries are a method of meeting the text-size criteria, you do not then have to test text-size across all the variations of the page (created by breakpoints in the media queries). That would be like inception, so the page must (in a variation) make it possible to reach at least 200% text-size.

What now?

Firstly – don’t panic! WCAG 2.1 is relatively new, now is the time to take in the new requirements and consider how you can accommodate them. These are not the decree of some standards body saying how you must make your website; these are known issues for people with access needs converted into requirements. They provide a baseline for preventing those issues, for larger organisations you should also do usability testing with people to take it to the next level!

Nomensa now use WCAG 2.1 by default in our accessibility testing and consultancy, so if you’d like help integrating WCAG into your sites, apps or policies please do get in touch.

Explore our case study to witness how we’ve played a pivotal role as Royal Mail’s long-term accessibility partner, driving progress towards WCAG 2.0 Level AA and shaping a robust digital accessibility framework.