I ran into a weird situation just now. I have a container view in our app which needs to read out all of the views when tapped, but only one view should be able to be accessed individually. Because some of the views are complex views with their own subviews, I setup my ADA logic to read the accessibilityLabel of a view if it has one, and if not, to build one from the subviews.
Well, today we had to add the word "button" to the help button when it's being read because the container view was tapped. So I simply added the word "button" to the label's accessibilityLabel and everything worked fine. Then I realized, this may change it to read "more information button button" when tapped individually, since I had set the accessibilityTraits property of the button to be UIAccessibilityTraitButton.
However, to my surprise, it read it correctly as "more information button." Does Apple detect extraneous "button's" in an accessibilityLabel and remove them when the trait is set to be a button? Would they also remove extraneous "label's" from a button when it's trait is set to be a label? I find this extremely cool, and incredible forethought on Apple's engineer's parts, if this is the way it works.
Edit: If this is the way it's done, could someone point me to where this is documented? I wasn't able to find it, although I'm currently still working on this fix so I didn't do the most in depth search I could have done.
I've had some time now to do some proper testing. VoiceOver will remove the extra labels if you set the traits properly. This allows for you to have the type read in a container view, and still set an accessibilityTraits.
So, for example, if you set the accessibilityTraits to UIAccessibilityTraitButton and the last word in your accessibilityLabel is button, it will remove the last word and only read button once. If, however, you set the accessibilityTraits to `UIAccessibilityTraitImage', it will not remove the button, and will end its reading with "button image". Changing the last word to "image", however, has it only read image once.
Pretty nice forethought on Apple's part with that implementation.
Related
I am looking for a way, that does not involve a UITextView or 3rd party framework, to make multiple tappable links, on a label. A side note, with the string, for the label is, it’s fetched from a server, so we don’t know the links ahead of time.
As an example, lets say there’s a post, and it has two links, each to a random site dynamically fetched from the server. After detecting that they are links, which I can do, how would I make those tappable?
I have scoured StackOverflow, there have been no duplicates or this question, that I can find. If you find something exactly like this question, feel free to mark it as a duplicate. All I’ve seen were people recommending to use a UITextView, a 3rd party framework, or to use attributed strings, but the links are known at that point, they aren’t dynamically fetched.
As #DonMag pointed out, in the comments of the question - I could in fact use a UITextView, and disabling scrolling, which fixed the original reason I was having, that made me turn to do it with a UILabel.
If you would like to do it with a UILabel class then:
set 'isUserInteractionEnabled' property to true
create a Tap Gesture Recogniser and assign it to the gesture recognisers collection outlet of the label
write 'IBAction func didTapLink(_ sender: Any)' which opens a selected link and connect is with the tap gesture recogniser 'sent action selector' outlet
set 'text' property with a link
if you must to display a link as in a browser then:
set 'attributedText' property with a link
add 'NSAttributedString.Key.link' attribute to the link range
I want to output a image when a user taps on the keyboard. Let's say the user taps A on the keyboard in a UITextView. Instead of outputting the normal A, I want to output the picture of an Ape.
If a user taps "S" I want to output the image of a sun. Is this possible with out having to make a customized keyboard?
Besides creating a custom keyboard yourself, there isn't really a neat method to getting an image output.
One thing you could do is program Swift to automatically recognise the letter input and display an image over or replacing the letter as a result.
To do this, assign a variable to your editable UITextView or UITextField. If you are using XCode you can do this by control-dragging the text field into your code and it will automatically create a weak var, but you can change the strength in the pop up box that appears.
Since you now have a variable, there are two options as to how you display the image. One way is rather boring and will clutter your code, but essentially involves this, which I have simplified for the purposes of demonstration:
if UITextInput == a {
// add image
}
You would have to repeat this for every letter of the alphabet.
Or you could create a dictionary in which each letter corresponds to each image, and find a way to cycle through them, depending on the user's input. Even though this is harder to program for a newbie, it makes the code much neater and quicker.
This is the link to the official Apple documentation on dictionaries:
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/CollectionTypes.html#//apple_ref/doc/uid/TP40014097-CH8-ID113
However, since I assume you are programming an app for the younger market, I would recommend creating a custom keyboard as it will be easier in the long run.
Hope this helps,
will
I have problem when in iOS settings is enabled this setting "Button Shapes"
It causing this underline in application (first picture with enabled setting, second without)
Any idea how to programatically or in storyboard disable it?
I tried attributed text but I get same result :(
I'm newbie in Swift.
Thanks for help!
It's not a problem. You should not make any attempt to counter any accessibility changes set by the user. They are there for a reason.
This is an answer by user4291543 from this question Remove underline on UIButton in iOS 7
[yourBtnHere setBackgroundImage:[[UIImage alloc] init] forState:UIControlStateNormal];
I found this answer works with SWFrameButton
And for all the others saying "Don't Do This", SWFrameButton is a very good example of when you would want to do this. I also think the OP's situation is a perfectly valid scenario as well...
I totally agree with #maddy's comment:
It's not a problem. You should not make any attempt to counter any accessibility changes set by the user. They are there for a reason.
But I did stumble on a way to accomplish the task at hand...
In addition to a UIButton, you'll also need to make a .png file that contains nothing (meaning the entire contents have an opacity of 0%). Go ahead and load that into your xcode project's assets.
Now go ahead and set the Button's Background to that image you just provided. (In my case, I called it clear) This will remove the underline from the button's text. However, now you can't see the boundaries of the button. This can be solved by changing the Background of the button's View. Go ahead and select any color for the View's Background property and now the background of the View visibly defines the button's boundaries. You're able to see this because your clear.png has an opacity of 0%.
see the Attributes inspector for UIButton here.
Rather than trying to defeat the underline by going to make a label perform some action via UITapGestureRecognizer, this allows you to still use a UIButton. Keeping inline with accessibility features to mark buttons for people that want to do that.
You could create a custom button class with a label (with clear color). If you set the text of this label instead it shouldn`t get an underline.
Are you sure you want to do that?
Apple added an accessibility feature to mark buttons for people that want to do that. Apple will probably reject your app because it defeats a system function meant to help the disabled.
I found the solution. All you have to do is set a picture as the background of the button. just pick a picture with the same color as the button you created.
There's a "Containers" rotor option in Voiceover which allows the user to quickly navigate through "high level" sections of the screen via single finger swipe up and swipe down actions. For example, the Calendar app has three high level items: navbar, contents and toolbar.
My app uses custom UIView subclasses and, no matter what I try to do, all my views seem to belong to a single container. I can't split them into logical sections. I tried putting them in separate views implementing the UIAccessibilityContainer protocol and setting a few of the accessibility properties on the parent views.
Does anyone know how to create multiple containers?
I did some digging on this issue and think its a private trait Apple is using. First I noticed the only containers recognized are standard UIKit type objects like UITableViews, UITabBars, UINavigationBars, etc. So next I used the debugger to inspect the value of the accessibility traits for these components. They're all 0x200000000000. Just to be sure I didn't miss an UIAccessibilityTrait I checked all of their values. None of them match the value. Furthermore if you set your views accessibility traits to this mysterious value it'll work just like you want! I tried determining the location of this constant but didn't have much luck. If you want to do more digging it looks like apple stores accessibilityTraits using an NSObject category that uses associated objects with some constant value named AXTraitsIdentifier.
Practically speaking you could do something like the below but since its not defined in a public API its functionality could change in the future
//Note the navBar has to be run through a voice over pass before the value is set :( or you can just directly set the value to 0x200000000000.
myContainerView.accessibilityTraits = navBar.accessibilityTraits;
I'd love to hear if anyone one else has info on this? So far I haven't found an ideal solution.
I have been able to make the views in my app reachable by single finger swipe up and swipe down actions when the "Containers" rotor option is selected by setting the accessibilityContainerType property of my views to semanticGroup.
Has anyone run across this warning message building for the iPhone?
More importantly do you understand how to fix it?
"unsupported configuration data detection and editable"
It's seems to be the UITextView that is complaining.
Here's a screenshot.
The problem is that you have that textview set both to editable + to detect/autolink phone numbers, events, addresses, etc. a text area can either be editable and not detect/autolink text, or it can autolink text but not be editable.
Your settings for that textview should look like:
or
but not like:
I think in your scenario, the text input is only used to input text, nothing more. Then when it get's presented back, the "presenting text view" will take care of detecting the potential information... dates, events, etc.
To be more precise : in a simple app scenario, a user types in some text (let's say an event input text view - with no detection necessary at this point). Then when it get's eventually presented back to him or another user (let's say the detail view of the event), the text will be presented back in a "non-editable" text view that in turn will be able to have detections.
I know this question is a little old, but this is how I resolved it;
In Interface Builder I have Links Detection selected, and Editable Behaviour not selected.
Then, in my ViewController, I implemented the UITextView - (BOOL)textViewShouldBeginEditing:(UITextView *)textView { } delegate method and return NO.
It removed the warning and prevents the user from being able to edit the UITextView's content.