Why Accessibility Buy-In Falls Flat
Convincing stakeholders to invest in accessibility often fails because of how the conversation is framed. Arguments based on corporate responsibility, ethics, and legal liability rarely move the needle. People tend to dismiss concerns they cannot personally relate to, and you cannot build empathy with facts, charts, or compliance checklists alone.
The deeper issue is that many people simply do not understand how accessibility applies to their product. Accessibility is frequently seen as a dull constraint that produces uninspired designs, so businesses dismiss it as a niche concern for an irrelevant minority.
A more effective approach is to make accessibility visible. Start by mapping the different types of accessibility needs — permanent, temporary, and situational — directly onto your product. This gives people a concrete reference point instead of an abstract concept. From there, run a small number of usability sessions to see where customers struggle or get blocked. If direct customer access is unavailable, work through sales, customer support, or customer success teams for proxy testing.
Watching real customers encounter real barriers in a real product has more impact than any slide deck. Once that groundwork is laid, you can introduce the broader terminology — inclusive design, neurodiversity, EAA, WCAG, ARIA — and bring people with disabilities into testing to properly represent your customer base. Ask for small commitments first, then build on them. Throughout, repeat the same message: accessibility is not expensive if it is built in early, but it is very expensive when retrofitted later.
Responding to Common Objections
Anticipating objections is part of the process. Concerns about cost, timing, competition, and product complexity will surface, so it helps to have concrete responses ready that reframe accessibility as a business advantage rather than a charitable expense. Below are seven common stakeholder objections and rebuttals that tie accessibility to revenue, risk, and customer experience.
"Accessibility Is an Edge Case"
Objection: "Given the state of finances right now, we can't invest in accessibility."
Response: "1 in 6 people worldwide experience disabilities. Competitors [X, Y, Z] have already launched accessibility efforts ([references]). It doesn't have to be expensive — but it will be very expensive if we retrofit later."
"There Is No Business Value in Accessibility"
Objection: "We need to focus on efforts that will directly benefit business."
Response: "The extended accessible market is estimated at 2.3 billion people controlling an incremental $6.9 trillion in annual disposable income. Accessibility aligns with goals to increase leads, boost customer engagement, mitigate risk, and reduce costs."
"We Don't Have Disabled Users"
Objection: "Our data shows no disabled users at all. This seems like a waste of resources."
Response: "If a product is inaccessible, users with disabilities can't and won't use it. Make it accessible and we open the door for prospective users for years to come. Small improvements can have high impact."
"Screen Readers Won't Work With Our Complex System"
Objection: "Our application is complex and used by expert users. Would it even work with screen readers?"
Response: "It's not only about screen readers. Accessibility needs can be permanent, temporary, or situational — think of holding a baby or recovering from an accident. It is universally useful for everyone."
"We Can't Win Market With Accessibility Features"
Objection: "To increase market share we need features that benefit everyone."
Response: "Modern products succeed not by adding more features but by designing better ones — improving efficiency, success rate, and satisfaction. Voice control and auto-complete were originally accessibility features and are now used by everyone. The entire customer base benefits."
"Our Customers Can't Relate to Accessibility Needs"
Objection: "Our customers are young and healthy. Accessibility isn't a priority."
Response: "People of all ages can have accessibility needs. Accessibility features signal inclusivity to every potential customer. Younger audiences increasingly value corporate responsibility, making this a differentiator that builds long-term loyalty."
"Let's Add Accessibility Later"
Objection: "We need to focus on core features. We can add accessibility once the product is stable."
Response: "Integrating accessibility from the start is far more cost-effective than retrofitting. Adding it after development means auditing, then redesign and redevelopment — significantly more expensive. Delaying also exposes the business to legal risks as lawsuits for non-compliance increase. The financially prudent move is to do accessibility now."
Building Accessibility Research From the Ground Up
Establishing accessibility research practices from scratch can feel overwhelming, especially in large organizations. Booking.com's case study on building accessibility research offers a practical model. A key lesson: automated accessibility testing alone is not reliable. Compliance does not guarantee good user experience — manual testing ensures customers actually achieve their goals effectively.
Start by gathering colleagues and stakeholders who care about accessibility. Document existing research and identify gaps. When possible, include 5–12 users with disabilities in accessibility testing. Launch a small initiative around key flows first — tap into critical touch points and research them — then extend to components, patterns, and full service design. Eventually aim for inclusive sampling across all research projects, with at least 15% of usability testers having a disability.
Recruiting testers with disabilities is a common struggle. Reach out to local chapters, training centers, non-profits, and public communities for people with disabilities. Ask the admin for permission to post a research announcement, and include an extra $25–$50 in the incentive for on-site testing to cover disability-related transportation.
Adapting Microsoft's Inclusive Design Toolkit to your own product's user needs makes disability considerations less abstract and easier for the whole organization to relate to. The core principle: inclusive design builds a door that anyone can open. Accessibility is not a checklist — it is a practice that involves real people with real disabilities throughout all UX research activities.
Getting the Ball Rolling
For most people, accessibility is a black box. They have never seen a customer with a disability using their product and do not understand what it involves. Making accessibility relatable and visible — even through just a handful of tests with people with disabilities — changes the conversation.
No manager deliberately wants to ignore their paying customers' needs; they simply need to understand those needs first. Ask for small commitments, build on early wins, and set up an explicit accessibility roadmap with actions, timelines, roles, and goals. That approach generally works far better than arguing over legal and moral obligations, which tends to put stakeholders on the defensive and stalls progress entirely.
Resources To Keep Building The Case
Persuading stakeholders is rarely a one-off conversation. You will need a steady stream of evidence, examples, and techniques to keep accessibility advocacy moving forward. The following starting points cover both the strategic side of pitching accessibility and the practical side of researching with disabled users.
The Strategic Pitch
- Making the business case: R Gregory Williams’ piece on building arguments that land with budget holders gives concrete framing for return on investment.
- Research as a tool for change: Maya Alvarado documents how Booking.com built accessibility research practices into a mature organization, showing where such work plugs into existing processes.
- Advocacy toolkits: Yichan Wang’s Designer’s Accessibility Advocacy Toolkit and the related Inclusive Design Toolkits from Vitaly Friedman collect templates and templates-ready materials for persuading teams internally.
- Case studies as evidence: Deque’s accessibility case study and success-story library is a quick way to find sector-specific examples of how accessibility fixes delivered measurable results.
The Research Practice Side
- Getting the method right: Brian Grellmann’s guide to accessible UX research runs through study design, tech choices, and interview technique from start to finish.
- Recruiting inclusively: Ela Gorla’s advice on participant recruitment cautions against leaning on the same small groups of disabled testers and shows how to widen the pool.
- For screen-reader studies: A cheatsheet by Slava Shestopalov distills what to watch for when testing with blind users, while Tanner Kohler’s research summary covers mobile screen-reader quirks specifically.
- Practical moderation tips: Most usability work is fixable: Peter McNally offers tactical advice for running sessions where disabled participants feel comfortable and heard.
Accessibility Audits Are Not Enough
When someone asks you for “proof” of an accessibility problem, the strongest evidence usually does not come with URLs or screenshots. Staff work fine; real problems show up in how ordinary people interact with a digital product. While automated checks and expert audits remain useful, they miss failures that appear only during use — like a help chat that announces a screen-reader error message that does not open its focus, or a form that is indistinguishable from its darker backdrop, or a barely-visible “Close” button. What works better when building and sustaining a case is to combine sparse automated stats with interviews and observations for context designers and developers can actually act on, allowing anyone to start with access to research of their own — joining a journey towards inclusive design that usually begins as painful and does not have to be. If teams need to iterate, they need the input of disabled users directly: no shortcut can replace watching a real attempt to complete the task.
