How to Manage Web Accessibility Across Decentralized University Departments

TL;DR: A university website isn’t one site — it’s hundreds of departmental sites maintained by thousands of contributors who aren’t web professionals. That makes accessibility a governance problem, not a one-time remediation project. The scalable model combines a central authority (policy, single WCAG 2.2 AA standard, training, accessible templates) with distributed responsibility (each unit owns its content), held together by accountability and automated continuous monitoring. Point-in-time audits can’t keep up with content that changes daily across so many owners — monitoring is what makes accessibility sustainable at campus scale.

Most accessibility advice assumes a single website with a small team that controls every page. A university is the opposite. The athletics department, the chemistry faculty, the registrar, the library, dozens of research centers, student organizations, and a central communications office all publish to the same .edu domain — often on different CMSs, with different templates, by people whose job has nothing to do with the web. When OCR or a complainant tests “the university website,” they don’t care which org chart box owns the broken page. The institution is liable for all of it.

This is why web accessibility in higher education is fundamentally a governance problem. You cannot fix it once and walk away, and you cannot centralize every content decision onto one team. What works is a deliberate operating model: clear policy, a single standard, shared tooling, training, accountability, and — the piece that makes the rest sustainable — continuous monitoring. This guide lays out that model.

Why Decentralization Breaks Accessibility

The structural reality of a campus web presence creates predictable failure modes:

• Volume and velocity. Thousands of pages change every week. New faculty bios, event posts, uploaded syllabi, posted videos, updated catalogs. Each change is a chance to introduce a new failure.
• Non-specialist authors. A professor uploading a scanned reading or a department assistant posting a flyer PDF is not thinking about tagged structure or alt text — and shouldn’t have to become an expert to do their job.
• Tool sprawl. Central comms runs Drupal; the business school runs WordPress; a research center uses Squarespace; the LMS is Canvas; the catalog is a separate SIS export. No single fix covers them all.
• Unclear ownership. When everyone can publish and no one is clearly responsible for accessibility, defects sit unowned until a complaint arrives.
• Audit decay. Even a thorough accessibility audit captures a single moment. Across hundreds of decentralized owners, that snapshot is out of date within a semester.

The stakes are not theoretical. Under Section 504 and the 2024 ADA Title II rule, the institution must meet WCAG 2.2 AA across all of this content, and the OCR complaint process routinely produces resolution agreements that demand exactly the kind of program described below.

The Core Tension: Central vs. Distributed Ownership

Every campus accessibility program has to resolve one question: who owns accessibility?

Fully centralized — one team reviews and fixes everything — does not scale. The team becomes a bottleneck, content piles up waiting for review, and departments resent the friction. It also misplaces responsibility: the people creating inaccessible content never learn to stop.

Fully distributed — every department fends for itself — produces wild inconsistency. Some units do excellent work; most do nothing, because they lack expertise, time, and any reason to prioritize it.

The model that works is federated: a strong central authority sets the rules, provides the tools, and monitors compliance, while distributed owners are responsible for their own content within those rules. Think of central as the referee and toolmaker, and departments as the players who own their results.

Building the Governance Model

1. One policy, one standard

Publish a written, dated accessibility policy that names WCAG 2.2 Level AA as the single institutional standard for all web content, regardless of department or platform. A single standard ends the per-unit debate about “how accessible is accessible enough.” The policy should reference Section 504 and ADA Title II, define scope (it covers everything on the domain), state roles, and describe how barriers are reported and accommodations requested. Pair it with a public accessibility statement.

2. A designated coordinator and a liaison network

Name a central 504/ADA web accessibility coordinator with real authority — budget, the ability to block non-compliant procurement, and a direct line to leadership. Then build a liaison network: each college, major department, and high-traffic unit names a contact responsible for accessibility within their area. Liaisons are not expected to be experts; they are the accountable point of contact who receives reports, coordinates fixes, and attends training. This network is how central authority reaches distributed reality.

3. Accessible templates and a component library

