WCAG 2.2 New Criteria for Healthcare Websites: 9 Changes

WCAG 2.2 is an additive update rather than a completely separate accessibility framework. It retains the WCAG 2.0 and 2.1 success criteria, adds 9 new criteria, and removes 4.1.1 Parsing because it is now obsolete.

For healthcare teams, that distinction matters. A website designed around WCAG 2.1 does not automatically address the new interaction requirements introduced by WCAG 2.2.

The 9 additions are:

Level A

Level AA

Level AAA

These are official WCAG conformance levels. They should not be described as separate "healthcare requirements" simply because healthcare examples make them particularly relevant.

WCAG 2.2 includes the WCAG 2.1 success criteria, except for 4.1.1 Parsing, which was removed as obsolete. W3C describes the update as additive and recommends WCAG 2.2 as a new conformance target, even where formal obligations still reference an earlier version.

That creates three separate questions for healthcare organisations:

Keeping those questions separate prevents teams from turning a technical recommendation into an inaccurate legal claim.

The strongest way to understand WCAG 2.2 is to map each new criterion to an actual patient interaction.

Level: AA

When a keyboard user moves through a healthcare website, the focused component cannot be entirely hidden by author-created content.

Consider an appointment form with a sticky header, floating chat widget, cookie banner, or fixed footer. A patient can successfully tab to a button while still being unable to see which control currently has focus.

Developers should test keyboard navigation across:

One common implementation mistake is testing focus only on a static page. Fixed interface elements can change the result as the viewport changes.

Level: AAA

This criterion applies a stricter requirement. No part of a focused component can be hidden by author-created content.

The distinction matters when your organisation targets AAA accessibility or wants a stronger internal accessibility standard. Do not describe this criterion as an AA requirement simply because 2.4.11 is AA.

In practice, teams targeting enhanced accessibility should test focus visibility across different viewport sizes, zoom levels, and interface states.

Level: AAA

WCAG 2.2 introduces a specific AAA requirement for the appearance of keyboard focus indicators, including requirements concerning indicator size and contrast.

A visible focus state is not necessarily a sufficient focus state. A faint outline that disappears against the surrounding interface can remain difficult to identify.

Healthcare design systems should define focus states as reusable component behaviour rather than leaving each developer to implement them independently.

Level: AA

If functionality requires a dragging movement, the interface needs an alternative pointer input method unless an applicable exception applies.

Healthcare examples include:

For example, a patient should not be forced to drag an appointment block across a calendar when an equivalent selection or keyboard-accessible control can perform the same task.

During healthcare implementations, we look beyond whether a component works with a mouse. The important question is whether the same task remains available through another supported interaction method.

Level: AA

WCAG 2.2 specifies a minimum target size of 24 by 24 CSS pixels for pointer inputs, subject to defined exceptions and spacing conditions.

This affects common healthcare controls such as:

The requirement does not mean every control must literally be 24 by 24 pixels. WCAG defines exceptions, including spacing, equivalent controls, inline targets, user-agent controls, and essential presentations.

A practical design review should therefore measure both the target and its surrounding space. Small controls placed close together can create problems even when each control technically appears usable.

Level: A

Repeated help mechanisms should appear consistently across pages where they occur. Examples can include contact information, support mechanisms, self-help resources, or other assistance mechanisms.

For healthcare services, this can affect patient support, portal assistance, accessibility information, and telehealth technical support.

The implementation issue often starts with different teams placing support controls independently. Establishing help components within a shared design system reduces inconsistent placement across patient journeys.

Level: A

WCAG 2.2 addresses situations where information already entered or provided during the same process is requested again. Where the criterion applies, that information should either be automatically populated or available for the user to select, subject to its defined exceptions.

Imagine a patient enters their date of birth during registration and then encounters the same question again during appointment booking. Requiring unnecessary re-entry creates friction and increases the opportunity for errors.

The same issue can occur with:

The criterion does not mean information can never be requested twice. Security, validity, and other defined exceptions can apply.

A useful implementation approach is to map every multi-step patient journey and identify which values should persist between stages.

Level: AA

This is one of the most important WCAG 2.2 changes for patient-facing healthcare platforms.

The criterion addresses authentication processes that require users to perform cognitive-function tests. WCAG identifies mechanisms such as password-manager support and copy and paste as examples that can reduce cognitive burden.

For a patient portal, review:

WCAG 2.2 does not simply say that CAPTCHA is prohibited. The criterion contains specific requirements, alternatives, and exceptions concerning cognitive-function tests.

That nuance matters because healthcare teams sometimes replace one authentication barrier with another without testing the complete login journey.

For teams researching SC 3.3.8 accessible authentication healthcare requirements, the practical priority is to test whether patients can authenticate without unnecessary memory, transcription, or problem-solving demands.

Level: AAA

This criterion provides a stricter authentication requirement than 3.3.8. It addresses cognitive-function tests and requires an alternative authentication method or a mechanism that assists users with the test.

Healthcare organisations targeting WCAG 2.2 AA should not present 3.3.9 as an AA requirement.

However, AAA requirements can still influence design decisions where patient access, organisational policy, or a higher accessibility target justifies additional controls.

Patient portals concentrate several of the new WCAG 2.2 requirements into a single journey. Authentication, forms, appointment booking, navigation, and mobile interactions can all create barriers.

