What Changed in WCAG 2.2? A Practical Introduction to the Newly Added Success Criteria for Web Accessibility

In the previous article, we covered what kind of guideline WCAG 2.2 is and why we need to address web accessibility now. In this second article, we will finally take a gentle, practical look at what changed in WCAG 2.2. When you hear that a standard has been updated, you may feel as if the rules have changed dramatically. In reality, WCAG 2.2 builds on WCAG 2.1 and adds more concrete support for areas where people often struggle in real-world use. So rather than thinking “everything we understood before is now useless,” it is more natural to see this update as a way to refine existing efforts into something closer to actual user needs.

What You Will Learn in This Article

• How WCAG 2.2 changed from WCAG 2.1
• The key points of the 9 newly added success criteria
• How to think about the removed success criterion
• Points that should be prioritized in real-world reviews
• Areas where the UUU web accessibility service works well, and areas where it does not

WCAG 2.2 added 9 success criteria to WCAG 2.1 and deprecated 1 success criterion. The basic structure has not changed, and the four principles of “perceivable,” “operable,” “understandable,” and “robust” remain the same. In other words, the items that have always mattered—heading structure, alternative text, keyboard operation, contrast, and proper form labeling—remain important. On top of that, the new additions focus more deeply on everyday UI usability, such as making focus easier to see, avoiding reliance on drag operations, making input easier, reducing burden during authentication, and improving touch target usability. Put another way, WCAG 2.2 is easier to understand as a version that pays even more attention not only to “whether users can perceive something,” but also to “whether they can operate it without confusion” and “whether they can complete tasks without unnecessary burden.”

One major premise to keep in mind is that many of the newly added WCAG 2.2 success criteria are not “advanced future concerns.” They are directly connected to issues already happening on corporate sites, service sites, recruitment sites, municipal websites, e-commerce sites, and registration screens. For example, a fixed header may hide the focused item when a user presses the Tab key; small buttons may be difficult to tap on a smartphone; UIs that rely on drag operations may be hard to use; and login screens may impose complex authentication every time, creating heavy burden. Many readers have probably experienced these situations themselves. WCAG 2.2 identifies these kinds of “common inconveniences” and provides more concrete criteria for improving them.

The 9 Success Criteria Added in WCAG 2.2

Now let us review the 9 newly added success criteria from a practical perspective. You do not need to memorize all of them at once. First, it is important to understand what kind of user difficulty each criterion addresses.

2.4.11 Focus Not Obscured (Minimum)

This success criterion requires that when focus moves through keyboard operation or similar methods, the focused item must not be completely hidden. For example, when a fixed header or sticky menu exists at the top of the screen, a focused button or link may slip underneath it as the user tabs through the page. The user then cannot tell where they are, making it difficult to continue operating the page. In practice, it is important to account for the height of fixed headers in scroll behavior and to check how focus appears. This issue is especially easy to miss in forms, modals, accordions, navigation, and other areas where keyboard operation is common.

2.4.12 Focus Not Obscured (Enhanced)

This is a stronger version of the previous criterion. It requires that the focused item not be hidden by other content. While 2.4.11 asks for the minimum condition that the item is not completely hidden, 2.4.12 more firmly ensures that the focused item remains visible. In practice, many organizations focus on AA compliance first, so it is realistic to prioritize 2.4.11. However, designing from the beginning so that focus is not hidden by overlapping UI elements will usually improve the overall user experience as well.

2.4.13 Focus Appearance

This success criterion requires the focus indicator—the visual sign showing “where the user currently is”—to be sufficiently visible. In modern web production, outlines are still sometimes removed for design reasons, but doing so makes it difficult for keyboard users to understand their current position. Even if a focus indicator technically exists, a thin line or a color that blends into the background may make it practically invisible. In practice, it is important to carefully design focus outlines, background changes, underlines, thickness, and contrast. Design and accessibility are not opposites. A visible focus indicator also creates reassurance and makes operation easier.

2.5.7 Dragging Movements

This success criterion requires that users not be forced to rely only on dragging operations. For example, if a slider value can only be changed by dragging, a map location can only be selected by dragging a pin, or items can only be reordered through drag and drop, the UI may become a major burden for some users. People who have difficulty with fine motor control, people using assistive technologies, and people who primarily use a keyboard may not be able to complete the task at all. In practice, alternatives such as buttons, numeric input, selection-based controls, and keyboard support should be provided. Dragging can be convenient, but it should not be the only available method.

2.5.8 Target Size (Minimum)

This success criterion requires minimum consideration for the size of targets operated by touch or pointer input. On smartphones, when small links or icons are crowded together, mis-taps become more likely. This is an inconvenience experienced by many users, regardless of disability. It has a particularly large impact on older users, people using one hand, and people operating while moving. In practice, it is necessary to check not only the visual size of buttons and links, but also whether the actual tappable area is large enough. Small close buttons, pagination numbers, and card UIs where only a tiny area is clickable are common candidates for review.

3.2.6 Consistent Help

This success criterion requires consistency in the location and discoverability of help functions provided across multiple pages. For example, if contact information, chat support, FAQ links, or help buttons appear in different places on different pages, users may struggle to find the assistance they need. Especially in procedures, applications, and registration flows where anxiety can arise, consistency in help paths greatly affects whether users can continue. In practice, effective basics include unifying help links at the page-template level, placing important support links in the same location, and using consistent wording. It may seem plain, but this criterion strongly supports a stable user experience.

