4 ms·

My experience internally at Apple is that accessibility was important, but it's also in the critical path for automated UI tests. So broken accessibility means

My experience internally at Apple is that accessibility was important, but it's also in the critical path for automated UI tests. So broken accessibility means broken tests. Good accessibility also means tests are easy to write. The company prioritizes accessibility, but engineers focus on tests.

ssivark 1y ago
This is interesting. For anyone intending to improve the accessibility situation of software, would there be value in "open sourcing" a suite of tests -- or at least a recipe for constructing them? (based on hard-earned experience writing accessible software) Even tests are structured as feature checks (for QA by humans, or soon by AI agents) would be quite useful for devs writing software who have no direct experience with building for accessibility. Do you think it might be possible to get Apple to open source anything like this? Maybe ex-Apple people who care deeply about these challenges?
Gigachad 1y ago
Apple has tons of accessibility features that don't benefit automated testing at all. It's clearly been made a priority regardless of profitability.
- demosthanos 1y ago
  Just curious: Are you speaking as an insider or just guessing about the test coverage?
  - Gigachad 1y ago
    Just looking through the settings they have stuff which would have no obvious automation angle. The reduce transparency option for example, the noise recognition feature to alert you of fire alarms, pairing with hearing aides, etc. Tim Cook said himself in an interview that they provide accessibility features regardless of ROI.
    - ohdeargodno 1y ago
      That's not the initial point. The point is that UI tests are so much easier and less brittle if they're going to be using the accessibility tree, rather than relying on a few selectors. click("Enable Frobzinator") is infinitely more maintainable than click(button().index(7)), and if you eventually remove the accessibility description, your test fails, letting you immediately know what's wrong, and whether it's the test no longer up to date, or if you broke something.

ssivark 1y ago

This is interesting. For anyone intending to improve the accessibility situation of software, would there be value in "open sourcing" a suite of tests -- or at least a recipe for constructing them? (based on hard-earned experience writing accessible software) Even tests are structured as feature checks (for QA by humans, or soon by AI agents) would be quite useful for devs writing software who have no direct experience with building for accessibility. Do you think it might be possible to get Apple to open source anything like this? Maybe ex-Apple people who care deeply about these challenges?

Gigachad 1y ago

Apple has tons of accessibility features that don't benefit automated testing at all. It's clearly been made a priority regardless of profitability.

demosthanos 1y ago
Just curious: Are you speaking as an insider or just guessing about the test coverage?
- Gigachad 1y ago
  Just looking through the settings they have stuff which would have no obvious automation angle. The reduce transparency option for example, the noise recognition feature to alert you of fire alarms, pairing with hearing aides, etc. Tim Cook said himself in an interview that they provide accessibility features regardless of ROI.
  - ohdeargodno 1y ago
    That's not the initial point. The point is that UI tests are so much easier and less brittle if they're going to be using the accessibility tree, rather than relying on a few selectors. click("Enable Frobzinator") is infinitely more maintainable than click(button().index(7)), and if you eventually remove the accessibility description, your test fails, letting you immediately know what's wrong, and whether it's the test no longer up to date, or if you broke something.