Precondition : Accessibility Talkback on.
Problem : While typing in characters from soft keyboard into the edit text, the characters are announced twice.
(I think once by the keyboard and once by the edit text).
Problem: Sighted users don't understand/empathize well with the types of information that blind users need. They just use a keyboard with TalkBack on, without actually closing their eyes and experiencing it the way a blind or partially sighted user would.
Solution: Close your eyes and actually use the keyboard the same way a TalkBack user would. You will discover that there are actually two relevant pieces of information here. The key that you're going to select and the key that you've actually selected.
Real Solution: Let Android do its thing unless you REALLY know what you're doing. More often than not, well intentioned, developers just muck things up when they start trying too hard. Provide content descriptions for your non-text controls, hook up some nice data associations when necessary and otherwise leave things alone.
Related
This is an Android question.
Inside my <TextInput> (ReactNative (which renders an EditText in Android)) when the user types "#" and then they use Androids swipe mode to auto-complete a word, it adds a space between the "#" and the autocompleted word. So what I was doing was, onChange of the text, I replace the space between "#" and the word, however while the user is in swift mode, it is really messing things up. The space comes back and the swift autocomplete messes up to another word.
Is there a way in react-native to listen when the user accepts an autocompletion? I want to then check if the previous two chars are a # (hashtag and space) and if so, then replace it with just # (hashtag without space).
I was thinking the onCommitCompletion- https://developer.android.com/reference/android/widget/TextView.html#onCommitCompletion(android.view.inputmethod.CompletionInfo) - fires after a suggested word is accepted - is this true? If it is this would be perfect and I can submit a PR to react-native to accept this for Android.
Here is a video of what's happening: https://gfycat.com/AdmirableGrizzledIrishsetter
Low quality:
This is happening because you are typing a text via Swipe feature of your keyboard. The Swipe feature automatically adds an extra space before and after the String. There is no way to get rid of it, it's an integrated feature of(some) the keyboard. We have no control over it.
Don't worry, the end user is aware of it and all he has to do is type the whole text rather than using Swipe feature to input his text.
Try disabling AutoComplete inside your TextInput , perhaps like <TextInput autoCorrect={false}/>, I'm not sure.
Also, this isn't the problem with Android phones only, try installing GBoard in an Apple Device and you'll face the same problem.
I worked on a major keyboard for 2 years and I have no idea what you mean by "swift mode". But there is no such feature in the generic keyboard API. It may be a feature of some particular keyboard, but there'd be no way to programmatically turn it off.
What you're describing comes closest to sounding like autospacing. This is not a concept that Android has, it would be a concept of each individual keyboard. And since Android knows nothing about it, it can't turn it off (on many keyboards the user could, but that's it).
You might be able to override it (not turn it off, but force the spaces to disappear) if you were to do some work with either overridding the InputConnection or setting a text watcher in Java and altering the text to be inserted, but neither can be done at the react native level- you'd need to write a custom edit text and link that down to react native via a native component.
I think this would be onCommitCompletion - I'm not sure though I am not able to test yet. I think in this callback I would get the position, and see if there is a leading space, and if so then remove that leading space.
I am trying to make my app more accessible. I am having a hard time finding helpful things because there isn't a lot of documentation (at least I could not find it).
In my app, Talkback does not announce the element type for ImageViews. What I basically want is for Talkback to announce my contentDescription for the ImageView and follow it up with ", Image".
This link states that " Many accessibility services, such as TalkBack and BrailleBack, automatically announce an element's type after announcing its label, so you shouldn't include element types in your labels. For example, "submit" is a good label for a Button object, but "submitButton" isn't a good label." but it does not specify which element types it announces and which it does not.
https://developer.android.com/guide/topics/ui/accessibility/apps.html
Does anyone have any idea if Talkback announces "Image" after the contentDescription for ImageViews?
When does Talkback announce a link as a "Link"? Or is it the developer's responsibility to add it at the end of the contentDescription? Can I make talkback announce clickable text as a "Link"?
Any help/information/pointers is greatly appreciated. Thanks in advance.
A: don't add stuff to the end of the content description. It is an accessibility violation and in almost ALL circumstances just makes things less acessible (will explain more later).
B: A lot of contextual things are communicated to TalkBack users via earcons (bips, beeps, etc), you may just not be noticing.
C: Yes, this is confusing and difficult to determine, no images are not announced, though I think this is for good reason. For example, an image with a click listener may just be a fancy styled button. In iOS there are traits for you to change for this, Android has omitted this highly useful feature, so we're stuck with odd workarounds. The ideal solution would be for the Accessibility APIs to allow the developer to communicate this information.
As for links, typically inline links in text views are announced (basically anything android detects and underlines automatically), but otherwise are not. So, in practice A LOT of links are missed.
Now, as for when you should/should not supply this information yourself. If unsure, just don't and you'll obtain a reasonably high level of accessibility by following the above guidelines. In fact, any of the considerations below are really just fighting the Android OS limitations, and are their problem! However, the Android Accessibility Ecosystem is very weak, and if you want to provide a higher level of accessibility, it is understandable, however, difficult! In your attempts you can actually end up working against yourself. Let me explain:
In Accessibility there is a line between providing information and consistency. By adding contextual information to a content description you are walking along this line. What if Google said "We're not going to share contextual information, add it yourself!".
You would have buttons in music players across different music playing apps that announce in TalkBack like this:
App1: "Play, Button"
App2: "Play, Actionable"
App3: "Play, Clickable"
Do we have consistency here? Now a final example!
App4: "Play, Double Tap to click if you're on TalkBack, Hit enter if you're a keyboard user, use your select key for SwitchAccess users....."
Notice how complicated App4's Play Button is, this is illustrating that the information that TalkBack is using is NOT JUST FOR TALKBACK. The accessibility information from you app is consumed by a multitude of Accessibility services. When you "Hack" contextual information onto a content description, sure it might sound better for a TalkBack user, but what have you done to Braille Back users? To SwitchAccess users? In general, the content description of an element should describe the element, and leave contextual information for TalkBack to calculate/users to figure out given proximity to other controls.
TO ANSWER YOUR TWO PARTICULAR ISSUES (Images and Links):
What I recommend for images is in the content description make it obvious that the thing your describing is an image.
Let's say you have a picture of a kitten.
BAD: A kitten, Image
Good: A picture of a kitten.
See here, if TalkBack fails to announce this as an image (which it will) the user still gets the idea that it is a picture. You have added contextual information to the content description in a way that has ACTUALLY BETTER DESCRIBED THE CONTROL. This is actually the most accessible solution! Go figure.
Links:
For links this gets a bit tricky. There is a great debate in Accessibility about what constitutes a link vs a button. In the web browser world, this is a good debate. However, in native mobile I think we have a very clear definition:
Any button that when activated takes you away from your current Application Context, is a link.
The fact that the Context (Capital C Context!!!) is going to change significantly when a user interacts with a control is EXCEPTIONALLY important information.
TalkBack fails to recognize links A LOT, and as such, for this very important piece of information, if you find that TalkBack is not sharing this information, go ahead and append ", link" to your content description for this element. THIS IS THE ONLY EXCEPTION TO THIS RULE I HAVE FOUND, but believe it is a good exception. Reason being, YES it does add a violation or two for other Assistive Technologies, but it conveys important enough information to justify doing so. YOU CANNOT create a WCAG 2.0 compliant application of reasonable complex User Interface using the Android Accessibility APIs. They have too many limitations, you simply can't do everything you need to do to accomplish this without "hacks". So, we have to make judgement calls sometimes.
I am implementing a viewpager which has multiple hints to a particular functionality. Now when I activate talkback feature it reads the content in the current view. I also want the talkback to say as "swipe left for more hints" how can I do that.
Easy answer: Don't. This may be a sensible thing to say if the user is using TalkBack Gestures. But what if they're using an attached USB keyboard in conjunction with TalkBack? Is this really the ONLY way to reach those items. Probably not. And if it is, you're app may work great for TalkBack gestures, but is broken for switch access and keyboard access. TalkBack users know how to use TalkBack, switch users know how to use switches, etc. Use good, common design patterns in your layouts, and let users figure things out for themselves.
Let's explain this in a different way. Let's say you have a button. You have marked this thing up so it looks like a button. Do you have a big sign next to your button that says "HEY, CLICK YOUR MOUSE HERE TO ACTIVATE THIS BUTTON"... no of course not. Users know how to use buttons. Use reasonable design idioms, and users should understand how your UI works, independent of whether they are using TalkBack, Switches, Keyboards, etc. It is misleading, inappropriate, and actually LESS accessible to include TalkBack gesture specific instructions on how to perform actions.
See WCag 2.0 Guideline 4.1
I have an app that I would like to submit to Google Play Store, just to be able to say I have an app that others would find useful. I thought it would be a freebie until I found a similar app-for-pay that mine has more features than. Mine also looks better. Whatever, my questions are about the keypad.
Here are screen shots of input screens, one with output filtering. Output pops up after the Show button is pressed. (The Help button clarifies the overly-terse "output filtering" portion.)
The only keys I need are the ten digits 0-9 and the backspace and Next keys.
Is there an input type that I haven't stumbled onto yet that would have just those 12 keys?
Or is there a way to hide the math symbol, ABC, and "Swype" keys? (Their presence isn't overly distracting, but it would be better without them.)
(I know I could try to design my own custom keypad, but it would be really hard to set up a dozen listeners for a dozen new buttons and have to handle my own text field editing. Meanwhile, the existing look and feel is standard and the app is FINISHED if I don't go this route! It wouldn't be wise to go this route would it? A lot more work not worth the effort?)
there is an android:inputType="number", Also it wont allow any other special characters too...
I've been looking to create a custom keyboard for my application. At first, I started to look at the SoftKeyboard for the SDK examples, but reading the Android Developer Group led me to this post:
This is really not how the input
method framework is supposed to work.
An IME should be a generic input
facility, not for a particular
application. If you need some
app-specific input, you should build
it into your UI rather than pushing
it out to a generic IME.
How do I build an app-specific input within the UI? I mean, is there a way to extend the Keyboard app or something and use it only in my application?
Features needed for the keyboard:
Shift key to display some other keys
Special keys like square root or PI
etc.
PS: an ugly solution could be to make a table of ImageButton for example, but I wanted to make something clean.
I'm not really sure if there's a straight-forward solution to this (to that extent that it is even possible to understand the real reason behind the original question).
As is quoted in the original question:
If you need some app-specific input, you should build it into your UI
rather than pushing it out to a generic IME.
What is meant by that, is not that you within your app should try to build in such input features by extending or modifying the soft keyboard on the phone. There are so many different soft keyboards (and basically, the soft keyboard is just another app), since most phone manufacturers create their own version, and people download 3rd party keyboards (such as Swype or SwiftKey etc.), and I can't picture there being a way for you to "hack" into those to add a few buttons or whatever it is you want (which could also be a major security hole, another reason why it probably isn't possible).
What instead the above quote suggests, is that you have to create some other form of input besides the keyboard. One such example, and a very good one if I might add, is how the RealCalc Scientific Calculator looks:
Now this isn't open source, so I can only guess how the code looks like (but it shouldn't be too hard a guess either): in its simplest form, this is just a grid with lots of buttons. Each button handles the onClick event, which would mean performing some kind of action (changing the label on some other buttons, showing a menu, displaying some text in the upper label or whatever), and that's probably pretty much what's to it. And of course, the phone's soft keyboard is never displayed (since you don't need a keyboard with all those buttons (and also there aren't any input fields to write anything in)).
It all boils down to the already mentioned quote: If you need some app-specific input, you should build it into your UI. Or in other words: create buttons (and don't display the soft keyboard if you don't need it) and make things happen when you click them.
And just to have mentioned it: if you do want to create your own IME (which I strongly believe is not the case here), you should have a look at the following resources:
Onscreen Input Methods
Creating an Input Method
Soft Keyboard sample
In my humble opinion you should take a look at the beginning of reference about keyboard and keyboard view http://developer.android.com/reference/android/inputmethodservice/Keyboard.html and http://developer.android.com/reference/android/inputmethodservice/KeyboardView.html.
There you can see an example of defining keyboard using XML file. I think that this is what you are looking for.
As mentioned by #sebap123
Keyboard and KeyboardView class are the one you need to use,
Further, for Implementation, here is a quick detailed guide.