Accessibility problems are rarely only accessibility problems.
They usually point to places where the process has started to crack.
Here are the most common places the process cracks.
A feature reached QA and nobody is sure what "done" means. A design decision changed during implementation, but nobody updates the thinking and reasoning behind it. Everyone handles quality differently. Problems appear late and suddenly everyone needs to stop and try to fix everything under pressure.
All these lead to accessibility issues, but they're mostly process issues.
We rarely treat them as such though. Our response is usually way too narrow. We fix the bug, close the ticket and move on. Then the same kind of problem appears again in another feature, with a different label and the same root cause. We think it's different, but it's really the same.
Accessibility gives you useful signals, if only you listen. It shows where ownership is unclear. It shows where design and delivery drift apart. It shows where quality depends on who you happen to be talking to.
That can feel uncomfortable, but it's useful.
If you keep finding accessibility problems late, ask where the process broke that allowed this to happen. Fix the issue, sure, but don't stop there.
It may be your definition of done is too vague or QA is carrying too much responsibility at the end. If your product decisions are not being written down clearly enough, that's a problem bigger than one accessibility issue.
When you improve the habit, accessibility issues become less likely next time.