When I step back too soon from making decisions, it could happen that an accessibility issue will reach QA or even production. The easiest response then is to add another step in the process and ask someone else, usually the accessibility expert, to review and approve so that we catch the mistake next time.
And that may work for a while. But it also creates the bottlenecks I've been writing about.
I prefer to ask different questions that help everyone understand what was the earliest moment we could reasonably have caught the problem.
For rework, the timing matters quite a lot because accessibility problems have higher costs associated with a fix the latter on in your process you spot them. A keyboard problem you find in QA probably started with an inaccessible component. Confusing screen reader output might trace back to an unclear design. No alternative text might have been missing from the acceptance criteria.
Finding that earlier moment gives the team a chance to improve how it works. The answer will be different depending on where you could have reasonably noticed the problem in the first place. Not everything needs yet another approval step.
Why reasonably? Because we can't predict every issue all the time and adding a process for everything will eventually slow everyone down. I'm always looking for patterns, especially problems the team has already fixed before. This approach helps those in charge step out of routine decisions. It also keeps me from becoming the person who must inspect everything.
Step one. After the accessibility issue, fix the bug.
Step two. Ask where the team could have caught it earlier, without waiting for someone senior or specialised to notice.
Step three. Fix the process.