Is it possible to build assistive applications for the iPhone that work in the same manner that VoiceOver does? (Using the UIAccessibility API) - To clarify, We would like to build a screen reader in the same vein as VoiceOver. Or, is VoiceOver the only assistive technology that is allowed to work on an iOS device?
Yes, you could build your own screen reader technology into your own app.
You would have include your own speech synthesis library, such as CMU FLite, which may not sound as good as VoiceOver, and subclass or add categories to all of your app's UI and text objects that you wanted to support your private assistive behavior.
There are a small number of talking apps in the iOS App store that do some limited custom voice assistance within some of the app's views, without VoiceOver having to be on. (Advertisement: my Talking Tuner is one example.)
Your assistive tech would only work within your own app, and would not be able to interact with the physical button or any other apps as Siri and VoiceOver can.
VoiceOver is currently the only assistive technology app on iOS, and I suspect that Apple will keep it that way. There's a bunch of benefits to having the screenreader being part and parcel of the whole package rather than allowing 3rd party apps, including:
A screenreader, by definition, needs to be able to access the UI and contents of other apps. There's a whole bunch of security and privacy issues here. While there are some ways to mitigate this - eg. Android requires assistive technologies to be specifically given permission in a control panel - why even go there if it's not needed?
Some of the things that VoiceOver does - like intercepting touch - likely need special system support; and again that's not something that you generally want to allow any app to do. There's a sense in which a screenreader is a special case of app, and it's far easier to manage these cases where a screenreader needs special support from the OS if its all in-house than if that support needs to be extended to 3rd parties via some API, and that API needs to be somehow secured against misuse (see point above), and the API has to be documented and supported in future OS releases.
Having one screenreader means there's just one app to test with for accessibility. This hugely simplifies life for the developer. On iOS, test with VoiceOver, and you're done. By contrast, on Windows, you have to test against perhaps JAWS, NVDA, and maybe WindowsEyes too. And some of these apps do things that others don't, so your app may need to workaround one or the other.
Having the screenreader being part of the package also means that it works with new features right from OS release. Apple can guarantee that new iOS features are accessible from day 1. To do this with 3rd party accessibility software, they'd have to let 3rd parties in on new OS features, which is unlikely for a company as secretive as Apple.
Unfortunately, VoiceOver is currently the only assistive technology allowed. If you need to work with VoiceOver, it is pretty easy; all you have to do is add this line of code for each items you want the user to identify:
[myView setIsAccessibilityElement:YES];
[myView setAccessibilityTraits:UIAccessibilityTraitImage];
[myView setAccessibilityLabel:NSLocalizedString(#"Image of dog", nil)];
Related
Is it possible to make iOS and Android apps compliant with Section 508 of the U.S. Rehabilitation Act? I have an upcoming meeting where this question will be raised.
See here for Apple's docs on how to make apps fully accessible: Accessibility Programming Guide for iOS
In particular:
If you use only standard UIKit controls, you probably don’t have to do much additional work to make sure your application is accessible. In this case, your next step is to ensure that the default attribute information supplied by these controls makes sense in your application
I've done a couple of section 508 reviews but don't take what I say as the final word or a legal opinion.
Section 508 is usually used in government contracts and is part of the purchasing process. If your app is not completely 508 compliant this won't mean you can't get the contract, it just means you may lose out if someone has an app that is more compliant then yours with the same general feature set and usability.
As far as 508 compliance on a mobile device the VPAT, which is the form you need to fill out does not specifically mention smart phones. Take a look at
http://www.itic.org/policy/accessibility
To view the current VPAT. If I had to fill out a VPAT I would focus on "Section 1194.21 Software Applications and Operating Systems" since you are writing an application for what is basically a computer with assistive technology on it.
I'm a totally blind iPhone user and from my personal experience with the accessibility of Apple's built in applications as well as many third party applications I would say creating an application that is 508 compliant or very close is doable.
Android is a different story. I don't have any firsthand experience with Android but do to the different levels of Android, different hardware, and customizations from the device makers that may negatively impact accessibility you can't guarantee your app will be accessible. The best you can do is try to find a handset with good accessibility, develop on that handset, and in the VPAT make it clear that you only tested with one specific hardware device so your results will vary. With Apple it's safe to say that if an app is accessible on iOS 4.0 it will be accessible on an iPhone 3GS, iPhone 4, iPad, and iPod touch since they control the operating system and hardware. My understanding is that Android's accessibility API is more limited then Apples so that is something else to take into account.
For an introduction to making iPhone apps accessible other then Apple’s documentation see this
For an introduction to general Android accessibility see this. Pay attention to the choosing a phone section for more detail on the fragmentation issue I mentioned earlier.
For a developer introduction to writing accessible Android apps see this
Sure, you can use a similar feature to VoiceOver, vibrations, sounds, use the flash on the iPhone 4, etc. You can't use braille though.
I have developed an app for the Android and it's working well, finally, and thanks to all the help from StackOverflow!!
Now I am being asked to make it work on the iPhone. I looked at iPhone a while ago but not recently.
What does everyone think? Should I take the time to learn Objective C and iPhone and port the app or forget it?
Are there any books that cross-reference functions so that you can look up how to do something in iPhone that you already have on Android?
From my experience in school, if you have already been able to create a working smartphone app in at least one mobile OS such as android, it wont take long before you can understand objective C and cocoa framework stuff. The only problem with that is you may probably need an apple developer license to use XCode.
So, I would say go for it since you also get paid, and also here is a link to iphone development guide for android developers : http://integratingstuff.com/2011/02/27/starting-iphone-development-as-an-android-developer/
Probably, it's better to get a partner who develop to iOS than doing it yourself.
Focus on a platform and let your products run to all users.
Unless you are using a framework that supports both iOS and Android (something like the Corona SDK) you won't have much actual code that will transfer over. Ideas, algorithms, logic, graphics, designs, etc will all transfer over just fine. Those are the hardest parts (IMO) of software dev.
Objective C (the language iOS apps are written in) is not that hard of a language to learn if you already know C-based languages (like Java). There are a few concepts that are different, but for the most part, it's not that bad. The biggest challenge for developing on iOS is buying a Mac. You can program for Android on Windows or Linux boxes, but iOS apps can only be developed on an Apple. Unless there is something that has happened in the Hacintosh arena that allows for iOS development on other platforms, you're stuck buying new hardware. BUT if you already have a Mac, download XCode and go to town!
Like Haphazard said, if there is enough money in it to make it worth your time, do it.
If you are getting paid, go for it! (Also, it could be a great learning experience.)
When I had to make the same decision, I considered the following criteria:
how much money is in the app on the other platform ?
how many times will this happen in the future, or is this going to be the only app? (how big is the benefit of learning the other platform for the future)
how much insider know-how is in the app that one is willing to reveal to another programmer porting this app (in my case I do mostly device handling apps, which is not really all that common)
what is the opportunity cost of spending time on porting an app instead of developing another profitable on the initial platform
If you have any possibility, you may look into similar apps and see how they are doing on the two platforms...
Good luck, whatever you are going to do...
I just learned about this and have not tested it yet, but one thing that you could do depending on the app you have you could take a look at PhoneGap. It looks pretty promising, though it may not work for your case with your initial application already made. But in the future this could help.
Unfortunately you will either have to re-write the app from scratch for iOS, or hand over the job to an experienced iOS developer. You can fairly easily port over the logic and computations in your app from Java to Objective C, but the user interface is the area where you cannot really re-use anything (except maybe icons), and the user interface tends to be a large portion of most apps.
As an Android developer who has ported several of my apps to iOS, I can say that this transition is a hard one. Firstly, you need to buy an iPhone and a Mac (if you don't already have these), since you cannot develop apps for iOS without the Apple hardware. Secondly, you need to learn how to use XCode and Objective C or Swift. And thirdly, since XCode ONLY allows creating the user interface graphically (as opposed to Android which lets you hand-edit the XML), there are many hidden things which can cause you to come unstuck. (UPDATE: Using the new SwiftUI approach to user interface design really helps with this last point, and in my opinion makes the transition from Android to iOS easier).
Finally the Apple and XCode environments seem rather alien to someone who is used to Windows and Android Studio. There are things like the Home and End keys having completely different behaviors to Windows which is frustrating. Also you have to use a combination of key shortcuts and mouse movements to hook up user interface elements to your code. Also, there are big annoyances such as the pop-up keyboard on iOS not pushing the content out of the way automatically like it does with Android. This is probably because Android is an OS designed for multiple screen sizes, whereas iOS is design for a limited number of screen configurations, but it makes iOS feel inferior and harder to work with from a developers point of view. (UPDATE: Using a ScrollView in SwiftUI solves the keyboard obscuring problem).
My company built its own project management web application. It's like basecamp on steroids. The core features of this application are:
create task lists
assign tasks to team members
track hours against task items
I am looking to build mobile application(s) as an extension to the web application. The mobile applications(s) must:
reproduce the features mentioned above
connect to the same database as the web application
retain drag drop capabilities
provide a rich user experience equivalent to or better than the web application
work on iphone, droid and blackberry
Given the requirements above, how should I approach the development of this mobile application? There's about 20 smart phone users in my company: 8 iphones, 7 droids and 5 blackberries.
I've heard of development frameworks like Phonegap that allow you to develop in HTML, Javascript and CSS. The software then works cross platform across blackberry, iphone and droid. If I am an average/slightly-above-average programmer, will I be able to build a high quality cross platform mobile application with PhoneGap (or another x platform development framework) that meets the above requirements?
Or should I build each iphone, droid and blackberry application independently?
What's the best approach? What are the trade offs?
John,
Well it sounds like you've got a bit of work ahead of you! When you have an existing web-based application, there are two basic approaches to getting your app available on any particular device: you can (1) write a native app that implements the functionality you want for each device you want to support or you can (2) write a web-based "wrapper" for your existing app and serve the content as HTML/CSS to those same devices.
Option 1: Build a native app for each platform you want to support
As for the first approach, the benefits can be great. By using each device's native frameworks, you have the complete ability and flexibility to take advantage of the best features of each device. Your app's views can also render faster, since all you will be fetching from your server is the data to populate the views with (i.e., you do not have to load images, HTML templates, or CSS files at all).
The drawback with this approach is that it inherently requires each device to have its own application. So if you're supporting a web app, an iPhone app, an Android app, and a Blackberry app this means that you have 4 completely separate codebases to maintain. If you add some sort of new feature to your web app (which you presumably will at some point), you will also have to implement that new feature in the three other separate code bases. Given the fact that these devices can have different interaction models, this could pose a challenge. Another drawback here can be distribution (i.e., you may have to go through a review process for something like the iPhone app store depending on how you want to distribute your app). It also means that the amount you will have to learn is quite a bit greater since each device has its own API set and programming "philosophy".
Option 2: Write a web-based "wrapper" for your app (perhaps using a library)
This approach also has a great deal of benefits. First off, if you use a framework like PhoneGap or Sencha Touch or Rhomobile, the big benefit is that you theoretically write the "mobile app" code once and it works across each of the devices supported by the framework. Compared to writing a native app for three platforms, this is a lot less work.
Downsides here are as follows. This approach runs as a website in the device's browser, so you will not have access to all of the functionality of every device. All of the great stuff in the iOS and Android API's will by definition not be available to you. You are also somewhat limited here with regard to local storage, but this may not be a great concern to you given your web app. Another drawback is that there will be more bandwidth required from your server this way, since you are serving all of the HTML, images, and CSS that you would otherwise not have to with a native app. Depending on the number of users and complexity of the pages, this could be significant to you or not. Another downside here is that you cannot go full-screen (with the iPhone in Mobile Safari for instance there is always a toolbar at the bottom).
General Concerns
One thing that concerned me reading your question was your list of requirements. Reproducing features and connecting to a remote data store are things you can definitely do with both native and web-based mobile apps. But "retain[ing] drag drop capabilities" is not. With an iPhone, for instance, you can use handles in a UITableViewCell to provide a way to reorder lists, but full-on drag-and-drop is not really something that fits with a mobile device's user interaction model. You may have to re-think this one.
The requirement to "provide a rich user experience equivalent to or better than the web application" is also a bit troubling. While phone-based apps can have really streamlined ways to get at and manipulate data, remember that you are designing for a screen that is a few inches square. It is physically impossible to provide the same breadth of information in an organized manner than you can with a 21" HD widescreen monitor.
Remember that you're designing here for mobile, so you want to take advantage of the available platforms but remember that you're dealing with small screens and limited interaction methods (touches, swipes, and gestures).
My recommendation is that if this is your first time at this, you want to support all of these devices, and you already have experience with the web, I would suggest taking Option 2 and using one of the above-mentioned frameworks. It would be the easiest way to start and there wouldn't be any radically different concepts for you to have to learn.
Good luck!
An additionally comment on what Neal L posted above, with Rhomobile you can access the devices native capabilities as well as have drag and drop in your views.
There are several training and example videos here: http://rhomobile.com/webinars/
This just saves time.
Since I already have a web applciation.
I can just stick it inside a webview.
The question is: Does it turn off many users? How many users will be disgusted that the entire iPhone app is written in WebView?
I think it's pretty safe to say that most iPhone users are expecting apps to use the power of the iPhone, not just be a portal to a mobile website.
Think about facebook mobile compared to iPhone facebook app. If you're an iPhone user, I'm assuming you'd much rather use the app than a mobile version of the site (or mobile version of the site contained in a WebView in a an app).
That being said, depending on your app, if the mobile version of your app is highly usable, it could be okay...
Just my thoughts...
John Gruber on Daring Fireball just wrote about this today.
From a usability perspective, native apps usually feel better. They may also be more responsive and handle large amounts of data more gracefully. I have a few so-called "apps" on my devices which are just glorified Web apps, and they don't necessarily scream quality.
If you've already done your app, then just ship it. But keep your mind open to feedback from your users.
The answer is almost certainly "no". People care far more about the usability and experience of interacting with your application than what API-supplied widget you use to render it.
I read Apple has begun removing apps that are like this. Well technically, they remove apps they think could be easily implemented as a webapp instead. Yours obviously qualifies ;)
Source: http://techcrunch.com/2010/03/07/apple-cookie-cutter-apps/
EDIT: Apple seems to not mind, according to the Human Interface Guidelines:
If you have a webpage or web application, you might choose to use a web view to implement a simple iPhone application that provides a wrapper for it.
Of course, Apple has a tendency to contradict themselves. ;)
Apple human interface guidelines says this isn't even allowed. I forget where it comes from, but somewhere in the guideline it says apps that are only web views are not allowed. I'm about 95% sure I've seen this. Can anyone confirm?
I'm looking to create a mobile version of our website/web app. What's a good way to provide the best, most fully featured version.
Part of the reason for creating it is instead of an iPhone app, so I'd like to offer an iPhone web app that takes full advantage of the iPhone's version of WebKit (so CSS animations, being able to rely on good javascript support etc). However, I'd also like the site to work well on other smart phones as well as more basic mobile phones as well.
Do I create two sites (Mobile WebKit and basic mobile web) and redirect based on User Agent? Can I create one site that degrades well? What are the possibilities, and how do other people handle it?
Also: are mobile web simulators worth a damn? I have an iPhone, so can test easily on that. If I want to test on Blackberry/Palm Pre do I really need a device or are there reliable simulators?
These are some of the iPhone specific libraries that provide a native look and feel on webkit:
iUi
jQTouch
Sencha Touch
iWebkit
Getting it to work on most phones will definitely be an issue with most libraries as they are built around with the iPhone's screen size (320x480) in mind.
To get a wider coverage of devices including Android and J2ME phones, checkout Yahoo Blueprint. It's a markup language that translates for various platforms and devices.
You could either get the mobile view based on User Agent by dynamically switching the stylesheet on your server when spitting the page. This is not a recommended approach though for heavy-duty pages as you will still be sending huge chunks of data that would not be rendered. Alternatively, if you have a clear separation of your views, you can templatize the view based on User Agent and/or other parameters. This has the advantage of keeping your controller logic in one place with only changing views. You could use the above libraries for iPhone/iPod Touch and switch to a simpler mobile version for other smartphones or tweak it as you want.
Creating a separate mobile version of the site can be painstakingly difficult to maintain when changes arise.
The iPhone and Android simulators are as close as it gets to the real deal. The iPhone won't let you do stuff like make calls on the simulator for obvious reasons, but the Android provides mock implementations for basically everything on the device.