The Hidden Accessibility Risks in a Higher Ed Website Redesign
A website redesign feels like the obvious moment to get accessibility right. You are rebuilding everything. You have a new design system, a new CMS, and a clean slate. If you are going to bake accessibility in anywhere, it is here.
And yet most higher education institutions come out of a redesign with the same accessibility problems they went in with, plus a few new ones created by the migration itself.
This is not always the agency's fault. Accessibility scope is frequently undefined in the RFP, underfunded in the contract, and undertested before launch. Here is where the risks accumulate and what institutions can do to address them.
The Agency Scope Gap
Most higher education web agencies are hired to do three things: strategy, design, and CMS build-out. Accessibility is sometimes named in the contract as a requirement, what happens if the agency’s scope stops at delivering the strategy, and redesigned CMS and not actually building all of the pages?
An agency that commits to "building an accessible website" may mean the design system uses accessible color palettes and the templates pass an automated scan. That is a meaningful starting point. It is not a complete accessibility program. It does not cover:
The content that gets migrated from the old site into the new templates
The PDFs that survive the migration untouched
The third-party tools that get embedded in the new site
The forms that are rebuilt in the new CMS
The videos that get carried over without caption review
The departmental pages that content owners populate after the agency hands off
A template can be accessible. The content that goes into it may not be. The agency typically does not own that content, and by the time the institution realizes the gap, the agency engagement has ended.
Content Migration Without Accessibility Review
Content migration is where most redesign accessibility programs fall apart. Moving thousands of pages from an old CMS into a new one is labor-intensive work that happens under time pressure, usually in the final weeks before launch. Under those conditions, accessibility review gets cut.
Pages get migrated as-is. Images carry over without alt text. Heading structures that were wrong in the old site are wrong in the new one. Documents that were never accessible are linked again on the new site. The new CMS is technically capable of supporting accessible content. The content itself is not accessible.
This is not a hypothetical problem. It is the standard outcome of a migration done without dedicated content review capacity. The institution launches a new site that passes a homepage scan and fails everywhere else.
Third-Party Tools That Were Never Evaluated
Higher education websites embed a significant number of third-party tools: event calendars, course catalogs, application portals, payment systems, chatbots, social media feeds, video platforms, and interactive maps, among others. These tools are selected, contracted, and integrated by different departments at different times, and their accessibility is rarely evaluated before they go live.
Under ADA Title II, public institutions are responsible for the accessibility of third-party content that is integral to accessing their programs and services. A course registration portal that a student cannot navigate because the vendor's tool is not accessible is not the vendor's problem. It is the institution's.
Every third-party tool that gets embedded in a redesigned site should be evaluated for WCAG 2.1 AA conformance before go-live. Vendors should be able to provide a Voluntary Product Accessibility Template, commonly called a VPAT, that documents the tool's conformance. If a vendor cannot provide a VPAT, that is a meaningful signal about their accessibility program.
Forms Rebuilt Without Accessibility Testing
Forms are among the highest-risk elements on any educational website. Inquiry forms, application forms, financial aid forms, event registration forms, and contact forms all involve user input, and all are common sources of accessibility failures.
A redesign typically involves rebuilding forms in the new CMS or in a form platform like Formstack, Gravity Forms, or a similar tool. The visual design gets updated. The underlying accessibility frequently does not improve because form accessibility requires more than visual design: it requires proper label associations, clear error messages that tell users what went wrong, required field identification that works with screen readers, and keyboard navigation that functions correctly through every field and submission step.
Forms should be explicitly included in pre-launch accessibility testing, not assumed to be covered by the template audit.
The Pre-Launch Accessibility Test That Does Not Happen
Most agency redesign contracts include some form of quality assurance before launch. That QA typically covers functional testing: does the site load, do the links work, do the forms submit. It may include a pass through an automated accessibility scanner. What it rarely includes is a substantive manual accessibility review of the built site before it goes live.
The result is that accessibility issues that would have been caught with a few hours of keyboard navigation testing and screen reader evaluation make it into production. They are then discovered by users, which is the most expensive and most damaging way to find them.
Building a pre-launch content and accessibility review into the project timeline, with dedicated time and a defined scope, is the single most effective intervention available to institutions that want to launch an accessible site. It is also the step that most project timelines cut when schedules compress.
What Institutions Can Do Differently
The risks above are predictable, which means they are preventable with the right planning.
Define accessibility scope in the RFP. Name WCAG 2.1 AA explicitly. Specify that it applies to templates, content, forms, and third-party integrations. Ask agencies how they test for accessibility and what their process is for content migration review.
Budget for content migration as a separate workstream. Content migration done well, with accessibility review built in at the page level, is not something that happens as part of the agency engagement at no additional cost. It is skilled work that requires dedicated capacity and a realistic timeline. Plan for it separately.
Require VPATs from all third-party vendors before integration. Make this a procurement requirement, not an afterthought. A vendor who cannot provide accessibility documentation should not be integrated into a site that is subject to ADA compliance obligations.
Schedule a pre-launch accessibility review. Before the site goes live, conduct a content and accessibility review that covers built pages, forms, PDFs, and third-party embeds. This review should include manual testing, not just automated scanning. The two to three weeks before launch when everything feels locked in is exactly the right time to do this, because it is still possible to fix things.
A redesign is an opportunity to get accessibility right. Most institutions miss it not because they do not care but because nobody defined the scope, built in the time, or assigned the capacity. Those are solvable problems if you address them before the project starts rather than after the site launches.
Shine Media Studio works with K-12 schools, colleges, and universities on website accessibility audits, remediation consulting, staff training, and content build-out. If your institution needs help knowing where it stands or getting the work done, we are ready to help.
Schedule a discovery call to talk through your situation, or request a free homepage scan as a first step.
This post is provided for informational purposes only and does not constitute legal advice. Institutions with specific compliance questions related to ADA Title II, Title III, or Section 504 should consult qualified legal counsel.