The highest-leverage thing a central team can do is make the accessible path the default path. Provide CMS templates and a component library where the heading structure, color contrast, focus indicators, and keyboard behavior are already correct. When a department builds within an accessible template, whole categories of failure — contrast, keyboard operability, skip links, landmarks — are solved before anyone touches the content. You shift authors from “get it right” to “don’t break it.”

4. Training that targets the right people

Generic “accessibility 101” reaches no one. Train by role:

• Content editors (the largest group): alt text, meaningful link text, headings, and not uploading scanned PDFs. Short, task-specific, repeated each term.
• Faculty: captioning lecture video, accessible course documents, and what the LMS does and doesn’t fix.
• Developers and theme owners: WCAG technical criteria, ARIA, and testing.
• Procurement and IT buyers: how to read a VPAT and what contract language to require.

Make foundational training a condition of CMS publishing access. People who can’t publish without it, will take it.

5. Procurement gates

Decentralized campuses buy a lot of software, often unit by unit. Every procured platform — application portals, LMS plugins, library databases, event tools — must clear an accessibility gate: a reviewed VPAT and contractual conformance commitments before purchase. Because Section 508 conformance documented in a VPAT is your evidence but the institution carries the obligation, the central team must hold this gate even when a department wants to move fast.

6. Accountability with teeth

Governance without accountability is a suggestion. Tie it to something real:

• Publish unit-level scorecards. Departments respond to being measured against peers.
• Set remediation SLAs. Critical defects (a broken application form) get days; lower-severity items get a defined window.
• Route persistent non-compliance up the chain — to deans and vice presidents — rather than leaving it stranded with an overwhelmed liaison.
• Document everything. A dated remediation plan with owners and target dates is both a management tool and exactly what OCR expects to see.

Why Monitoring Is the Linchpin

You can write a flawless policy, train everyone, and ship perfect templates, and the site will still drift out of compliance — because content changes daily across hundreds of owners you don’t directly control. The governance model needs a feedback loop that operates at the same speed and scale as the publishing.

That loop is automated continuous monitoring. Instead of auditing the whole site once a year and discovering a semester’s worth of accumulated failures, you scan continuously and catch each regression close to when it’s introduced. Monitoring is what makes the federated model work in practice:

• It finds new failures across the entire domain automatically — including departmental sites no central team would have time to review by hand.
• It routes defects to the responsible unit, turning “the website is broken somewhere” into “your department’s page published an uncaptioned video on Tuesday.”
• It powers the scorecards and SLAs that make accountability real, with objective per-unit data.
• It catches regressions so a remediated page that someone later edits doesn’t silently break again.

Automated monitoring won’t judge caption accuracy or whether alt text is meaningful — those need human review, as our automated vs. manual testing guide explains. The right division of labor is automation for breadth, speed, and regression-catching across thousands of pages; humans for the judgment calls. But at campus scale, no human-only process can keep up. Monitoring is the only mechanism that matches the volume and velocity of decentralized publishing — which is why continuous monitoring is the scalable answer to a problem that one-time audits and heroic central teams cannot solve.

A Realistic Rollout Sequence

You can’t fix everything at once. Sequence it:

1. Baseline. Run an automated scan across the whole domain to size the problem and identify the worst-offending units and highest-traffic pages.
2. Stand up governance. Publish the policy, name the coordinator, recruit liaisons, and turn on monitoring.
3. Fix the high-stakes, high-traffic content first — admissions, financial aid, registration, the homepage — per a written remediation plan.
4. Ship accessible templates so new content is born compliant.
5. Train by role and gate publishing access on it.
6. Operationalize accountability with scorecards and SLAs fed by monitoring data.
7. Sustain. Treat the monitoring feed as a standing operational process, not a project that ends.

A university website is too large, too fragmented, and too fast-changing to keep accessible through audits and central heroics alone. The institutions that stay compliant treat accessibility as governance — a single standard, distributed ownership, real accountability — wired together by monitoring that operates at the speed of campus publishing. Govzu continuously scans every corner of your domain against WCAG 2.2 AA, attributes new failures to the units that own them, and feeds the scorecards and SLAs that make distributed accountability work — so accessibility holds up across hundreds of departments, between audits, and long after any OCR agreement closes.