Skip to main content

Insight • Accessibility leadership · Estimation · Risk

Accessibility Estimates & Delivery Confidence

Estimation looks scientific from the outside. Inside, it’s still a structured guess. This insight shows how PERT, Agile practices, and real accessibility issues work together to build confidence without false precision.

PM Engineering QA Exec
Share this insight
Abstract visualization of project estimation and uncertainty in software delivery.

Key takeaway

Estimates don’t become trustworthy by being precise. They become trustworthy when uncertainty is acknowledged, structured, and revisited as teams learn.

Model

Uncertainty

Start with ranges, not certainty.

PERT

Structure the guess (O, M, P).

Agile planning

Re-estimate as you learn.

Confidence

Make commitments you can defend.

Uncertainty PERT Planning Confidence

I tell people that project leaders use the word estimate because the word guess cheapens the profession. Imagine if the world realized we were guessing at everything we did. The moment you swap the word estimate for guess, the process feels less comfortable and more honest.

That is the point.

The most important lesson for accessibility planning is this: you can be wrong without being careless. Estimates fail when we pretend uncertainty does not exist, not when uncertainty shows up.

There are two kinds of guesses. Uninformed guesses demand precision before anyone has enough information: “We need a number by Friday.” Informed guesses are honest about what is known and what is not: “Here is what we know, what we do not know, and how we will refine it as we go.” Most organizations do not fail because they estimated. They fail because they demanded certainty too early.

Why estimates improve as we go

In project management, this is called progressive elaboration. That is a fancy way of saying you learn more as you go. I think most people would agree with me that “progressively elaborate” sounds cooler. It helps with the mystique of the discipline.

Early estimates often feel inaccurate because they are. That is expected. The purpose of early estimation is not to be right. It is to establish a range of outcomes and decide what to do next.

Accessibility work often starts with the biggest unknown of all: we do not yet know what issues we will find. That makes accessibility estimation a good discipline for teaching teams how to estimate honestly.

The Polaris lesson: estimating the unknown

During the Cold War, the U.S. Navy built the first submarine-launched ballistic missile system: the Polaris program.

They faced a problem we still face today: estimating work that has never been done before. Traditional estimation methods failed because they assumed known tasks, known durations, and known dependencies.

To solve that, the Polaris team developed PERT (Program Evaluation and Review Technique). PERT introduced a simple but powerful concept: use three estimates instead of one.

PERT uses:

  • Optimistic — if everything goes well
  • Most likely — based on what we know today
  • Pessimistic — if risk factors show up

Then you calculate a weighted average. The estimate is still a guess, but it is structured, and it acknowledges uncertainty.

Applying PERT to accessibility work

Accessibility estimates often fail because leaders ask for one number before teams have enough information to provide it.

PERT gives us a better language:

  • Optimistic: “If issues are minor and mostly fixes in CSS or labels.”
  • Most likely: “Based on what we have seen in similar products.”
  • Pessimistic: “If we discover structural issues, custom components, or missing architecture support.”

This helps teams communicate risk, not just duration.

A concrete example: Name, Role, Value

Imagine an issue like “Name, Role, Value” (a common accessibility failure when custom components don’t expose proper semantics to assistive technology).

A team may not know how hard it will be until they inspect the component library and see what patterns exist. But they can still estimate intelligently:

  • Optimistic: One component is missing a label attribute.
  • Most likely: Several reusable components need fixes and regression tests.
  • Pessimistic: The entire component pattern needs redesign and re-implementation.

That range tells leadership something meaningful: this might be a quick fix, or it might be architectural work.

How Agile teams use Planning Poker for accessibility

Agile teams often estimate using Planning Poker. It is not as mathematically explicit as PERT, but it follows the same principle: use a group’s collective experience to estimate uncertainty.

Planning Poker works well for accessibility when the team has shared reference points. The key is to avoid estimating on the text of the issue alone. Instead, estimate on how many components are impacted, whether the issue touches shared patterns, whether it requires design plus development plus QA verification, and whether regression testing is needed across pages.

Without those reference points, planning poker becomes a confidence contest. With them, it becomes a reliable estimation practice.

From fixing issues to preventing them

The long-term payoff of estimation discipline is prevention.

The more teams estimate accessibility work, the more they notice patterns: the same failures, the same root causes, the same types of issues that cost the most to fix late.

Over time, the focus shifts. Instead of “How long will it take to fix?” the team starts asking “What can we do to stop introducing this issue? Where should we add guardrails? What should be part of our Definition of Done?”

That is when accessibility stops being a backlog of fixes and becomes part of delivery confidence.

Questions this insight answers

  • How do I estimate accessibility work accurately?
  • What is PERT and how does it apply to accessibility projects?
  • How do I give a project estimate when the work is unfamiliar?
  • How do I build stakeholder confidence in my estimates?
  • What is the relationship between uncertainty and delivery confidence?
Share this insight

How I lead

This insight demonstrates Reality-Based Commitments

Estimates aren’t promises — they’re informed commitments made under uncertainty. This is how I help teams communicate risk honestly, set expectations early, and avoid false precision.

Small, realistic commitments build trust long before delivery gets hard.