I've been there.
You've done an audit and it surfaced loads of accessibility issues. Now you've flooded your backlog with cryptic accessibility tickets you need to plan in.
Someone suggest you take a break from regular development and plan a sprint with just these accessibility fixes.
Fixing loads of issues in a single sprint might seem efficient, but it's rarely sustainable.
Quick wins come from intense effort. Lasting change comes from consistent progress.
An accessibility sprint can and will deliver short-term improvements. Chances are though that you will forget about it the second the sprint is over. And without ongoing attention, new issues will creep in. Now you're playing a sick game of whack-a-mole. You'll start rushing fixes without fully understanding the needs of disabled users. So you're back in the break/fix cycle you were trying to avoid.
So what's a better approach?
Make accessibility part of your regular workflow.
Focus on small and consistent efforts.
Speed solves problems today. Routine prevents them tomorrow.
Speed will make you treat accessibility like a box-ticking exercise.
Routine will put you in continuous learning mode. Now you're testing with real users and refining over time.
You no longer need that frantic sprint and instead can cruise along and make meaningful progress. You're no longer concerned about the now, but building for the future.