The Business Case Isn't the Enemy of Community Signal

Keisha's governance critique in her analysis of icon menu failures is structurally sound. Organizations that only fix accessibility when someone builds a revenue argument will, predictably, break it again. That pattern is real and well-documented. But the article's implicit conclusion — that business case framing is somehow in tension with community-centered accountability — deserves a harder look. After fifteen years covering this space, I'd argue that framing is a false binary, and accepting it may actually slow the governance reforms Keisha is rightly pushing for.

The question isn't whether community signal should be primary. It should be. The question is what organizational architecture makes that signal durable — and business cases, built correctly, are part of that architecture rather than a substitute for it.

Where the Governance Critique Lands

Keisha is right that patch-and-regress is the dominant failure mode. The Section 508 program maturity model (opens in new window) is explicit about this: organizations at lower maturity levels respond to individual pressure points rather than building standing feedback mechanisms. Icon menu failures are a textbook example. A component gets flagged, a sprint gets funded, the fix ships — and then a design system refresh eighteen months later reintroduces the broken pattern because no one connected the original fix to governance infrastructure.

That's a real problem. But notice what's doing the work in that failure scenario: it isn't the business case that caused the regression. It's the absence of governance. The business case got the fix funded. The missing piece was the institutional memory and process architecture to protect that fix over time. Those are separable problems, and conflating them leads to a misdiagnosis.

Business Cases as Governance Infrastructure

Here's the analytical frame I'd push back with: a well-constructed business case isn't a one-time persuasion event. It's a data artifact that, if built into the right systems, becomes part of the governance infrastructure Keisha is calling for.

Consider how WCAG 2.1 Success Criterion 4.1.2 (opens in new window) gets operationalized in mature organizations. The technical requirement exists. Legal exposure exists. Community feedback exists. But the organizations that actually maintain compliance over multiple design cycles are the ones that attached measurable outcomes to the original fix — retention metrics, support ticket reduction, task completion rates from usability testing with disabled users — and built those metrics into their design system's acceptance criteria. The business case didn't replace community accountability. It gave the community's feedback a format that survived leadership turnover and product roadmap churn.

This is the strategic alignment dimension that often gets underweighted in governance conversations. Community signal is primary data. But primary data that isn't connected to organizational decision-making systems doesn't stay primary for long. It gets deprioritized the moment a new VP arrives with different priorities.

The Real Risk of Dismissing Business Cases

The deeper concern I have with Keisha's framing — and I want to be precise here, because her structural critique is correct — is that dismissing business case framing as insufficient can inadvertently give organizations permission to dismiss it entirely. If the message accessibility advocates send is "business cases aren't enough," some product organizations will hear "business cases aren't necessary" and default to doing nothing until legal pressure forces action.

The DOJ's web accessibility guidance (opens in new window) is clear that Title II and Title III obligations exist independent of business justification. But enforcement is uneven, and the organizations most likely to face enforcement action are often not the ones most likely to change behavior in response to it. According to the WebAIM Million annual report (opens in new window), the prevalence of detectable WCAG failures on high-traffic homepages has remained stubbornly high despite years of legal pressure — suggesting that legal framing alone isn't moving the needle at scale.

Business cases reach organizational constituencies that legal and moral framing doesn't. As explored previously in this publication's analysis of icon menu failures, product teams respond to metrics framing in rooms where other arguments stall. That's not a reason to abandon community accountability — it's a reason to use every available lever simultaneously.

What Durable Accessibility Change Actually Requires

The Great Lakes ADA Center's resources on organizational accessibility (opens in new window) and similar regional centers consistently point to the same pattern in organizations that maintain accessibility gains: they don't choose between community accountability and business alignment. They build systems where both inputs are standing requirements.

In practice, this looks like: community feedback channels that feed directly into design system governance; accessibility metrics embedded in product OKRs alongside revenue metrics; and business cases written to include user impact data — task completion rates, error rates, qualitative feedback from disabled users — not just revenue projections. The W3C's Business Case for Digital Accessibility (opens in new window) explicitly frames community benefit and business benefit as complementary rather than competing.

This is the strategic alignment lens our editorial approach consistently applies: accessibility gains that survive organizational change are ones where community signal has been translated into multiple organizational languages simultaneously, not sequenced with community first and business second.

The Sequencing Problem

Keisha's article implies a sequencing: community signal should come first, business cases come second. The sequencing framing itself is part of the problem. In organizations with mature accessibility programs, these aren't sequential inputs — they're concurrent ones. Community feedback is collected continuously. Business metrics are tracked continuously. Governance structures ensure both feed into the same decision-making process.

Building on this framework for understanding icon menu failures and their organizational roots, the real intervention isn't choosing which argument to lead with. It's building the organizational infrastructure where neither argument has to be made repeatedly from scratch — where community signal and business alignment are both standing inputs into a system that doesn't depend on any individual advocate's ability to make the case in the right room at the right time.

That's a harder organizational problem than either framing alone suggests. But it's the accurate one. The practical implication for governance leads: stop writing business cases as one-time funding requests and start writing them as living documents tied to design system acceptance criteria, OKR cycles, and community feedback loops. That's the structural move that makes community signal stick.