WCAG 2.2: Practical steps for teams and organizations

WCAG 2.2: Practical Steps for Teams and Organizations

WCAG 2.2 introduces nine new success criteria, aimed mainly at mobile, motor, and cognitive accessibility, so it's not worth putting off. Target level AA, and start with the criteria that most affect key user journeys, such as login, payment, and forms. The recommendation itself isn't law, but through the EN 301 549 standard and European legislation, it's gradually being built into legal requirements. Whoever starts now avoids having to fix things later under deadline pressure.

In short:

• To upgrade to WCAG 2.2, it's advisable to start with fixes that have the biggest impact on critical user journeys, such as login and checkout, and roll them out gradually.
• The core new criteria include improvements around focus visibility, target size, and increasingly important accessibility around login, including biometric and password-manager systems.
• Applying the new guidelines isn't immediately mandatory, but legal practice is already cautiously building in requirements from EN 301 549 and European legislation, so delaying isn't advisable.
• During implementation, manually checking focused elements, modal windows, and critical forms is essential, since automated tools don't catch every issue.
• Moxy Web recommends building accessibility in from the start of a project, using both automated and manual testing, and offers support with planning, implementation, and documenting compliance.

Table of Contents

• What WCAG 2.2 is, and why it matters now
• A deeper look at the most important new criteria
• Legal context: EN 301 549, the EAA, and Slovenia's ZDSMA
• A practical plan for teams: how to roll out and prioritize changes
• Checking compliance: tools, manual reviews, and user testing
• How we approach rolling out WCAG 2.2 at Moxy Web
• How Moxy Web can help with implementing accessibility
• Sources
• Frequently asked questions

What WCAG 2.2 is, and why it matters now

WCAG stands for the Web Content Accessibility Guidelines, prepared by the W3C, the international consortium that sets technical standards for the web. WCAG 2.2 is this consortium's official recommendation, adding nine new success criteria while maintaining full compatibility with versions 2.1 and 2.0 — meaning everything a site already met remains valid.

The new criteria aren't a random addition — they're a response to years of accumulated experience from users navigating by keyboard, touch, or assistive technology. The focus falls on three areas: easier operation on mobile devices, less demanding motor skills for clicking and dragging, and clearer support during login and filling out forms. Understanding WCAG 2.2 explains the intent, the user benefit, and common implementation techniques for each criterion, a good first stop before making changes to your site.

For organizations, this means one thing: it's an upgrade to existing work, not a fresh start from zero.

A deeper look at the most important new criteria

Six criteria from WCAG 2.2 most often require changes to design and code:

• Focus Not Obscured (2.4.11/2.4.12): an element that has keyboard focus must not be partially or fully hidden by a sticky header, chat window, or cookie banner.
• Target Size (2.5.8): clickable elements should be at least 24 x 24 pixels, except when they're sufficiently spaced from neighboring targets or have an equivalent alternative.
• Dragging Movements (2.5.7): every action requiring dragging (a slider or rearranging elements, say) must also have a click- or key-based alternative.
• Accessible Authentication (3.3.8/3.3.9): login must not require solving a cognitive task alone, such as transcribing distorted text, with no alternative like a password manager or biometrics.
• Consistent Help (3.2.6): a help contact, chat, or phone number should appear in the same location on every page where it's present.
• Redundant Entry (3.3.7): information a user has already entered during the same process shouldn't be required again, except when necessary for security reasons.

In practice, the most common mistakes are modal windows covering a focused button, small delete icons in tables, and login forms with no alternative to a CAPTCHA. The fixes are often small: enlarging the clickable area with extra padding instead of changing a button's visual size, or adding a keyboard alternative to dragging with the right ARIA labels, as Understanding WCAG 2.2 explains.

Pro tip: When testing modals, check whether the element focus has just moved to stays fully visible above a cookie banner or sticky header, since this is a key accessibility criterion in the early version of WCAG 2.2.

Legal context: EN 301 549, the EAA, and Slovenia's ZDSMA

WCAG on its own isn't law — it's a technical recommendation from the W3C. It gains legal weight through the standards and directives that reference it, so it's worth understanding where the connection currently stands between the new version and your organization's obligations.

• The harmonized European standard EN 301 549 currently references WCAG 2.1, while updating it to WCAG 2.2 in an officially harmonized form is still underway, so organizations can adopt the new criteria preventively, even before they become formally required.
• The European Accessibility Act (EAA) extends accessibility obligations to private service providers as well, including ecommerce, banking, and transport services, with June 28, 2025 being an important deadline for certain services.
• Under domestic legislation, Slovenia's ZDSMA requires public-sector entities to publish an accessibility statement, respond to user complaints, and exposes them to regulatory oversight with corresponding penalties for non-compliance.

