I am currently making a custom keyboard for iOS 8, and I came across the problem that it is impossible to type. I found that you have to be far too accurate and press your finger exactly on the keys. This is obviously not the case for the system keyboard, as no matter where you type, some key gets pressed.
So my question is, how would I go about implementing a feature like that?
This likely relates to your tap zone. I believe for buttons Apple has firm recommendations for size in the Human Interface Guidelines. You will likely need to make the zone as large as possible without overlapping with neighboring buttons.
https://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/
From my experience, you should create a gap-free grid of buttons, and only add a gap to the graphic representation of the button.
Related
iOS has built-in support for accessibility, for UIButtons it reads the title of the button followed by a hint "double tap to activate" (by default). Sometimes we are required to make a non-UIButton control behaving similar to UIButton in terms of accessibility, so we would set its accessibility trait to button and hardcode "double tap to activate" for accessibilityHint.
I don't like altering system behaviours, and I've seen accessibility users who prefer single tap instead of double tap (there's an option they can set), although I haven't checked if the opt for single tap instead of double tap, does the system hint become "single tap to activiate".
What is the common practice regarding accessibility support for a non-UIButton control that is tappable? Thanks!
I've seen accessibility users who prefer single tap instead of double tap (there's an option they can set)
I'm really curious to know how it's possible using VoiceOver because a single tap with one finger deals with the accessibility focus. In the UIButton documentation, Apple states: 🤓
VoiceOver speaks the value of the title [...] when a user taps the button once.
Would you mind detailing the way to activate this option you mentioned because I'm really astonished, please? 🤔
What is the common practice regarding accessibility support for a non-UIButton control that is tappable?
Using a hint is a very good practice to provide useful information to the user but this information mustn't be crucial for using because the accessibility hint may be deactivated in the device settings.😰
Admittedly speaking, this kind of element must be read out in such a way that its goal and its using are clear enough for any user: that's what traits are made for. 👍
Many traits are well known and give rise to different actions like adjustable values, customed actions and the rotor items using.
Besides, it's also possible to use the accessibilityActivate() method so as to define the purpose of a double-tap with one finger of an accessible element. 🤯
The way you want to vocally expose the possible actions on a tappable control depends on the content of your application.
Finally, keep in mind that hardcoding a hint must be understood as a plus information but definitely not as an essential one because it can be deactivated by the user: a conception oriented a11y is very important when building an app. 😉
I want to create a custom keyboard, and I want to add more characters on it. if user long press a button it show more characters. like IOS default keyboard shows popup button after long press.
I created a very complex keyboard a few months ago where every key needed to have at least 5 different variations (Amharic dialect). I found that many pop ups do not work very well as they don't pop up over the top of the keyboard, I looked at how other keyboards achieved this but couldn't find a way to make it work. You can see a question on this problem here.
As a work around I created my custom keyboard with an extra row on the top, this was normally filled with numbers but on a long press would switch to show the alternative keys available. On long press the key pressed would be added to the field and if they chose on of the alternatives it would then replace the first key.
To give you a better idea here are some images:
Regular Keyboard:
Long press:
NOTE: Excuse the poor quality but I could only find an intermediate version of the project to screen print.
While working on this project I found that pop ups were a lot more difficult to achieve than this. I researched creating my own pop ups with bezier paths and also using pop ups themselves with the CYRKeyboard Button. (Note although the CYR gif shows the exact functionality required I found this gif to be extremely misleading). But in the end I came back to the above solution which worked very smoothly, quickly and easily.
Hope this helps
I will word this question embarrassingly awkward and primitive as I have spent ten minutes searching for the answer and failed miserably. Please help/nudge to resolve!
Desired IOS Feature
Setting the upper navigation bar over all Apps to a custom color and text value that navigates to a specific App when tapped
Example
The App SleepCycle when it is set to Alarm-Clock mode, and when the User is in any other App other than SleepCycle. The top of the screen then becomes red with the text 'SleepCycle' and when you single-tap it you navigate to SleepCycle
Question
What is this feature called and how do you programmatically implement it?
When I've dabbled with this in the past, the hack(?) I used was to register as a Voice Over IP / audio app in Background Modes. WARNING: I have never tried to ship such an app to the App Store, as it seemed like a dubious approach.
Maybe I'm just searching for the wrong term, but I've been able to find very little information on this subject, and I think it could be a problem for my app.
A while back, there was an article on the accuracy of the touch screens on iOS devices, and it seemed quite poor compared to other phones. Here is a link a posting about it:
http://forums.macrumors.com/showthread.php?t=1660713
Anyway, many of the commenters referred to "perspective compensation" as a cause for the inaccuracy. Basically, they are saying that iOS intentionally registers touches above the actual point of contact to compensate for the typical viewing angle of the user or for the angle of their finger or something like that. I have found that there is some credibility to that claim myself by doing as one of the commenters suggested and trying to use my iPhone upside down. I did find that it was difficult to touch things in some cases, and I have also noticed this problem in one of the apps I'm developing.
So, in case you want to skip all that rambling above, here is why it's a problem for me:
I am developing an app that is intended to be used by two people at the same time. The iPhone or iPad is placed on a surface between two people who are sitting across from one another, and they are instructed to quickly and accurately touch items on their respective halves of the screen competitively. What the article's comments made me suspect might happen, and what I have also found in practice is that the person using the phone upside down will have trouble touching buttons and dots on their first try. I've also tested slowly with a stylus and found that the touchable area of a button does indeed extend below a button, or above the button for the person using the phone upside down, hence the discrepancy and problem/disadvantage for that person.
So finally, if you want to skip that also, here is my question: Can "perspective compensation"(if that's what it's called) be disabled programmatically, and can it be done for specific views of an app? Have any of you noticed this and dealt with it in an app of yours?
While I have found that "perspective compensation" does seem to be occurring, I have not found any official documentation of it, and therefore have no idea how or if it can be disabled. When I search for "perspective compensation," the only results I find are links to the same article and comments.
I can't help but expect that this may have been asked before or is solvable with a simple checkbox, but perhaps for lack of the correct term to use, I have been unable to find any leads.
Thanks in advance for any of your solutions or suggestions!
This can't be done with the current SDK. All we have access to is the touch location, which is at a single point. Other search terms you might try are "digitizer" or "raw touch data", but there is definitely no check box or simple option.
To implement this, you will have to compensate for the touch location yourself. You'll need to play around with a compensating offset value for the upside-down buttons. Hit testing on views is probably the best place to do this, then your buttons can just respond to events as normal.
I have a long text on my view, when I tap on it VoiceOver reads the text.
Is there a default behavior to stop VoiceOver reading?
If not, is there a way to do it programmatically? for example when the view receive a tap.
Thanks in advance.
Without knowing the content or the interface it is difficult to give a solid answer to this question but one way to approach this problem it to try to not think of the experiences between a VoiceOver user and any other user as different experiences in the first place.
If you don't want VoiceOver users to repeatedly hear a long string of text you probably are also making the assumption that other users are going to be skipping over it after they have read it once as well.
Consider altering your interface so that the information is only presented once in a flow or is only presented when the user needs it and requests it, like contextual help.
Again, not knowing the interface or the purpose of the text makes it hard to answer this question directly but I generally find that building one interface to be inclusive of everyone often helps to point out that what might be perceived as just an Accessibility concern is actually a broader user experience concern and not just confined to the VoiceOver interface.
I hope that helps a little bit.