Skip to main content

We use cookies to make sure the website can function, to measure traffic and to support the marketing of our services. By using the website, you agree to our use of cookies. Please read our privacy policy for further information about our use of cookies.

Help Center
Request A Demo

FAQ on WCAG 2.1 - The new standard for Accessibility

Jennifer Chadwick avatar

What does WCAG mean?

WCAG stands for "Web Content Accessibility Guidelines".

WCAG is the international standard for web accessibility, developed by the (World Wide Web Consortium) W3C, the internet standard organization that is also responsible for HTML and CSS standards. Siteimprove is a member of the W3C and actively participates in the standardization efforts within the area of digital accessibility.

What is WCAG 2.1?

In 2018, W3C released 17 new success criteria to WCAG 2.0 thereby introducing WCAG 2.1. On August 11, 2020, a working draft of an additional set of guidelines, WCAG 2.2, was released.

Shortly after the release of WCAG 2.1 we reviewed the criteria to see which could be validated through automated testing within our platform.  This led us to add checks for WCAG 2.1 - 1.3.4 Orientation (A), 1.3.5 Identify Input Purpose (AA) and 2.5.3 Label in Name (A).

They are part of the next release of the new version of the Siteimprove Accessibility product.

Since 2017, Siteimprove has participated in co-authoring the new set of accessibility conformance rules (ACT) for conformance with WCAG 2.1 within the W3C ACT Task Force.  The purpose of this work is to write a set of standardized rules that measure conformance with WCAG 2.0 and 2.1.  The WAI-Tools Project has been extended into early 2021, and we are at the stage of writing new checks to as pr.

Why was WCAG 2.1 released?

WCAG 2.0 was released in 2008.  A lot has changed in 10 years, in both technology itself and usage of websites, and the need for accessibility, on devices beyond the desktop experience.  For this reason, there are new success criteria relating specifically to mobile and tablet interactions.

Also, considerations for certain user groups were not recognized at the time.  More information is now available to understand user needs. This includes the preferences of those with low vision and cognitive disabilities. In WCAG 2.1, new success criteria have been added to address this.

Given this information, it is easy to understand why the majority of the new success criteria at 2.1 cannot be tested automatically.  For example, criteria related to mobile, conformance must be tested manually with the device. 

Siteimprove is working to write automated checks for WCAG 2.1 success criteria where possible.

When did WCAG 2.1 come into force?

WCAG 2.1 was made an official W3C recommendation on June 5, 2018.

The EU web accessibility directive that came into force in EU member states on the 23 September 2018 references WCAG 2.1 as the standard to be used. The first deadline for EU member states to report to the European Commission on their compliance with WCAG 2.1 at Level AA is September 23, 2020.

In the US, Section 508 was updated to WCAG 2.0 (entering into force January 18, 2018), it is not clear if and when it will get updated to WCAG 2.1. or 2.2.

The Americans with Disabilities Act (ADA) only states in Title III that communication, including web/internet, must be made accessible. It doesn’t reference any particular standard. Up until now WCAG 2.0 has widely been considered the de facto standard for ADA compliance of websites. Now that WCAG 2.1 is the new official W3C recommendation for web accessibility, we expect that there will be an increasing expectation for websites to live up to WCAG 2.1 and likely 2.2.

The Accessible Canada Act (ACA) was passed by the government of Canada on June 21, 2019, bringing accessibility legislation at the federal level for all provinces, not just Ontario (where the Accessibility for Ontarians with Disabilities Act (AODA) has been in effect since 2005). The expectation is that the ACA will adopt “the latest standard for web accessibility” which at the time, will mean either WCAG 2.1 or 2.2, once this is enforced.

Additional success criteria at WCAG 2.1

Most of the new WCAG 2.1 success criteria are related to, and have the goal to address people’s needs, around the following:

  • Mobile usage
  • Cognition
  • Low vision

Proposed success criteria at WCAG 2.2

There are now proposed nine additional criteria that have been drafted at WCAG 2.2.  The first public working draft was released on August 11, 2021, and feedback from the public is being accepted until September 18, 2020. 

The W3C Working Group has completed the process of adding new Success Criteria and is publishing this version for a wide review of the changes since WCAG 2.1, before the finalization of WCAG 2.2.

