Pretty much, yes. The more complex the app the worse it tends to get. Say you have a button that says "Send Email" - the default accessibility label would have

Pretty much, yes. The more complex the app the worse it tends to get. Say you have a button that says "Send Email" - the default accessibility label would have the screen reader just read the text, and that's great. And your testing framework can layer on top of this and, say, make sure the button works. It gets a bit more complicated when you apply more rigor to testing - you need the ability to query the state of your program in a way that isn't truly necessary for usability, and forces developers to implement things in ways that are far from intuitive. Take an example, let's say you're building a Facebook app. Instead of "Like This Post", you might have to label the button "Like joebob's post at 3/23/2012 2:17PM" just so the testing framework can uniquely identify one button over another. And this brokenness is hidden, since the visible button is still labeled "Like This Post". Worse, say you want to test that a view changes size when interacted with. Now you're literally embedding sizes and coordinates into accessibility hints/values/labels to make this happen. This devolves very, very quickly. There's been some promising progress on iOS automated testing - the fact that it's happening represents a maturing of the platform and an embrace of quality engineering rather than the seat-of-pants approach we've seen thus far. That being said, the most popular frameworks are still woefully immature.