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.
Related
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.
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 want to know if it's possible to design my android app UI with HTML5 and CSS3.
If it's possible, is there any performance issue?
Android has WebView which can render HTML content, but it doesn't provide the same user experience as native apps so its use is generally discouraged.
Yes it possible. As rhoadster91 stated, you can use a normal Android WebView which loads your "index.html". All your HTML files should be in the "assets/www" directory. But you'll find plenty tutorials out there which explain everything step by step. Have a look at Googles developer site.
A second possibility would be Phonegap. It is a little tool which helps you to deploy your app for various devices (Android, iOS, WP,...) while coding your app only once in HTML.
I experimented with jquery mobile, native application and phonegap. Building a web application at first seemed very attractive at first as the coding is a lot easier compared to native applications. Here is my opinion based on my research:
Using phonegap slows your application responses, it loads slowly and together with jquery mobile the response and load time increases. So I didnot use it.
Using jquery alone was no different in Gingerbread mobile and on emulator you can clearly see the lag in switching between one div to another div. I didnot use it either.
What I did was use android Webview. I wrote my own javascript and css and placed them on the head section of my page. Used div for changing pages on button click. This approach worked really good giving nearly native performance.
Sorry that I don't have a example code for you to see. My question is that I have 8 image buttons for my menu and I need to know how to make the image buttons show and not show.
Meaning When you go to the menu on Android it shows 7 buttons and hides the 1 button that's for iOS and when your on the iOS it shows all 8 image buttons. I have search on Google for two days now still lost.
I have one solution for menu buttons: Try this AwesomeMenu link.
You will have to make your own modification according to your requirement.
If you're writing a web app and you need to know if the app is being accessed on an Android device or an iOS device, you should look at the user agent string.
Here's a list of iOS devices and their user agent strings: http://www.enterpriseios.com/wiki/UserAgent (First hit on Google, can't speak for the accuracy).
Here's one for Android devices: http://www.gtrifonov.com/2011/04/15/google-android-user-agent-strings-2/ (again, no idea how accurate; do your own research to be sure).
You just have to look at navigator.userAgent in your JavaScript and figure out what device the user is using. That's a start, anyway. (You'll also want to look at the iOS web app documentation to see Apple's specific meta tags and stuff to make your web app work nicely on iOS, and I'm sure Android has something similar).
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...)