3.3.7 Redundant Entry

This success criterion requires that users generally not be asked to re-enter information they have already provided within the same process. For example, if a user enters their name or address early in an application form and is later asked to type the same information again in a confirmation or separate step, the burden is high and input errors are more likely. This increases cognitive and memory burden and simply takes more time. In practice, possible improvements include carrying over information from previous steps, using autocomplete appropriately, and making confirmation screens easy to edit. This is a criterion where accessibility and UX overlap strongly, because it is fundamentally about not forcing users to do unnecessary work.

3.3.8 Accessible Authentication (Minimum)

This success criterion requires that authentication not impose excessive cognitive function tests on users. For example, asking users to memorize and enter complex strings, select certain items from images, or solve puzzle-like CAPTCHAs can become a major barrier for some users. Security is of course important, but if a security measure prevents people from using the service, it defeats the purpose. In practice, review points include not blocking password managers, not unnecessarily prohibiting copy and paste, providing alternatives, and reconsidering one-time links or multi-factor authentication design. This is a very important perspective for sites that handle login and membership registration.

3.3.9 Accessible Authentication (Enhanced)

This is a stronger authentication-related criterion. It asks, at a higher level, that users be able to authenticate while avoiding cognitive burden as much as possible. Since it is AAA level, it is not mandatory for every project. However, for services where authentication and identity verification are central, it is very useful as a design direction. It is an important theme beyond just a success criterion number when thinking about both user safety and usability.

How to Think About the Deprecated 4.1.1 Parsing Criterion

In WCAG 2.2, 4.1.1 Parsing was deprecated. At first glance, this may make you wonder, “Does that mean we no longer need to care about valid HTML?” But that is not the case. The reason Parsing was removed involves the evolution of modern browsers and assistive technologies. Formal syntax checking alone is no longer as meaningful for judging accessibility as it once was. However, this does not mean HTML structure can be broken. Proper implementation of headings, labels, buttons, links, landmarks, and form elements remains extremely important. In other words, the emphasis has shifted from “syntax for the sake of syntax” to a more practical question: “Is the implementation correctly conveyed to users?”

Points to Prioritize in Real-World Reviews

After reviewing all of this, WCAG 2.2 may feel demanding because several new items have been added. However, priorities in real-world work can be organized fairly clearly. The areas that are easiest to start with and have a large impact are focus-related behavior, tap target size, and form/authentication design. These are areas where issues are relatively easy to find on existing sites, and where improvements are easy for users to feel. Even simple checks—such as operating major user flows with a keyboard, testing button usability on a real smartphone, or checking whether login and inquiry forms require unnecessary re-entry—can reveal many problems.

For example, consider a job application form. A user enters their name, address, phone number, and email address, but the confirmation page is hard to edit; going back clears the input; required fields are shown only by color; the submit button is hidden behind a fixed header when focused; and checkboxes are too small to tap on a smartphone. In this kind of situation, the new WCAG 2.2 criteria become a useful guide for improvement. Standards may look abstract, but in reality they exist to reduce these kinds of concrete inconveniences.

Where UUU Web Accessibility Service Fits Well

Let us also touch on the compatibility with the UUU web accessibility service, which is part of this series theme. Services like UUU that provide browsing support functions—such as text size adjustment, contrast adjustment, line spacing and character spacing adjustment, animation stopping, text-to-speech, translation, and furigana display—are compatible with accessibility as an entry point because they help users move closer to a browsing environment that suits them. Especially for organizations that cannot immediately carry out a full site renovation, these services are also attractive because they make user consideration more visible.

On the other hand, many of the newly introduced success criteria cannot be fully satisfied by simply installing a tool. For example, if focus is hidden behind a fixed header, the page implementation itself must be adjusted. If a UI can only be operated by dragging, alternative operation methods must be designed. Target size problems require changes to the design of the actual buttons and links. Easier authentication and reduced redundant entry also require review of forms and system design. In other words, services like UUU have strong compatibility in the area of browsing support, but many of the implementation and operation requirements added in WCAG 2.2 still require careful improvement of the content and UI itself. Understanding this distinction makes it easier to balance tool-based support with essential improvements.

Summary of Part 2

WCAG 2.2 does not drastically overwrite WCAG 2.1. Rather, it is a guideline that reinforces practical usability in line with today’s web environment. The 9 newly added success criteria are all deeply connected to actual user experience: visible focus, alternatives to drag operations, easier tapping, consistent help paths, reduced redundant entry, and lower burden during authentication. In that sense, this update is also an opportunity to rethink accessibility not as “special accommodation,” but as a foundation for UI that people can use without getting lost.

In practice, it is recommended to first review the main flows of existing sites, especially important situations such as keyboard operation, smartphone operation, form input, login, and authentication. And while support measures such as the UUU web accessibility service are valuable for browsing assistance, it is also important to remember that many of the new WCAG 2.2 requirements can only be met by carefully reviewing the original design and implementation. In the next article, we will focus on why forms become difficult to use and explain the basics of input support and error design with more concrete screen examples.

Reference Links

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI: What’s New in WCAG 2.2
• W3C WAI: Understanding WCAG 2.2
• W3C WAI: How to Meet WCAG 2.2 (Quick Reference)
• WAIC: Web Content Accessibility Guidelines (WCAG) 2.2 Japanese Translation
• WAIC: Announcement of WCAG 2.2 Japanese Translation Release
• WAIC: Resources