Hacker News Reader

Comment by commandersaki | Hacker News Reader

My opinion is good accessibility requires a good chunk of money, especially for surveys and testing. Something that Apple, in my opinion, does exceptionally well (big user of their accessibility features since 2002). FOSS just can't compete here sorry to say.

View on HN

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.

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?

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.

I think you're partially right. The development of good accessibility features require what any other feature would require- time. Since there aren't enough skilled people willing to give their time to make a good dent in the issue, the only solution left is to pay people for their efforts, sadly.

What kind of people are needed, accessibility experts? I think such people are usually PMs or designers, not engineers.

Accessibility experts typically end up creating a bunch of requirements that need engineering man-hours to fulfil. That tends to be boring dev work that most people don't want to do for free. It's hard enough to find people to work on the shiny, fun stuff in open-source.

Sounds like a task for an LLM.

Sounds like a good task for LLM to fuck up the codebase to a point it's unmaintainable.

LLMs are terrible at accessibility since it requires a lot of implicit context. I'm currently implenemting accessibility for a web app. LLMs (sonnet 3-4, gemini 2.5) make a huge mess and they need a lot of supervision and planning

You don't need to be an expert to verify basic checklists. Adding accessibility labels to your buttons, making keyboard navigation work are supposed to be part of your work as an "engineer". Can you imagine building a bridge and saying "yeah no I haven't checked the sidewalks are safe that's an accessibility feature" ?

A basic understanding of accessibility principles is a requirement if you intend to call yourself an engineer (and work on UI facing elements, of course.)

I don't know if this applies here, but my previous experience with doing amateur open source stuff against a code base work corporate backing was that they'll out-code you if they don't care about it. As in be very slow at doing reviews (because they are busy doing features their manager wants them to do, but it's their area that's being changed so the review is still needed), and things can bitrot in that time because they're actively working on it. In one case the lead then said too bad the project is a meritocracy and people who do the work daily has the say.

I sometimes worry that this focus on accessibility testing and the industry around it makes folks think this is some monumental undertaking that they can't hope to approach themselves. But a lot of these issues are glaringly obvious (e.g. "this UI element has no label so I can't identify it"). The visual equivalent would be shipping your app with transparent text labels or a 2 pixel font height.

Any developer can test their software with a screen reader for free. If it's not usable with a screen reader, it won't be usable to screen reader users. The problem is that almost nobody who isn't Blind will do this, or even consider doing it. They'll effectively build an entire UI flow without running through it even once. If you're lucky, they'll work at a company that has some policies and checklists for accessibility and they'll follow that. If you're really lucky, they'll pay to have someone else do accessibility QA. But even just testing it yourself the way it's going to be used would be a huge step up.

Absolutely, FOSS cannot compete with Apple in the same way I, an amateur with a flimsy seesaw, cannot compete with a professional lumberjack with a chainsaw. But I am still miles ahead from a person grabbing my seesaw and sawing their foot off with it. Clumsy and inefficient as I am, I can still get some work done and walk back home to carry the logs.

Apple's accessibility on iPhones for (partially-)cognitively-impaired people is terrible. You either get a ridiculously unusable simple interface, or you get the inflexible non-customisable confusing normal interface.

Do you have any good examples of design for cognitively impaired people?

I don't, just speaking from experience helping one use an iPhone. Too many features can cause confusion, or accidental breakage with no way to revert. Not enough features is a problem too. Feature mechanisms can also cause emotion. So you need enough flexibility that you can customise the interface exactly to the person.

Some examples from iOS: The iPhone wallpaper change gesture is easy to trigger, losing that favorite photo, and needing assistance to go into the settings and fix it again. A big issue I saw was popup context menus can cause confusion when accidentally touching a message in the wrong way. Another was a regression in the latest iOS, in the messages app, when you write a long message, you can't scroll up to what you are replying to; previously you could minimise your draft at least and then scroll up. The photos app clip object feature with its silvery object outline caused delight, despite the feature itself not being used at all, just accidentally.

Reply on news.ycombinator.com