How to stop creating new accessibility issues: Governance that works in the real world

You fixed 500 PDFs in the last sprint. This sprint: faculty uploaded 600 new ones, and none of them accessible. Your "remediation program" is just an expensive treadmill running in reverse.

If accessibility issues reappear every publish cycle, you don't have a program. You have an infinite loop that burns budget, exhausts teams, and never solves the problem because you're treating symptoms instead of causes.

Real accessibility programs catch problems early in the process. They stop inaccessible content before it slips through prevention systems, enable faculty workflows, and enforce governance with real power. This isn't about policing creators or adding approval bottlenecks. It's about making accessible-by-default the path of least resistance.

In a recent conversation with Chronicle Intelligence, we unpacked what this looks like in practice. You can get the key takeaways or watch the full discussion.

Here's what governance that scales looks like:

• Stops creating new problems by building accessibility into publishing workflows before content goes live
• Enables faculty and staff with training, templates, and realistic processes they'll use
• Establishes clear escalation paths with real consequences when standards aren't met
• Locks down procurement so inaccessible third-party tools never enter your ecosystem
• Proves progress through ongoing monitoring and transparency that leadership understands

First, let's examine why this approach is the only scalable strategy.

Stop fixing what you could have prevented

Accessible-by-default publishing eliminates the remediation treadmill by catching issues during creation, not after publication.

Laura Rothstein, Emerita Professor of Law and Distinguished University Scholar at the University of Louisville, cuts to the heart of it: Accessibility needs to be "done at the front end" so "you don't have to wait for a student to ask." That's the shift. In the past, faculty got notified when a student with disabilities enrolled, then scrambled to fix materials. Now, though, course content must be accessible from day one.

This changes everything:

• Before: Student requests accommodation → Faculty scrambles → Accessibility team remediates → Student gets access three weeks late
• After: Faculty creates accessible content → All students get day-one access → Your team builds systems instead of firefighting

But here's the problem Rothstein identifies: "Campuses not prepared... are a burden on faculty." Most institutions have built their programs around reactive accommodations, not universal design from the beginning. Faculty who've taught for decades suddenly need to understand heading hierarchies and alt text before publishing their first syllabus.

The gap between what's expected and what faculty can realistically do without support is where programs break.

Support faculty or watch your program collapse

Prevention only works when faculty have training, templates, and support built into their workflows, not dumped on them as extra work.

Rothstein puts it simply: Universities need to provide clear training and establish processes that faculty can follow. Faculty aren't resisting accessibility on principle. They're overwhelmed by new technical requirements that nobody's equipped them to handle.

What enablement looks like in practice:

The burden Rothstein mentions is real. A biology professor who hand-draws molecular diagrams shouldn't need a PhD in Web Content Accessibility Guidelines (WCAG) to make them accessible. Give them templates, alt text guidance specific to scientific images, and a clear escalation path when they're stuck.

Training alone won't cut it. Faculty need tools that make accessible content creation the easiest option, not the hardest. When your Content Management System (CMS) flags missing alt text before publishing and offers a template, you're enabling. When you send a stern email about compliance, you're just adding stress.

What happens when faculty refuse

Clear processes for handling content that doesn’t meet standards make accessibility a requirement, not a suggestion.

Rothstein raises the scenario every accessibility leader dreads: "Suppose you tell a faculty member … ‘You've got a student in your class who says you're posting all these videos and [they] can't access them.’ And the faculty [member] is refusing to do anything about that. Now what happens?"

Most campuses have no answer. They've got policies on paper but no enforcement mechanism when someone ignores them.

What you need in place:

• Clear notification process: Faculty get specific guidance on what needs fixing and by when.
• Support offers first: "We'll help you remediate" beats "you're in violation".
• Escalation authority: Department heads and deans can require compliance.
• Documented refusals: Track who was offered help and declined.
• Legal consequences defined: Outline what happens when faculty put the university at risk.

Rothstein warns that universities could face situations where faculty refusal leads to litigation, and the institution might not provide legal counsel if the faculty member was given appropriate support and still refused to comply.

The goal is to make it crystal clear that accessibility isn't optional, support is available, and there are consequences for refusing both.

Who decides when rules don't apply

Define who owns exceptions and what happens when someone refuses to comply because without consequences, policies are just suggestions.

The faculty refusal scenario Rothstein outlined leads to a harder question: Who decides what happens next? Your accessibility coordinator can flag problems and offer support, but they can't force compliance. Department heads can encourage, but can they require it?

Here's what governance with teeth looks like:

