WCAG 2.2 vs 2.1 for Sitecore Teams: What Changed and What Authors Actually Break

If you run a Sitecore site for a university, a hospital, or a regulated business, the accessibility deadline is no longer theoretical. Under the Americans with Disabilities Act (ADA) Title II rule, the Department of Justice adopted Web Content Accessibility Guidelines (WCAG) version 2.1 Level AA as the technical standard for state and local government sites. After an extension issued in spring 2026, public entities serving 50,000 or more people, which includes state universities, have to comply by April 26, 2027, and smaller entities and special districts by April 26, 2028. The extension moved the dates. It did not remove the exposure: Title II has prohibited disability discrimination for years, and people can and do sue over an inaccessible site right now, without waiting for either deadline.

I have shipped Sitecore components on regulated pharmaceutical properties, where an accessibility miss is not a backlog ticket but a compliance event, so I want to be precise about two things this article is and is not. It is a practical guide to what changed between WCAG 2.1 and 2.2 and what your content authors will break after launch. It is not a promise that passing an automated scan makes you compliant. Those are different claims, and confusing them is how teams get caught.

What actually changed in WCAG 2.2

WCAG 2.2 is additive. Everything in 2.1 still applies, and 2.2 adds a handful of new success criteria. The legal floor named in the current Title II rule is 2.1 AA, but 2.2 is the current version, the new criteria are where real user pain lives, and building to 2.2 keeps you ahead of the standard rather than chasing it. Four of the additions matter most at the component level, and each has a direct Sitecore consequence.

Accessible authentication is also new in 2.2 and worth knowing, but it lands more on your login flow than on your content components, so I am keeping the focus here on the four above.

The honest summary of the delta: 2.2 is mostly about not breaking orientation and reach for keyboard and touch users. If your 2.1 work was solid, 2.2 is a short list of additions, not a rebuild.

The failures come from authoring, not just code

Here is the part teams underestimate. Most accessibility regressions on a mature Sitecore site are not developer bugs. They are authoring choices, made months after launch by someone who never saw the design review, working in fields your component left wide open. A front-end fix an author can override is temporary. The durable fix is to put the constraint in the CMS so the wrong choice is hard to make.

This table is the one I keep coming back to, because it names where each failure starts and where the real fix lives:

The pattern across every row is the same. You can fix any of these in front-end code once, but if the CMS still lets an author undo it, you will be fixing it again next quarter. So we encode accessibility into datasource fields, rendering parameters, and rich text rules, and where a rule cannot be enforced by a field, we enforce it at render time:

// Refuse to emit an informative image with no alt text
if (model.ImageIsInformative && string.IsNullOrWhiteSpace(model.Alt))
{
  // Log it, show an Experience Editor warning, and do not render the <img>
}

What Axe and Lighthouse can and cannot tell you

Automated tooling is necessary and it is not sufficient. I run both, and I am careful about what I claim from each.

Axe, from Deque, has a rules engine aligned to WCAG, so it is good at catching machine-detectable failures: missing labels, contrast below threshold, invalid ARIA. I run it on Storybook or static fixtures for each library component, on key templates in content management preview and on the delivery side, and in continuous integration (CI) against a small list of URLs after each release. What Axe cannot see is keyboard flow, screen reader verbosity, and whether the content actually makes sense. It will pass a page that is unusable with a keyboard.

Lighthouse is a useful regression signal in CI and a nice trend chart. It is not a legal attestation. A Lighthouse accessibility score of 100 means the automated subset it checks found nothing, not that the page meets AA. Treat a score drop as a stop-the-line signal to investigate, never as proof of compliance. The false confidence a high score creates is its own risk, because it makes teams stop looking.

Neither tool replaces the manual pass. Keyboard-only navigation, a real screen reader on the navigation, forms, modals, and media, and a check that the content reads sensibly are all still human work. On regulated properties I treat that manual pass as the actual gate and the automated tools as the early warning system that keeps the manual pass from finding surprises.

A minimal automated check in CI looks like this, and it belongs on every release, not just launch:

import { injectAxe, checkA11y } from 'axe-playwright'

await page.goto(url)
await injectAxe(page)
await checkA11y(page, null, { detailedReport: true })

A definition of done you can hold a component to

To keep this from being a vibe, we attach a checklist to every component and do not merge it until every line is true:

• Axe is clean on the Default, Active, Error, and Mobile stories, with any known exception documented in the component folder.
• The keyboard script passed and is checked in alongside the component, so the next developer can rerun it.
• Contrast is verified against the design tokens, not a one-off hex value someone pasted in.
• The CMS fields prevent the top authoring failures for that specific component.
• Reduced-motion behavior is verified.

When a component clears that list, it is not just "passing a scan." It is built so that the most likely author mistake is the hard path and the accessible choice is the default. That is the only version of accessibility that survives contact with a real content team over a multi-year site life.

The compliance-pressure reality

Back to where this started. The deadlines are real, the standard named in the rule is WCAG 2.1 AA, and building to 2.2 is the sensible way to clear that bar with margin. But the deadline is the floor, not the goal. On the pharma sites I have worked on, the driver was never the calendar. It was that a real person using a screen reader could not complete a task, and that is both the legal risk and the actual point. Fix it at the CMS layer, prove it with a keyboard and a screen reader, and use the automated tools to keep it fixed.

Further reading

This piece is adapted, with permission, from Mohd Naeem's WCAG 2.2 AA for Sitecore Components, which goes deeper on the render-time validation sketches and the full delivery pipeline. The checklist above is available as a free, structured WCAG 2.2 AA quick reference and component checklist. If your components are being generated by AI tools, the same failures show up at scale, and the review checklist for AI-generated UI covers how to catch them. For the platform-and-partner picture around all of this, see the enterprise CMS pillar.