Here's an uncomfortable question: if you hired a brand-new engineer tomorrow and gave them zero accessibility training, would the component they ship next week be accessible anyway?
If you hesitated, you just learned more about your organization's real accessibility maturity than any audit report could tell you. Most teams measure maturity by effort — "we did a training," "we fixed the issues from that one audit." Real maturity is measured by outcome: can a screen reader user actually complete checkout, without anyone in the building thinking about it that day?
The Trap: Mistaking Activity for Maturity
Picture a mid-size SaaS company. Eighteen months ago, a demand letter arrived. Legal panicked, engineering scrambled, a contractor fixed the flagged pages, and everyone moved on feeling like accessibility was "handled."
Now picture the next product launch. New checkout flow, new modal, new date picker — built by a different team, on a different sprint, with zero knowledge of what got fixed last year. Guess what shows up in QA? The same category of issue: unlabeled form fields, a focus trap, contrast that fails 1.4.3 Contrast (Minimum), Level AA.
Nothing was fixed structurally. The organization didn't get more accessible — it just patched one visible symptom. That's the difference between activity and maturity, and it's the single biggest blind spot in how companies self-assess.
This is where an accessibility maturity model earns its keep. Borrowed from the same underlying idea used in security and DevOps maturity models, it doesn't ask "how many issues do you have right now?" It asks "how systemic, repeatable, and durable is your process for preventing and catching issues?" That's a fundamentally different — and far more honest — question.
The Five Stages, Plainly
Most digital accessibility strategy frameworks converge on a similar arc, whether they use these exact labels or not. Here's the practical version.
Stage 1: Unaware / Reactive. No formal process exists. The organization's only engagement with accessibility has been triggered by an external event — a demand letter, a complaint, a customer escalation. Fixes are applied narrowly to whatever was specifically named, and nothing proactive happens beyond that. If the letter never arrives, accessibility never comes up.
Stage 2: Aware. Leadership knows accessibility is a risk and a responsibility, but the organization's response is still episodic. Maybe there's been a one-time audit. Maybe someone attended a webinar. Accessibility exists as a concept in people's heads, not yet as a workflow.
Stage 3: Developing. This is where most "we take accessibility seriously" organizations actually sit. There's been a real audit and a real remediation push, possibly recurring, possibly with some internal training. But accessibility still lives outside the standard product, design, and engineering workflow. It's a project that gets scheduled, not a property the system enforces. Findings get fixed once — but nothing structurally stops the next feature from reintroducing the same category of problem.
Stage 4: Integrated. Accessibility criteria are built into the design system itself, not bolted on afterward (this is the whole premise of building it in from day one — see our design system article). Accessibility annotations are a standard, non-optional part of design handoff (more on that in our design handoff guide). Automated checks run in CI/CD. Accessibility sign-off is a normal line item in code review, not a special request.
Stage 5: Optimizing. The organization doesn't just prevent regressions — it measures and improves continuously. Accessibility metrics feed into the same dashboards as performance and uptime. Teams treat accessibility debt the way they treat technical debt: tracked, prioritized, paid down deliberately.
Short bolded title line above the table, as required:
Maturity Stage Comparison: What Each Stage Actually Looks Like Day-to-Day
| Stage | Trigger for Action | Where Accessibility "Lives" | New Hire Test Result |
|---|---|---|---|
| 1. Unaware / Reactive | Demand letter or complaint | Nowhere — ad hoc | Fails — no guardrails exist |
| 2. Aware | Leadership concern, no process | In people's heads | Fails — depends entirely on who's asked |
| 3. Developing | Scheduled audits, periodic remediation | A side project, outside sprints | Usually fails — process doesn't reach daily work |
| 4. Integrated | Built into design system + CI/CD | Design system, code review, handoff docs | Passes — tools and templates carry the load |
| 5. Optimizing | Continuous metrics and prioritization | Dashboards alongside performance/uptime | Passes, and issues shrink over time |
The Diagnostic Question That Cuts Through Self-Deception
Ask your team this, honestly: would a newly hired engineer or designer, with zero specific accessibility training, still produce a reasonably accessible component just by following your existing standard tools, templates, and review process?
If the answer is yes, accessibility is genuinely embedded in your system — you're at Stage 4 or 5. If the answer is "well, it depends who trained them" or "our senior dev usually catches that in review," accessibility still depends on specific individuals' tribal knowledge. That's Stage 2 or 3, no matter how many audits you've paid for.
This single question is more revealing than any self-reported checklist, because it forces you to separate what your best people know from what your system actually enforces.
The Stat: WebAIM's annual "WebAIM Million" evaluation of the top 1,000,000 home pages has repeatedly found the vast majority — in recent years around 95–96% — have detectable WCAG 2 failures, with low-contrast text and missing alt text among the most common. That's not a story about bad developers; it's a story about accessibility not yet being built into the standard workflow at almost any organization. (WebAIM: The WebAIM Million)
Why Most Organizations Are Stuck Between Stage 2 and 3
It's not for lack of caring. It's because the natural response to accessibility risk is to treat it like a fire to put out, not a system to build. A demand letter triggers urgency. Urgency triggers a scoped fix. A scoped fix feels like progress — and it is progress — but it isn't maturity.
Meanwhile the exposure keeps growing. UsableNet's annual ADA Digital Accessibility Lawsuit Report has tracked several thousand federal ADA website lawsuits filed per year in the U.S. in recent years, with plaintiffs' firms increasingly sending pre-suit demand letters as well as filing suit — and retail/ecommerce consistently shows up among the most-sued industries in those same reports. An organization stuck at Stage 2 or 3 isn't just leaving users behind; it's leaving the same door open that got it in trouble the first time.
What To Do With Your Stage (Don't Skip Steps)
This is the part teams get wrong most often: they read a maturity model, feel embarrassed about landing at Stage 2, and immediately try to leap to Stage 5 — full CI/CD automation, org-wide dashboards, the works. That almost never sticks.
If you're at Stage 1, you need a real baseline audit before anything else. You can't build a roadmap on a demand letter's narrow findings list.
If you're at Stage 2 or 3, your next move isn't more automation — it's building the internal knowledge and process foundation that Stages 4 and 5 depend on: get your design system and handoff process in order first, because automated testing wired into a system that has no accessible foundations just automates catching the same problems forever.
If you're at Stage 4, your next move is instrumentation — start measuring, not just preventing.
A maturity assessment should set a realistic next step, not inspire an unrealistic leap. Match the plan to the stage you're actually in, not the stage you wish you were in.
Find Out Where You Actually Stand
Self-assessment is useful, but it's also exactly where the "activity vs. outcome" trap does the most damage — it's hard to grade your own homework objectively when the grader and the student are the same team.
Get an honest, outside-in maturity assessment of where your organization actually stands, and leave with a roadmap sized to your real stage, not an aspirational one. Start with a maturity assessment and find out exactly what your next right move is — not the one five stages away.