The C.A.R.E. framework: how to communicate accessibility impact
Doing great accessibility work and explaining the impact that it has are two different skills. A team can be excellent at testing, fixing, and shipping accessible products, and still struggle to make the case to a VP, a legal team, or an awards panel.
That gap is what the C.A.R.E. framework closes. It is one repeatable structure for turning accessibility work into a narrative with evidence behind it.
Why this approach pays off twice
This pays off in two directions that reinforce each other.
Internally, the teams that keep getting resourced for accessibility work are the ones that can point back to what happened last time: what worked, what was learned, and what changed.
Externally, that same skill powers a Gaady Award submission, a conference talk, a case study, or a response to a tough customer question. It's the same approach in every case, turning the work into a narrative with evidence behind it.
Grounding the story in the curb-cut effect helps too. Designing accessibility routinely unlocks value far beyond the audience a team set out to serve.
Introducing the C.A.R.E framework
Every credible accessibility story shares the same through-line: the involvement of lived experience, not as an audience served, but through perspectives that helped shape the work in the first place. C.A.R.E. is built to surface exactly that, stage by stage.
Was it:
- a customer who couldn’t complete a transaction?
- a colleague who flagged a barrier internally?
- a research participant whose experience your team could no longer ignore?
Describe what the baseline experience felt like, and use tools like video or direct quotes whenever you can. This is what makes the “after” land later.
If this wasn’t business-as-usual work for your team, it’s okay to say so. Naming it up front helps a story build trust rather than lose it. Every organization has to start somewhere!
Don’t stop at “we tested with people with disabilities.” That’s a good start, but not the finish line. Show where feedback from people with disabilities changed the direction of a decision, rather than simply validating something that was already locked in.
Think across your full product development lifecycle:
- Discovery: interviews, diary studies, and concept testing
- Design: wireframes, prototypes, and accessibility-annotated designs
- Development: reviews and QA across a range of assistive technologies
- Launch: validation and beta testing
- After launch: continuous research and regression tracking
The earlier lived experience is incorporated, the less retrofitting your team will need to do later and the greater the impact of the effort.
Keep asking: how did this input change what was built? Not just how the audience benefited from what was built.
Almost every accessibility team has fielded some version of the question, "well, how many of our customers actually use a screen reader?" Combat that by pairing numbers with real user experiences: quotes, video, and before-and-after moments that put a customer to the impact.
Draw from four buckets of outcomes:
| Outcome type | Examples |
|---|---|
| User outcomes | Task completion, confidence, satisfaction, and reduced frustration |
| Product outcomes | Fewer issues, faster releases, and better design |
| Business outcomes | Reduced support tickets, retention, revenue, and NPS |
| Accessibility outcomes | WCAG conformance, audit improvements, and critical issues fixed |
This is not an exhaustive list, and you don't need to strive to collect all of these, some will be more relevant and/or readily available than others. Pick two or three outcomes across categories rather than focusing on just one. Different outcomes resonate with different audiences: legal cares about conformance and audit improvements, while your Head of Customer Experience will care more about retention. This approach is what will help you flex your storytelling muscles regardless of who is in the room.
One tactic worth considering: when precise revenue impact data isn't available, try building a directional estimate. For example, for a B2C organization, you could: take your customer base, apply an assumed percentage of customers with disabilities (based on your market, industry, etc.), and multiply by average revenue per user. This example will help you demonstrate the retention impact, and put a dollar figure to it. It's directional, not exact, so state any assumptions transparently, and apply a conservative estimate if you want a more cautious approach.
This stage is key for setting you up for the future. Be honest about the trade-offs that were made, what didn’t get done, and what surprised you. Naming your constraints doesn’t weaken your story. It’s what makes it believable, and it’s what sets you up to remove those roadblocks next time. This will also help you make a compelling case to dedicate time to any unfinished or deprioritized items.
Evolution is where you resist the finish-line mentality. While it’s important to celebrate your successes, accessibility is ongoing, and what’s next matters as much as what’s done. There’s always more to do!
One story, many audiences
We often get asked if different versions of the story need to be built for every audience. The simple answer is no. One well-built story, with the emphasis shifted depending on who’s listening, is usually enough.
For an internal audience, lean into the nitty-gritty of the approach, the operations will resonate more than for an external audience who won’t have the same context. For a conference talk, lean on the catalyst and evolution, this is the hook that will resonate with an audience who wants to know why the work started and how it landed without needing an org chart to follow along.
Build your own story
The C.A.R.E. Framework worksheet walks through each of these four components so you can build your own accessibility story, whether that’s an internal update, a Gaady Award application, or a conference talk.