Key stages covered
- Predictable delivery is a competitive advantage
- Measurable intangibles
- Intangible 1: How well known the goals and problems are
- Intangible 2: Engagement in collaboration, not merely coordination
- Intangible 3: How adaptable teams are to change
- Intangible 4: The cost curve of risk
- For leaders: your opportunity
Predictable delivery is a competitive advantage
So why does it elude so many digital organizations?
When executives attempt to gain clarity into the workings of digital delivery cycles they are often rebutted with circular reasoning, arguments about resourcing and plenty of technobabble.
What gives? One minute a project is delivered on time and under budget, while others struggle to even find the finish line.
— Every CTO ever
Measurable intangibles
The difference between projects that soar and those that plummet is simply a teams tendency to:
- Ensure goals and problems are well known
- Be engaged in collaboration, not just downstream coordination
- Stay adaptable to inevitable change
- Reduce risk before it becomes disruptive
Those tendencies might seem intangible, but accessibility is a way to measure all four.
Those seemingly intangible delivery metrics are what accessibility makes tangible.
Accessibility helps any enterprise overcome the struggle to understand why delivery is unpredictable by measuring these seemingly intangible metrics.
Intangible 1: How well known the goals and problems are
Design and code were never the hard part. What’s hard is:
- Understanding the strategic business intent
- Communicating the strategic business intent
- Maintaining a shared understanding of the strategic business intent
While agile methodologies and ceremonies allow for discovery, broadcast and touchpoints to keep teams aligned, that only happens if they do it.
Indicators goals and problems are well known
- Inclusive product goals
- Reasonable accessibility annotations
- Accessibility acceptance criteria
Action item: Review the product goals
That strategic business intent must written as an inclusive product goal and communicated by the product ownner. Similar to OKRs (objecives and key results), product goals see the big picture — often lasting several months.
This question surfaces the intangible:
For every product owner: Are product and feature goals written to include accessibility?
If not, why not? What resources do you need to write accessibility into product goals?
If they’re not setting, communicating and updating an inclusive product goal, they’re not leading the product.
What’s in a good product goals
A strong product goal can be deconstructed as follows:
- Do something
- for the user and/or business
- with this purpose.
If any component is missing, the goal is weak. For example, here’s a weak product goal:
Weak product goal: Improve onboarding to decrease support calls
Notice what’s missing? This product goal is leaving out the customer.
Strong product goal: Accessibly improve onboarding for all customers, decreasing support calls.
What strong product goals do
Product goals give the team the ability to discover real user needs, including people with disabilities. In doing so, they surface potential friction points early like flashy widgets, uncommon customized interactions, or high-risk flows.
This discovery sets the direction and helps the team balance risks and constraints with opportunities:
- That flashy widget might not worth the maintainance costs.
- Uncommon patterns will require extensive customization that will slow down development.
- Payment services, customer care portals or documentation require extra attention to avoid complaints.
Intangible 2: Engagement in collaboration, not merely coordination
With the product goal mapping the business intent and surfacing risks, the rest of the system must support and maintain a shared understanding of that intent.
Symptoms of weak downstream coordination
Downstream waterfall style archaic workflows allow people to hide, disengage and make it “someone else’s problem”.
- Quality monitoring is externalized as someone else’s responsibility. Search engine optimization? Page speed? Code best practices? A team waits for someone to tell them the page isn’t performant.
- Cross-team handoffs are interpretive: Design → dev → QA is a “throw it over the wall and translate game”, so “we think it’s close enough” ships.
- “Done” is ambiguous: It looks like it solves the problem, but the outcome isn’t testable until it’s live or nearly live.
- Risk is discovered via blocked dependencies: Specialist capacity, external partner schedules or an unconsidered legal approval all add delays.
Signals of collaboration
Accessibility surfaces poor downstream coordination practices because creating a product that’s inclusive of people with disabilities from beginning to end demands legitimate and thoughful collaboration.
With an inclusive product goal in place, these questions must be asked if a team is to fulfill its strategic business intent.
Design signals
UX research: Do we include people with disabilities?
The most basic collaboration teams can perform is finding out how people using assistive technology or settings (like larger text) are using your products. If the team doesn’t know how someone who is blind experiences the onboarding, how can they design for them.
UI designers: Are interfaces using our design system as a foundation?
If your enterprise has an accessible design system, its usage also speeds up design and development cadence and reduces the opportunity for errors. However, many designers resist design systems, typically in search of a glorious portfolio over solving problems for customers.
UI-Dev handoff: Do we include basic accessibility annotations? How are they received by the developer team?
By adding some simple labels to the design for headings, control types and images, designers can immensely help developers by reducing guesswork about the intended user experience. This speeds up development work and requires designers to understand a little more about how software engineers work.
Developer signals
Team agreements are regularly reviewed documents detailing how teams work, helping align working hours, communication habits, tools used and what is required for work to be ready for assignement and what determines a task is done.
Team agreements: Is accessibility represented your definition of ready?
A useful team agreement would require accessibility acceptance criteria to be defined before development work can begin.
Team agreements: Is accessibility represented your definition of done?
As part of work being considered done, demonstrating functionality with just the keyboard and screen reader to the product owner must be included as part of delivery.
Intangible 3: How adaptable teams are to change
If you’re reading this guide, it’s likely your enterprise lacks a cohesive accessibility strategy and the time has come to implement one.
That implementation, if carefully rolled out, can signal which teams are paying attention, can adapt and welcome change.
Signals teams are adaptable
- New training is incorporated quickly into schedules.
- New requirements are effectively adopted into product goals, design practices and team agreements.
- Quality checks are conducted locally before it accumulates in production.
- Automated and manual audits are remediated within an agreed amount of time
Intangible 4: The cost curve of risk
Most executives underestimate accessibility’s financial leverage.
A product team’s ability to prevent accessibility defects earlier becomes a competitive advantage by reducing costs and improving customer experience.
Cost progression of accessibility remediation
The later a defect is discovered, the more disruptive and expensive it is to fix it.
Here’s the real cost progression per defect:
| Stage detected | Multiplier | Business impact |
|---|---|---|
| Design | 1× | Requirement clarified, pattern adjusted, no code rewritten |
| Development | ~6× | Engineering rework, retesting, missed velocity |
| QA / post-launch | ~10–20× | Design and engineering rework, regression risk, release delays |
| Lawsuit / demand letter | 50×–200×+ | Remediation under deadline, legal fees, monitoring, operational drag, brand impact |
The cost of lawsuits and complaints
The total cost of fixing a serious accessibility issue post complaint is around $15,000 each.
We don’t ship risk: The most expensive place to discover an accessibility issue is in a courtroom.
At that point, you’re not paying for a defect—you’re paying for years of organizational drift. Compliance deadlines will be imposed externally, priorities will be reordered, and your teams lose control of their roadmap.
Accessibility is cheap: Remediation is expensive — it’s operational failures with receipts.
You either fund prevention or you fund disruption. The price difference is measured in orders of magnitude, not percentages.
For leaders: your opportunity
Embedding accessibility into delivery is not about slowing teams down — it’s how you increase predictability.
Teams move faster when:
- Work is clear.
- Standards are known.
- Reviews are predictable.
- Issues are caught early.
- Defects trend downward.
Accessibility manifests each of those attributes in a measurable way, and that makes it a signal of predictable delivery.