A company finishes a big accessibility push. Maybe a lawsuit forced it, maybe a looming deadline did. The team fixes everything in the audit, the report closes, and accessibility quietly drops off the roadmap. A few months later, the same problems are back, introduced by new components, fresh content, and a redesign nobody thought to check.
The fixes were real. They just didn't last because the work was treated as a one-time project rather than an ongoing program.
A sustainable program is the opposite of that. It starts with culture, separates WCAG conformance from legal compliance, embeds accessibility into design and development before QA ever sees the code, and uses a maturity framework to measure progress over time. The goal isn't a perfect site on a single date. It's an organization that handles accessibility the way it handles security, performance, or any other ongoing operational discipline.
The contents of this blog include excerpts from our recent webinar, The Accessibility Mindset: Building a Program That Sticks, with Jeff Adams (VP of Accessibility Operations), Michele Lucchini (VP of Products and Delivery), and Giacomo Petri (Director of Accessibility Auditors) at UsableNet.
Disclaimer: This blog is for education only and is not legal advice.
Why Culture and Attitude Come First
Most organizations sit somewhere on a continuum between three modes: reactive, compliant, and embedded.
Reactive teams act because they were sued, received a demand letter, or are racing a deadline, such as the European Accessibility Act or ADA Title II. Accessibility is treated as a legal problem, which disrupts timelines and makes budgets unpredictable. It's also the most expensive way to handle the work.
Compliant teams have moved past the immediate crisis. Accessibility is a box to check, sometimes during design or development, often at the end, when QA is left to find everything. The box gets checked, but the work tends to pile up at the worst possible moment in the lifecycle.
Embedded teams treat accessibility as part of their development process. Product owners think about it during scoping. Designers think about it during wireframing. Developers think about it during component creation. QA confirms it rather than discovering it. Vendor contracts require it.
Reaching the embedded state isn't a tooling problem. It's a cultural one. Teams have to genuinely believe that accessibility matters, from executive sponsors who allocate budgets down to developers writing code. Without that shared attitude, even the best processes and tools deliver mediocre results.
It's also worth remembering that "the digital ecosystem" extends well beyond the website and mobile app: kiosks in stores, airports, and medical offices; social media; email marketing; and internal systems employees rely on. All of it counts.
An honest first step is to assess where your organization actually is, not where you want it to be. Trying to skip from reactive to embedded in a single budget cycle is how programs stall. Pick the realistic next step from your current position and build momentum from there.
In this clip, the panel discusses why the shift from reactive fixes to an embedded accessibility program begins with culture.
WCAG Conformance Is Not the Same as Legal Compliance
This distinction is one of the most common sources of confusion in accessibility programs, and one of the most important to get right.
Conformance is a technical measurement against the Web Content Accessibility Guidelines. WCAG treats every violation as a failure, full stop. A missing alt attribute on a decorative image in a rarely visited page and a flashing animation that could trigger a seizure are both failures. They count the same.
Compliance is a legal concept. It evaluates whether the product is genuinely accessible in the real world, where perfection isn't achievable and severity matters. A program with a few isolated bugs but strong governance behaves very differently, both legally and practically, than one with systemic accessibility failures and no plan.
The two should be aligned, but they aren't always. The Americans with Disabilities Act doesn't specify a WCAG version; that came from case law and practice. The European Accessibility Act, by contrast, writes the standard directly into the law and goes a step further: it asks organizations to demonstrate an accessibility program, not just a passing scan. That framing, treating accessibility issues as bugs to manage rather than gaps that constitute failure, is closer to how mature organizations actually operate.
We've also seen this shift up in US courts. In one recent New York case, a defendant with documented accessibility work in progress (policies, audits, and real remediation) had a complaint dismissed because the judge saw a few isolated bugs rather than a systemic problem. That's one case, not a trend, but it points toward the idea of a "substantially conformant" site as the practical legal target rather than absolute WCAG conformance.
The practical takeaway is to avoid setting "WCAG conformance" as the goal of your program. Set "demonstrable, sustained progress with documented governance" as the goal instead. The first is binary and unattainable. The second is what mature programs actually achieve.
The panel explores that distinction further in this clip, including why a mature program cannot be reduced to a binary pass-or-fail result.
Severity, Priority, and the End of Binary Thinking
If you accept that not every WCAG failure carries the same weight, the next question is how to prioritize the backlog. Severity is the starting point, but it isn't the whole picture.
Severity describes the impact on users. Flashing content that can trigger seizures is critical because it can cause direct physical harm. A decorative image missing alt text is a real failure, but the screen reader user simply hears "image" and moves on. Both must be fixed; only one needs to be fixed today.
Legal exposure layers on top. Some low-severity issues, such as missing alt text or insufficient color contrast, keep appearing in demand letters because automated tools easily detect them. That ease of detection translates directly into legal exposure, even when user impact is modest. Issues that appear in lawsuits against peers in your industry also move up in priority regardless of severity.
Product context matters too. The same WCAG issue in a checkout flow, login flow, or core navigation is far more important than the same issue on a rarely visited archive page. Critical user journeys are the backbone of the experience.
Roadmap awareness is the last lens. If a component is scheduled to be rebuilt next quarter, investing significant engineering time in fixing the current version may not be the best use of resources. Track it, flag it, and ensure the rebuild is accessible by default.
These dimensions matter for a simple reason: no team has infinite engineering capacity. Prioritization isn't optional. It's mandatory. And it's no longer just a technical decision; it's a management decision about where risk and user value are highest.
This is also where the limits of automated testing become visible. Automated tools scale beautifully and quickly catch a portion of issues. But they detect only 10 to 30 percent of accessibility problems, and the ones they miss (keyboard traps, screen reader workflow failures, cognitive friction, contextual barriers) are often the ones with the highest real-world impact.
One operational tip: when teams are early in their accessibility journey, fix some quick wins alongside the hard problems. Visible progress builds organizational momentum and makes it easier to justify continued investment. Getting stuck on a six-month component rebuild as the first initiative tends to drain belief in the program.
In this clip, Giacomo Petri explains how teams can use severity, risk, and context to make smarter remediation decisions.
Shift Left: Why Timing Drives Cost
"Shift left" isn't a new concept, but most organizations still haven't fully adopted it. Knowing and doing are different, and audit data makes the gap visible. Many critical accessibility issues aren't last-minute bugs. They were introduced during design, architectural decisions, or component creation, then propagated across hundreds of pages before anyone noticed.
The economics make the case better than any philosophical argument:
- Fixing an issue in a Figma design: a ten-minute conversation. Call this 1x.
- Fixing the same issue in a reusable component already deployed across 200 to 300 pages: engineering rework, regression testing, sprint allocation, and deployment coordination. About 6x the cost.
- Fixing the same issue after a plaintiff attorney sends a demand letter: legal fees, settlement discussion, mandatory timelines, reputational exposure, and executive escalation. About 30x the cost.
These multipliers are based on the cumulative time and resources required at each stage. The later an issue is identified, the more work has been built on the wrong implementation, and the more roles are pulled into remediation: designers, developers, QA, product management, business stakeholders, and legal and compliance experts.
Accessibility debt behaves like technical debt. The longer it sits, the more expensive it gets. Teams familiar with that pattern in cybersecurity or performance engineering will recognize it instantly.
What shift left actually looks like in practice:
- Accessibility is part of design reviews, not just QA.
- Component libraries are accessible by default, so what scales does so correctly.
- Developers receive education, not just checklists, because understanding creates consistency in a way that checklists don't.
- Third-party vendors are part of the equation, with accessibility requirements written into procurement and contracts.
Shift left looks different at different scales. For smaller organizations with simpler architectures, it's mostly a matter of attitude, prioritization, and investment. For enterprises with multiple development teams, design agencies, vendors, and digital properties, this requires policy work, role-specific goals, and, sometimes, funding training for the external partners you depend on. It's easy to talk about and complex to actually implement.
Watch as the panel explains why timing matters and what shifting accessibility left looks like in practice.
Using the W3C Accessibility Maturity Model
Once culture, prioritization, and shift left are in motion, the question becomes how to sustain this over time and prove to auditors, regulators, or procurement teams that you're sustaining it.
The W3C's Accessibility Maturity Model provides a framework for exactly that. It isn't a finish line, and it doesn't replace audits or user testing. It's a way to measure the maturity of your program across seven dimensions:
- Communications: Is there an accessibility policy? An accessibility statement? Clear ways to report and discuss accessibility?
- Oversight and culture: Executive sponsor, program leader on the leadership team, documented commitment, and a real budget.
- ICT development lifecycle: How accessibility is built into design, development, QA, and content creation. This is where Shift Left lives.
- Knowledge and skills: Ongoing education, hiring practices, employee resource groups, and outside expertise to fill gaps.
- Procurement: Are accessibility requirements written into vendor contracts and evaluated during sourcing?
- Support: For employees needing accommodations, and for customers raising accessibility concerns.
- Personnel: Job descriptions, recruiting, and bringing lived experience into the team through hiring people with disabilities.
Each dimension has proof points you can score against four maturity levels:
- Inactive: Little awareness or recognition of need.
- Launch: Planning underway, not yet organized.
- Integrate: Roadmap in place, approach defined, well-organized execution.
- Optimize: Organization-wide embedding, continuously evaluated.
Most organizations sit between Launch and Integrate. Optimizing isn't permanent, either. If a program leader leaves, priorities shift, or budgets contract, an organization can move backward. That's why continuous evaluation matters.
The maturity model is also increasingly visible in procurement. State-level entities preparing for ADA Title II have started asking vendors whether they maintain a maturity model assessment. The EAA, with its program-documentation requirement, points in the same direction. Even where regulation doesn't explicitly require it, the maturity model is a useful artifact to have when someone asks how seriously you take this work.
Frequently Asked Questions
Can AI replace accessibility expertise?
No, but it can amplify a mature process. AI works well for scaling parts of automated testing, executing well-defined tasks, comparing audit results against policies, and analyzing large sites to surface the most recurring issues for prioritization. It does not replace human judgment (the majority of WCAG success criteria require contextual evaluation that AI can't reliably do), and it cannot stand in for testing with real users with disabilities. A developer using AI without accessibility competence is a point of failure: if the developer can't judge whether the AI's output is correct, errors go undetected rather than being caught. The responsible application of AI accelerates the work; it doesn't substitute for the underlying process or expertise.
In this clip, the panel discusses where AI can support accessibility work and where human judgment remains essential.
For higher-ed institutions with large PDF libraries, should we train faculty or use a vendor?
Both. Train faculty and anyone creating new PDFs so you stop accumulating accessibility debt one document at a time. For large existing libraries, a vendor is usually the practical answer, because internal teams can't absorb the volume without significant operational drag. This is also a good moment to cull the library. One food manufacturer cut their library of more than 5,000 PDFs in half before sending the rest for remediation, because much of it was outdated. Partnering with campus libraries, bookstores, and print shops also helps catch documents that pass through their hands for classroom use.
In this clip, Jeff Adams explains why institutions need to prevent new PDF accessibility issues while also addressing the existing backlog.
How do we decide what to prioritize first?
Start with the "do no harm" principle for any issue that can cause direct physical harm, such as flashing content. From there, combine severity, legal exposure (especially issues showing up in demand letters in your industry), product context (core user journeys first), and detection ease. The right mix depends on your organization, your sector, and the specific maturity of your program. And don't overlook celebrating progress, because early wins, even small ones, are what build internal belief in the program.
In this clip, Michele Lucchini discusses how organizations can identify the arguments and internal champions most likely to move accessibility work forward.
What's the legal risk from color contrast issues specifically?
Most ADA web accessibility plaintiffs are screen reader users, so color contrast usually doesn't appear in the initial complaint. Where it shows up is later, when a plaintiff attorney has an expert run an automated scan and adds findings to the claim. Because color contrast is one of the easiest issues to detect automatically, it's a frequent addition. To reduce legal exposure, clear the issues that automated tools find easily, such as color contrast, missing alt text, and missing labels, because those are the ones expert witnesses can produce on the first scan.
Where do the 1x, 6x, and 30x cost multipliers come from?
They reflect the cumulative time and resources required at each stage of the product lifecycle. Fixing an issue during design is the baseline, because accessibility is embedded in team knowledge and processes, so it costs roughly 1x to address. Once the issue has shipped to QA or production, the cost rises to about 6x because of coordination overhead and regression testing across already-built functionality. When issues are identified through user complaints or legal claims, the cost rises to roughly 30x because remediation now involves designers, developers, QA, product management, business stakeholders, and often external legal or compliance experts to assess risk.
In this clip, the panel explains why accessibility issues become significantly more expensive to fix when they are discovered later in the lifecycle.
Build a Program, Not a Project
A sustainable accessibility program isn't a one-time engagement that ends when an audit closes. It's a continuous discipline that requires executive support, embedded processes, prioritization frameworks, and a way to measure the program's maturation over time.
UsableNet supports organizations across all of this: managed remediation on the live site, expert auditing and user testing, training, and the platform tooling to find and fix issues with code-level guidance. Where your program needs the most help depends on where you sit on the continuum from reactive to embedded.
Schedule a consultation to discuss your current program and the next step.
