WCAG 2.1 vs WCAG 2.2

Differences between WCAG 2.1 and WCAG 2.2

Published: November 4, 2022

    Have our accessibility experts contact you

    Protected by reCAPTCHA and the Google Privacy Policy and Google Terms of Service.

    Share via:

    The web content accessibility guidelines WCAG is an international standard focused on making web content accessible to people with disabilities. It was a group of individuals and organizations, the world wide web consortium, which took a proactive stance in developing the WCAG. These accessibility advocates created the WCAG guidelines to create a single standard for web accessibility. This article will teach you about WCAG 2.1 and WCAG 2.2 Differences.

    On February 27th, 2020, the W3C released the first working draft of WCAG 2.2, an extension of WCAG 2.1. So while there are not many changes between the two, the WCAG 2.2 does have nine additional success criteria, including one that was promoted from AA to A.

    These updates mainly focused on new helpful guidelines for using ebooks and other digital content types. They mainly focus on compliance and web accessibility on touchscreens and mobile platforms.

    Read on to learn more about these differences and how they help people with disabilities.

    Differences between WCAG 2.1 and WCAG 2.2 success criteria

    The WCAG 2.2 is a comprehensive guideline for web developers, website owners, students, content creators, policymakers, and others to follow while making web content accessible to everyone.

    The main difference between WCAG 2.2 and WCAG 2.1 lie in improved accessibility based on the same three conformance levels for three groups of users with disabilities. They are:

    • Users with low vision
    • Users with cognitive limitations or learning disabilities
    • Users with restrictions like large fingers or motor disabilities that make using mobile devices challenging

    The main reason and need for this update and to take a more proactive stance towards web compliance was the increase if mobile users. The update helps web owners and developers create websites with optimal mobile device accessibility.

    While developing or updating web content, it is better to comply with the latest WCAG 2.2 version than the previous WCAG version.

    Web content accessibility guidelines benefit everyone

    Not only the disabled users benefit because of WCAG 2.2; the current editor’s draft benefits everyone. It is because all users have their prerequisites and needs while consuming web content. For example, while mainly the deaf and hard of hearing need captions to enjoy a video, it is also helpful for someone who can listen to it. Some people may have to mute a video to watch it to avoid the sound disturbing someone. In this case, the captions come in useful.

    New guidelines accommodate people with disabilities

    WCAG 2.2 is backward-compliant, extending WCAG 2.0 and 2.1 without significantly changing the previous versions. In other words, you know you conform to the earlier versions, 2.0 and 2.1, if you conform to WCAG 2.2.

    The WCAG 2.2 in total introduces nine new success criteria, which are:

    • 1. Guideline 2.4.7 Focus Visible (A)

      This is not a new success criterion, but it has just been promoted from AA to A. According to it, WCAG 2.2 now lets you use the default browser focus state or create your prominent focus states.

      There are three ways to maintain your focus state branding. You can do it:

      • By reversing the link and background colors
      • By adding a thick border
      • By using a combination of the above two strategies
    • 2. Guideline 2.4.11 Focus Visible (Enhanced AA compliant)

      According to this WCAG 2.2 guideline, your design system focus states should display visible keyboard focus indicators by:

      • Surrounding the entire focused element with a 1-pixel or more significant border
      • Having an 8-pixel or greater edge on the shortest side
      • Maintaining a color change with a 3:1 contrast ratio from the unfocused state
      • Maintaining a 3:1 contrast ratio with background colors or having 2 pixels or greater borders surrounding the focused element.

      Also, ensure any focusable elements taken out of the design system and used on the website or app do not overlap or hide the focus indicator with other screen elements.

    • How this guideline affects people with disabilities

      This success criterion ensures everyone can see and use a keyboard because they will always know where the focus is. This is essential because it is practically impossible for a user to navigate a website without seeing what they focus on.

    • 3. Guideline 2.5.7 Dragging (AA)

      According to this guideline, WCAG 2.2 stipulates that web developers must supply alternatives to the dragging action in user interface components. The only exception is when dragging is essential, like when a user adjusts the price range search filters.

      This is a vital enhancement that can prove helpful because everyone has something or the other to reorder. If nothing, a user may want to drag and reorder the apps on the homepage in an organized manner.

    • How this guideline affects people with disabilities

      This guideline helps ensure this by letting people with disabilities no longer feel left out because they cannot do things like dragging with a mouse.

    • 4. Guideline 2.5.8 Pointer Target Spacing (AA)

      This new guideline requires that web owners maintain sufficient space around fixed reference points like navigation links and form fields that aren’t inline. The only exception here is in the case of links placed within paragraphs.

      Additionally, tiny targets measuring less than 44 pixels in width or height should have at least 44 pixels high and side selection area. It is also okay to offer users a means to enlarge elements to at least 44 pixels in width and height.

      How this guideline affects people with disabilities

      This allows everyone visiting the website to conveniently click on any user interface component. Not just those born with mobility impairment benefit from this success criterion.

      Even aging leads to loss of motor control, making it difficult for users to click anything they want on mobile devices. It is especially beneficial to those with more giant fingers or poor hand and eye-coordination.

    • 5. Guideline 3.2.6 Consistent Findable Help (A)

      This success criterion stipulates that any human contact details, like phone numbers, chatbots, and emails, should be located in the same place on all web pages. This applies both visually and codewise.

      How this guideline affects people with disabilities

      This new guideline was necessary because there is always the chance of something going wrong when a visitor is on a site. And they will want to contact the website owner. In this case, the easier it is for them to do so, the better their web experience will be.

      Besides, the easier and quicker they find the contact information, the easier it will be for customer service to help them. Even if a user does not need immediate help, just knowing there is help nearby boosts their confidence.

    • 6. Guideline 3.2.7 Visible Controls (Level AA)

      This new success criterion in WCAG 2.2 requires that web owners not hide critical controls to a process behind a hover or focus state. For example, an app or website should not have checkout buttons that appear only if the user hovers over its text.

      The best way to determine whether critical controls are easily accessible is through usability testing. Testing helps you detect actions that will slow down or make a user’s web experience terrible.

      And to best achieve this, it is always better to have people with various technical capabilities, like experts and novices, do the testing.

    • 7. Guideline 3.3.7 Accessible Authentication (A)

      To ensure web accessibility, you must make your visitors’ web experience as convenient and comfortable as possible.

      So instead of forcing users to remember and manually type in passwords for authentication, users should be permitted to copy and paste passwords into form fields.

      They should alternatively be allowed to:

      1. Use password managers.
      2. Use their device face scan for the authentication process.
      3. Use OAuth to authenticate third-party providers.
      4. Use a USB two-factor authentication method where users can press buttons instead of typing unique codes.
      How this guideline affects people with disabilities

      The idea is to offer many ways to authenticate the process so that users can find one way that works best for them. This helps users with cognitive disabilities because online interactions end up twice as fast and half as stressful.

      Besides, the more accessible visitors can log in, the easier it is to secure accounts from third parties.

    • 8. Guideline 3.3.8 Redundant Entry (A)

      With this success criterion, web owners must limit users’ time to re-enter the same information while filling out forms. For example, users should not have to re-enter the shipping and billing address if they are the same.

      Instead, it is better to code the web page to auto-populate fields with any data the user has stored in the browser where possible. The only exception to this rule is in the case of essential re-entering of data, like while validating passwords for security verification.

      How this guideline affects people with disabilities

      The benefit of this guideline is the improved web experience it offers. For example, users with disabilities depending on assistive technologies like screen readers may find it challenging to use slower on-screen keyboards, imperfect voice dictation, and websites that log out slow users.

      By letting users enter information only once, users experience a faster and less stressful web experience. Besides, it gives users the time and capacity to ensure they enter accurate and complete information.

    WCAG working drafts help web developers plan for updates

    With these new success criteria greatly enhancing users’ experiences through proper access to resources and various assistive technologies, developers can plan updates based on WCAG 2.2.

    And even though there is a chance of the draft changing before publication, developers know that the new criteria will become a final recommendation after the official release.


    With so much revolving around web content accessibility guidelines and web accessibility, many of our visitors constantly ask us related questions.

    Here are a few of the most frequently asked questions and answers we get.

    • 1. What are WCAG 2.2 guidelines?

      WCAG 2.2 guidelines define how web developers and web owners should make web content more accessible to users with disabilities. Web accessibility should be easy and convenient for users with a wide range of disabilities, including language, learning, neurological, visual, cognitive, and speech disabilities.

    • 2. When did WCAG 2.2 come out?

      The WCAG 2.2 was still a working draft when written, and only a candidate recommendation snapshot was released on September 6th, 2022. The first public working draft and additional supporting documents are yet to be made public, and its expected release date is December 2022.

    • 2. Is WCAG 2.1 a legal requirement?

      Yes, WCAG 2.1 is a legal requirement for federal agencies and their contractors. However, it is not precisely legally required for private businesses. Private businesses do not have to comply with specific standards, but their websites must be accessible.

    • 3. Who does WCAG 2.1 apply to?

      The W3C accessibility guidelines working group created the WCAG 2.1 to improve accessibility guidance for three major groups of people. And these people are users with:

      • Low vision
      • Cognitive or learning disabilities
      • Disabilities that make using mobile devices challenging

    Wrapping things up

    There is no doubt that there are some significant differences between WCAG 2.1 and 2.2, which may initially seem somewhat overwhelming. However, web owners and developers must continue testing their websites and apps to ensure continual web compliance for users of assistive technology.

    With constant evaluation, you can ensure you do not miss anything critical in web compliance. You, in the process, will also know that your digital product is up to date and conforms with the latest WCAG version.

    This is especially important because the WCAG is not final, and the W3C will constantly update even the final version as technology advances.

    We at ADA Site Compliance can help ensure your website or app remains web compliant. We provide web compliance using various strategies like a digital accessibility cognitive function test to detect accessibility issues in digital products.

    Our team of accessibility professionals will not just guide you on removing any obstacles you may have in your digital product. They will also help you take a proactive stance by teaching you how to avoid these barriers in the first place.

    Share via:

    Speak With An Expert Now


      Protected by reCAPTCHA and the Google Privacy Policy and Google Terms of Service

      Have a question?

      We’re always here to help.