How To Build A Business Case To Promote Accessibility In Your B2B Products — Smashing Magazine

The Argument Stakeholders Actually Hear

Passion for accessibility rarely translates into budget. Gloria Diaz Alonso learned this the hard way: a polished presentation on the moral and usability benefits of inclusive design was met with indifference from stakeholders who saw no revenue impact, no regulatory pressure, and no reason to act. The problem was not the idea, but the framing. A presentation is not a business case.

The decisive question is not “Why is accessibility good?” but “Why should we spend money and resources on this instead of something else?” Answering that requires translating design conviction into the language of risk, revenue, and competitive positioning. Here are the key questions that structure the analysis and how to approach them.

Addressing the Cost Objection Before It Arises

Every engineering hour spent on accessibility is an hour not spent on new features. That is an opportunity cost stakeholders will calculate, so the case must reframe the expense as an investment with measurable returns. Four questions guide the effort:

• Why should we spend money and resources on this and not on something else?
• What exactly do we want to do?
• What are the expected results?
• How much would it cost?
• How can I make a decision?

Risk Prevention as a Starting Point

Most stakeholders have heard of accessibility through regulation, and that awareness is an entry point. The European Accessibility Act (EAA), the Web Accessibility Directive (WAD), the Americans with Disabilities Act (ADA), and Section 508 of the Rehabilitation Act have made compliance a boardroom topic. A summary table covering the goal of each regulation, who it targets, relevant deadlines, and how it affects your specific business context helps ground the conversation without overwhelming.

For companies operating in one country, add a summary of local regulations. Explain that WCAG is the third-party international standard most laws reference. But be careful: regulation alone rarely closes the deal. If your company is not currently required to comply, the response is predictable — “We are not required to do it.” Early adoption means preparing in advance at marginal cost for new features, but many organizations will still deprioritize that until the requirement is certain. Regulation opens the door; it does not walk the case through it.

The WCAG baseline is useful context, but stakeholders need evidence of value beyond legal exposure. If that is the only pillar of the case, the easy exit is always available.

Finding the Commercial Leverage

Procurement is changing. Larger companies increasingly require accessibility as a condition of vendor selection, which transforms compliance into a checkbox in the sales process. To determine whether this affects you, talk to the sales team about client inquiries regarding accessibility plans. If a strategic client asks — or pushes for — accessibility commitments, document it. Background research matters: Are these clients bringing significant revenue? Are they industry leaders others follow? Did they raise the question once, or did they pressure for a concrete answer?

Competitor analysis is another angle. Check whether competitors publish accessibility statements, display external certifications in their footers, or mention compliance in sales materials. Basic keyboard navigation testing and automated checkers can estimate their current level. If competitors are non-compliant, accessibility becomes a differentiator. If they are compliant, ignoring the issue risks losing deals.

Bringing the Value Back to Your Users

A recurring objection is that a B2B product has few users with disabilities, so accessibility is superfluous. The rebuttal requires specific examples, not general statements. Analyze your actual user base:

• If users are office workers spending hours in the software, keyboard navigation improves efficiency.
• If the user age skews over fifty, font size flexibility matters.
• Outdoor use means sun glare demands high contrast.
• Workers wearing gloves need larger target sizes.

Neurodiversity should always be factored in. The goal is identifying everyday situations where accessibility features benefit users without disabilities.

Evidence beats theory. Search insight repositories for accessibility-related feedback, knowing that users rarely say “accessibility” — they say “colors,” “hard to click,” “zoom,” “keyboard,” or “error.” If a repository does not exist, customer service records and help requests are an alternative source of evidence. Discover user feedback about difficulty with color contrast, click targets, or keyboard navigation — these are accessibility requests that the user might not label as such.

Accessibility as a Subset of Good Practice

Accessibility work rarely exists in isolation from design and development quality. In design, the overlap with usability heuristics is substantial: clear labels, precise error messages, consistent layout, page structure, and user control are simultaneously accessibility improvements. Many WCAG design-related success criteria map directly onto Nielsen Norman’s ten usability heuristics, which stakeholders already accept as good practice.

For development, accessibility produces more structured, readable code. Proper markup, logical code order, landmarks for responsive interfaces, correctly identified components with unique labels — all prevent unexpected behavior while satisfying accessibility requirements.

QA teams can align their existing responsibilities with accessibility testing. Responsiveness testing is typically mandatory, as is keyboard navigation, which it turns out also increases efficiency for repetitive tasks. The hidden advantage is that considering accessibility means adopting clearer guidelines for the entire development loop — which is precisely what teams should be doing anyway.

Building the business case means showing that accessibility is not a favor done for a tiny group of disabled users. It overlays with the things the organization already claims to value: product quality, engineering maintainability, competitive position, and risk management. That is what makes the conversation one about investment rather than expense.

Two Starting Points: New Builds and Legacy Code

When you argue for accessibility inside your organization, the strategy you propose depends heavily on where your product stands in its lifecycle. Two situations cover most cases: building something new, or retrofitting accessibility into a product that has been live for years.

