[nfbcs] FW: compiling iPhone apps to Android apps

[Larry Wayland]

So true. I have long wondered when we were going to get the same
consideration for the job and education as we get for home and
entertainment.  This is something I have brought up when talking to groups,
especially developers.
It seems we have been mostly left out in these two areas.  Don't get me
wrong, I think it's great we have the access we have in home and
entertainment, but it would make things so much better if we had better
access to computers at work and school.  Honestly is it really that
difficult?

Larry




-----Original Message-----
From: nfbcs [mailto:nfbcs-bounces at nfbnet.org] On Behalf Of Steve Jacobson
via nfbcs
Sent: Sunday, March 29, 2015 12:44 PM
To: NFB in Computer Science Mailing List
Subject: Re: [nfbcs] FW: compiling iPhone apps to Android apps

Joe,

Thank you for this response, I appreciate your comments.  Understanding as
much as we can about the strengths and weaknesses of all of the alternatives
that we have is very useful.  Your description of what works and what
doesn't is very useful.  While I have also disabled speech on my iPhone, I
generally am able to figure out what I did.  I definitely had occasions with
my Windows Mobile phone when I had no idea how I got to a given state.

Just for clarity, by "more open systems," I was thinking of systems like
Windows where Microsoft has less control over development as well as open
source.  Microsoft has some control, of course, by upgrading their operating
systems and requiring that software be changed to work within their changes,
and I think things are probably more closed now than they once were.

What troubles me a great deal is that all that we are discussing and
describing works pretty well in the entertainment and leisure market.  If
Apple really falls down on the job or if Android really pulls out in front
and accessibility is good, I can switch.  We can play the market, so to
speak.  However, we often don't have the same flexibility when dealing with
software on the job site.  We have to use what our employers adopt.  That is
still mostly Microsoft, although more software is web-based now.  Still, one
sees cases where software is developed that is just not at all accessible or
marginally accessible and we are not able to just switch platforms in those
cases.  As I said, too often it seems as though we have to fight the same
battles over and over again as well.  For example, after twenty years of
accessibility at Microsoft, in Office 2013, the dialog that let's you design
your email signature in Outlook and the one that lets you address envelopes
in Word is not accessible to any screen reader that I am aware of.  So who
addresses envelopes any more?  The point is that these are basically text
controls and they are not accessible, but probably will be with the next
major release whenever that is.  How can we be at a point where a text
control is not accessible?  

I had to use a reader recently to get credit for a required course on
diversity from my employer.  It was flash-based and was designed in such a
way that it appeared to be very scrambled with Window-Eyes, JAWS, and NVDA.
This is the case even though Adobe has been writing white papers on FLASH
accessibility for a decade or more.  We get all excited that we have WCAG
guidelines.  However, while these are pretty good, they are not simple if
you look at all of them, and for most web developers or people developing
web-based software for a large company, the number of people affected by
following them is probably in the single digits.  While I am biased because
I was negatively impacted, I'm not sure what made it necessary for that
particular course to use FLASH.  It was primarily a series of windows of
information with questions with checkboxes.  But I paid a reader to help me
so that a software developer somewhere could feel he or she was artistically
fulfilled.  <smile>  I think a lot of our employability as blind people is
being undermined by software that is not accessible, mostly because someone
has made development choices that do not take us into account.  This is
mostly done because people just don't know the impact they might be having
on us, but sometimes it is strictly because we are a small market and really
don't affect the bottom line in a way that makes up for the additional costs
of accessibility added after the fact.  

On the other hand, how is a company supposed to make their web site
accessible when they find that it is accessible with Internet Explorer and
Chrome and not with FireFox, or it is with JAWS but not with Window-Eyes or
NVDA, or in the case of Wells Fargo, it worked with NVDA and Window-Eyes but
not with JAWS?  And these examples apply only to Windows.  I have not even
touched upon what works with Chrome under Android, or Chrome under IOS
versus Safari under IOS?  In other words, I don't think developers have it
easy either.

Don't get me wrong, we have a lot to be thankful for and we've made a good
deal of progress.  At the outset, no smart phones were accessible at all,
and when a new version of an operating system came out, we would have to
wait months or years before it would be accessible.  Still, I really thought
twenty years ago at the Microsoft Summit that by 2015 more of this would be
automatic.  Getting the perspective of developers is, in my opinion, key to
our understanding of what might be done to make this process more
consistent.

Best regards,

Steve Jacobson

On Sat, 28 Mar 2015 22:14:21 -0600, Joseph C. Lininger wrote:

>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








_______________________________________________
nfbcs mailing list
nfbcs at nfbnet.org
http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
To unsubscribe, change your list options or get your account info for nfbcs:
http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/lhwayland%40sbcglobal.net