How to Build a WCAG 2.2 Compliance Plan for Higher Ed
Most institutions I talk to don't have a WCAG 2.2 problem. They have a planning problem.
The scanner already told them there are 4,000 issues. The vendor demo was impressive. Legal forwarded the Title II rule. And the accessibility coordinator is sitting there with a 90-page PDF, a deadline, and no document that a provost will actually fund.
I spent 21 years inside higher education, including a long run at Quinsigamond Community College, and the gap was always the same: plenty of findings, no plan. So this is the plan — the one you can put in front of a budget committee and defend line by line.
Start with scope, not the scanner
A scanner crawls what it can reach. It does not know that your LMS holds 60,000 instructor-uploaded PDFs, that three departments run their own WordPress sites, or that your application portal is a third-party product you can't edit.
Before you run a single audit, write down the surface:
- Public web — the .edu marketing site, department sites, microsites
- The LMS — course shells, uploaded documents, publisher content
- Applications and portals — admissions, financial aid, the student information system
- Documents — the single largest category, and the one scanners barely see
- Procured software — anything you bought rather than built
You are not assessing all of it this week. You are naming it, so the plan is honest about what's in and what's out. A plan that quietly omits 60,000 documents isn't a plan; it's a liability with a cover page.
Assign an owner to every line
The most common reason a compliance plan stalls has nothing to do with technology. It's that "the website" is owned by Marketing, the LMS by IT, documents by individual faculty, and accessibility by one coordinator with no budget authority over any of them.
For every item in scope, name a human:
- Who fixes it
- Who signs off that it's fixed
- Who pays for the tooling
If you can't name those three people for a category, that category is your real risk — not the contrast ratio a scanner flagged.
Prioritize by harm and reach, not by scanner severity
Scanner "critical" is not the same as institutional risk. A critical-flagged decorative SVG on a low-traffic page matters less than an inaccessible registration form every student must use in week one.
Rank by two questions:
- How many people hit this, and can they route around it? The registration flow, the LMS login, the financial aid form — these have no workaround.
- What's the harm if it fails? A student who can't register has a different problem than a slightly awkward heading order on the alumni page.
This is the part a budget committee understands. "We are fixing the things that block students from enrolling and getting aid, in that order" is a fundable sentence. "We are remediating 4,000 issues" is not.
Put a number on it before someone asks
Every plan dies the same death: someone asks "what does this cost and when is it done?" and there's no answer.
You don't need a perfect number. You need a defensible one:
- Documents priced per page or per batch, at realistic volume
- Web remediation scoped by template, not by page (fix the template, fix 200 pages)
- Training priced per seat for the people who create content
- A monitoring line, because this is not a one-time project
A rough, transparent budget you can walk through beats a precise number nobody believes.
Sequence it against the real deadline
The ADA Title II rule sets concrete dates — the larger-entity compliance date lands in April 2026, with April 2027 for smaller public entities. Which one applies to your institution depends on the governing jurisdiction, and it's worth confirming rather than assuming. (I wrote a separate piece on what the Title II timeline actually means for institutions.)
Work backward from your date. If documents are 80% of your remediation surface — and for most institutions they are — then a timeline that spends six months on the marketing site and three weeks on documents is sequenced backward.
Governance: the part everyone skips
A plan without governance is a project. A plan with governance is a program that survives the coordinator changing jobs.
Minimum viable governance:
- A named accessibility owner with a real reporting line
- A procurement checkpoint so you stop buying inaccessible software
- A recurring review, quarterly at minimum, with a metric you actually track
The institutions that hold up over time are not the ones with the cleanest first audit. They're the ones where accessibility is somebody's named job, with a budget line, reviewed on a calendar.
The shape of the plan
Put together, a defensible WCAG 2.2 compliance plan is nine moving parts: institution profile, scope, current state, priority framework, ownership, budget, timeline, governance, and a review cadence. None of it requires you to be a developer. All of it requires you to decide, write it down, and assign it.
That's the work. The scanner was never the hard part — the plan was.