Estimating an accessibility fix
The story whose size depends on whether the team treats it as a bug or a feature.
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 color 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?
Like design-system changes, the upstream fix is small and the downstream coverage is the actual work. Size what you're committing to.