Setting showsTouchWhenHighlighted, e.g. via the IB option "Shows Touch On Highlight," on a button without a title will alter the VoiceOver description. After reading the accessibility label, VoiceOver beeps and announces a description of the image. Is there a way to disable this behavior?
Setting the accessibilityContainerType value to UIAccessibilityContainerTypeSemanticGroup works and that's great 👏 but I'm not sure that
this is the goal of this element.
Even if a button my be seen as a container, I understood this instance property dealt with
data-based containers rather. 🤔
I looked into your problem that arouse my curiosity and couldn't find out an appropriate solution with the Apple API unfortunately.
First, I thought that this solution may help but it didn't work as you mentioned in your comment... thanks. 😉
Apparently, when the showsTouchWhenHighlighted property is used, there's an added view inside the button that renders the glow touch ⟹ this is a UIButtonBarPressedIndicator image you can detect thanks to the Debug Hierarchy in Xcode for instance. 👍
This new image seems to put the default value of the accessibility trait property of your button image even if you have already changed it programmatically. 🤯
So, in order to avoid VoiceOver from using the screen recognition and reading out some useless information, I made something very ugly but efficient to reach your goal in the viewDidAppear for instance (see the 'basic operations' sheet of this link):
myButton.subviews.forEach{$0.accessibilityTraits = .none}
Bad hack due to a native problem of implementation or a simple line of code that anyone can understand, this solution removes every possible VoiceOver screen recognition from the button 🥳... and I'm still interested if you can explain a little bit the reason why your solution works, please. 😉
Set accessibilityContainerType = UIAccessibilityContainerTypeSemanticGroup.
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. 😉
Swift...
So I've got an existing app and I'm working on its appearance. The current task is customising the decimal pad that pops up when the user hits a textField.
I've looked around on how to make it but it always seems that you have to go into the iPhone/ipad settings and add the custom keyboard.
eg. This StackOverFlow Question
and they all seem to point to this same tutorial..
iOS 8: Creating a Custom Keyboard
My problem is that I don't want the user to have to go into settings.
So the question is....IS THIS POSSIBLE?
The following pic is what I want to use. I have made this in an XIB file through adding a target keyboard which makes the new folder with KeyboardViewController.swift , info.plist and NumPad.xib. Though i think I'm on the wrong track, can someone point me the right way please.
Also anyone know the exact dimensions this view should be.. assuming what I'm asking is in fact possible. Let me know if I'm not being clear enough!
NumPad.xib(pic)
Many many thanks,
Steve
SOLUTION: Thanks to Andrea for correcting my search keywords. It led me to this Stack Question which hopefully sends some others to the correct end of the internet that have mistakes custom keyboard with custom input views!
Sure it is possible without going into settings, but they are called custom input views.
You should look into inputViews here what Apple says about them Custom views for data input.
Basically when the user press a text field instead of loading the usual keyboard it loads an inputView that you specify, pay attention that custom keyboard term is misleading. If you google for tutorial you'll find most probably link like the ones that you found.
For a practical example check this tutorial or this, is a little bit old, but the principle are still the same
I am learning to develop iphone apps and I have a simple question.
I am making a really simple app which allows the user to set the volume of the device on the settings screen using a slider instead of the volume buttons.
It may be quite obvious for experienced developers but I just can't find the answer I am looking for.
My question is:
How can I make this slider?
Basically I want to do this (image: https://www.dropbox.com/s/b81bzdwyrab0ha7/slider.png?dl=0):
I used to think that I could use a regular UISlider but some documentation says that I need to use something called a MPVolumeView. The problem is that I can´t find a good tutorial that tells how to use this explicity.
I found this link on the apple documentation but I dont understand how this works. – http://developer.apple.com/iphone/library/documentation/MediaPlayer/Reference/MPVolumeView_Class/Reference/Reference.html
And the description says: Use a volume view to present the user with a slider control for setting the system audio output volume, and a button for choosing the audio output route. When first displayed, the slider’s position reflects the current system audio output volume. As the user drags the slider, the changes update the volume. If the user presses the device volume buttons while sound is playing, the slider moves to reflect the new volume.
This is exactly what I want but I dont understand the example it gives. If you could please tell me how t make this slider work, even if it is on a new one-view project, I would really appreciate it.
Also I am aware that this method also creates an airPlay button next to the volume slider. Is there a way to delete this button? (My app is a simple productivity app so I only want the slider, not the airplay button).
I also understand that this will not work on the simulator. How am I supposed to know that this will work without having to test it on an actual device (I am not registered as a developer yet)?
Plus, I only know objective-c, not swift. If you could please restrain from using swift in your answers I would apreaciate.
Thank you so much for your help.
PD: English is not my first language. Sorry for any mistakes I made.
The MPVolumeView class is designed to let you do exactly this. It's in MediaPlayer.framework, so add that to your app to make things build correctly.
You create it and make it visible the way you instantiate any other subclass of UIView, which you probably know by now.
You disable the routing button by setting the "showsRoutingButton" property to false.
"How am I supposed to know that this will work without having to test it on an actual device?"
By seeing that it's been there since iOS 2.0, and is used in countless apps?
The process to writing such a slider is incredibly simple, look into UISlider(https://developer.apple.com/library/ios/documentation/UIKit/Reference/UISlider_Class/) and then use the float value from the slider to set the volume.
If you do not want to write your own slider, look on GitHub(github.com) for controls that do this for you. After doing a quick search, I found this UISlidersubclass that adjusts volume.
I am developing an iPhone app, and have come across an issue that leaves me completely perplexed.
In the app, there is a normal UIView, which consists of a UISegmentedControl. This UISegmentedControl is not once called or looked at in the code, in fact, there is no IBOutlet whatsoever, it lives only on the Storyboard.
Every time I load the app on my phone, my segmented control looks like this:
However, to my dismay, after a certain yet to be found out mixture of using the app, putting it in the background, and then using it again, the segmented control turns into this:
I know I don't have much more information to provide as of yet, but it seems hard to give any sort of code when there isn't any to do with the UI of the segment.
What I can say is that my "Use AutoLayout" is switched off.
I hope one of you can provide me more insight on how to fix this, thanks.
I am looking to implement a custom toolbar that sits above my keyboard for a text field with some custom values. I've found a ton of tutorials online but this question is for asking what's the best way to do this.
This tutorial here http://blog.carbonfive.com/2012/03/12/customizing-the-ios-keyboard/ provides the most common way I can see across many tutorials, with creating a new subclass of UIView and using delegates to get that information across.
That's the commonality. However, I came across this tutorial which in the view controller itself just creates the toolbar, assigns it to the textField inputAccessory and it's good to go. In fact, I tried out the code and without any effort, I have now a custom keyboard.
http://easyplace.wordpress.com/2013/03/29/adding-custom-buttons-to-ios-keyboard/
This just seems a bit too easy to me though and I'd think the proper, Apple recommended way would be to create that UIView subclass and use delegates so that the view controller with the text fields acts as that delegate.
I'm specifically targeting iOS 7 in my app.
What are people's thoughts on this? If the second easier link is supported and is likely to pass Apple's guidelines, it's a good starting point but if delegates are the way to go, I'd rather look into that from the start.
Your thoughts will be appreciated.
There is no 'Apple Approved' way to do this, and its hard to believe anything you do here would get your app rejected. The custom keyboard you reference in your post has the iOS6 look and will appear outdated in an iOS6 app. I'll mention some iOS7 suggestions shortly, but the constant danger of mimicking what the System looks like today is guaranteed to look outdated later. In Mac/Cocoa development, Apple use to say at the WWDC that if you did something custom, make it look custom, don't take a standard Apple widget and try to duplicate it. But that advice is mostly ignored.
For iOS 7, you can create buttons that appear just like the system ones do (not pressed), but of course when someone presses them, they won't act like system buttons (i.e. animate up and "balloon" out.
I'm currently using a fantastic add-on keyboard, my fork of KOKeyboard (which uses the buttons above). This is such a cool addition. While the buttons look like iPad buttons, each one has 5 keys in it. By dragging to a corner you select one of the four, and tapping in the middle gives you that key. This might be overkill for your app, but it really helped me with mine. It looks like this:
(the Key / Value is in the under laying view.) The center control lets you move the cursor - its like a joy stick - and can be used to both move and select text. Amazing class, I wish I'd invented it!
Also, for any solution, you want to use a UIToolbar as the view holding the keys, for the reason that it supports blur of the view it overlays, just like the keyboard does. You can use the UIToolbar with no bar button items in it (if you want), and just add subviews. This is a "trick" I learned here, as there is no other way to get blur!
David's KOKeyboard (er…, the one he used - see David's comment below) looks nice. I suspect that he is using the official Apple mechanism:
inputAccessoryView
Typically, you'd set that value on a UITextView, but it can be any class that allows itself to become the first responder.
The provided view will be placed above the default apple keyboard.
It is correct that there is no official mechanism (and it is suggested against) to modify any system provided keyboard. You can add to it, as above. You can also entirely replace it for with your own mechanism. Apply will forgo the keyboard setting on your view and use a custom input mechanism if you set
inputView
set it to any view - Apple will still manage its appearance and dismissal as it does the custom keyboards.
Edit: Of course, iOS 8.x added significant access to keyboards. (not mentioned here)