How to Meet WCAG 2.2 AA on Drupal: A University Checklist

For a US public university running Drupal, WCAG 2.2 AA conformance is a governance problem first and an engineering problem second. Drupal core is already built to the standard. What decides whether an institution meets the deadline is the operating model around the platform: how brand variation is constrained across departmental subsites, which accessibility checks are built into the editorial workflow, what gates are placed on third-party procurement, and how regressions are caught before they ship.

This guide is the working sequence Vardot uses on US higher-education Drupal engagements. As a Drupal Diamond Certified Partner and one of the most active US firms in higher-ed Drupal, we have run variations of this work on flagship institutional sites, college subsites, and 200+ departmental multisite footprints.

Image

What success looks like at WCAG 2.2 AA on Drupal

A university Drupal estate that holds WCAG 2.2 AA across hundreds of editors and dozens of subsites has, in our experience, a consistent shape:

• An accessible base theme, Olivero, or an Olivero-derived institutional theme with brand variation constrained to a pre-validated palette of CSS tokens.
• CKEditor 5 text formats locked down so editors can't introduce inaccessible markup.
• Editoria11y running in the editor and axe-core running in CI, catching most regressions before they merge.
• AI-assisted alt text at content entry, with human review on every save.
• Layout Builder and Views patterns governed centrally, not audited per subsite.
• Third-party tools and LMS embeds are gated at procurement on a VPAT (Voluntary Product Accessibility Template) or ACR (Accessibility Conformance Report).
• A published accessibility statement and a monitored feedback channel, a dedicated email or form owned by a named, accountable individual or team.
• An annual external audit that validates the operating model rather than discovering fundamental gaps.

The checklist below is the sequence that produces that shape.

What's actually new in WCAG 2.2 (and why it matters for Drupal)

WCAG 2.2 adds nine success criteria to 2.1 and removes SC 4.1.1 (Parsing). It's a strict superset, so meeting 2.2 AA also satisfies the 2.1 AA federal floor. Six of the new criteria land at Level A or AA. These are the ones to design and review against:

• 2.4.11 Focus Not Obscured (Minimum)  AA. Sticky headers, cookie banners, and chat widgets can't entirely hide the focused element. This is the most common 2.2 regression we see in departmental themes.
• 2.5.7 Dragging Movements  AA. Any drag interaction needs a single-pointer alternative. This hits map widgets, file uploaders, and sliders.
• 2.5.8 Target Size (Minimum)  AA. Interactive targets must be at least 24×24 CSS pixels, with documented exceptions. Older university templates fail this on icon-only social links and mobile menu toggles.
• 3.2.6 Consistent Help  A. Help mechanisms (contact, chat, FAQ) must appear in the same relative order across pages. That's quite significant for a 50-subsite estate, where the help pattern is rarely owned by anyone.
• 3.3.7 Redundant Entry  A. Don't make users re-enter the same information within a process unless it's essential.
• 3.3.8 Accessible Authentication (Minimum)  AA. No cognitive function tests in authentication unless an alternative is provided. This is relevant to SSO landing pages and admissions portals.

The three AAA additions aren't required for AA conformance, but 2.4.13 Focus Appearance is worth referencing when scoping new theme work.

Across higher-ed Drupal audits, three patterns recur. Theme customizations break what core got right, when custom CSS overrides focus indicators or brand tokens push contrast below 4.5:1. Contributed modules ship without parity with core's accessibility commitment. And editorial content, alt text, PDFs, third-party embeds, and video captioning account for the majority of post-launch findings. The eight steps below address each.

The Drupal WCAG 2.2 AA checklist

The sequence assumes Drupal 10 or 11. Drupal 11 isn't strictly required to hit WCAG 2.2 AA; Drupal 10 with current contrib will get you there. But Drupal 11's CKEditor 5 baseline and the Drupal CMS Accessibility Tools recipe make several steps materially easier.

1. Start from Olivero (or audit your custom theme against it)

Outcome: The institution's base theme becomes an accessibility floor that brand variation cannot fall below. Department rebrands to stop introducing focus and contrast regressions.

Why this matters for universities: Starting from an accessible base and constraining brand variation through CSS variables is cheaper than re-auditing 40 subsites every time a college rebrands.

2. Tighten CKEditor 5 text formats

Outcome: The scope of the contract between the platform and the editor is narrowed. Editors can no longer introduce inaccessible markup, even if they want to.

Why this matters for universities: The text format is the contract with your editors. Tightening it once is more durable than auditing output forever.

3. Install Editoria11y for in-editor checking

Outcome: Compliance moves left from a central web team to the hundreds of decentralized editors who actually create the content.