• Exception authority: One person (not a committee) approves legitimate exceptions with a documented rationale.
• Support-first approach: Offer concrete help before any escalation: "We'll remediate this for you" or "Here's the template."
• Clear consequences: Faculty who refuse support after being offered it face defined outcomes.
• University counsel involvement: Legal counsel weighs in when refusal creates institutional risk.
• No blanket immunity: Faculty who put the university at legal risk after refusing appropriate support may not get institutional legal defense.

Rothstein points out that universities might not provide counsel to individual faculty members who were given proper support and still refused to make content accessible. That's not theoretical; it's the legal reality when someone's individual choices expose the institution to liability.

Most accessibility issues resolve with help, not enforcement. But the small percentage that don't? You need a plan before they land on your desk.

Make vendors prove it before you buy

Verification loops and standards in vendor onboarding stop inaccessible third-party tools from entering your ecosystem.

Cyndi Wiley, Digital Accessibility Lead at Iowa State University, cuts through the noise on Voluntary Product Accessibility Templates (VPATs) and accessibility checklists: “[They're] not magic wands." The real work is verification, so don't just collect them as paperwork.

What makes procurement governance work:

• Require VPATs for every software review: There are no exceptions, even for "small" purchases.
• Verify vendor claims: Sales reps filling out checklists isn't the same as compliance.
• Negotiate remediation timelines: Include fix deadlines in the contract in case the product fails.
• Walk away when necessary: If it doesn't meet WCAG standards, don't buy it.
• Use money as leverage: As Wiley (bluntly) puts it, "Money really is the only thing that's going to work in our current culture to steer vendors to make their products better."

The Higher Education Community Vendor Assessment Toolkit helps, but only if you enforce what it reveals. Kristina England, who manages procurement accessibility across the entire University of Massachusetts system, makes the distinction clear. Her office handles procurement standards system-wide because it requires centralized authority. Individual campuses can't negotiate vendor contracts on their own.

Every inaccessible tool you buy creates years of remediation work. Prevent future headaches at procurement.

Control who publishes (before they publish broken content)

Guardrails, permissions, and pre-publish checks prevent inaccessible content from flooding your digital properties.

Christina Adams from Siteimprove raises a point most teams miss: “[You might need to] limit or control who can create content." That sounds restrictive until you realize the alternative; everyone publishing whatever they want means everyone creating accessibility debt you'll spend years fixing.

Control mechanisms that work:

• CMS permissions: Not everyone needs publishing rights; some roles should submit content for review.
• Pre-publish validation: Automated checks flag things like missing alt text, broken heading hierarchy, and color contrast failures before content goes live.
• Template libraries: Approved, accessible templates for common content types (course syllabi, event pages, forms).
• Publishing workflows: High-risk content types such as PDFs, videos, and interactive tools require accessibility sign-off.
• Content governance policies: Define clear rules on who can publish what, where, and under what conditions.

Adams frames this as necessary friction: "You do have to slow down the creation of inaccessible content before we're going to make progress on this at all."

The goal is to make sure people with publishing power have the training, tools, and accountability to use it responsibly.

Show your work, prove your progress

Programs are judged by progress, not perfection. That means showing your work publicly and tracking improvement over time.

Adams makes a point that accessibility leaders often miss: "Show your program ... be transparent ... we're working on it." Leadership doesn't expect everything to be fixed by April. Users don't expect perfection overnight. But both expect visibility of what you're doing and whether it's working.

What transparency looks like in practice:

• Public accessibility statements: What's accessible, what's not, what you're fixing next
• Published roadmaps: Timelines showing what gets addressed when
• Clear reporting channels: Where users report issues and how quickly you respond
• Progress dashboards: Metrics showing improvement trends, not just compliance scores
• Issue queues: Transparent backlogs so people see their reports aren't disappearing into a void

Terrill Thompson at University of Washington agrees with this approach: Publishing what you've addressed and what's in the queue builds trust with users and defuses complaints before they escalate to formal grievances.

The programs that survive scrutiny prove momentum. Siteimprove's platform, Siteimprove.ai, turns scattered accessibility work into reportable progress by crawling your entire web presence, scoring accessibility on a page-by-page and domain-by-domain basis, mapping issues to owners, and tracking trends over time. That way, you’ll have the data when leadership asks, "Is this working?"

Make governance operational, not aspirational

Accessibility programs fail when prevention is treated as optional. The programs that scale build governance into every workflow: procurement that blocks inaccessible tools, publishing systems that catch issues pre-launch, and monitoring that proves progress to leadership. Siteimprove's Digital Governance platform operationalizes this across your entire digital presence.

Set policies that enforce accessibility standards. Monitor compliance in real-time across websites, course content, and third-party tools. Track which teams maintain excellence and which need support. Prove ROI with dashboards that leadership understands.

Stop reintroducing the same problems every publish cycle. Request a demo to see how Siteimprove helps accessibility leaders run programs that stick.