Estimating an accessibility fix

Accessibility fixes aren’t bugs. They’re features the team didn’t ship the first time.

Treating an a11y issue as a bug — “fix the modal so it traps focus” — sizes the trap. It doesn’t size what the trap depends on: the rest of the keyboard-navigation story, the screen-reader announcements, the colour contrast that probably has the same problem on the next modal too. Most “small a11y fixes” are entry points into a class of issue that runs through the whole component.

The honest estimate is on the class, not the instance. Ship one fix and you’ll be back next sprint for the sibling, and the sibling’s sibling, until someone admits the work is “audit the modal interaction model” and sizes it that way.

What gets said in the room

Frontend: “Adding the focus trap is half a day.”

QA: “Does the close button announce on screen readers?”

Designer: “Is the contrast on the secondary button passing?”

Lead: “How many other modals have the same shape?”

PM: “Are we doing all of them, or just the one customers complained about?”

Questions worth asking before voting

• Is this an instance or a class? How many similar components exist?
• Audit scope: this component, this page, this product?
• WCAG target — A, AA, AAA?
• Testing: axe, manual screen-reader, keyboard-only walkthrough?
• Regression prevention: lint rule, story snapshot, CI check?
• What’s the ongoing budget for a11y work after this lands?

If it’s a class rather than an instance, split the one component customers hit from the audit of the rest — and size each against what you’re actually committing to.

Size the class, not the instance. One focus trap is half a day; the pattern behind it is the story.

Like estimating a design-system change, the upstream fix is small and the downstream coverage is the actual work. See the other worked estimation examples, or open a free planning poker session once the scope is agreed.