[nfbcs] FW: compiling iPhone apps to Android apps

[Joseph C. Lininger]

Hi Steve,
You wrote,

> What I've really liked about the iPhone compared to my previous 
> experience is the stability. It just seems to work. There are 
> occasional glitches, but nothing  substantial. I've heard a few 
> stories of people working with Android tablets indicating that may not 
> have always been true, but would you comment on that? 

I don't have a modern Android tablet, and the one I did have wasn't all 
that useful from an accessibility standpoint. I can comment on the 
stability of the phone though. I use a Samsung Galaxy S4. It happened to 
come with Talkback, so I had no issues there. There's a shortcut you can 
use without sight to turn it on. When you first set it up, you do have 
to answer some questions dealing with whether you have a google account 
and that sort of thing. Other than that, provided you like the default 
settings, it works out of the box. There are some things I recommend 
people change to make the device more useable by the blind, but if you 
choose not to change those things the device still works.

The couple of times I've had to reset the device have been because of my 
errors, not those of the device. It doesn't generally crash or anything 
like that. I had to reset it once because I some how disabled the screen 
reader, and I got it into a state where you couldn't reenable it. Don't 
ask me how I did that; I look at it as a hazard of needing to use access 
software. Most of the time, though, the device just does what it's 
supposed to without too much bother. I've had apps that don't work 
right, but I ascribe that to the app not to Android. For instance, I was 
screwing around with one of those remote control apps, trying to use it 
to control my TV. The "-" button on the virtual remote didn't work. It 
was there but disabled. I considered that the app developer's fault, not 
something in Android.

There are two major accessibility issues I have with the device. First, 
I'm not a big fan of the dialer like I said in a previous message. I 
have not played much with the iPhone, but it looks from the bit I saw of 
it that maybe the dialer works more like what I'd want. Second, it looks 
like if you purposely disable Talkback once it's been enabled, the 
shortcut you used to turn it on initially cannot be used to reenable it. 
I don't turn it off, but still. They really ought to make it so that if 
you, for instance, lend your phone to someone who switches that off, it 
can be reenabled easily. It could be that there is a way and I just 
havne't found it. I'm mostly self taught where Android is concerned 
after all.

You wrote,

> As a developer who has stated you prefer more open systems, do you 
> have thoughts on how we get accessibility more into the core of such 
> systems  sooner? 

First, when I say I prefer more open systems, that doesn't necessarily 
mean I insist on open source. You could consider Windows a closed 
system, as an example, and people use that. My main problem with Apple's 
version of a closed system is that they've gone so far as to tell people 
which programs are even allowed to exist that can run on the devices 
they create. Google has done that to an extent as well, but there are 
two differences. First, they're less likely to do that. Second, you have 
the option of installing software from a source other than google play 
if you really want to.

Now, let me answer the question you asked. To an extent, it's actually 
the same problem whether it's a closed system or an open system. 
Specifically by open system now I mean open source since I think that's 
what you were refering to. The problem being, someone has to write 
accessibility support in. In the case of a closed system, it either have 
to be a third party developer like Freedom Scientific or GWMicro, or 
else a manufacturer like Apple. It could be a private developer like in 
the case of NVDA, but that's not as likely.

With an open system, in theory anyone who has the know-how could do it. 
In practice, the difficulty is that features in open source projects are 
driven largely by what interests people and by what the developers want 
to work on. That means you have to either do it yourself or find someone 
else who is willing to do it. Then you have to get your changes accepted 
into the project. It is possible someone could develop a propriatary 
screen reader for an open source system, but those don't tend to be as 
well received in that environment. You also have a much larger risk that 
things will change rather quickly and unexpectedly.

Android is an interesting case in that it is perhaps the first open 
source system to gain the type of popularity it has and to capture a 
major portion of a particular market. Specifically what I'm getting at 
here is that Android is one of the only (if not the only) open source 
project I am aware of where marketing and consumer demand play a major 
roll in what gets included and what doesn't. Probably the next closest 
example you could come up with would be one of the Linux offerings from 
Red Hat, but those are not nearly as mainstream as the Android operating 
system has become. So it uses a largely open source model, but is found 
in places where you previously only saw closed source platforms. That 
has some interesting ramifications for standards setting in general, and 
for accessibility in particular.

You wrote,

> What degree of governing or guidelines would be acceptable to 
> developers without restricting their need to have flexibility?

Depends what you mean by governing or guidelines. If you mean how closed 
or open a platform is, I would argue developers will accept or reject 
that sort of thing without considering accessibility in the slightest. 
If you're talking about development guidelines in order to make systems 
more accessible, I don't think developers have a problem with that in a 
general sense. Ideally, the best situation would be one in which there 
are standard controls and such which just work if they're included in an 
app. For the most part, that's what I've been seeing happen with my 
Galaxy S4. I don't know if that's the case with Apple, but I gather it 
is. The difficulty comes when someone wants to use a non-standard 
control, or they want to redesign a standard control to have it work in 
a non-standard way. I can't see developers being willing to give up that 
flexability, even though I wish everyone would just use standard 
controls and make it easier on all of us.

You don't see the custom control thing in the mobile market as often as 
you do on regular computers. I'm not sure if that's a function of how 
the systems are built (APIs provide more functionality so developers 
don't have to resort to custom controls), the fact the platforms are 
limited and so they can't support as much of it, or if it's a 
combination of the two. It could even be something completely different. 
Do Apple or Google perhaps tell developers they can't do that, or do 
they perhaps discourage it?
Joe