Estimation sounds scientific. We wrap it in spreadsheets, formulas, and confidence intervals. Underneath all of that, an estimate is still a guess. The moment you swap the word estimate for guess, the process feels less comfortable — and more honest.
The most important lesson for accessibility planning is this: you can be wrong without being careless. Estimates fail when we pretend uncertainty doesn’t exist, not when uncertainty shows up.
There are two kinds of guesses:
- Uninformed guesses — “We need a precise guess by Friday.”
- Informed guesses — “Here’s what we know, what we don’t, and how we’ll refine it.”
Most organizations don’t 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. We start with high-level assumptions and refine them as we learn.
Early estimates often feel inaccurate because they are. But that’s expected. The purpose of early estimation is not to be “right.” It’s to establish a range of outcomes and decide what to do next.
Accessibility work often starts with the biggest unknown of all: we don’t yet know what issues we’ll 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’s structured, and it acknowledges uncertainty.
Applying PERT to accessibility work
Accessibility estimates often fail because leaders ask for one number — “How long will it take?” — 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’ve 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’s not as mathematically explicit as PERT, but it follows the same principle: use a group’s collective experience to estimate uncertainty.
Planning Poker can work well for accessibility when the team has shared reference points. The key is to avoid estimating purely on the text of the issue and instead estimate on:
- How many components are impacted
- Whether it touches shared patterns
- If it requires design + development + QA verification
- If regression testing is needed across pages
Without these reference points, planning poker becomes a “confidence contest.” With them, it becomes a reliable estimation practice.
From fixing issues to preventing them
Here’s the long-term payoff: estimation discipline teaches prevention.
The more teams estimate accessibility work, the more they notice patterns: the same failures, the same root causes, the same “expensive” types of issues.
Over time, the focus shifts from “How long will it take to fix?” to:
- “What can we do to stop introducing this issue?”
- “Where should we add guardrails?”
- “What should be part of our Definition of Done?”
That’s when accessibility stops being a backlog of fixes and becomes part of delivery confidence.