I used to look at all the tickets we kept revisiting and ask why we missed all those accessibility bugs.
I'm starting to think the better question is why we had enough confidence to call the work done in the first place.
Sometimes work reopens because the team did exactly what the process asked them to do. But maybe the process was incomplete and asked too little of them.
I don't mean that as a clever line. I mean it literally.
I've seen enough features get marked done, only to later come back to them because users couldn't complete a key task without help. In all these instances, it was either QA who found an issue after the next sprint has already been planned. Or, even worse, users found it in production.
A "small accessibility fix" is anything but. That small fix touches several screens because the team never had a shared pattern. The support team hears the complaint after launch, but the team could have caught it earlier in the process.
That's starting to look at a confidence problem. The team believed the work was finished, but the evidence for that belief was misplaced.
Maybe the acceptance criteria described the output, but not the user journey. Maybe ownership was clear for delivery, but unclear for quality. Maybe accessibility came in as a review step instead of a product decision while the work was still flexible.
I'm starting to pay more attention to that gap.
What did done mean there? Who had enough information to make that call? What would have helped them see the risk earlier?
When accessibility creates rework, I don't want to stop at the issue.
I want to understand what made the bug possible in the first place.