This post adapted from the article, “The WCAG 2.1 Update: A Brief Look at What’s Changed,” originally published in the September 2018 issue of Mealey’s™ Litigation Report: Cyber Tech & E-Commerce. Mealey’s is a subscription-based information provider and a division of LexisNexis.

Copyright © 2018 by Hiram Kuykendall.  Any commentary or opinions do not reflect the opinions of Microassist or LexisNexis, Mealey’s. Comments welcome!

What Changed from WCAG 2.0 to WCAG 2.1?

On June 5, 2018, the World Wide Web Consortium (W3C) released an incremental 2.1 update to the Web Content Accessibility Guidelines (WCAG). WCAG is a set of principle-based rules that are widely cited in legislation and litigation as containing actionable tests that evaluate the degree to which a website, web application, document (such as PDF files) and other information and communication technology (ICT) is accessible. The 2.1 update offers improved guidelines in the areas of low vision, cognition, and mobile devices.

Summary of Changes

1. WCAG 2.1 is backward compatible to WCAG 2.0.
2. WCAG 2.1 retained the Level A, AA, and AAA system of rating.
   • As before, the recommended level of compliance is Level AA, which is inclusive of Level A.
   • Level AAA once again contains guidelines that are not readily achievable or that have a specific purpose not generally encountered.
3. There is one new guideline: 2.5 Input Modalities.
4. There are 17 new success criteria:
   • 5 Level A, 7 Level AA, 5 Level AAA
   • 8 Mobile, 5 Vision, 4 Cognitive
5. Guideline 2.3 has been changed from “Seizures” to “Seizures and Physical Reactions.”
6. New glossary definitions have been added.

WCAG 2.1 – Potential Legal Impact

The 2.1 update will likely be slow to have any effect. Laws such as Section 508 of the Rehabilitation Act of 1973 have incorporated WCAG 2.0 by reference directly into the law (See 702.10.1 and  E25.04, Accessibility Standard).  Making the move to cite WCAG 2.1 would be a substantive change requiring the U.S. Access Board to implement rulemaking, a process that could take a few years. Bruce Bailey, Accessibility IT Specialist at the U.S. Access Board, responded to a Microassist email inquiry that there are no immediate plans to do so.

The 2017 Section 508 Refresh, states:

E207.2 WCAG Conformance. User interface components, as well as the content of platforms and applications, shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1).

702.10.1 WCAG 2.0, Web Content Accessibility Guidelines, W3C Recommendation, December 11, 2008, IBR approved for: Appendix A (Section 508 of the Rehabilitation Act: Application and Scoping Requirements), Sections E205.4, E205.4 Exception, E205.4.1, E207.2, E207.2 Exception 2, E207.2 Exception 3, E207.2.1, E207.3; Appendix B (Section 255 of the Communications Act: Application and Scoping Requirements), C203.1, C203.1 Exception, C203.1.1, C205.2, C205.2 Exception 2, C205.2 Exception 3, C205.2.1, C205.3; and Appendix C (Functional Performance Criteria and Technical Requirements), 408.3 Exception, 501.1 Exception, 504.2, 504.3, 504.4, and 602.3.

In addition, as of August 2018, the Voluntary Product Accessibility Template^® (VPAT^®), Version 2.2 still includes WCAG 2.0 Level A, AA, AAA in all its latest editions (WCAG, Revised 508, EN 301 549, and International). NOTE: See December 2018 update, below: 

December 2018 update

Version 2.2 was updated and re-versioned to VPAT 2.3 on December 19, 2018. Among other changes, the update includes WCAG 2.1 with the EU (European Union), WCAG, and INT (combined) editions of the VPAT, but not the Section 508 version.

See the ITIC’s VPAT Change Tracking document, available on the ITIC VPAT page, for details. — Editor

A VPAT, or Accessibility Conformance Report (ACR), is a standardized accessibility report. It is completed by a vendor and provided to purchasing departments as evidence of a product’s accessibility. The template is owned and maintained by the Information Technology Industry Council (ITI) and was originally created to assist in Section 508 evaluations by federal purchasing departments. Since its inception, it has gained increased popularity in other public sectors such as state government, higher education, and K-12.

Conversely, many private sector companies specializing in accessibility auditing and remediation have incorporated the WCAG 2.1 standard into their products. This proactive measure allows those who want to evaluate their digital assets under the more restrictive standard to do so.

For more on the latest version of the VPAT^®

See Hiram’s article, “Introducing VPAT^® 2.0, the More Stringent Accessibility Reporting Tool Required for Government IT Procurement.”

