What’s new in WCAG 2.2

employees checking website for WCAG 2.2 compliance

The latest version of the Web Content Accessibility Guidelines (WCAG), WCAG 2.2, is now a W3C recommendation. With this official recommendation from W3C, WCAG 2.2 is stable and ready for developers to implement successfully. 

Before you become too alarmed at the need to learn more about WCAG 2.2 standards, know that  it is not considered a major update. As such, if your website already conforms to WCAG 2.1, then you should not have too many changes (if any) to implement in order to comply with the latest WCAG standard.

We are already receiving a lot of questions about this new web accessibility standard, and we are happy to provide the WCAG 2.2 checklist and all of the answers that you need in order to provide a website that is fully accessible and follows guidelines.

Is WCAG 2.2 backwards compatible with previous versions of WCAG?

Web Content Accessibility Guidelines (WCAG) 2.2 is almost completely backwards-compatible which means that it builds on previous versions. However, there is one exception. WCAG Success Criteria (SC) 4.1.1 Parsing is obsolete and removed from WCAG 2.2.

Although Parsing is removed, this does not mean that the accessibility addressed in SC 4.1.1 will not continue to be addressed. The goal of SC 4.1.1 was to ensure that assistive technologies could parse HTML correctly. In other words, if the HTML was implemented correctly according to HTML specifications, assistive technologies were not able to interpret the structure correctly.

With today’s advancements in technology, assistive technology no longer needs to directly parse HTML. If any problems still exist without this requirement, they are already addressed by other success criteria. 

How many new success criteria are added in WCAG 2.2?

WCAG 2.2 adds nine new success criteria:

  • 2 level A criteria
  • 4 level AA criteria
  • 3 level AAA criteria

With the addition of these nine new success criteria (and one removal), WCAG 2.2 has 86 success criteria.

WCAG 2.2 checklist: What are the new success criteria added?

The new success criteria added to WCAG include:

This checklist will explain each of the new WCAG 2.2 success criteria and why they are important.

2.4.11 Focus Not Obscured (Minimum) (AA)

Focus Not Obscured (Minimum), WCAG 2.2 level AA requirement, says that when an item receives keyboard focus, it is always at least partially visible.

Why it’s important

Sighted keyboard users rely on keyboard focus to navigate a web page. Keyboard focus indicators such as outlines and borders allow the user to see where their focus is. When the focused content is not visible, users cannot see where their focus is, and the user may not know how to proceed or think that their system is locked up.

To see keyboard focus in action, use the keyboard to tab through the active elements of this page. Notice the outline that you see on each active element as you tab through.

Common places where we see focus obscured are sticky headings, sticky footers, and non-modal dialogs. These elements will often cover up parts of the page including the item that currently has focus.

2.4.12 Focus Not Obscured (Enhanced) (AAA)

While the WCAG 2.2 AA Focus Not Obscured success criteria requires that the item is always at least partially visible, the AAA Focus Not Obscured (Enhanced) criteria requires that all of the item and its focus indicator must be fully visible. 

2.4.13 Focus Appearance (AAA)

Focus Appearance is a AAA success criteria that requires focus indicators to be fully visible when an item receives focus. The focus indicator must

  • Be at least a two-pixel wide perimeter of the unfocused component or sub-component
  • Provide a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states

This new WCAG 2.2 success criteria includes two exceptions:

  1. The focus indicator is determined by the user agent and cannot be adjusted by the author, or
  2. The focus indicator and the indicator’s background color are not modified by the author.

Why it’s important

Keyboard users rely on focus indicators to follow their focus through the active elements of a page. By ensuring that the focus indicator is large enough and provides sufficient contrast against the unfocused state of the element, we help a variety of users including 

  • Low-vision users who require sufficient contrast to see the change
  • Users with cognitive or memory impairments who may be easily distracted or forget where their focus is currently located

2.5.7 Dragging Movements (AA)

Dragging movements are defined as an operation where the pointer engages with an element on the down-event and the element (or a representation of its position) follows the pointer until an up-event. This includes drag and drop actions.

The Dragging Movements success criteria, included in the latest version of WCAG,  requires that in addition to using a mouse for dragging movements, allow the operation to be achieved with a single pointer alternative. 

The exception to this requirement is that if the dragging is considered essential or the functionality is determined by the user agent and not modified by the author, then the single pointer option is not required. The functionality is considered essential if the information or functionality of the content would fundamentally change if the operation was removed and it cannot be achieved in another accessible way.

Why it’s important

Some people cannot use a mouse to drag items. Consider a user with hand tremors or another motor disability. They may not be able to hold a mouse steady enough to move the item to where it needs to go.

Consider a list of items that a user needs to reorder. The functionality is provided by allowing the user to drag and drop each list item. Provide the same functionality using a single pointer action. If the user clicks or taps the list item, provide up and down arrows that the user can select to move the items. 

2.5.8 Target Size (Minimum) (AA)

Target size refers to the amount of space a target (link, button, etc.) takes up. The size of a target must be at least 24 by 24 CSS pixels. The target size criteria has some exceptions.

  • Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
  • Equivalent: The function can be achieved through a different control on the same page that meets this criterion;
  • Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target 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 or is legally required for the information being conveyed.

