The flagship is fine. The edges are not.
Ask a web director about their main site and you will usually hear a confident answer. It was redesigned recently. It runs on a supported CMS. Someone owns it.
Ask about the research center that launched its own WordPress install in 2018, the summer program microsite, or the county department that hired a local designer, and the answer gets quieter. Those sites are on your domain. Under Title II, they are very likely your institution’s web content.
On April 20, 2026, the Department of Justice extended the Title II web and mobile app compliance dates. State and local government entities with a total population of 50,000 or more now have until April 26, 2027. Entities under 50,000, and every special district government, now have until April 26, 2028. The technical standard did not change: WCAG 2.1 Level AA. Source: the DOJ interim final rule extending the Title II compliance dates (91 FR 20902).
Why these sites go unseen
They were built for good reasons. A department needed something fast and the central team had a backlog. A grant required a site. A vendor offered to host one. Nobody did anything wrong. But over a decade, those decisions add up to an estate that nobody can count.
Common traits:
- Outdated CMS versions or plugins.
- No named owner since the person who built it left.
- Themes that were never tested for accessibility.
- PDFs uploaded directly with no tagging.
- Not in any central inventory or scan.
Step one: find them
Start with what you have: DNS records, SSL certificates, hosting accounts, analytics properties, and search results for your domain. Ask finance about recurring payments to hosting and website vendors. Ask deans and directors directly.
For estates that span dozens or hundreds of properties, a discovery tool is faster and keeps the list current. KWALL implements Accorbis for this purpose; see how KWALL implements Accorbis. Whatever the method, the output is the same: a list with an owner, a platform, and a status for every site.
Step two: decide what each site is for
Not every site deserves remediation. Some should be retired. Some should be merged into the main site. Some should be rebuilt on a supported starting point. A short decision for each saves months of fixing things nobody needs.
Retire
Expired programs, past events, and duplicate content. Archive properly and redirect.
Merge
Small sites that would serve users better as a section of an existing site.
Fix in place
Active sites with real audiences and an owner willing to keep them current.
Rebuild
Sites on unsupported platforms where fixing is more expensive than starting fresh.
Step three: put a gate on new ones
The estate will grow again unless new sites have a path that is easier than going around the web team. That path should include an accessible starting theme, a named owner, and a review before launch.
A hypothetical: the lab site nobody remembered
Imagine a university research center that launched a site for a grant years ago. The faculty member who built it has retired. The site still lists events, publishes PDFs of reports, and has a contact form that emails an inbox nobody checks. A member of the public who uses a screen reader cannot get past the form. When the complaint arrives, the central web team learns the site exists.
That site was always the institution’s responsibility. The only thing that changed is that someone found it.
A first-week checklist
- Export DNS records for every domain you own and list each subdomain.
- Pull SSL certificate records to catch hosts DNS does not show.
- Ask finance for recurring payments to web hosts, agencies, and site builders.
- List every analytics property tied to your organization.
- Email deans, directors, or department heads asking what sites they run.
- Record each find with URL, platform, owner (or “none”), and last update date.
Decision criteria for each site
Use the same questions for every site so decisions are consistent and defensible:
- Does a current audience depend on it?
- Is there a named owner willing to maintain it?
- Is it on a supported platform with supported software?
- Would its content serve users better inside another site?
- Is the cost of fixing it lower than the cost of rebuilding it?
A site with no audience and no owner is a retirement candidate. A site with both, on a supported platform, gets fixed in place.
Frequently asked questions
Are sites hosted by a third-party vendor still our responsibility?
Generally, content you provide or make available through contracts can still be covered. Review the rule’s third-party provisions with counsel.
What about student organization sites?
It depends on your relationship to the content. Treat this as a legal question and document the decision.
How long does discovery take?
It depends on the size of the estate and the tools. Start now so the answer does not decide your timeline for you.
Do we need a new CMS to govern all these sites?
No. Governance can sit above the platforms you already run.
Who should make the retire-or-keep decision?
The site owner and the central web team together, with a documented reason. Leadership should back the criteria so decisions do not stall.
What should happen to a retired site’s content?
Move anything still needed to a maintained site, archive the rest according to your records policy, and redirect the old URLs to the closest live page.
Next step
If you suspect your estate is bigger than your inventory, tell us what you are working on.