Based on our healthcare IT experience, five criteria deserve particular attention during portal reviews:

Registration commonly involves several related fields and multiple steps. Review whether information persists correctly, whether errors can be recovered without starting again, and whether keyboard users can complete the entire process.

Authentication deserves more than a visual check. Test password managers, copy and paste, MFA flows, CAPTCHA implementations, focus behaviour, and error recovery.

Calendar interfaces frequently introduce small targets, focus problems, dragging interactions, and repeated data entry.

For mobile booking, review whether dates, buttons, close controls, and navigation elements remain sufficiently separated and usable.

Persistent navigation, floating controls, help mechanisms, and modal interfaces can affect focus visibility and consistent help.

If the portal itself needs redevelopment, Qrolic Health provides accessible patient portal development with accessibility considerations incorporated into patient-facing workflows.

An accessible patient portal should be assessed as a complete journey rather than as a collection of isolated screens.

A WCAG 2.2 review should combine automated tools, manual testing, keyboard testing, assistive technology, and journey-level testing. NHS guidance explicitly recommends automated testing, manual testing, and testing with people, while noting that automated testing covers only some accessibility requirements.

Run the complete patient journey without a mouse.

Check:

Confirm that every interactive control can receive focus and that focus remains visible.

Test sticky headers, cookie banners, chat widgets, modal windows, and fixed footers.

The critical question is not whether focus exists in the code. It is whether the user can identify and operate the focused component.

Review appointment buttons, calendar controls, icons, close controls, and mobile navigation.

Measure target sizes where appropriate, then check spacing and nearby controls against the WCAG exceptions.

Review repeated information, preserved inputs, autocomplete, validation, and error recovery.

A form can technically submit successfully while still creating unnecessary barriers during completion.

Test password managers, copy and paste, CAPTCHA implementations, MFA, and screen-reader compatibility.

The authentication process should be tested from start to finish, including failed attempts and recovery.

NHS guidance also recommends testing accessibility throughout development rather than relying exclusively on a final audit.

If your organisation needs a broader implementation assessment, our healthcare accessibility and WCAG compliance services focus on accessibility requirements across healthcare digital experiences.

Yes. The technical standard and the applicable regulatory position should be considered separately.

For recipients of HHS federal financial assistance covered by Section 504, HHS adopted WCAG 2.1 Level AA as the technical standard for covered web content and mobile applications.

In May 2026, HHS OCR announced a one-year extension to the applicable compliance dates. The revised deadlines are May 11, 2027 for recipients with 15 or more employees and May 10, 2028 for recipients with fewer than 15 employees.

Therefore, a US healthcare organisation should not automatically claim that WCAG 2.2 AA is its legal requirement simply because WCAG 2.2 is the current W3C Recommendation.

There is also an important technical planning point. HHS states that an alternative standard such as WCAG 2.2 AA or AAA may qualify under the rule's equivalent facilitation provision when it provides substantially equivalent or greater accessibility and usability.

Your compliance team should therefore document the legal baseline separately from the engineering target.

Current NHS guidance states that NHS services should meet WCAG 2.2 and identifies 6 of 9 new criteria at A and AA levels as requirements for NHS websites and mobile apps. The remaining three new criteria are AAA.

That makes WCAG 2.2 particularly important for NHS-facing digital teams and suppliers.

Even when your applicable legal requirement references WCAG 2.1, adopting WCAG 2.2 as an engineering target can provide a clearer current accessibility baseline.

The practical benefits include:

The key is to describe this as an engineering and accessibility strategy, not as a universal legal requirement.

Use the following checklist before launching or materially changing a patient-facing healthcare website.

Design

Development

QA

Governance

A WCAG 2.1 implementation does not necessarily require a complete rebuild to address WCAG 2.2.

Start with a structured migration review:

The amount of development work depends on your existing components and architecture.

A mature design system may require targeted component updates. Older platforms with tightly coupled interfaces may need broader changes, particularly around authentication, forms, calendars, and navigation.

Accessibility work becomes more effective when it starts during product design rather than at the final QA stage.

Qrolic Health works on healthcare websites and patient-facing platforms where accessibility considerations intersect with forms, portals, integrations, authentication, content, and patient workflows.

Our approach is to treat accessibility as part of design, development, integration, and QA. That allows teams to identify interaction problems earlier and connect WCAG requirements directly to the components and journeys patients use.

For organisations planning remediation or a new healthcare platform, the goal is not simply to produce an accessibility checklist. It is to establish a practical technical baseline that developers, designers, product owners, and QA teams can maintain.

WCAG 2.2 changes healthcare accessibility primarily through interaction requirements. The most important areas for patient-facing teams include authentication, repeated information, touch targets, focus visibility, and alternative interaction methods.

The 9 new success criteria should be assessed against real journeys such as registration, login, appointment booking, forms, telehealth, and patient portal navigation. At the same time, healthcare organisations must distinguish WCAG's technical guidance from jurisdiction-specific legal obligations.

For US organisations covered by HHS Section 504, WCAG 2.1 AA remains the specified technical standard. NHS guidance currently requires WCAG 2.2 for NHS services.

Treating WCAG 2.2 as part of product engineering and QA gives your team a clearer way to address accessibility before patients encounter barriers.