Hacker News Reader

Comment by markerz | Hacker News Reader

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.

View on HN

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

Just curious: Are you speaking as an insider or just guessing about the test coverage?

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.

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.

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?

Reply on news.ycombinator.com