How One of the Largest Online Public Universities in the US Built Accessibility Into Its Engineering Workflow Ahead of the DOJ WCAG 2.1 AA Deadline

As one of the largest online public universities in the US, the institution serves hundreds of thousands of students, including many with ADA-protected accessibility needs. With that scale comes responsibility. And with the DOJ's Title II rule now requiring all public entities to meet WCAG 2.1 Level AA, that responsibility has hardened into a legal obligation.

For a university operating on this scale, accessibility is not a back-office concern. It is the front door of every student's journey, from admissions to financial aid to the learning platform itself. And until recently, that front door was being inspected on a yearly cycle, by hand, with results delivered months after the code had already shipped.

The Old Model Could Not Keep Up With the Pace of Modern Software Development

For years, the institution worked with a third-party accessibility consultancy that performed manual audits on a scheduled cadence. The output of each engagement was a static PDF report. The team would receive a list of violations, file tickets, and start working through a remediation queue that consistently stretched beyond a year.

The structural problem was clear. Manual audits, no matter how thorough, could not keep pace with continuous deployment. Non-compliant code reached production routinely, not because anyone wanted it to, but because there was no checkpoint that could catch it.

For an institution serving a student population with significant ADA-related needs, this was not just an operational inefficiency. It was a source of real legal exposure. The university had already faced consequences from serving sub-compliant digital experiences, and the engineering manager leading this work knew the model needed to change before the DOJ deadline arrived.

A Shift-Left Approach: From Annual Audit to Engineering Gate

The team hypothesized that accessibility would never be solved at the audit layer. It had to be solved at the code layer, at the moment a developer was writing it.

That meant moving accessibility into the standard software development lifecycle, the same way unit tests, linters, and security scans had been moved years earlier. The principle was simple: prevent non-compliant code from ever reaching production.

The team's existing test infrastructure already ran on TestMu AI's Web Automation cloud for desktop browser coverage, so adding the Accessibility Suite into that workflow was a natural extension rather than a parallel program. They built it in at three checkpoints:

During local development. Engineers run automated Playwright-based scans against the views and routes they are building. Issues surface in their IDE, in real time, while the code is still being written.

At the pull request stage. TestMu AI's CI/CD integration is wired into the team's continuous integration system. Any pull request containing accessibility violations is automatically caught and blocked from merging. The same gate runs alongside the team's existing Web Automation suite, so engineers see functional and accessibility failures in a single check.

Across production sites. TestMu AI's Test Scheduling runs weekly automated scans on the institution's public-facing properties. The team uses these scans not as a final report, but as a living roadmap, prioritizing remediation work against what is actually live and being seen by students today.

Solving the Ephemeral Environment Problem

Like many large institutions, the university does not yet have a non-production ephemeral environment where engineers can point a scanner at code before it merges into the main staging site. Building that infrastructure is a longer-term project.

Until it is in place, TestMu AI's scheduled production scans serve a critical interim function. Rather than waiting on quarterly audits, the team treats weekly scan output as their authoritative remediation backlog. New violations are identified within days of being introduced, not months.

This dual-layer approach, CI gating for new code combined with scheduled production monitoring for everything already deployed, gives the team the closest thing to full coverage they can achieve while their environment infrastructure catches up.

Coverage That Extends Beyond the Browser

For a university serving students who interact with the institution across laptops, tablets, and phones, browser-only testing was never going to be enough. The team uses TestMu AI's Real Device Cloud to validate accessibility on the actual devices their students use, including assistive technology behavior on real iOS and Android handsets rather than simulators.

This matters because mobile accessibility issues, particularly around screen reader behavior, focus management, and touch target sizing, often do not surface on desktop or in emulated environments. Catching them on real devices, before release, closes a gap that manual audits had historically missed entirely.

A Cross-Functional Program, Not Just an Engineering One

While the program is owned by engineering, the institution's accessibility team and legal stakeholders are deeply involved. Accessibility teams run their own automated tests against staging environments using the same TestMu AI tooling. Legal and compliance leaders see consolidated reporting from the same dashboard.

This unified view matters. In most institutions, engineering, accessibility, and legal teams work from disconnected systems, a static audit PDF for one, a ticket backlog for another, a quarterly report for the third. Things fall through the cracks. The institution's redesigned program eliminates that gap by giving every stakeholder a view into the same underlying data.

Because TestMu AI supports WCAG, ADA, EAA, and Section 508 standards out of the box, and works across web, web apps, iOS, and Android, the program covers the institution's full digital footprint with one toolset rather than several.

What's Next

The university's accessibility program is no longer reactive. It is built into the way code is written, reviewed, and shipped. New violations are caught at the pull request stage. Existing ones are tracked against a continuously updated production scan. And the institution has a defensible, repeatable model in place ahead of the WCAG 2.1 AA deadline.

For a public entity serving hundreds of thousands of students, that change is not just operational. It is the difference between meeting a regulatory deadline and being meaningfully ahead of it.

The next phase of the program will focus on completing the ephemeral environment infrastructure, which will allow the team to push CI gating even earlier in the development lifecycle, before code reaches the main staging branch at all.

Ready to operationalize accessibility in your own SDLC? Schedule a demo to see how TestMu AI can help your team meet the DOJ WCAG 2.1 AA requirements with a proactive, automated engineering gate.