If this one sounds familiar, it may be because, at level AAA, a minimum target size was already required in WCAG 2.1. To meet level AAA conformance, the target must be at least 44 by 44 CSS pixels.

Why it’s important

Have you ever tried to select a small button or link with a mouse or on a touch screen but just can’t seem to tap the right spot? It either seems like nothing is happening or you select the wrong item. This is likely because the target size of the active element is not big enough. This is especially hard for people who struggle with fine motor skills. 

By allowing a minimum amount of space between targets, it reduces the chance of a user selecting the wrong item.

3.2.6 Consistent Help (A)

Offer help and be consistent where you offer it. Consistent help requires that if you offer help and the mechanism to access that help is located on multiple pages within a set of web pages, ensure that the mechanism is located in the same place on each page. This criteria applies to help offered as 

  • Human contact details
  • Human contact mechanism
  • A self-help option
  • A fully automated contact mechanism

Note that this new WCAG 2.2 success criteria does not require that you provide access to help. It only requires that if you do provide access, then be consistent with where you provide it.

Why it’s important

Consistency is especially important for users with cognitive disabilities. By providing access to help in the same place on each page, users can easily find the help that they need since it is where they expect it to be.

For example, if you provide contact information in the footer of your website, ensure that it is included in the footer of every page.

3.3.7 Redundant Entry (A)

When collecting information from a user, don’t ask for the same information more than once unless the information can be auto-populated or is available for the user to select.

Exceptions to this success criteria apply when 

  • Re-entering the information is essential (for example, verifying a new password)
  • The information is required to ensure the security of the content
  • Previously entered information is no longer valid.

Why it’s important

Some people with cognitive disabilities have difficulty remembering what they have already entered.

3.3.8 Accessible Authentication (Minimum) (AA)

Don’t rely on cognitive function tests to complete an authentication process unless that step provides at least one of the following:

  • Alternative: An alternative authentication method that does not rely on a cognitive function test
  • Mechanism: A mechanism to assist the user in completing the cognitive function test
  • Object recognition: A cognitive function test to recognize objects (such as CAPTCHA)
  • Personal content: A test to identify non-text content the user provided to the website

A cognitive function test is anything that requires users to remember, manipulate, or transcribe information. This includes and is not limited to

  • Remembering information such as a username and password
  • Typing (transcribing) characters
  • Using correct spelling
  • Performing calculations
  • Solving puzzles

Why it’s important

Users with cognitive issues such as memory impairments or dyslexia may find it difficult or impossible to remember a password or solve a puzzle. 

3.3.9 Accessible Authentication (Enhanced) (AAA)

The level AAA requirement for accessible authentication is essentially the same as the level AA requirement except that it only allows cognitive function tests if the user is provided an alternative method or a mechanism to assist with the test. There is no exception for object recognition or personal content.

Is there a legal requirement to Implement WCAG 2.2 Standards?

While legal complaints often reference WCAG conformance, it  is a global web accessibility guideline and not a law (in any country that we know of). 

Our experience in the legal landscape is that if a website or other digital content such as a PDF document complies with WCAG, it is accessible and conforms to laws such as the Americans with Disabilities Act. So while WCAG is not a law, it is still the recommended standard to follow for legal accessibility compliance.

Does Be Accessible test for WCAG 2.2 conformance?

Yes! It is our goal to always provide the latest and greatest accessibility services. Our team has been watching WCAG updates closely to ensure that we provide full understanding and accurate testing to all success criteria as soon as they are recognized as a final official recommendation.

As digital technology continues to evolve, we welcome updates to accessibility guidelines. We recognize that by updating digital content to conform to WCAG 2.2 standards, we provide the most inclusive environment available.

Avatar for David Gevorkian

By David Gevorkian

David Gevorkian started Be Accessible because of his passion for delivering exceptional customer service. Prior to Be Accessible, he spent much of his early career working for financial institutions in sales, treasury, and product management. David earned his Master’s in Business Administration from Salve Regina University in Newport, Rhode Island. He discovered a common need for web and mobile accessibility during his previous roles, and as a result, he created Be Accessible to make accessibility in reach for any type of business. David is a strong advocate for creating aesthetic and accessible products usable by all people across the world.

Contact Us

Please complete all fields.

Recent Posts

animated woman working on a laptop and creating social media posts

Guidelines to Make Your Social Media Posts Accessible

Find out our checklist for social media accessibility. Learn the best practices to create accessible social media posts and reach every customer.

Read more about Guidelines to Make Your Social Media Posts Accessible
animated mobile phone with accessibility icon

Guide to Mobile App Accessibility Standards

Wondering how to make your app accessible that complies with ADA and WCAG? Read our checklist about accessibility standards for mobile apps.

Read more about Guide to Mobile App Accessibility Standards
Animated man and a woman showing an envelope with accessibility icon inside it

Email Accessibility: Guidelines & Best Practices

Incorporate the best practices to create accessible emails. Follow our guidelines for designing ADA-compliant emails for every campaign.

Read more about Email Accessibility: Guidelines & Best Practices