ADA Title II is here. What public colleges should do before April 2027.

The Department of Justice's final rule on the Americans with Disabilities Act Title II is now in force. State and local government entities serving populations of 50,000 or more must conform their web content and mobile apps to WCAG 2.1 Level AA by April 26, 2027. Smaller entities have until April 26, 2028. For a USG institution, an HBCU operating under a state system, or any public college covered by Title II, this is the deadline you build a remediation plan against.

This post is what we tell incoming higher-ed clients before we touch their CMS.

What Title II actually requires

The final rule, codified at 28 CFR Part 35, points at WCAG 2.1 Level AA as the substantive technical standard. Two practical implications:

1. It's not a Section 508 retread. Section 508 also points at WCAG 2.0 AA (and as of the 2018 Revised 508 Standards, WCAG 2.0 Level AA), but Section 508 applies only to federal agencies and their contractors. Title II is broader: it covers state and local government, including state university systems. Most USG institutions are squarely in scope.
2. WCAG 2.2 AA is equivalent facilitation. WCAG 2.2 was published as a W3C Recommendation in October 2023 and adds nine success criteria on top of 2.1, including new focus-management, dragging, and target-size requirements. USG's accessibility guidance accepts WCAG 2.2 AA as equivalent facilitation. Delivering 2.2 demonstrates a higher posture without breaking compatibility.

The rule covers "web content," which DOJ defines broadly: marketing sites, application portals, course catalogs, student-services pages, and most institutional digital touchpoints. Third-party content embedded in your site (Slate forms, video players, social embeds) is in scope to the extent you can substantially affect their accessibility.

What "conformance" looks like in practice

Conformance is not a sticker on the homepage. It's a documented, defensible, ongoing posture across four working surfaces.

1. Automated baseline

axe-core or Pa11y running in CI on every PR, gated to fail the build on any serious or critical violation. Lighthouse Accessibility scored at 100 on a representative set of pages (home, hub, program detail, application form, contact). This catches roughly 30 to 40 percent of WCAG issues, not all of them. Don't believe anyone who tells you the automated baseline is sufficient.

2. Manual verification

WAVE manual scan of the same gated page set. A keyboard-only walkthrough of every primary user flow (Find a program, Request information, Start an application, Find a contact). Screen-reader walkthroughs on VoiceOver (macOS, iOS) and NVDA (Windows). At minimum quarterly post-launch, more often during active development.

3. Documented contracts

The deliverables procurement reviewers ask for:

• Public Accessibility Statement at /accessibility-statement, citing the conformance standard, date of last review, contact for reports, and acknowledgement/response timelines.
• VPAT 2.4 Rev 508 (Voluntary Product Accessibility Template), signed by an internal owner and updated when the site changes materially. This is the artifact federal procurement teams cite.
• Accessibility Conformance Report (ACR), which is the published, plain-language version of the VPAT.

The pattern: written commitments, not just code. OCR investigations and procurement audits both run on paper trails.

4. Governance

A working program needs ownership. Pick a person, give them budget and authority, and make their name show up in the accessibility statement. Quarterly internal scan, annual external audit, a procurement-ready posture that doesn't depend on the current marketing team being there.

Where Modern Campus Omni CMS helps and where it doesn't

Most USG sites and a long list of HBCUs run on Modern Campus Omni CMS (also called OU Campus or simply Omni). Omni is accessibility-aware out of the box: heading-order linting, alt-text prompts, contrast warnings in the editor. But conformance depends on the templates and the content authored in.

Where Omni helps:

• Template-level constraints. If your component library locks contrast, focus rings, and landmark roles into the markup, content authors can't accidentally violate them.
• Editor affordances. Image uploads prompt for alt text. Heading-order changes raise warnings. Color pickers respect a theme.

Where Omni alone doesn't get you there:

• Decorative drift. Editors apply colors and font sizes outside the system. The page-builder freedom that makes Omni pleasant for editors also makes it possible to fail contrast inside a single page.
• Third-party embeds. Slate forms, Mainstay chatbots, and embedded video players each have their own accessibility profile. Omni doesn't audit them.
• Tabular data and complex widgets. Custom JavaScript inserted into a page (an animated stat band, a multi-step form, a carousel) inherits no a11y guarantees from Omni. It has to be built right.

The right pattern is template-locked, editor-trained, third-party-vetted. Templates that ship at WCAG 2.2 AA. Editor training that builds the habit. Third-party embeds reviewed against the same standard before they go live.

The audit-to-remediation sequence

For an existing site that needs to be ready by April 2027, work backwards from the deadline. A 5-page audit at $2,000 to $5,000 and a 6-to-12-month remediation runway is realistic for most institutions.

Months 1 to 2 — Audit. WAVE + axe + keyboard + screen-reader. Output: severity-tagged finding list, prioritized roadmap, costed remediation plan.

Months 3 to 6 — Critical-tier remediation. Fix every critical and serious finding. Land template-level fixes that cascade across many pages first; one-off page fixes second.

Months 7 to 9 — Major-tier remediation + governance. Fix every major finding. Stand up the CI scan. Train editors. Publish the accessibility statement.

Months 10 to 12 — External audit + ACR publication. Engage a third-party auditor. Resolve any remaining findings. Publish the ACR. Drill the reporting and response process.

Ongoing — Quarterly internal scans. Annual external audit. Material-change updates to the ACR within 30 days of any significant site change.

What we ship to make this defensible

Every higher-ed engagement we lead delivers the following accessibility artifacts:

• Pre-build conformance risk audit
• Component-library a11y guarantees documented in the design system
• axe-core CI integration with gating thresholds
• VPAT 2.4 Rev 508 (or ACR) on the deliverable
• Public accessibility statement on the institution's domain
• Editor training materials and recorded walkthroughs
• Quarterly post-launch scan + remediation budget held in retainer

If you're in a state-system institution and you don't yet have a written accessibility plan tied to April 2027, that's the conversation. We do a 30-minute readiness call. No deck.

Book a 30-minute accessibility readiness call.