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?
Related
In a nutshell, my goal is to create my own program for visually looking at game controller input.
However, it appears that once the unity application is in the background, ergo, once I switch to a different window to play a game, the controller input for my unity program is no longer read.
I've seen that the user Elringus had a project called UnityRawInput to help with this, but it only works for keyboard input. I've seen a lot of different responses related to this question that mention using native libraries to "hook" to get background input, but it apparently only works for keyboards.
What information is out there such that I can hook to game controllers themselves? I cannot seem to easily search for information pertaining to game controllers (and their various axis) themselves and not keyboards.
Why not a keyboard? Because I am very interested in a game controller's triggers in the way where, when pressed slightly, it can preform "weaker" actions rather than being pressed all the way, which a keyboard cannot discern as far as I can tell.
Though, wherever the solution might be, even outside of Unity, I'd like to know. Thanks! :D
There are multiple fields on my screen which is designed in unity. While filling downwards input is blocking due to the keyboard.
Unity never supports the auto-scrolling screen just like the native Android/iOS.
Also, One more problem is the user has to input into a Keyboard input instead of an actual input box
Please check this screenshot for better understanding.
What would be the ideal way to overcome with this?
TouchScreenKeyboard
You have to detect when the keyboard is open and do some logic that scales, or re-anchors the text field.
Is there any datepicker UI elements that I can use on my iphone application? Native one is found to be too big.
Maybe the right question is why is it too big? Apple has done a pretty good job of making a set of controls that apply for most circumstances, look stylish, and are usable by the user.
The default control is the size of the iPhone keyboard, and it was made this way for a very good reason: all elements are easily viewable and selectable by touch. If you have a lot of UI elements making life difficult, consider displaying the selected date/time in a label and edit it in a modal dialog.
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!
my app asks the user yes-no questions, user replies using a uiswitch on screen. i've been thinking about creating a custom version of the switch that would display yes/no instead of on/off and would use a green/red background as an indicator of the value. after creating a mock up i'm not so sure this is the way to go. using the default switch doesn't feel right but so does changing it too much. what do you think?
It really depends; some custom applications have extremely custom UIs (such as ConvertBot, for example) and it works great for them. The risk is sometimes worth the effort. In other scenarios, custom widgets result in breaking usability. I don't think that changing 'ON/OFF' to 'YES/NO' is groundbreaking, if you do it right you can pull it off no problem.
I think if your mockup was better done (the slider should be divided into two to have YES AND NO of equal length with equal padding on both sides) it would look a little better.
From a user interface perspective, this is a bad idea. People have already learned the default switch, so why change it now?
Additionally, you run the risk of adding another source of bugs to your application that was not present before.
Depending on the app, this can be very valid. Sure people are used to the default controls, but changing the text or colors is not going to break the user's understanding of these controls. Its still the same switch underneath.
In your example you color both the Yes/No. That is the only concern I would have that you did change how the core switch works. Typically, it works with a highlighted color and a grey color. So, having it stay colored on both options could potentially be confusing.
Regardless, if you want to build your app this way, you should. Just because the iPhone offers great default controls doesn't mean developers shouldn't innovate and add their own or take the default controls to the next level.
Take a look at the custom UISwitch control that I built to allow me to change the background color of the control. You could use the same method to change the text, the font, or the text color very easily.
http://www.homick.com/posts/custom-uiswitch-control
The code is available on Github and includes a PSD that is used to build three different png files that the control uses. You can modify the contents of the psd to recreate the png files in whatever format you like. Swap those into the control and away you go.