Making Your Website Accessible Part 4: WCAG 2.1

The latest revision of the Web Content Accessibility Guidelines (WCAG), version 2.1, was recently published. While it’s a few years old, I still often refer to my series of blog posts that break down WCAG 2.0 because unlike many of my other articles on web accessibility, it refers to the WCAG criteria by number. This extra part to the series is to specifically cover what’s new in WCAG 2.1.

Backwards Compatibility

I’m really glad that the guidelines are backwards compatible. The guidelines document explicitly states:

WCAG 2.1 builds on and is backwards compatible with WCAG 2.0, meaning web pages that conform to WCAG 2.1 also conform to WCAG 2.0. (0.5)

So, while the numbering no longer groups guidelines by conformance level, it means that anything that referred to specific guidelines by their number is still the same. The numbering grouping by conformance level was convenient, but never necessary anyway, since the WCAG Quick Reference has filters by level.

As such, I will specifically focus on new Level A and AA guidelines that have been added (see the list from 0.5.1).

Presentation

A couple of new guidelines relate to general presentation of content.

The first is that non-text objects including UI components (the most common would be buttons), and graphics should have a 3:1 contrast ratio 1.4.11

The second is about text spacing 1.4.12. If the site doesn’t already use these properties, then a user should be able to set these properties without any problems:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Steve Faulkner has created a bookmarklet to test text spacing already.

Responsive Website

Wait… didn’t we already cover this? Yes we did, but some of the new guidelines are met by making your site responsive. In particular:

• Content not restricted to a specific orientation (landscape or portrait) 1.3.4
• Content will reflow and “work” at a high zoom without multiple scrollbars at 320px width and 256px height 1.4.10

Not all responsive sites will necessarily look great at such a small viewport size, but they should still be functional and usable.

Identification and Labels of Inputs and Status Messages

2.5.3 specifies that any component that uses a name, should have the label at the start of the name. While not specific to inputs or forms, it’s probably where labels and names are used the most.

Furthermore, users should be able to identify the purpose of all input fields 1.3.5. Is it for a name, address, email? While using the correct input type helps with error identification, inputs should use the autocomplete attribute so that users can take advantage of this functionality.

Status messages should also be identified using the role attribute with the appropriate value 4.1.3. These most commonly relate to forms as well to provide the user with, for example role=”alert” for error messages, or role=”status” for submission success/failure or brief search result messages.

Interactions

Interactions that rely on certain actions or types of human-computer interaction can be problematic, since it assumes the use of specific types of devices or ability to perform set actions in all contexts. A few of the new guidelines cover some expectations on how sites or apps should function accessibly.

If a keyboard shortcut consists of only a letter, punctuation, number, or symbol character, then it can be turned off or remapped, or it only applies when a particular UI component has focus 2.1.4. The last one is common for audio or video interface controls, or games, but otherwise, I generally recommend not to implement keyboard shortcuts at all since you never know what it might interfere with.

In the previous version of WCAG, there was an emphasis on making sure keyboard only users can access content, but with touch screens and mobile devices, there are other considerations as well.

Motion based functionality needs to also work through UI components plus motion response can be turned off 2.5.4. Disabling motion response can be either through the app itself or by supporting a system feature. (I could never get used to most of the motion functions, so I’m glad this is in the guidelines now.)

Content should function with a single pointer without requiring path-based action 2.5.1.

Related to 2.5.1, when using a single pointer, functionality is not triggered by the down-event (i.e. pressing the mouse button down or touching a screen) or it can be aborted, undone, or automatically cancelled by the up-event (i.e. letting go of the mouse button or moving a finger off a screen) 2.5.2.

There are exceptions to these 2.5 input guidelines where the method of input is essential (e.g. path-based motion in a drawing app), but hopefully they’re fairly obvious.

Finally, this last one will probably be the most problematic for most sites. For content that triggers additional content only by either mouse hover or keyboard focus, the revealed content:

• can be mouse over’ed,
• stays visible until the trigger is removed, and
• can be dismissed (typically with a Close button or ESC key) without moving the trigger 1.4.13

This criterion does not include built-in browser or device functionality (e.g. tooltip via title attribute), or modal popups and other components that steal focus.

I say this one will cause the biggest problem, because a large portion of sites have hover/focus-based submenus for their main navigation, and if it’s a purely HTML/CSS menu using hover/focus, there is no way to dismiss the submenu that appears. With our current technology (someone correct me if I’m wrong), you would need to use a JavaScript based menu so that on pressing the ESC key, it can close the submenu.

I tend to encourage pure HTML/CSS sites when possible without the bloat that often comes with JavaScript library heavy sites, and so sites work even with script blockers or without JavaScript loading. It’s obviously possible, but still complicates things. So, I’ll be interested to see how this guideline might change best practices and/or if this functionality is somehow integrated into a browser.

Conformance

The conformance section (5) did not previously exist. While optional, I always recommend that a conformance claim be made. Even if it’s only a partial claim, having an accessibility statement has many benefits, since it shows that you or your organization are aware of web accessibility, have thought about it, and how far you’ve implemented it.

It shows that you care.

The guidelines are clear in what is required for a conformance claim:

• full pages/site 5.2.2 needs to meet all required guidelines 5.1 of a specific Level 5.2.1
• all pages in a process (e.g. purchasing online) must be compliant at the specific level or higher 5.2.3
• only accessibility-supported ways of using technology are considered for the success of the guidelines 5.2.4, and if not, should not interfere with accessible access to the rest of a page 5.2.5

A conformance claim must have 5.3.1:

• the date,
• guideline name, version, and link,
• level,
• pages covered (e.g. if it includes subdomain), and
• technologies required (e.g. JavaScript) for accessible use.

There are a number of optional components that are recommended 5.3.2, as well as how to deal with partial conformance due to third-party content 5.4 and unsupported languages 5.5.

Nevertheless, too often, I encounter sites where I can’t find any contact information, let alone who to contact specially about accessibility issues. In some cases, there’s a form, but sometimes it’s hard to tell that it’s gone through and if I don’t hear back, why would I use the contact form a second time? So, I would say that in addition to what WCAG requires, I would add that you should:

always have contact information.

Take Away

I’m glad they’ve added these new guidelines and honestly, most of them will not be extra work considering current best practices and recommendations for general usability and user experience.

I would love to hear if people have already started looking at their website’s conformance in regards to WCAG 2.1, or any other thoughts!