In theory, yes, but in practice it's probably a very bad experience unless actively worked on. For instance, I worked on a "seat chooser" once, that actually was very keyboard friendly and worked with screen readers. But trying to actually use it to select a specific seat for a blind was impossible. A seeing user can just press the seat directly, or tab quickly until the correct one is selected. But with voiceover it had to read out "seat 7B, $5 extra, not occupied, extra leg room, aisle, power outlet".
An actually useful way of selecting a seat would be to specify a seat directly, or some kind of filter for wanted features, a table or whatever. Not just take a visual way of presenting something and slap on some voice data.
The two aren’t comparable. It’s not even close. I take it you haven’t actually built an iOS app.
That said, for sure, you can build a custom UI that is inaccessible, but with iOS if you build something that is close to conventional, you’d be surprised by how well it works.
Provide a non custom UI alongside the custom one. Use tabs to offer ‘graphical’ and ‘list’ views.
The comment I replied to said this:
> In theory, yes, but in practice it's probably a very bad experience unless actively worked on
It’s also not even clear that the UI they described was that bad for blind people.
The voiceover information is relevant to making a selection, and the blind person can’t see that data so it needs to be read to them at some point. Of course it’s not as easy to use as if you can see it. They describe a search function, and I propose a plain list, but there isn’t a lot of evidence that either would require less interaction.
Obviously it's bad. Becoming blind doesn't magically make you infinitely patient. Having to listen to a whole listing of airplane seats one by one with unnecessary details when you just want to book a place would probably make you crazy. Well it's the same for your blind users.
They don’t. Why would you expect them to be able to?