Building Accessibility In From Day One

New products and features offer a rare chance to apply an accessibility-first approach. When accessibility is a default consideration from the start, you prevent issues from ever reaching users and avoid the expensive rework that retroactive fixes require.

The critical enabler here is treating accessibility as a shared responsibility, not a specialist concern. If you wait until after implementation to run an audit, you inherit every issue that could have been avoided during design and development. Some of those issues become disproportionately hard to solve late in the process. Consider drag-and-drop for rearranging a list: if single-point interactions were a requirement from the beginning, implementation is natural. If you only realize the need after release, you are redesigning an interaction flow across devices and edge cases.

Distributing ownership means each role carries a piece of the work:

• Product owners must include accessibility as a requirement and allocate time and resources for it.
• Designers follow best practices and guidelines so the design itself is accessible.
• Developers include proper markup, semantics, and follow accessible coding guidelines.
• QA acts as the final filter, catching as many issues as possible before release.

When everyone spends a bit more effort on accessibility within their existing tasks, the result has a solid baseline. You will still want expert input on specific problems, and an audit of the released product will likely uncover some issues that slipped through. But the volume will be drastically lower.

That reduction matters because the audit process itself is expensive and slow. First you define who runs it — internal staff or an external provider. Then you agree on scope, since checking an entire product is impractical; you start with the most important workflows and key pages. Analysis produces a prioritized list of issues with remediation recommendations.

Remediation planning follows: estimating team capacity, grouping similar issues to minimize context switching, and eliminating duplicates that arise when auditors don’t know your architecture — several documented issues may trace back to a single shared component. For a large product, this entire process can consume three months before any actual fixing starts. Fewer issues reaching the audit means the whole cycle compresses significantly.

An accessibility-first approach also has a clear learning curve. People take extra time on their first few tasks while they learn alternative patterns — a designer figuring out how to convey status without relying on color alone, for instance. After a few repetitions, valid strategies come to mind automatically and the effort drops. Investing in educational resources accelerates that curve. People work better when they understand the value of what they are creating, and internal accessibility expertise reduces the overall effort.

This strategy applies to new features within existing products as well. Including accessibility by default in everything new prevents issues from accumulating.

Considering accessibility from the beginning can help you to largely reduce the number of issues that may appear in audits after the release since it prevents the issues from accumulating, distributes the effort across the full product team, and substantially reduces the cost, as there will be less need for retroactive remediation of the issues that appear.

Retrofitting Accessibility Into Existing Products

Legacy products present a different challenge. Accessibility competes with a million other priorities and can look like a massive effort that brings reduced value. The technical debt may be high, the user base of people with disabilities small, and the sheer number of existing issues so overwhelming that fixing everything at once would take years. You won't get anywhere trying to solve all problems simultaneously. A few strategies can kick things off.

Start with the Design System. Issues there are inherited by every product that uses it, so fixing them at the source is far more efficient than having each product team solve the same problem independently. Run a quick review:

• Does it consider color contrast?
• Does it consider target size?
• Does the documentation include accessibility considerations or guidelines?
• Are there color-dependent components?

If a dedicated team owns the Design System, reach out to understand their awareness level. Where knowledge gaps exist, offer an introduction or help them fix what they don't know. When you spot issues, organize a proper audit of the design system from the design and development perspective and pair up with the team to fix what you can — extra hands on strategic issues. This collaboration is also a chance to document guidelines for complex components, helping product teams reuse accessible patterns.

If the Design System is in good shape, doesn't exist, or you prefer to focus on the product itself, set a manageable scope. Pick the two or three workflows your users rely on most. Within those, choose pages with different structures — a form, a table, plain text, heavy imagery — to get a representative sample. Pages sharing a structure often share problems, so variety surfaces more critical issues.

With scope set, audit — but with a reduced scope. A product that has never considered accessibility will have an overwhelming number of issues. A full audit tests all 59 success criteria at levels A and AA, with manual testing across browsers, screen readers, and devices. You could end up with hundreds or thousands of documented issues, making the effort feel impossible and the business case untenable. Unless strategic customers are demanding compliance, that pitch fails.

Instead, propose a reduced first audit focused on three quick wins:

• Running an automatic check. Fast, self-reporting, and capable of finding roughly 30% of issues — a good starting point.
• Doing basic manual keyboard testing. Verify that all interactive elements are focusable, in logical order, and respond to expected keyboard commands.
• Doing a quick responsive test. What breaks when changing viewport or zooming in? Can functionality still be used?

These three tests surface a large portion of critical blockers while staying close to the overlap between accessibility and general good design and development practice, without consuming excessive time.

The goal of this first audit is not to solve everything — it's to get easy-to-identify critical issues as a starting point. That approach delivers value quickly while reinforcing that accessibility is not a one-time fix but a continuous process. It also reveals where teams need guidelines and training, and helps define minimum requirements for each role going forward. Treat it as a learning opportunity.