The takeaway is simple: whoever waits for the official standard update risks doing this work under time pressure, instead of on their own schedule.

A practical plan for teams: how to roll out and prioritize changes

Rolling out WCAG 2.2 works best across five steps, which a team can spread over several sprints:

1. Inventory your pages and applications, flagging key user journeys such as login, checkout, and form submission.
2. Run an automated tool for a quick scan, catching obvious mistakes such as insufficient contrast or missing field labels.
3. Manually review critical paths with a keyboard and screen reader, since automated tools don't catch every new criterion — obscured focus, for instance.
4. Include brief user testing with people who actually use assistive technology or have motor limitations.
5. Roll out fixes by priority, and cover them with regression tests so the mistakes don't come back with the next update.

When scheduling the work, address critical user journeys first, then visual focus and touch targets, and treat authentication as the third priority, since it often requires coordination with an external login provider. You can fold the Target Size and Consistent Help criteria into your definition of done and PR checklist, so they become part of routine work rather than a special initiative.

Pro tip: Add a single line about accessibility to your issue template, so developers see the criterion before they even start writing code.

Checking compliance: tools, manual reviews, and user testing

Automated tools reliably catch missing labels, low contrast, or incorrect heading structure, but they don't catch whether help is consistently placed across the site, or whether focus is actually visible in every state of the interface. That requires a manual review with a keyboard and screen reader.

• Manually check modal windows, sticky elements, sliders, and login forms, since that's where the most common mistakes against the new criteria show up.
• Organize brief testing with users who actually use assistive technology, and log the specific obstacles they run into, not just general impressions.
• An accessibility statement should include the scope of testing, known exceptions, and a contact for reporting issues, as ZDSMA expects from entities it covers.

The W3C notes that techniques are only a recommended way of meeting a criterion, not a legally binding requirement, so judging the intent of a criterion matters more than mechanically following a list of techniques.

How we approach rolling out WCAG 2.2 at Moxy Web

On our projects, we use automated scans, manual testing with a keyboard and screen reader, and checks against real user journeys, since that's the only way to surface mistakes that tools alone don't catch. Before requesting a quote, prepare your site's address, a list of key user journeys, and any existing findings you have, since this speeds up the first conversation.

— Ziga

How Moxy Web can help with implementing accessibility

Accessibility isn't a one-time fix — it's part of how a site is built from the start, which is why at Moxy Web we treat it as an integral part of the build, not an add-on at the end. We can help assess your existing site, prepare a concrete roadmap based on the priorities described above, implement changes in the code, and draft an accessibility statement.

For an initial conversation, prepare your site's address, a list of key user journeys, and any existing testing findings you may have. You'll find more about our website building and maintenance services on our services page, where you can also get in touch.

Sources

For further reading, we recommend WCAG 2.2, the W3C's explanations, EN 301 549, and domestic resources on ZDSMA. Accessibility also has a positive effect on search visibility, covered in more detail in this overview of the link between accessibility and SEO. For further steps, also see the website-building checklist and the guide to accessibility for business owners.

• Directive (EU) 2019/882 (European Accessibility Act)
• Web accessibility directive: standards and harmonisation
• Gov

Frequently asked questions

What is WCAG 2.2, and how does it differ from earlier versions?

WCAG 2.2 is a recommendation from the W3C consortium that adds nine new success criteria to the existing web content accessibility guidelines. It stays fully compatible with WCAG 2.1 and 2.0, so previous accessibility work remains valid, supplemented by requirements for mobile and motor accessibility.

Is WCAG 2.2 a legally binding standard?

WCAG 2.2 on its own isn't law — it's a technical recommendation. It becomes legally relevant through the EN 301 549 standard, which currently references WCAG 2.1, while incorporating the newer version is still underway.

Which WCAG 2.2 criteria are most urgent for teams?

It's worth addressing the criteria that affect critical user journeys first, such as Focus Not Obscured, Target Size, and Accessible Authentication. These directly affect login, payment, and filling out forms, so they deliver the most benefit relative to the effort invested.

What does the European Accessibility Act say about deadlines?

The European Accessibility Act extends accessibility obligations to private service providers, with June 28, 2025 being an important deadline for certain services, such as ecommerce. The scope of the requirements varies by type of service, so it's worth checking whether your business falls within them.

Can Moxy Web help prepare an accessibility statement?

Yes — Moxy Web can help assess where you stand, prepare a roadmap, and implement the changes that form the basis of an accessibility statement. To start the conversation, it helps to prepare your site's address and a list of key user journeys; you can find out more on our services page.

Recommended

• What Are Design Standards: A Guide for Businesses
• The Digital Strategy Creation Workflow: A 2026 Guide
• UX Design Best Practices for Digital Professionals
• A Website-Building Checklist: A 2026 Guide