WCAG 2.1 – A Look at the Changes

The following is a brief overview of the new WCAG 2.1 success criteria (content from W3C is noted in italics or otherwise identified).

Guideline 1.3 Adaptable

1.3.4 Orientation (Level AA)

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

NOTE

Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where binary display orientation is not applicable.

The WCAG definition of “essential” is

If removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform.

Historically, mobile apps locked the screen into a resolution that could not be expanded (through “pinch and zoom”) or rotated. This offers problems for people with low vision and mobility challenges who may need to alter the rotation to clearly perceive the content.

1.3.5 Identify Input Purpose (AA)

The purpose of each input field collecting information about the user can be programmatically determined when:

• The input field serves a purpose identified in the Input Purposes for User Interface Components section; and
• The content is implemented using technologies with support for identifying the expected meaning for form input data.

This success criteria states that when possible, the user agent (a web browser is a good example), should auto-populate fields that have been marked as containing certain types of information. For example, a checkout form that asks for the user’s address can be marked to alert the browser of the type of required information. The browser could then pre-populate the information based on past entry of similar values.

1.3.6 Identify Purpose (AAA)

In content implemented using markup languages, the purpose of User Interface Components, icons, and regions can be programmatically determined.

The goal is to allow the localization of objects like icons and other interface components. Localization refers to making an object reflect recognizable cultural characteristics such as language or regional iconography. There are three examples cited by the WC3:

• A website uses ARIA landmarks to identify the regions of the page, and users can hide areas that are not the ‘main’.
• The links in the navigation of a website are marked-up so that users can add their own icons.
• Icons on a website use are marked-up so that the user can substitute their own icon set into the page.

Please note this is a Level AAA success criterion and not likely to be required in the near future.

Guideline 1.4 Distinguishable

1.4.10 Reflow (AA)

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Vertical scrolling content at a width equivalent to 320 CSS pixels;
• Horizontal scrolling content at a height equivalent to 256 CSS pixels.

The intent is to allow the user to increase content to 400% without having scrollbars extend horizontally and vertically at the same time. Scrolling in multiple dimensions creates a heavy cognitive load. It is also physically taxing for someone who may be viewing the screen at high magnification. People who have mobility challenges may also find navigating with two scrollbars difficult.

1.4.11 Non-Text Contrast (AA)

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

• User Interface Components: Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
• Graphical Objects: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

1.4.11 Non-Text Contrast (AA) is similar to success criterion for large text in 1.4.3 Contrast (Minimum). In short, as a user tabs between objects such as a button, form field, link, etc., there must be sufficient indication to show where the focus is. Currently, it is common to find objects like form fields that lack a focus indication. As such, the user is unsure when they have entered the field and can perform the necessary data entry.

Active User Interface Component Examples

Focus indicators, selection indicators, and user interface components need to be perceived clearly. The W3C provides a table of items with sufficient contrast on its “Understanding WCAG 2.1” site. Table 1 is a copy, with only minor changes, of the W3C’s Active User Interface Components Examples table, with some descriptive text and hex color values in italics.

Table 1: Active User Interface Component Examples

Type	Description	Examples
Link Text	Default link text is in the scope of 1.4.3 Contrast (Minimum), and the underline is sufficient to indicate the link.
Default focus style	Links are required to have a focus indicator by 2.4.7 Focus Visible. Where the focus style of the user-agent is not adjusted on interactive controls (such as links, form fields or buttons), the default focus style is sufficient.
Styled links or buttons	Where links or buttons have been styled (including the focus indicator), these must meet the 3:1 contrast ratio.
Text input (minimal)	Where a text-input has an indicator, such as a bottom border, that indicator it must meet 3:1 contrast ratio.
Text input	Where a text-input has an indicator, such as a bottom border, that indicator it must meet 3:1 contrast ratio.
Text input focus style	Adding a focus indicator is required, and must meet 3:1 contrast ratio.
Text input using background color	Text input using a different in background color to indicate the input, no border is required to indicate the input box.
Text input using background color focus style	Where an author-created focus style is applied to a dark background, it should have 3:1 contrast with the surroundings and/or input.

1.4.12 Text Spacing (AA)

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• 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.

Historically, issues related to low vision have been difficult to evaluate. In response to this, WCAG 2.1 set exacting requirements for text spacing that complement the existing low vision principles such as success criteria 1.4.4 Resize text, 1.4.3 Contrast (Minimum), etc.

Issues related to low vision have been of particular interest to the W3C as the U.S. population continues to age. Currently about 10,000 baby boomers turn 65 each day and make up nearly 20% of the American public.

