[nfbcs] FW: compiling iPhone apps to Android apps

[Jorge A. Paez]

Steve:
Excelent points.
As far as Flash, it looks pretty.
That's all it comes down to, though personally I think that's a rather
odd choice for using an outdated coding platform.
Regarding the issue with different screenreaders behaving differently
on different platforms and browsers, I don't know what we'd have to do
about that.
I mean theChase site is inaccessible with Window Eyes--although at
least they put up a warning.
I have JAWS though and the site works just fine.
The solution might be to just code for the industry leaders--JAWS in
Window's case and Voiceover as the Apple screenreader, but then that
would leave out a lot.
Not to mention the different screenreaders reacting differently
depending on what browser you use, issue.
We've made a lot of progress maybe, but I think this is going to be a
constant struggle until screen readers are some how standardized.
Although, if they become standardized that would kill the competition
and the AT companies would probably do all they could to stop anything
from being standard on that front.
I think the AT companies in general are asmuch a problem as all the
other components.




On 3/29/15, Steve Jacobson via nfbcs <nfbcs at nfbnet.org> wrote:
> 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/jorgeapaez1994%40gmail.com
>


-- 
Thank you.




Jorge A. Paez

LinkedIn: http://www.linkedin.com/in/jorgeapaez

Elance page: http://jorgeapaez1994.elance.com