Just because I listen doesn't mean I agree.
I can understand why you shipped an inaccessible feature and still say we need to change it.
It took me a while to learn that. I used to worry that asking too many questions would weaken my position. So I thought showing up to a meeting with all the answers meant I was coming in from a position of strength. Sometimes I was right. But being right was usually much less useful than I thought.
A deadline might explain why keyboard testing was skipped or why the screen reader experience is confusing. A rushed handover might explain why the final build doesn't match the accessible design. None of that removes the impact on the person who can't use the feature.
But understanding that does tell me where I can push.
If the team lacks knowledge, I can help them learn. If time is tight, we can cut scope instead of cutting accessibility. If the same component keeps causing problems, we can fix it once rather than patch every feature built with it.
I still open my mouth and speak up when something isn't right. I still challenge decisions. I still ask teams to fix work that excludes people. But I do that without pretending every bad outcome came from carelessness.
Because I take the time to understand, it makes my challenge more precise. It helps me address what caused the problem, not only what appeared on the screen.
My rule became to ask what made the decision feel reasonable at the time, before I tell someone that they got it wrong.