1.4.13 Content on Hover or Focus (AA)

Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

• Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
• Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
• Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

In short, dynamically adding information that obscures other content is a failure. For example, hovering over a text field should not make visible a tool tip that covers another piece of content. In the event it does, the user should be able to dismiss the offending tooltip. Conversely, the information that does appear should remain present until it is dismissed.

Guideline 2.1 Keyboard Accessible

2.1.4 Character Key Shortcuts (A)

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

• Turn Off: A mechanism is available to turn the shortcut off;
• Remap: A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc);
• Active Only on Focus: The keyboard shortcut for a user interface component is only active when that component has focus.

One of the challenges of creating an accessible user interface is accommodating people who use assistive technologies and those who do not. For example, the use of shortcut keys can greatly assist the average person in performing a function such as going to the next screen in an elearning module. The conflict occurs when assistive technologies use the same keys as the application. For instance, pressing the “H” on a keyboard will take screen reader users to the next heading on a page. If an application developer has remapped the “H” key to open a menu, then the two keys are in conflict. This principle asks that there be a solution for de-conflicting the assistive technology and user-programmable key assignments.

Guideline 2.2 Enough Time

2.2.6 Timeouts (AAA)

Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions.

Timeouts can be a source of irritation and represent a significant challenge for those with a disability. Alerting the user that a timeout is about to occur or has occurred prevents the user from completing the task at hand.

Please note this is a Level AAA success criterion and not likely to be required in the near future.

Guideline 2.3 Seizures and Physical Reactions

2.3.3 Animation from Interactions (AAA)

Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.

Having extra movement on the screen can be disorienting for users with certain types of permanent or temporary cognitive challenges. One of the guiding principles of accessibility is to provide the user with the ability to control their environment. As such, 2.3.3. Animation from Interactions asks application developers to avoid certain practices or provide a means to stop certain types of distracting animations.

Please note this is a Level AAA success criterion and not likely to be required in the near future.

Examples (Source: W3C, “Understanding Success Criterion 2.3.3: Animation from Interactions”):

• Parallax scrolling with option to turn off unnecessary motion globally:
  • A site includes extra animations when the user scrolls. Decorative elements move in and out of view horizontally when the essential page content is scrolled vertically. A control at the top of each page allows the user to turn off unnecessary animations. The ability to turn off non-essential animations is a site-wide setting.
• Transitions that support the reduce motion preference:
  • A site includes a non-essential transition when loading new content. The transition is a page-flipping animation that respects the reduce-motion CSS media query. When the user enables the reduce motion preference, the page-flipping animation is turned off.
• Essential animation:
  • A web application provides a feature to author animated sequences. As part of this tool the author needs to preview the animation.

Guideline 2.5 Input Modalities

2.5.1 Pointer Gestures (A)

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

In short, anything you can do through a complicated gesture such as a pinch and zoom on a map must also be made available through a single point method such as selecting a zoom in and zoom out button. People who lack fine motor skills require this additional method as a complex gesture may be beyond their ability.

Examples (Source: W3C, “Understanding Success Criterion 2.5.1: Pointer Gestures”):

• A web site includes a map view that supports the pinch gesture to zoom into the map content, and drag gestures to move the visible area. User interface controls offer the operation via [+] and [-] buttons to zoom in and out, and arrow buttons to pan stepwise in all directions.
• A news site has a horizontal content slider with hidden news teasers that can moved into the viewport via horizontal swiping. It also offers forward and backward arrow buttons for single-point activation to navigate to adjacent slider content.
• A mortgage lending site has a slider control for setting the amount of credit required. The slider can be operated by dragging the thumb, but also by a single tap or click anywhere on the slider groove in order to set the thumb to the chosen position.
• A slider control can be operated by dragging the thumb. Buttons on both sides of the slider increment and decrement the selected value and update the thumb position.
• A floor planning web app lets the user place shapes representing pieces of furniture on a map representing a room. The user can drag a shape to reposition it, but they can also accomplish this by clicking on a drag handle in the center of the shape then clicking arrow buttons to move the selected handle. Similarly, they can resize the shape by pinch-and-zoom, but they can also do this by clicking a drag handle on its boundary and then clicking the arrow buttons.

2.5.2 Pointer Cancellation (A)

For functionality that can be operated using a single pointer, at least one of the following is true:

• No Down Event: The down-event of the pointer is not used to execute any part of the function;
• Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
• Up Reversal: The up-event reverses any outcome of the preceding down-event;
• Essential: Completing the function on the down-event is essential.

