UIAccessibilityIsVoiceOverRunning() tells me if VoiceOver is active, but if it were not I wish I could turn it on. Is there a way?
I do not believe there is a way to do this. Even if there was this would be a tarrible idea. I'm a blind Ipod user who uses Voiceover on a regular basis. When ever I let a sited person borrow my Ipod I have to make sure to turn Voiceover off since using Voiceover changes most jestures to have a different meaning. If you need Voiceover to be enabled for a specific reason I suggest you display a message to the user explaining why Voiceover needs to be turned on with instructions on how to do so. If the user will need to toggle Voiceover on and off frequently instructions for setting the tripple click option to activate and deactivate Voiceover would be helpful.
Related
I'm currently implementing accessibility for my game. I'm using UIAccessibilityTraitAllowsDirectInteraction for the buttons of the interface, as suggested by Apple. It works well, but the problem is that you have to touch every button of the interface once, to 'activate' it. It makes sense, as the blind people have to go through all the elements of the interface before they can use it.
However, I'm using the same interface again and again in the game, I'd like to disable voiceover if the user has already discovered the interface in that game session. (that'll probably be an option that you can enable/disable in the game settings).
Can you think of any way to do that?
I’m creating an application which will be used by visually impaired users using voiceover (in built screen reader in iPhone).
Certain group of visually impaired persons use external keyboard.
1)Is there any way to Control the reading order of controls in iPhone using xCode?
I want a particular control to be read after another. Similar functionality can be achieved via tabIndex property in other programing languages. Is there any similar property available in xCode with which we can control the reading/navigation order of controls?
2)Is it possible to shift focus from one element to another on any event? I tried working with "nextResponder",but it is not working.
3)If a regular user is using iPhone with an external keyboard, it becomes difficult to understand where the current keyboard focus is and thus makes the application difficult to use. Is it possible to provide focus caret (black border around the control which is currently focused?) When Voiceover is ON, a black border is shown around the items which are focused
1) Do you mean: this
2) There is a way to switch focus from one element to another after something changed
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, yourElementOfFocus);
or if it is an layout change
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, yourElementOfFocus);
3) I don't quite understand your question... If voiceOver is turned on, doesn't it automatically shows a border around the element it is currently focussed on?
Is pinch for font size changes in tableview ok re usability?
Seems a good idea from my perspective, but wondering would users find it ok, or does it break an iPhone best practice?
I read through the tableView human interface guidelines and didn't see anything explicit there. In the Direct Manipulation section it says:
people can use the pinch gestures to directly expand or contract an area of content
If the user is using a pinch and zoom to change all text in a tableview it doesn't really seem to me like it is really proper "direct manipulation." It seems like it is more of a global setting change with a generic gesture. I think the real decision would come down to why are you planning to offer this gesture to the user? Is there a common use case for your app that the user would want to adjust the font size often? Are they going to change it more than once per session?
I know it is nice to offer lots of features, but any extra features are just going to obfuscate the real features. It may confuse the user if they accidentally do a pinch and then the text size is changed and they don't make the connection.
Overral, I don't think it breaks and explicit rule, but I would be really careful about deciding to add this "feature." If there is a really good reason to do it, I would say go for it, otherwise, it probably isn't worth the risk of getting rejected from the store and/or possibly confusing the user.
I vote no if it's key to the functionality of your app. You're having to train people to do something that may not be intuitive for them to realize that's there. If you look that the Twitter official app, they do something similar to expand the content in that cell, but you could totally live without that capability if you didn't know it was there.
When I've learned that I have to write some code to make the iphone keyboard go away. I was quite surprised. I was surprised even more when it become apperent that it is just the top of the iceberg.
What are the expected UI behaviors that aren't provided by system OOTB?
Is the list below complete?
The expected UI behaviors:
Focusing next text field when [done] is hit
Hiding the keyboard when background is hit
Using Touch Up Inside to fire a button action. (To give user opportunity to change his/her mind)
Supporting the screen rotation.
Some of that is silly, but some of it has uses as well.
Focusing next text field when [done] is hit
Which field is "next"? If you have a large form with fields both next to and above/below each other, next might not be so obvious. Even if they are in some linear layout, the iPhone would have to work to figure out which one is next. Do you want to wrap around at the end of the form, or dismiss the keyboard, or submit the form?
Hiding the keyboard when background is hit
I mostly agree with you here, though there are a few cases where this is useless. For example, adding a new phone number in the contact app.
Using Touch Up Inside to fire a button action
This one I really don't get. I can only guess that it's designed to allow you to use buttons instead of the touchesBegan/Moved/Ended methods. I guess it could be useful, but I've never used anything but Touch Up Inside.
Supporting the screen rotation
Many apps just don't work in any other orientation, such as games. If you want to use rotation, you only have to add two lines of code assuming you've done your layout well.
I hope this helps explain some of the strangeness. Aside from the keyboard dismissal, I've never really found anything too annoying. The one thing I wish they supported was using the highlight state of UIButtons for the set state. It would be a quick and easy toggle button, but I've taken to screenshotting a highlighted button and using that for the background image of a selected button.
Want a rounded rectangular button that isn't white? Since that one uses a background image, you can't just click something somewhere that makes it the color of your choice. You have to create your own image or you could even use CSS (WTF!?) to do it.
Unfortunately, the iPhone SDK lacks a lot of helpful things one would think would just be there. However, many people have taken the time to write wrappers for many of these kinds of things to help facilitate development - a quick google search into the functionality you are expecting may turn up a lot of useful answers!
For example, you could make the keyboard go away when you tap outside of it by creating a new view when it appears, and placing that view behind any user-interactable views on the screen. When that new view is tapped, it will become first responder and cause the keyboard to slide away (because the UITextField is no longer first responder).
Such a thing could be easily implemented as a drop-in fix for pretty much anything you'd need it for with very little code.
Still should have been included in the SDK in the first place, though!
I have an app with a UITextField, amongst other things. When the user first taps on the text field, there is a noticeable delay before the virtual keyboard appears. On a 3GS it isn't too obvious, but on an older iPhone the delay can be around 1 second. After that the keyboard always pops up instantly. The delay is only the first time the keyboard pops up after app startup.
It looks like the initial UIKeyboard instantiation takes some time (quite a bit...) but is kept around after that.
I found very little information about this, which surprised me. However I did find this write up of the issue along with a hack-around solution.
http://blog.weareuproar.com/preloading-the-uikeyboard
My question is: is this hack around the only available solution? Is there a way to signal the framework (e.g. via info plist?) to instantiate the keyboard on startup?
No, there is no other (documented) way to do that. And even Apple's built-in apps (such as Maps) suffer from the same problem. You can either go with the hack you linked to or follow Apple's advice to not load stuff in advance before you really need it. By the way, this isn't much of an issue anymore with the iPhone 3Gs and the new iPod touch. The newer and faster devices load the keyboard almost instantly.