Accessibility Is a Business Decision, Not a Compliance Task

Treat accessibility as product quality and risk management, not a final checklist. Here is how to build accessibility into decisions, delivery, and cross-functional accountability.

Most accessibility work I see in the wild is done in the wrong order, by the wrong people, at the wrong time. A design ships. QA flags it. A junior designer is asked to "add accessibility" to a finished mockup. They tweak some contrast values, add some aria-labels, and call it done. The audit passes. The product is technically compliant. And exactly nobody using assistive technology is actually having a better experience. We've shipped accessibility theatre.

When we built the NBC Direct Brokerage app, I made a deliberate decision early on: accessibility wasn't a compliance line item. It was a design constraint, in the same category as performance and visual hierarchy. The app shipped to a 4.7-star App Store rating, and a meaningful portion of that rating came from older customers who told us, in reviews, that it was the first banking app they'd been able to use without help. That's not a compliance win. That's a business win measured in retention, word-of-mouth, and a very specific kind of customer loyalty you cannot buy.

Accessibility is not an edge case. It is core product quality, risk control, and customer trust. Teams that treat it as strategy ship better experiences for everyone.

Compliance gets you sued. Accessibility gets you customers.

Treating accessibility as a compliance question gets you the bare minimum needed to avoid legal trouble. Treating it as a business decision gets you a product that works for an enormous, underserved market segment that competitors are actively shipping a worse experience to. Roughly one in five users in any consumer app has some form of accessibility need: visual, motor, cognitive, or situational. Most products treat them as a rounding error. The companies that don't, win them disproportionately.

Microsoft figured this out a decade ago when they reframed inclusive design as a growth strategy. Apple has been using accessibility leadership as a competitive moat since the original VoiceOver. The pattern is clear: accessibility done well is a feature, not a tax. The only question is whether your team treats it that way.

What we did differently on the NBC Direct Brokerage app

Six things, in roughly chronological order, made the difference. None of them were technically complicated. All of them required a leadership decision that accessibility was non-negotiable.

1. We hired with assistive tech in the room

From week one, every design review included a moment where someone walked the screens with VoiceOver. Not in a separate audit. Not a week later. In the same review. This single ritual changes everything because it makes accessibility issues visible while the design is still cheap to change. By month three, the team was designing with VoiceOver in mind without anyone having to remind them. The constraint became muscle memory.

2. We built tokens, not exceptions

Every colour in the system passed WCAG AA against every other colour it could appear next to. We built that constraint into the token architecture itself. If you tried to use a combination that failed contrast, the linter caught it before the PR opened. This meant designers couldn't accidentally ship inaccessible work even if they tried. Accessibility wasn't a thing we checked. It was a thing the system enforced.

3. We tested with real older users, not lab proxies

The biggest lift came from sitting with users in their seventies who'd never used the app before. They taught us things our usability lab never would. They taught us that our "clear" iconography was meaningless without labels. That our font sizing felt cramped at the system default. That our authentication flow assumed a kind of confidence with phones that simply wasn't universal. We rebuilt three core flows based on those sessions, and the App Store reviews from older customers visibly shifted.

4. We treated cognitive load as an accessibility issue

Most accessibility work focuses on motor and visual impairment. Cognitive accessibility gets ignored: reading level, decision load, instruction clarity. We pulled every piece of copy in the app down to a 9th-grade reading level and shortened our average sentence length by about thirty percent. The change was invisible to most users and life-changing to a meaningful minority. Support tickets about "I don't understand what to do" dropped by half in the next quarter.

5. We made keyboard and screen-reader testing part of "definition of done"

Engineers couldn't ship a feature unless they'd walked it with a keyboard and a screen reader. This added maybe ten minutes to each ticket. It saved us hundreds of hours of remediation work on the back end, and it built engineering muscle memory for accessibility from day one.

6. We measured what mattered, not what was easy

We didn't track "accessibility audit pass rate." We tracked task completion time for users with assistive tech, and we tracked the percentage of App Store reviews mentioning accessibility, ease of use, or readability. Those numbers told us whether the work was actually making the app better. They trended upward consistently for the first eighteen months after launch.

The objections, and why they're wrong

Every accessibility conversation eventually hits the same three objections. Here's how I respond to each, with as much patience as I can manage.

  1. "It's too expensive." Building accessibility in from the start adds maybe 5–10% to design time. Retrofitting it after launch costs 5–10x that. The expensive option is the one that defers it.
  2. "It'll slow us down." Only at the start. After six weeks, the team is faster, because constraints sharpen design decisions and reduce rework. I have never seen a team get slower in the long run from designing accessibly.
  3. "Our users don't need it." You don't actually know. You know what your current users tolerate. You don't know what users walked away in the first thirty seconds and never came back. Accessibility is the experience tax you pay to capture the users you're currently invisible to.

Where to start, if you're inheriting an inaccessible product

Don't try to fix everything. Run a one-day audit on your three highest-traffic flows. Find the five biggest blockers. Usually that means contrast, focus order, target size, missing labels, and reading level. Fix those in the next sprint. Communicate the wins internally and publicly. Then build accessibility into the design system so the next ten flows can't ship inaccessibly. That sequence: audit, quick wins, systemic guardrails. It turns accessibility from a guilt-inducing backlog into a steady drumbeat of improvements.

A practical first-30-days checklist

The NBC Direct Brokerage rating wasn't built in a launch quarter. It was built by a team that, eighteen months earlier, decided accessibility was going to be a first-class concern. That decision compounded. Every team that makes the same call gets the same kind of compound interest. The only question is whether you make the decision now, or after a customer has to publicly explain why your product locked them out.

In short

Accessibility creates commercial value when it is built into systems, rituals, and accountability from day one. Treating it as late compliance is the slow and expensive path.

Practical checklist

  • Assign accessibility ownership across product, design, engineering, and QA.
  • Include accessibility acceptance criteria in delivery planning.
  • Prioritise high-risk journeys first (authentication, payments, support).
  • Run testing with assistive technology before release, not after.
  • Track accessibility debt and remediation cycle time as operating metrics.

When to use this approach (and when not to)

  • Use this approach when decisions carry customer, revenue, or delivery risk.
  • Use it when multiple teams need consistent quality standards.
  • Use it when you need repeatable outcomes, not one-off output.
  • Do not treat accessibility as a final audit checkbox when legal and brand risk are live on core journeys.
  • Do not rely on automated scans alone—validate critical tasks with assistive tech and real flows.
  • Do not park fixes in "phase two" when exclusion is happening in authentication, pay, or support paths now.

Frequently asked questions

Why is accessibility a leadership issue, not just a design task?

Because it affects risk, trust, retention, and legal exposure across the business. It needs cross-functional ownership, not isolated design fixes.

When should accessibility work happen?

From the start. If teams defer accessibility to the end, costs increase and quality drops because core decisions are already locked.

What is the biggest accessibility mistake in product teams?

Treating accessibility as a late compliance check instead of a product quality requirement from discovery onwards.

How can leadership make accessibility operational?

Include accessibility in planning, acceptance criteria, quality gates, and KPI reviews across teams.

Why does accessibility improve outcomes beyond compliance?

It improves clarity, robustness, and usability for everyone, which strengthens trust and reduces support friction.