QA finds a keyboard trap in a feature that everyone thought was finished. They can't sign off on it as is. It just doesn't work with a keyboard if it traps users on the page.
So they leave a comment on the ticket. This then creates a familiar meeting where people ask if it's serious, should it block the release and can they fix this later?
QA did their job. They found a problem before users did. But by then, design has signed off, engineering has moved on and the release date is around the corner.
That keyboard trap was an avoidable issue. But now it feels expensive and disruptive. The team will start blaming accessibility for slowing delivery when the delay came from letting one unanswered question get all the way to release. "How should this work for keyboard users?"
If nobody has answered that before QA, QA is doing more than testing. They're interpreting intent and defining expected behaviour.
That's a bit much to ask of a final check.
QA should confirm decisions the team already made, not be the first meaningful accessibility review by default.
I'm exploring this question along with four more, in a free email course that helps digital health product teams find where accessibility rework starts. Sign up for Kill Accessibility Rework in 5 Days.