3 ms·

In an interesting side note, the whole situation is getting worse in mobile-land. On iOS the accessibility framework (which allows devs to label UI elements for

In an interesting side note, the whole situation is getting worse in mobile-land. On iOS the accessibility framework (which allows devs to label UI elements for screenreaders, among other features) has been almost entirely co-opted for use in automated testing. Lacking a real way to trigger UI elements programmatically testing frameworks have almost universally fallen back on hijacking the accessibility features of the OS to do its work. This makes me very concerned for actual app accessibility, since not only are we failing to implement accessible features (Apple's defaults are quite good, though imperfect) but we're actively breaking it instead.

bdcravens 14y ago
Can you explain further? How does using the Accessibility framework in a way other than designed to facilitate testing (code that really shouldn't make its way into the final app anyways) get in the way of Accessibility in the app used by the end user? Are the internal hooks into the Accessibility framework overridden at the API level?
- potatolicious 14y ago
  None of the testing frameworks I'm aware of alter the Accessibility framework itself - that's not the concern. The problem is that we're corrupting the data being fed into the framework to further our testing ends. Things like accessibilityLabel and accessibilityValue which are supposed to power screen readers are now instead filled with semantic data to facilitate testing. UI elements that aren't (and shouldn't) be screen readable now have accessibilityLabels attached to permit testing. UI elements that should have accessibilityLabels have their default values overridden so some test can have visibility into internal state, etc. You can avoid this - by #ifdef'ing your codebase straight to hell to make sure these don't make it into the shipping app, but I also don't see this being done. On the plus side it seems like TDD in general isn't a thing in the iOS development scene, though it's picking up, so most apps haven't messed with accessibility yet.
  - bdcravens 14y ago
    So am I understanding correctly: the attributes assigned to UI elements can have hints for accessibility sake, and the testing tools are filling those attributes with tags to automate to act/assert an element? Info that's valuable to the testing framework, but garbage for accessibility? Sounds like the testing frameworks have an obligation to provide a tool that can "clean" code for the final working version. Is there a way to do this in XCode without #ifdef'ing? (such as a pre-compilation plugin?)
    - potatolicious 14y ago
      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.

bdcravens 14y ago

Can you explain further? How does using the Accessibility framework in a way other than designed to facilitate testing (code that really shouldn't make its way into the final app anyways) get in the way of Accessibility in the app used by the end user? Are the internal hooks into the Accessibility framework overridden at the API level?

potatolicious 14y ago
None of the testing frameworks I'm aware of alter the Accessibility framework itself - that's not the concern. The problem is that we're corrupting the data being fed into the framework to further our testing ends. Things like accessibilityLabel and accessibilityValue which are supposed to power screen readers are now instead filled with semantic data to facilitate testing. UI elements that aren't (and shouldn't) be screen readable now have accessibilityLabels attached to permit testing. UI elements that should have accessibilityLabels have their default values overridden so some test can have visibility into internal state, etc. You can avoid this - by #ifdef'ing your codebase straight to hell to make sure these don't make it into the shipping app, but I also don't see this being done. On the plus side it seems like TDD in general isn't a thing in the iOS development scene, though it's picking up, so most apps haven't messed with accessibility yet.
- bdcravens 14y ago
  So am I understanding correctly: the attributes assigned to UI elements can have hints for accessibility sake, and the testing tools are filling those attributes with tags to automate to act/assert an element? Info that's valuable to the testing framework, but garbage for accessibility? Sounds like the testing frameworks have an obligation to provide a tool that can "clean" code for the final working version. Is there a way to do this in XCode without #ifdef'ing? (such as a pre-compilation plugin?)
  - potatolicious 14y ago
    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.