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.
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 using HTML5 validation to validate a form. The validation process works but the problem is how validation messages appears in Chrome for Android.
How can I fix this? It happens every time I test.
It seems you have two problems:
The shadowdom of older webkit versions can be targeted with general selectors. I.e.: form.my-form div Try to use classes as last selector part: .my-form .my-div. Maybee you should also check wether a * {box-sizing: content-box;} needs to be addressed. Alternativley you can fix those styles, by re-adding right styles using the webkit pseudos: http://trac.webkit.org/wiki/Styling%20Form%20Controls#Formvalidationmessage and http://trac.webkit.org/wiki/Styling%20Form%20Controls#WebKitr82180orlater
I'm not sure wether this is happening, here (your picture is not clear). There is an overflow bug in older webkit versions. Do not use overflow: hidden with positioned element as a wrapper for your form fields
Hello Stackoverflow Community,
I am writing Phonegap application, and i need to support Android 2.3 - 4.1.
On earlier android there are some bugs with keyboard, so I've created custom one on html. Now, I need for all androids version API <= 10 turn of virtual keyboard. Any ideas how to completely programmatically disable it?
Thanks,
-Dima
put below code in your manifest file, inside actvity node
android:configChanges="orientation|keyboardHidden"
it may help you
On earlier android there are some bugs with keyboard
First, there are many implementations of "virtual keyboards" in use in Android.
Second, I am not aware that Web developers have generally had problems with Android's soft keyboards. You are welcome to provide links to evidence supporting your claim.
Now, I need for all androids version API <= 10 turn of virtual keyboard. Any ideas how to completely programmatically disable it?
That is not possible. However, if your Web page does not have anything that allows conventional text input (e.g., <textarea>), then the soft keyboard typically will not appear on its own.
What options are available for handling text input on Android using Adobe AIR? What are the advantages and drawbacks to each option?
The current options available to AIR developers on Android for handling text input are:
StageText native text (default)
TextInputSkin (spark.skins.mobile)
TextInputSkin (spark.skins.spark)
StageText + TextInputSkin (spark.skins.mobile) hybrid
StageWebView (explained below)
Native view
I'll discuss some of the advantages and drawbacks of each approach below. If I've missed anything (or if you have other ideas that I haven't thought about) please let me know!
StageText
Handles input properly in all cases? Yes
Displays properly in all cases? No
Vertical alignment problems when scrolling.
By default, TextInputs running on mobile devices make use of StageText (native text) for input. StageText offers several advantages, as Adobe outlines in their online documentation, including auto-correct, customization of software keyboards, etc.
The biggest disadvantage to using StageText is described in bugbase ticket 3302441. StageText's positioning becomes broken when a user scrolls. Textfields appear outside of their respective TextInputs or, even worse, inside of other TextInputs. The only work-around for this defect is to design a UI that does not allow scrolling. Obviously this can be very difficult for mobile phones and phablets.
TextInputSkin (spark.skins.mobile)
Handles input properly in all cases? Yes
Displays properly in all cases? No
Inserts random characters on certain Android versions (ex. Nook running Android 2.3).
This component uses StyleableTextField internally. It is optimized for mobile use.
This component inserts additional, arbitrary characters into the TextInput as a user is typing on certain Android versions (ex. Nook running Android 2.3, Kindle HD running Android 4.0). See bugbase ticket 3547601.
If your application is only localized into English (or latin-based languages) and does not need to support older Android versions then this component may work well for you.
TextInputSkin (spark.skins.spark)
Handles input properly in all cases? No
Does not accept certain double-byte characters (ex. Korean).
Does not accept any input on certain devices (ex. Samsung Galaxy 10.1 running Android 4.0).
Displays properly in all cases? Yes
This component uses RichEditableText internally. It is not optimized for mobile use. Beyond that it demonstrates several defects (listed above) that make it unsuitable for use.
This component does not properly handle certain double-byte characters (in languages such as Korean). These characters seem to be inserted into the TextInput (the cursor progresses, visibly) but no text is rendered to the user. (It is possible that this issue could be resolved using an embedded font.) See bugbase ticket 3547591.
While testing the 3rd item mentioned above (input not being accepted on certain devices) an interesting thing was observed. After typing a couple of characters, if a user switches focus to a TextInput that uses the default StageText, at least some of the missing characters will be automatically inserted into the new field.
StageText + TextInputSkin (spark.skins.mobile) hybrid
Handles input properly in all cases? Yes
Displays properly in all cases? No
Sometimes the software keyboard's "show" animation is triggered twice in a row, creating an undesirable visual effect.
Sometimes focus handling is difficult and can result in the StageText-TextInput showing without a software keyboard until the learner touches it again.
This approach combines the benefits of StageText with the scrolling functionality of TextInputSkin (spark.skins.mobile). The general idea is to create 1 TextInput that uses StageText and assign it to a fixed location on the screen. This TextInput should be hidden by default. Other TextInputs (using TextInputSkin) can be created and positioned as needed on the stage. When one of these TextInputs gains focus, the hidden surrogate TextInput should be shown and focus should be shifted to it. As text is entered into the surrogate, a change-handler should copy the text to the user-selected TextInput. When the user tabs or clicks to set focus elsewhere the surrogate TextInput should be hidden again.
I can provide a code example of this if desired. There are a couple of drawbacks to this approach (mentioned above) but it's possible that they are the fault of my implementation.
StageWebView
Handles input properly in all cases?
Yes/No
Depending on the value of <renderMode> and <fullscreen> this component may work properly for you.
Is a little tricky to get working.
Displays properly in all cases? Yes
This approach involves displaying a simple HTML page inside of your AIR application using StageWebView. The HTML page contains <input type="text"> objects which make use of Android's native text and software keyboard. Communicating between the HTML page and the parent AIR app though is a bit tricky, since StageWebView does not support Flash-to-JavaScript communication in the same was as ExternalInterface.
Communicating from JavaScript to Flash
Communicating from JavaScript (or HTML) to ActionScript is difficult because StageWebView does not allow ActionScript to add callbacks. StageWebViewBridge offers this functionality has not been updated in some time and when I tried it, I was unable to get content to display using Flex 4.6 and AIR 3.5.
There are still ways to convey information to ActionScript using LocationChangeEvent. The idea behind this is for the AIR app to listen to location changing events and then parse the incoming event.location for information. For simple links this works easily but things get more complicated when it comes to forms. I tried the following approaches before settling on one:
Add an onclick handler to the form-submit button that sets window.location.href to a string containing URL-encoded key/value pairs. This approach does not work for reasons described in bugbase ticket 3362483.
Add an onclick handler to the form-submit button that dynamically modifies the form-target to contain URL-encoded key/value pairs and then submits the form. This approach does not work because LocationChangeEvents are not dispatched when form.submit() is called.
Add onchange handlers to <input type="text"> tags and modify the href attribute of a "submit" link to contain URL-encoded key/value pairs. When this link is clicked, your ActionScript LocationChangeEvent handler will be invoked and you can parse the incoming data using the URLVariables class.
Communicating from Flash to JavaScript
To communicate with JavaScript (call methods, pass parameters) use the StageWebView's loadURL method like this:
_stageWebView.loadURL( 'javascript:yourMethodName( "A string", true )' );
Unfortunately the loadURL method has a void return type (meaning that you can't retrieve data this way).
Other difficulties
The biggest drawback to this approach is described in bugbase ticket 3535948. If your AIR application uses <renderMode>direct</renderMode> or <fullscreen>true</fullscreen> then text input via StageWebView will be unusable. (Response will be sluggish. Users will be unable to select or delete characters.) If your app does not require either of those flags then this route may work well for you.
One workaround for the fullscreen limitation is to disable fullscreen mode only when your application needs to make use of a StageWebView. This can be done with StageDisplayState like this:
// Turn off fullscreen
stage.displayState = StageDisplayState.NORMAL;
// Turn on fullscreen
stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;
Native View
Handles input properly in all cases? Yes
Displays properly in all cases? Yes
The last remaining option (that I'm aware of) is to write a native extension that displays text-inputs and returns data to your AIR application. This is probably the safest (although most disappointing) option of the ones discussed in this thread.
We might have a solution that works atleast for our scenarios : http://blog.flexicious.com/post/Scrolling-Issues-With-TextInput-for-Flex-Air-Mobile-Native-StageText.aspx
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.