As one of the mobile success criterion, this principle asks that the user be able to avoid activating a feature by fully describing how a single pointer, such as a touch screen, would work. This is of great benefit to people who lack fine motor skills and may accidentally activate a feature, and then need to undo the action gracefully.

2.5.3 Label in Name (A)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Many development standards such as HTML5 have the ability to put a description on an object that is only perceivable by people who use assistive technologies such as a screen reader. This requirement asks that the visual and non-visual labels match. For example, a visible label that says “Last 4 Digits of your Social Security Number” and a label for assistive technology that says “Social Security Number” would not be equivalent and would therefore fail this success criterion.

2.5.4 Motion Actuation (A)

Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:

• Supported Interface: The motion is used to operate functionality through an accessibility supported interface;
• Essential: The motion is essential for the function and doing so would invalidate the activity.

As mobile and other anticipated Internet of Things devices become increasingly interactive, there needs to be a method to prevent certain types of inputs based on an individual’s ability. For example, a person whose hands tremble may want to disable features on a phone that activate when the device is shaken.

Examples (Source: W3C, “Understanding Success Criterion 2.5.4: Motion Actuation”):

• After text is input in a field, shaking a device shows a dialog offering users to undo the input. A cancel button next to the text field offers the same functionality.
• A user can tilt a device to advance to the next or a previous page. Buttons or links are also provided to perform the same function.
• A user can move or pan a device to change the view in an interactive photo. A control is also available to perform these same functions.
• A user can gesture towards the device to navigate content. Controls are also available to navigate.
• A user can choose an application setting which turns off Shake to Undo features.

2.5.5 Target Size (AAA)

The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:

• Equivalent: The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
• Inline: The target is a sentence or block of text.
• User Agent Control: The size of the target is determined by the user agent and is not modified by the author;
• Essential: A particular presentation of the target is essential to the information being conveyed.

Touch screen mobile devices can be problematic for people with hand tremors and other physical mobility challenges. To provide better user control, 2.5.5 Target Size sets a minimum pixel size and mandates that the minimum size not be alterable by the content author.

Please note this is a Level AAA success criterion and not likely to be required in the near future.

2.5.6 Concurrent Input Mechanisms (AAA)

Web content does not restrict use of input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or required to respect user settings.

A user may elect to use any number of input devices individually or concurrently. For example, a user may use a keyboard but still engage the device through use of a touch screen, stylus, or mouse.

Please note this is a Level AAA success criterion and not likely to be required in the near future.

Guideline 4.1 Compatible

4.1.3 Status Messages (AA)

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Users who rely on assistive technologies such as a screen reader can become disoriented if the focus is moved without alerting the user. For example, it is common for a dynamic message to appear stating whether a newly entered password meets the minimum application requirements. Sighted users can see this dynamically created message and act accordingly. To give a blind or low vision user who relies on a screen reader a similar experience, the screen reader must be able to detect the appearance of a message and read the message to the user without moving the user from the field to the message. This is done through a variety of coding techniques, but the result of each is that assistive technology is able to announce the message without moving the focus to the message.

Conclusion

In summary, we anticipate the adoption of WCAG 2.1 by purchasing departments will be slow until it is fully incorporated into federal procurements and the VPAT process. However, since WCAG 2.1 is an incremental increase to the 2.0 standard and is being incorporated into existing accessibility evaluation products, we do foresee that those entities who are proactively looking to be accessible will more quickly incorporate the additional guidelines. This is especially true for entities who specialize in the mobile and tablet space who did not have robust success criteria under WCAG 2.1.

What’s next in accessibility? Project Silver is underway!

Catch our CSUN 2018 interview on the next stage for accessibility standards: What Comes after WCAG? Jeanne Spellman on W3C’s “Project Silver.”

Talk with us about how the WCAG 2.1 update affects you, VPATs, and government IT procurements

Microassist provides VPAT Evaluation Services to vendors and government procurement officers to ensure that contract obligations are honored, both parties understand the accessibility of their products, and that all consumers of government can participate in civic benefits and functions. Contact our Accessibility Team today to discuss whether WCAG 2.1 or WCAG 2.0 services are right for you.

Photo collage credits: Unsplash, various images.

Related Posts

Making Democracy Accessible: How Polling Place Accessibility Is Shaping Up For November

Advancements in Web Accessibility: From WCAG 2.0 to WCAG 2.1

In Landmark Case Department Of Transit Slaps Airline With Penalty For Poor Treatment Of Passengers With Disabilities