I'm having some trouble getting TalkBack to work with a web view (testing with a Nexus 9 on Android 5.1). I read that TalkBack support was added to web views around the release of Android JellyBean by checking a preference titled "Enhance Web Accessibility." I can't for the life of me find this preference in the system settings.
Focusing on the web view in our application simply reads "WebView" and provides no other options.
Was TalkBack support for web views removed in KitKat? If not, what am I missing here?
Am using Mobile accessibility Plugin to read my customized talkback
My app work fine with Android 4.4.4 . Am using aria-hidden=true to stop default talkback of Mobile accessibility. But with that attribute lollipop doesn't focus to the event and not all reading
Your question is a little unclear. But I can guarantee one thing, this has nothing to do with the "Enhanced Web Accessibility" option. This was an experimental accessibility setting in Android 4.1 - 4.2 and has since been deprecated. This is why you cannot find this setting. What "Enhanced Web Accessibility" did was add some visual elements to help users spot things like Links and such with nice outlines. It has nothing to do with basic TalkBack support for WebViews, which has been supported since TalkBack was released, though it has certainly improved since then, and is still improving.
Now, this doesn't really answer your question. Only removes one of the solutions you seem to have been concerned about investigating. As per your actual solution, your question is a little unclear what your actual problem is. It seems to me you have some sort of event firing in a custom WebView you have created, and this should cause TalkBack to read something out. I await further details to continue this answer, though I suspect that you have not set the WebView's accessibility delegate.
mWebView.setAccessibilityDelegate(new View.AccessibilityDelegate());
It must be set to setJavaScriptEnabled (false);
web components analysis appears to be view.view.
Related
I'm developing an Android webapp (an app built with Android Studio mainly based on a single webview which loads remote content) that is meant to be used by visually impaired people.
Standard accessibility features, such as those provided by Android itself and Talkback, are completely useless for my use case, because this app is meant to be used in a completely non standard way, by using the headset button as the only input, and spoken text as the output.
The webapp is NOT meant to be used by people who are not visually impaired alike. We already have a completely different version of the webapp for that. However, I do want the spoken texts to be displayed on screen, mainly for testing/debugging purposes.
So, I don't need nor want to take advantage of Google Talkback, and my webapp, built from scratch using native TTS called from JavaScript (and TTS events, such as ending of utterances, triggering JavaScript code), already works fine when TalkBack is disabled.
However, my app is going to be used mostly on phones whose users DO have accessibility and TalkBack enabled (or perhaps other accessibility extensions - hopefully not, given the nearly nonexistent standardization of the framework for accessibility features).
So I need to prevent it from interfering with my own calls to the TTS engine.
Which is complicated as hell.
Also, I need it to be compatible with Android 2.x through 4.x.
On older Android versions, the problem is relatively small, as TalkBack doesn't inject scripts into the webview, and the webview is almost opaque, its contents being "invisible" to Talkback.
On newer versions, it's a nightmare.
Android doesn't provide a way to simply disable accessibility features from the app, which is ridiculous.
The AccessibilityManager.interrupt() method doesn't seem to do the trick, and it's practically undocumented, so I can hardly figure out in which ways I could try to use it.
There doesn't seem to be any documentation about how the injected scripts work and how I could try to interact with them.
And to screw things further, I'm reading that since 4.4.something, the scripts formerly injected by TalkBack are now replaced by something else, integrated into the very web engine, or something like that. So maybe even any hack I can figure out for TalkBack injected scripts may not work with the most recent versions.
Is there some workaround/hack to completely disable TalkBack from my app, for my app, when my app is running?
Is there a way to prevent the injection of javascript code from TalkBack (when the script injection is enabled systemwise)? (obviously without disabling javascript altogether in my webview, since I do use my own javascript)
Is there at least some documentation of those scripts available? Or their code? So that I could at least try to "fool" them?
Is there a way I can make some parts of the webview's content "invisible" to TalkBack?
Or any other suggestion in order to be able to have my app do its own call to TTS while avoiding Talkback to interfere with them, and render text on screen while preventing TalkBack from interacting with it?
I've been working with TalkBack and Android for about a month now and find the same frustrations you have - little to no documentation other than reading thousands of lines of source code. In 4.4 the WebView component changed to use the Chromium engine, which is from what I can tell the reason the scripts injected aren't exactly the same. Both still seem to be using ChromeVox. There are no public APIs for disabling TalkBack, it can be done with reflection if you're included to deal with the headaches that come with that. You're best bet is to disable ChromeVox (it's injected into your WebView automatically on 4.4+ and on lower 4.x assuming the web accessibility setting is enabled) from the JS side.
I can only test on 4.4 now, but this does the trick for me:
cvox.ChromeVox.host.activateOrDeactivateChromeVox(false);
https://code.google.com/p/google-axs-chrome/source/browse/trunk/chromevox/chromevox/injected/init_document.js?r=193
I'm developing an application for Android (and iOS) using PhoneGap, and have come across a problem where as a result of some -webkit-transform: translate3d(x,y,z); calls, my text input boxes that are created by Android are no longer lined up with the element on the page.
The issue that I'm experiencing is the same as this one, however I wish to hide the boxes that Android creates and instead use the ones that are present within my application's DOM. Is this possible?
There is a specific article about Android form bugs in our documentation, check it out. Unfortunately there is no full solution for this problem, but at least the newer Kendo UI Mobile versions implement a partial workaround for this issue (which btw was finally fixed in Jelly Bean). Since the workaround has several negative effects, consider if you want to use it at all.
Does anyone have any experience with making an Android app accessible when utilizing PhoneGap? At the very minimum we need to make our apps Section 508-compliant.
I have tried implementing some standard accessibility features (labels for textboxes, adding title attributes to divs, etc). However, when using TalkBack and Expore by Touch in Android, when my PhoneGap app is loaded it just says "WEB CONTENT" - and that's it. Nothing else about my app is spoken aloud.
When the same app runs in iOS with VoiceOver everything works quite well. It reads all of the "title" attributes just fine.
Yeah, I can reproduce that problem as well. It doesn't look like
TalkBack can read things inside the WebView. You should raise an issue
with them:
https://code.google.com/p/eyes-free/issues/list
I'm sure we'd be happy to work with them on it.
I've been having a look to the built-in haptic feedback you can enable trough the KickBack setting on the Accesibility menu. It works like I expected on most of UI elements.
For those who are not aware of what haptic feedback is, it's very simple, just vibrate slighty as the user presses any button/key/field.
Well, my problem is about enabling that feaure on a WebView interface. I made sure to enable it by calling WebView.setHapticFeedbackEnabled(true), but it wouldn't work. I also tried using the native Android Web Browser, but the haptic feedback is not enabled on there either.
I was wondering if someone has some tip on how to manually set that feedback for the WebView, cause I've been having a look to the API, and can't get any idea.
PD: I'm developing for FroYo on a Nexus One with 2.2.1.
Regards!
This is currently not possible since the default WebView control is not accessible. This will be fixed in Android 3.0, according to this blog entry If you must get accessibility working for web content displayed in your app take a look at IDEAL Web Reader It's open source so you may be able to use some of their code or ideas in your own application.
Does Android support visually impaired users in the same way as HTML alt tags are used to provide input for screen readers on the web?
If so, what is the best practice to code Buttons and ImageViews etc so they can be read by a screen reader?
I'm not quite clear on your question. The internet browser, or any applications that rely heavily on HTML rendering are not accessible This quote is taken from this blog post.
You can turn on the accessibility features by going to Settings --> Accessibility and checking the box "Accessibility". While the web browser and browser-based
applications do not yet "talk" using these enhancements, we're working on them for upcoming releases.
Android does provide screen reader support for a lot of applications, see this wiki page for a list of applications known to work well with Android using a free and open source screen reader.
I can't find any general guidelines for creating accessible apps but this LinkedIn group may be helpful. I don't have a LinkedIn account though so don't know how active the group is.
The best resource I've found on the Android Accessibility API is this code walk through: https://sites.google.com/site/gdevelopercodelabs/android/accessibility
See http://developer.android.com/guide/practices/design/accessibility.html for plenty of details on writing an accessible app.
The nearest equivalent to HTML's ALT is the contentDescription property - set in code or in XML.
If you are creating you own custom control, you'll need to do a bit more work to specify other details too; more details at the link above.
Most important thing: when you're done, test with TalkBack, the free Android screenreader from Google. (It's pre-installed on some Android models, but you can download from Android Market if you don't already have it.) You should be able to navigate to all the interactive elements in your app using the directional pad alone, and TalkBack should read out appropriate values for all elements as it does so. (It should pick up the contentDescription and read it out here.)
One thing to watch for is that from what I remember, the screenreader only reads out things that you can navigate to, so if you have instructional text on the page, it may not read out, so you may need to ensure that the contentDescription for other controls is suitably descriptive. To be sure, test with TalkBack, and see for you self (er, hear for yourself!) if what is read out makes sense.
(As noted in one of the other replies, although Android has an accessibility API, the Android browser doesn't actually support it (yet), so HTML pages - even properly marked up HTML code - isn't accessible on Android using the default browser. There are a couple of 3rd party browsers that add accessibility to HTML, though, such as the free IDEAL Web Reader app, which appears to wrap the Android HTML control and then add voicing on top of it. Hopefully Android will make their default browser fully accessible in some later release...)