We have not added any checks to WCAG 2.2 yet as they are still being finalized. 

What is the difference between WCAG 2.0,  2.1, and 2.2?

WCAG 2.1 and 2.2 are extensions of 2.0.  These later versions include all of the existing success criteria at 2.0, with 17 new success criteria added at 2.1 and nine (proposed) at 2.2.  Success criteria have been added at Level A, Level AA and Level AAA.

Is WCAG 2.1 backward-compatible with WCAG 2.0?

Yes.  If you are aiming for compliance at WCAG 2.1, this includes 2.0.  There have been no changes to the success criteria at 2.0.

Similarly, if you are aiming for 2.2, this includes 2.1 and 2.0.

Does Siteimprove check for WCAG 2.1?

Yes, we check many of the new success criteria that can be automated and do not require a manual test with assistive technology and/or mobile. We are continually adding new checks. For example, the three checks listed below (1.3.4, 1.3.5 & 2.5.3, and parts of 1.4.10, 1.4.11, and 1.4.12), will be part of the next release of the new version of the Siteimprove Accessibility product. See "Which success criteria are automated in the Siteimprove platform?" for a breakdown of new success criteria in WCAG 2.1 and the checks included. 

Which success criteria are automated in the Siteimprove platform?

Below we provide a breakdown of new success criteria in WCAG 2.1, what checks can be automated and which are manually tested, and whether or not Siteimprove includes an automated check in the new version of the Siteimprove Accessibility product.

The new Siteimprove Accessibility product will be released in the coming months. If you'd like to get involved with the development process and testing of Accessibility Next Generation, signup for the early access program. 

1.3.4 Orientation (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.

Automated check: Yes

This is included in the automated accessibility check. The check is based on Accessibility Conformance Testing (ACT) Rule ID b33eff: Orientation of the page is not restricted using CSS transform property.

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.

Automated check: Yes

This is included in the automated accessibility check. Check is based on ACT Rule ID 73f2c2: autocomplete attribute has valid value.

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.

Automated check: No

This is not included in the automated accessibility check as a manual review is required to ensure the autofill results provided in the browser are programmatically determined, i.e. by a screen reader.

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;

Except for parts of the content that require two-dimensional layout for usage or meaning.

Automated check: Partially

Siteimprove can automatically determine if it's even possible to present content at those dimensions. One rule that will be launched in the upcoming release already does part of that by checking that the <meta> element isn't used for preventing zoom on mobile devices.

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.

Automated check: Partial coverage planned for future

For a wide range of user interface components, such as buttons and form controls, we expect to implement rules that will work similarly to the existing rule that checks the contrast of text.

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.

Automated check: Partial coverage planned for future

Development of a rule is currently underway that will check if the text spacing attributes can actually be modified by the user. We also expect to implement rules that will check that text isn't clipped once the text spacing attributes are modified.

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.

Automated check: No

This is not included in the automated accessibility check as a manual test is required, i.e. with a mouse and keyboard.

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 include one or more non-printable keyboard keys (e.g., Ctrl, Alt);
  • Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.

Automated check: No

This is not included in the automated accessibility check. as a manual test with keyboard shortcuts is required. 

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.

Automated check: No

This is not included in the accessibility check as this would need manual testing to detect when timeouts occur in a system.

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.

Automated check: No

This is not included in the automated accessibility check as a manual test by triggering an interaction on the web page or mobile screen is required.

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.

Automated check: No

This is not included in the accessibility check as a manual test on a mobile device is required to operate the path-based gestures.

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.

Automated check: No

This is not included in the accessibility check as a manual test on a mobile device with a pointer is required.

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.

Automated check: Yes

This is included in the automated accessibility check. The Check is based on ACT Rule ID 2ee8b8: Visible label is part of accessible name.

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.

Automated check: No

This is not included in the accessibility check as this requires a manual test. (e.g. involves handling the mobile device.)

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.

Automated check: No

This is not included in the accessibility check as manual testing required with input modalities such as an additional/external mouse or keyboard.

Where can I learn more about WCAG 2.1?

Learn more about WCAG 2.1:

Learn more about the WAI-Tools project:

Was this article helpful?

11 out of 16 found this helpful