For self-auditing, Accessibility Insights is useful since it explains issues with visual helpers and guides you through the process. Screen reader testing adds value but is difficult without prior experience; many issues will already surface through automatic checks and keyboard testing.

Expected Outcomes And How To Frame Them

The outcome you target shapes the entire approach. The core question is whether you’re aiming for formal compliance or for practical user value that prepares the product for the future.

Compliance is essentially a binary state. To meet WCAG AA, for example, you must satisfy all success criteria at that level and every level below it. Each criterion exists to address a specific disability; cherry-picking leaves people out. In practice, even compliant products have minor issues, but the standard is all-or-nothing. Verifying this typically requires multiple audits, preferably from a certified external party. For a product that has never considered accessibility, reaching full compliance is a significant undertaking and may not be the best first move. It usually makes sense when the driving motivations are risk reduction and competitive advantage.

Compliance is binary, but accessibility is a spectrum. You can have a pretty good level of accessibility even if you are not fully compliant.

If the goal is to start including accessibility to help users and prepare for the future, a lighter result is more realistic. Instead of pursuing perfection, focus on eliminating the most critical barriers as quickly as possible. That means identifying and fixing the highest-impact issues and applying an accessibility-first approach to new development. The result won’t be perfect or fully compliant, but it removes major blockers with manageable effort and establishes a foundation for iterative improvement.

It is impossible to ship a 100% accessible product. As a product evolves, issues will always slip through. The objective is to ensure those issues are minor rather than critical. Getting resources to fix the most important problems already delivers value, even without full compliance.

Estimating The Costs Realistically

An accessibility-first approach typically requires assigning 5 to 10% of product capacity, settling toward 5% once the team climbs the learning curve. The business may still see this as too high. To counter that perception, emphasize the side value of accessibility and its significant overlap with standard design and development best practices.

To justify the cost, look for internal examples that compare against retrofitting. If none exist, pick a simple issue—like the absence of heading structure on a page—and ask a developer to estimate what it would take to retrofit that structure across 40 released pages. That tangible number makes the case for doing it right the first time.

Cost estimation for existing products is harder. A rough audit will reveal how many critical issues exist, and developers can help estimate the effort for the most obvious fixes.

The most interesting approach that helps you to reduce the “cost of accessibility” is exploiting the overlap between accessibility and usability or product features.

Where accessibility overlaps with usability or product features, it doesn’t demand dedicated capacity. Missing input labels confuse users—that’s a usability defect that is also an accessibility issue. Reflow criteria are time-consuming because they depend on responsive design, but that is still just good design. Review the product backlog and user feedback to find where accessibility improvements align with prioritised features, such as enabling mobile use or improving keyboard-navigation efficiency. The greater the overlap, the smaller the incremental effort.

When starting, keep the ambition modest. Small, steady progress beats a stalled grand plan. Early results spark curiosity, attract allies, and build a case for expanding scope. Alternatively, decide on an affordable capacity—perhaps 10 to 15%—and scope the work to fit that budget.

Finally, inventory existing resources before adding costs. Accessible design-system components, internal guidelines, related company goals, and educational sessions are all assets that don’t add to the project total. If the design system is already accessible, leverage it and ensure components are implemented correctly. Present this support as part of the business case.

Presenting The Decision To Stakeholders

Decision-makers are busy. An executive summary that brings the key considerations together helps them make an informed choice. Structure it around the three central questions:

• What exactly do we want to do?
• What are the expected results?
• How much would it cost?

If you are proposing a single direction, such as accessibility-first for all new work, a single slide with those answers is sufficient.

If there are multiple possible directions—for example, different products with different conditions or varying capacity commitments—use a decision-making diagram or matrix. Visualising the factors that influence strategy helps stakeholders see which products are the best starting points and where more capacity makes sense. Useful criteria include:

• Do we have clients asking about accessibility?
• Is the product already built on an accessible design system?
• Are we planning to open part of the product to B2C?
• Is responsive and mobile interaction a priority?
• Do we want to target governmental institutions?

Mapping these factors against possible directions clarifies the trade-offs, particularly when accessibility is being introduced across several products at once. Place the summary at the end of the presentation, or at both the beginning and the end, so the recommendation stays visible.

When The Timing Is Wrong

Even a strong business case can lose momentum due to shifting priorities, leadership changes, contract endings, or budget constraints. That is frustrating, but the effort is not wasted. Getting the topic onto the table plants a seed. In the meantime, run evangelisation sessions with teams to build allies and keep the conversation alive. When the next opportunity arrives, people will already understand the subject and support will come more easily. The change you have initiated will resurface, and your groundwork will pay off.

Key Takeaways

• Show how accessibility affects your own products and users specifically.
• Treat accessibility as a potential competitive differentiator.
• Reduce effort by pairing accessibility with usability work and planned product features.
• Factor in existing resources to lower the total project cost.
• Align expected results with the level of effort you can commit.
• Visualise your strategy to support quicker and better-informed decisions.
• Start small and iterate—it beats not starting at all.