What happens when QA finds an accessibility bug?
More often than not, what I've seen is it goes back one step in the process. That usually means the devs get it. That probably makes sense because someone needs to fix the implementation.
But it's not always the devs that missed something. What I always wonder is which decisions the engineer inherited and from whom.
Here's a more concrete example.
In a patient booking flow, the only way to choose an appointment is through a calendar. During testing, the team discovers that keyboard users can't select dates. QA decides to bounce the issue back to dev because the implementation is broken. But that's not where the buck stops. What if the design of the calendar predates the implementation? What if the team should first revisit the interaction they agreed on before development started?
That's a more expensive conversation once the feature is nearly finished.
I try to bring those questions into planning and design, while changes are still easier to make.
For our example, this means asking how someone can choose an appointment without a mouse, following up with maybe a calendar is not the optimal solution.
Don't get me wrong, we don't need to specify every keyboard interaction. Some problems only become clear in a working product. Those early conversations won't replace testing and trying to predict every detail can grind everything to a halt (hey, I've seen that too!).
But you can resolve important assumptions before those assumptions become an implementation. And no, some things are not implementation details. They are core to how users will be able to work with what you're building.
Sometimes, I think we place too much work on the developer's shoulders. How much are we asking them to solve after everyone else considers their part finished?