Implementing WCAG 2.1 Guideline Changes: Part 1

<a href"https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines (WCAG) is the international set of guidelines for accessible content on the internet for users with disabilities, including visual, auditory, physical and cognitive disabilities. Early this summer, the WCAG guidelines were updated to version 2.1 with 17 new success criteria spanning across all 3 levels. Most companies tend to follow the AA success criteria portion of WCAG, which means there are 12 mandatory new criteria to follow. Sometimes the WCAG guidelines can be difficult to understand, so let’s clarify what these new guidelines are trying to achieve.

Here’s what you need to know about the update:

1. WCAG 2.1 is backwards compatible with WCAG 2.0, meaning:
   • The previous categories and guidelines still apply
   • The numbering system still applies
   • The three levels of success criteria (A, AA, AAA) still apply
2. 508C guidelines encompasses the WCAG 2.0 guidelines, but has not yet been updated to follow the 2.1 guidelines.
3. These changes focus on improving accessibility for users with cognitive disabilities and low vision, as well as for users who browse websites on mobile devices at the levels of A to AAA standards.

For part 1 of WCAG 2.1 changes, we'll go over what has changed regarding Level A.

---

Additions to Level A Success Criteria

Level A conformance is the minimum level of compliance every site should meet. Every website, no matter the size of the organization, target audience or pages on the site, should meet this level. Usually, by following coding standards and using up to date versions of the CMS of your choosing, this level can be met on the development side. However, once custom theming, styling and content are added, that is where this area tends to fall short of fulfilling the Level A criteria. Here are the 5 new success guidelines for level A conformance.

2.1 Keyboard Accessible Guidelines

2.1.4 Character key shortcuts (A)

What Does This Mean?

If your app or website uses any kind of proprietary keyboard shortcuts for navigation, these shortcuts should be able to be turned off, modified or operated by voice command. If this applies to your site, there should be a resource available for users to determine if these voice commands and shortcuts will work for them, or if they need to modify or turn these commands off.

• Targeted Team Members: Designers, Developers
• P.O.U.R. Guideline: Operable
• Origin: Mobile

---

2.5 Input Modalities Guidelines

2.5.1 Pointer gestures (A)

2.5.1 Summary

Complex and confusing finger gestures such as double taps, swipes, or pinches should have an alternative operation like a button or link to produce the same outcome for users who physically cannot make these gestures or cognitively cannot remember these gestures.

• Targeted Team Members: Developers, Designers
• P.O.U.R. Guideline: Operable
• Origin: Mobile

---

2.5.2 Pointer Cancellation (A)

2.5.2 Summary

Users with physical disabilities may not have the same accuracy on touch screens as able users. A user should only create an action if they press down and up on the same item. For example, if a user presses on the “clear” button on a form but meant to press “send”, the user can slide their finger off of “clear” to reverse the action. Having an abort or undo action is also recommended for important actions like "clear all", "reset", "delete" and "submit".

• Targeted Team Members: Developers
• P.O.U.R. Guideline: Operable
• Origin: Mobile

---

2.5.3 Label in name (A)

2.5.3 Summary

Users who navigate websites and apps through speech technology should be able to, for example, send a form by reading whatever the button to submit the form reads. For example, if the button visually reads as “submit” but the name of the button in the code is “apply,” the speech action of "submit" will not trigger this action. In this case, the button will only trigger when "apply" is spoken.

• Targeted Team Members: Developers, Designers, Content Editors
• P.O.U.R. Guideline: Understandable
• Origin: Mobile

---

2.5.4 Motion actuation (A)

2.5.4 Summary

Users who lack certain physical movements should still be able to operate an app or site. Anything that requires custom movements, like the shake to remove all text on iPhones, should also be executable by a button or link as well. This also goes for users with tremors who may have uncontrollable movements, and would like to turn these motion activations off.

• Targeted Team Members: Developers, Designers
• P.O.U.R. Guideline: Operable
• Origin: Mobile

---

In part 2 of our series about the WCAG 2.1 update, we discuss Level AA and Level AAA changes.