Why this matters for universities: Roughly 20% of any university's web team owns 100% of the compliance liability for content produced by hundreds of decentralized editors. Editoria11y pushes the easy 60% of issues back to where they're created.

Image

4. Add AI-assisted alt text  with human review

Outcome: The largest single category of remediation cost is backfilling alt text across years of accumulated media drops from a multi-quarter manual project to an editorial review queue.

The non-negotiable is keeping a human in the loop. AI-generated alt text is a starting draft, not a compliance artifact. Vardot's Varbase distribution ships an AI Image Alt recipe that pre-wires this; outside Varbase, the configuration is straightforward.

Why this matters for universities: News archives and photo galleries accumulate thousands of unaltered images. Manual backfill is where remediation budgets disappear. (For how an AI-first CMS configures this out of the box, see our deeper write-up.)

5. Audit Layout Builder and Views patterns

Outcome: Page-assembly patterns are governed centrally. A single fix propagates across admissions, alumni, and research sites rather than being rediscovered with each audit.

Why this matters for universities: The same Card paragraph type appears on admissions, alumni, and research sites, with different content. One bad pattern propagates everywhere.

6. Stand up automated scanning in CI

Outcome: No deploy reaches production without passing an accessibility regression gate. The institution's exposure between audits is bounded.

Set the standard to WCAG 2.2 AA and seed it with your top 30 URLs per content type. Treat the output as a regression gate, not a compliance certificate. Automated tools catch roughly 30–40% of WCAG issues; the rest need manual testing and screen-reader review.

Why this matters for universities: CI scanning is what prevents a well-meaning departmental deployment from silently breaking accessibility across the rest of the estate.

7. Govern third-party embeds and PDFs

Outcome: Accessibility liability for inherited content LMS embeds, vendor widgets, PDF archives, and lecture-capture players moves into procurement and the editorial workflow, where it can actually be controlled.

Federal guidance is clear: the university is responsible for the accessibility of third-party digital content presented on its sites, except in narrow circumstances. Make that explicit:

• Require a VPAT or ACR from every new third-party tool, LMS integration, lecture-capture player, or embedded widget before procurement signs.
• Run a PDF accessibility check before publishing, or maintain a triage queue for unfixable archives. Archived content may be exempt under the DOJ rule, but the bar for invoking the exception is narrow.
• Caption all video content and provide transcripts for audio.
• Install the Decorative Image Widget module to force explicit decorative-image declarations rather than empty alt text.

Why this matters for universities: Most post-launch audit findings live in PDFs, third-party widgets, and uncaptioned videos, not in the Drupal templates.

8. Publish an accessibility statement and feedback path

Outcome: The institution has a documented commitment that signals an articulated process to regulators, auditors, and the public, and the first artifact general counsel will ask for.

Why this matters for universities: Title II expects an articulated process, and the statement is the document that demonstrates one.

What we don't recommend

Accessibility overlay widgets. Tools that inject an "accessibility menu" via a single JavaScript tag do not produce WCAG 2.2 AA conformance. The W3C, accessibility experts, and disability advocates have consistently recommended against overlay-based approaches, and Title II does not accept overlays as a substitute for accessible source content. We would not put one on a public university site.

Treating accessibility as a one-time audit. A pre-launch audit captures a snapshot, and decentralized editorial environments regress within weeks. The defensible posture is continuous: Editoria11y in the editor, axe in CI, a quarterly manual review on top-traffic templates, and an annual external audit.

How we run this on higher-education Drupal engagements

The checklist above is the what. The patterns below are what separate a compliant launch from a compliant estate eighteen months later.

• We sequence by risk, not by site. Rather than remediate subsite by subsite, we fix the shared foundations first: base theme, text formats, page-assembly patterns, so a single change protects the whole estate at once.
• We make the editor the owner, not the bottleneck. In-editor and CI checks put accessibility in front of the people creating content, so the central web team validates rather than triages. Pre-launch audits become a final check, not the moment of discovery.
• We put third-party accessibility at the procurement gate. No VPAT or ACR, no integration. Engineering doesn't own the accessibility of an LMS that is embedded and inherited; procurement does.
• We keep automation accountable to a person. AI accelerates alt text and remediation, but a human signs off before anything publishes.

Where to take this next

Most institutions don't need to be told they have a gap they need to know where it is and what to fix first. Vardot maps the gap by site area, sequences the remediation, and stands up the editorial and CI controls in this checklist.

Omar Alahmed is the Director of Engineering at Vardot, with nearly twenty years of Drupal experience ranging from version 5 to the current core. He specializes in enterprise platforms for higher education, government, NGOs, and mission-driven organizations worldwide, with a core focus on blending optimized performance, robust security, and SEO with strict digital accessibility.