Currently I am walking through my whole iOS app to optimize it for accessibility voice over. When it comes to the UITextView, which I subclassed, voice over is not acting like I thought it would. My UITextView subclass is only changing a path's color on the superview's layer in becomeFirstResponder and resignFirstResponder. So nothing special on my UITextView subclass that could interfere with accessibility.
As long as there is no text in the UITextView it is acting as expected. Voiceover tells me that it is a text field and that I can double tap it to edit. But as soon as there is text in the UITextView, the only thing voice over tells me, is the value of the UITextView. Voice over doesn't tell me anymore that this is an editable text field.
Am I doing something wrong? Why is it acting like that?
I do appreciate any help!
If you didn't edit any accessibility hints or labels for the text field it should act accordingly. If selected it should say:
It is a text field
If you are editing it
The editing mode you are in
The value of the text field (nil if empty)
Where the cursor is
Then while you type it says the letters you are entering as you enter them. When you hit space or enter it should say the word you just typed. As long as your text field is exhibiting these behaviors you should be fine.
Tip: if you want to know how accessibility elements should act, try using a native iOS app with accessibility turned on and compare it with your app.
Related
I have a problem with how VoiceOver announces my custom UITextInput while it has the keyboard focus: When the accessibility focus is moved to the UITextInput view by swiping left/right the UITextInput is correctly announced by VoiceOver and I am hearing something like Text field, is editing, <content of text input>, character mode, insertion point at end.
However, if I move the accessibility focus to the UITextInput by tapping on it, VoiceOver says empty line, which is not correct.
I would expect VoiceOver to make the exact same announcement regardless of how the UITextInput got the accessibility focus.
Any ideas what might be the cause of this strange behavior?
To mark up a text field you need to take advantage of a few different properties. First, the "Text field" part you can only get by having your custom control extend the UITextFIeld class. That's the only way you can get that announcement at the beginning without effecting the read out of other things. You could append this to the label. Here are the properties I would recommend for your custom text editor.
Preferred Markup
ClassType: Subclass of UITextField (Probably the most important piece)
AccessibilityLabel: The thing the entered text represents (Ex: Password, Username, etc).
AccessibilityValue: The entered text.
AccessibilityHint: "Some non critical information, that shares some details about what the entered information will be used for."
AccessibilityTraits: (NOT Static Text Trait)
Note that the hint isn't crucial information. Hints are frequently ignored, and just contain useful clarifying information.
Aleternate markup (NOT RECOMMENDED)
ClassType: Subclass of ????
AccessibilityLabel: Text field, $EditingState, $EnteredText, $InsertionPoint
AccessibilityValue: nil
AccessibilityHint: nil
AccessibilityTraits: StaticText (Weird, but if you're including role information yourself, we want the trait of static text on an editable text field, to avoid VoiceOver being smart, including it, and duplicating role information in the announcement... is this starting to feel like a hack yet???)
This is honestly a terrible idea, you really should just have your TextField inherit from the system UITextField and get all of that stuff for free, but if you must, this is how you wold achieve... similar behavior without doing so. I say similar because there are a few things you CANNOT replicate in a custom control.
keyboard type ("character mode") is more painful for you to grab than the system, and I recommend omitting in the custom case. The keyboard doesn't have to respect your requests for mode changes (custom keyboards and such), you can get into trouble and confuse users attempting to share this based on your application's settings. The system is the only thing that can get this right in all scenarios.
Inflection. By doing this the custom way you will lose the style and inflection from VoiceOver. The pauses between the Label and the Entered Text. The lower voice that is read when the placeholder text is read out, etc. You can add commas to your AccessibilityLabel to somewhat replicate some of this, but ultimately, your custom control will always sound a little "off" to a VoiceOver user... unless your custom view extends UITextField...
The problem I have is that I want to detect when the UITextField's text is being changed when the user taps on autosuggestion word.
Using textFieldShouldChangeTextinRange will also react to pasting any text from clipboard, but I want to process EXACTLY the autosuggested text replacement.
It is not possible, there is no UITextfield's delegates to implement it.
My requirement was to make a application specific keyboard i.e with a different theme and different key contents as compared to the default keyboard. But the way Apple states to implement keyboard requires user effort to add it through Settings->General->Keyboard which I don't want.
So, for that I tried to implement it using a UIView and making it the inputView for UITextView and it is working perfectly fine except for one issue. I added a functionality to add a linebreak in the textView. For that the code I used is
textView.text = "\(textView.text)\n"
Now, whenever I add a linebreak through keyboard, line is changed, but a new cursor appears to blink above the old cursor. I don't know how to get rid of that.
To explain the problem in a better way, here's a GIF image of the issue.
Please help.
I am working on iPad app and for textfield i have some validation like its text cant be empty if so it should display an error alert.But in iPad we have its default button at the bottom right corner of keypad which has image some what like a keyboard.Clicking on this very button the keyboard resigns automatically without any validation check
.
How i can disable the textfield resign clicking on this button.
[textField resignFirstresponder];
or
textfieldsholdreturn method will help ?
I'm not 100% sure about this, but the textFieldShouldEndEditing: method in UITextFieldDelegate protocol should be what you're searching for.
The documentation says:
Note: If you use this method to validate the contents of the text field, you might also want to provide feedback to that effect using an overlay view. For example, you could temporarily display a small icon indicating the text was invalid and needs to be corrected. For more information about adding overlays to text fields, see the methods of UITextField.
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.