The App I am working on has a name which is mispronounced by the talkback. I am able to fix this within the app by changing the spelling. But if I change the spelling in the android:label in the manifest, it is misspelled on the app icon on the phone. Does anyone have a way around this?
There is no way to do this. The fix would be for the LaunchScreen to have the ability to read an alternative label, and place it in the content description for the textView that represents your application.
TalkBack reads back things like this.
If a contentDescription is available this is read off.
If the view has "text" this is read off.
All other cases the view is not accessibility focused.
So, what is happening is TalkBack is grabbing onto the "text" of your view as provided by the name of the application. The Launch Screen does not provide a mechanism for overriding the contentDescription, and therefore will only ever read your text. This isn't a problem with your app, it is a problem with the Home Screen app. You may be able to fix this for users with different Home Screen apps, but there is absolutely no universal solution, and certainly no solution for the standard LaunchScreen application provided on stock Motorola, Samsung, and Nexus devices (most likely others as well, but I don't own any of them).
In the case that talkback is not pronouncing an acronym correctly, attempting to read it as a word rather than individual letters, you can use zero-width non-breaking space characters \ufeff to separate the letters invisibly.
Suppose you have the word CAT but you want it pronounced C.A.T.:
<string name="app_name">C\ufeffA\ufeffT</string>
It will still appear as CAT and won't be broken for line-wrapping.
However, your users will not be able to search for the app by typing CAT anymore.
You could change the text read by TalkBack programmatically with:
getWindow().getDecorView().setContentDescription("Name as pronounced")
Related
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.
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 a linguist, not a programmer, sorry. I was asked and am adapting a keyboard for a minority language in Africa. I have spent a lot of time on this and am willing to learn more and to dig deeper.
I am using the latest Android Studio in Windows 10 and am working from a code sample from Google here:
https://android.googlesource.com/platform/development/+/master/samples/SoftKeyboard?autodive=0%2F
I managed to adapt this sample to our local language and compile and install in a several different phones from our team and all the new characters in the alphabet are working fine (ǝƎ ŋŊ ɖƉ ɔƆ ɛƐ ɩƖ ʊƱ). No problems here, this is just background for those who like that.
The unexpected behaviour is sadly with several existing keys, which I have not altered: apostrophe, quotation marks, hyphen, etc. Those are characters which to me "are too active"; possibly an escaping-problem or something the like.
When using my new keyboard in WhatsApp I can type any text just fine, until I need (for example) an apostrophe. Then the apostrophe will delete any alphabet-letter backwards until it hits a "resisting character" (those are space, full stop, comma and some others) and then it will show itself. Example sentence: "Three pigs' house."
I am typing this:
Three pigs
then I hit apostrophe and am expecting this:
Three pigs'
but instead I get this:
Three '
You can see how the apostrophe has deleted "pigs" and has been stopped by the space behind "Three". The same happens for - and for " and for a few other "bad keys".
I have this unwanted behaviour in several "powerful apps" like WhatsApp and Telegram but NOT in a simple text editor like this one:
https://play.google.com/store/apps/details?id=com.maxistar.textpad
I double-checked and compiled the original sample keyboard: It shows the same bad behaviour in WhatsApp, Telegram etc. but not in Simple Text Editor.
So the Google sample SoftKeyboard is having issues. I quote their doc:
Example of writing an input method for a soft keyboard. This code is
focused on simplicity over completeness, so it should in no way be considered
to be a complete soft keyboard implementation. Its purpose is to provide
a basic example for how you would get started writing an input method, to
be fleshed out as appropriate.
I would like help please:
Is this really a problem with the keyboard, or is the fault with WhatsApp etc. for "doing too much" with the characters being sent by the keyboard?
Or how can I find out where the deleting is happening? (Since this is only an input method, the Android Studio's debugging tools do not yet work for me.)
Is there a forum, where I can get help for that specific SoftKeyboard?
Any input to help me to change my self-made keyboard so that it behaves normally in any App which needs text-input, even WhatsApp, Telegram and the like.
Or is there another working template out there, which I could use to make a working soft keyboard for our language. Since I am not a pro, I am hoping for something that I can import into Android Studio for adapting.
Please do not yell at me. Any input and any help is welcome. I can upload my files, but the behaviour can be observed from the original SoftKeyboard files (see my first link at top). If you can type your own language, please be grateful. My people would also love to write their language in WhatsApp. Thank you.
First update:
I have looked over the main Keybaord.java file and have changed
mPredictionOn = true;
to
mPredictionOn = false;
for
case InputType.TYPE_CLASS_TEXT:
This has helped to calm the unexpected behaviour but has also lost some of the functionality. And the caps state is no longer auto-undoing like it is meant to be after user hits one capital letter.
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.
My application name has 15 characters. But in apps list of android device does not shows the full name. So I want to set marquee for my lable in android manifest. But I dont know how even I didn't know wheather it is possible or not.
I was googling it near 4 hours but the solution is only for title of each activity and not for application name.
sample image for reference:
This is sample image taken from google. I could not take screenshot of my device.
Note the red marked name. I want this name to be scroll. If it is possible means please help me friends.
Thanks in advance.
You are not able to make the name scroll on the user's device, as this is (probably) a launcher feature. Unless the user's launcher is able to scroll long app names, it's not going to scroll. This is not something you can control through your app.
you cannot do that pro grammatically. Thats an default functionality of the every single OS manufactures . Its depend upon them only. Some manufactures will set marque and some of then wont set.
Marquee is not supported on all android mobile devices. Anyways check out this link you may be lucky ;)