In software, a breaking change is when an update makes some of the old code stop working.
You have to rewrite some things. You might need to adjust your systems that rely on that code. It's expected, even necessary sometimes. Developers often plan for it.
For users of the product, a breaking change is annoying but manageable. Your favourite app might look different. A button moved elsewhere. Some workflow stopped working and was replaced with something else. You adapt, you learn the new way, you carry on.
Sometimes though, a breaking change breaks accessibility. This doesn't just inconvenience someone. It locks them out entirely.
It's when that button you could reach with a keyboard yesterday is now replaced with a gesture-only control. It's when the screen reader worked fine the day before but not any more.
It's all broken in the new version and nobody noticed because nobody tested it.
For people with disabilities, a breaking change can mean losing access to their bank account. It could mean they can't do their job any more. They lose the ability to communicate.
And unlike developers who get migration guides and deprecation warnings, users just wake up one day to find the thing doesn't work. And it's expected!
We call that progress. We call that innovation.
But for some people, it's just broken.