Establishing Enterprise Accessibility Practices

Overview

Advarra’s product portfolio spans clinical research and governance software, much of it sold into organizations — universities among them — that hadn’t historically been required to meet strict digital accessibility standards. An incoming ADA rule changed that calculus for a large share of the customer base almost overnight, and updated VPAT requests started arriving fast, many of them attached directly to renewal conversations.

Internally, accessibility had never been treated as a first-class requirement. Like a lot of enterprise software companies, the organization was now catching up under real time pressure across seven applications built at different points, on different stacks, by different teams.

I owned this end to end: conducting the VPAT audits myself, producing the ACRs, centralizing the documentation, triaging and tracking remediation, and — because I’m well versed in front-end and accessible implementation techniques — fixing a meaningful share of the highest-impact issues directly rather than only reporting them.

The Challenge

Universities and similar customers fell squarely into the incoming ADA requirements, and many were actively evaluating whether Advarra’s products would put them at risk. Renewal conversations increasingly opened with a request for an updated VPAT, and the organization didn’t have a reliable, current one to hand over — accessibility had simply never been prioritized as a first-class product requirement.

The legacy enterprise applications were the hardest part of the equation. They carried years of accumulated UI patterns never evaluated against WCAG, on architectures that made remediation slower and riskier than it would be on a modern stack. There was no existing inventory of known issues, no severity model for triaging them, and no process for keeping documentation current as releases shipped and things changed.

Conducting the Audits and Centralizing the Record

I personally audited each of the seven applications against Section 508 and WCAG 2.1 AA and produced the corresponding ACRs. Rather than treating each VPAT as a one-time deliverable, I established a centralized location for the files and a cadence tied to the release calendar so ACRs were refreshed as products actually changed, not left to go stale until the next customer asked.

That combination — a single source of truth plus a standing update cadence — is what let the response to customer requests shift from “we’ll have to look into that” to handing over a current, defensible document.

Triage and Remediation

Not every finding carried the same weight, so I focused first on identifying and prioritizing the issues that would actually prevent someone with a disability from completing a task — not every technical deviation from spec, but the ones with real consequences for real users.

For each prioritized issue I provided remediation documentation and tracked the work in JIRA alongside the rest of engineering’s backlog, so accessibility fixes competed for priority the same way any other defect did rather than living in a separate, easily deprioritized channel. Where the fix was well scoped and time mattered, I executed it myself — my front-end background meant I could go straight from finding to fix on the highest-impact issues instead of waiting in a queue.

Building Accessibility Into New Work

For newer applications built on the design system, the goal shifted from remediation to prevention. I made sure those applications passed Section 508 and WCAG 2.1 AA compliance as a property of the system they were built on, not something verified late.

A core piece of that was an accessible color-token system. Rather than manually checking every color pairing for contrast, I established the palette using an approach modeled on the U.S. Web Design System’s “magic number” methodology — a predictable numeric relationship between token values that reliably predicts which pairings will meet contrast requirements. That let teams pick from the token set with confidence instead of re-litigating contrast on every new screen.

Key Decisions

1. Owning the audits directly instead of outsourcing them. Conducting the VPATs and writing the ACRs myself meant the findings were accurate, consistent across all seven applications, and available on the organization’s own timeline rather than a vendor’s.

2. Centralizing documentation on a release cadence. A VPAT that goes stale the moment a release ships isn’t much better than not having one. Tying updates to the release calendar kept the record current.

3. Triaging by real user impact, not raw finding count. Prioritizing the issues that actually blocked task completion for people with disabilities made a large, ambiguous backlog tractable and defensible.

4. Fixing the highest-impact issues directly. Where I could execute the remediation myself, I did — turning around critical fixes faster than a full documentation-to-backlog-to-fix cycle would have allowed.

5. Solving contrast at the token level with a repeatable method. An accessible color system built on a predictable numeric relationship, modeled on USWDS, meant new applications inherited compliant color pairings by default instead of requiring manual verification every time.

Outcome

Contracts and legal teams could respond to customer accessibility inquiries immediately, point to current documentation, and speak accurately to where remediation stood — a direct factor in protecting renewals during a period when many customers, universities in particular, were actively assessing accessibility risk as part of their decision to stay.

The legacy portfolio moved from no consistent record and no triage model to a centralized, regularly updated set of VPAT/ACRs and a working remediation pipeline. New applications built on the design system shipped Section 508 and WCAG 2.1 AA compliant from the start, backed by an accessible color-token system that removed contrast guesswork from day-to-day design decisions.

Reflection

The pressure of an approaching regulatory deadline made this work non-negotiable, but the lasting value came from building infrastructure rather than just clearing a backlog: a centralized, current record; a triage model based on real user impact; and a token-level color system that made new work accessible by default. That’s what let the organization keep answering customer questions confidently after the initial deadline pressure passed.

If I were extending this today, I’d look at how AI-assisted review could help catch likely accessibility issues earlier in design and code review on the legacy applications specifically — where manual audit capacity was always the constraint, not the will to fix things.