I have added skip to main content links on header in my web app. It works as expected in Windows and MacOS. It even works as expected in IPhone. But the same is not working in Android chrome/talk back.
when I check further, This skip nav links are not working even in webaim.org . The code I refer https://www.bignerdranch.com/blog/web-accessibility-skip-navigation-links/
Could someone please help why android chrome is having this issue? Is it a browser behavior? Please help.
Let's analyze what is happening in this scenario.
1) TalkBack sets ACCESSIBILITY_FOCUS to the element
This is very important, notice that this says ACCESSIBILITY_FOCUSnot FOCUS. For a hidden skipnav link to become visible it needs to get FOCUS as marking the element as visible (or perhaps shifting it on screen) with the :focus pseudo selector is a very common implementation of this. It's very important that such a control receives FOCUS, which it never does with TalkBack.
2) The user double taps to click the element they just heard get focus.
When the user activates the control a physical click event is set to the middle of the onscreen focus rectangle for the control. Similar to actually touching the screen.
3) The browser sees a physical click event occur on the page.
TalkBack essentially has blindly sent a mouse down event to an area of the page that has nothing or perhaps another control overlayed with this invisible element. Either way, the thing that the browser wanted to click was never "visible" because it never properly obtained FOCUS only ACCESSIBILITY_FOCUS and so the control is not there to be clicked.
Related
As many do , I ran into the problem of the softinput covering my send buttons so I did some searching and found the accepted way of fixing this issue is "android:windowSoftInputMode="stateAlwaysHidden|adjustPan"
and this works great on my device, but when I try it on my girlfriends phone it doesnt work. I see the dialog lift a little before the input shows up on screen , but not much and the send button is still covered. Why would this work on some devices , but not all?
Messing with the onscreen keyboard is difficult at best because on the one hand:
It's supposed to be where it is, that way users expect it, it's consistent, very important in UI design
BUT
It can get in the way.
The solution (based on the Android design guidelines, experience and feedback and so forth) is not to faff with it too much, you can have basically the following kinds of behavior:
*Pops up when activity starts (which happens if the activity has an input)
*Doesn't pop up when activity starts (despite the first input having focus <-- good) but will when the user taps.
It's good to dismiss the keyboard when the user is done, that is have the "enter button" take them to the next entry, if there's none left, hide it, if it's some sort of data capture form that validate as they go along, if not don't do this because they might press back in an attempt to get it up.
Addendum I
"adjustResize"
The activity's main window is always resized to make room for the soft keyboard on screen.
"adjustPan"
The activity's main window is not resized to make room for the soft keyboard. Rather, the contents of the window are automatically panned so that the current focus is never obscured by the keyboard and users can always see what they are typing. This is generally less desirable than resizing, because the user may need to close the soft keyboard to get at and interact with obscured parts of the window.
From the documentation here: http://developer.android.com/guide/topics/manifest/activity-element.html
Difference between adjustResize and adjustPan in android?
See there for more.
It's difficult to pan correctly because the layout of the activity can be many things, it could scroll to the left, it could all be relative, it's not one strip where it need only jump up and down, some things also have more than one solution, more than one way to pan so it is visible. You haven't really described what doesn't work btw. I'm trying to explain the issues of what I think you want.
Does this help?
Suddenly got here. You shouldn't mix several values inside android:windowSoftInputMode="" attribute. So, you can preserve android:windowSoftInputMode="adjustPan" and hide a keyboard with hideKeyboard() (look for this method in the Net). Probably you can add listeners to hide it everywhere inside the activity.
I've got some Javascript code that I have written which captures both keyboard and mouse events. The idea is that whenever I tap on an element (a TD) on the page it gets selected (basically I just change the class so it is highlighted), and I can use the arrow keys to change which element is selected.
However, when I view this page on the stock android browser on my phone (running Gingerbread), the browser eats all the events and my page is non-functional. Specifically, when I tap on an item on the page I see an orange colored rounded box surrounding the text, and my page does not get the event. When I hit the up and down arrow key, the box moves, but my code is not doing this, it appears to be something the browser is doing.
I suspect that what is happening is that the browser is trying to be "helpful" somehow. What I'm looking for is some way to give the browser a hint to not do this, or otherwise disable this behavior.
Update: Here is a more specific example of the problem I am seeing. I set up the following simple listener just to see what key code correspond to various keys:
document.onkeydown = function(evt) {
alert(evt.which)
}
Now, if the cursor is in a TextField and I hit the enter key on my phone, the alert pops up and says "13". BUT if I move focus away to another element (in this case a TD), when I hit enter, NOTHING HAPPENS.
Update: I have tried installing a half dozen different browsers. They all seem to swallow up the arrow keys (this is a physical keyboard on the device) and use them to scroll the screen around or to highlight different elements on the page, instead of passing the event to my web app so it can actually use them to do what I want to do! The only browser I have seen that does not do this is Firefox, which seems to just silently ignore them completely.
I have an Android app using PhoneGap 1.6 and Sencha Touch 1.1.1. One view has a text input field which behaves oddly in Android: it duplicates itself and it is very difficult to remove focus.
I have determined that it is a WebTextView coming up over top of the "real" input field. The problem I am having with this is that blurring the text field with screen taps is extremely difficult, and if you scroll the parent container, the WebTextView does not scroll with it, so you can see both at the same time.
The only way to remove focus on the element is to tap furiously all over parts of the screen, much like triggering the frustration detector from Mavis Beacon.
My actual question is: how can I turn off this functionality completely, or at least work around it? It is not reasonable to expect the user to do anything other than single-tap outside of the box, or press the Back button on the device to stop input in the text field. As it is, pressing Back simply stows the soft keyboard and does not give up focus.
These are browser bugs, triggered by some CSS-flags.
To explain the bug:
The device creates some kind of "screenshot" from the web-sites content. All transformations and transitions are made on top of the "screenshots" from the actual page.
If you have input elements, there will be some kind of proxy elements rendered on top of the "screenshot". Sometimes the are these proxy-elements at the wrong position.
This happens, if you trigger the website to be hardware-accelerted. You have to drop some CSS-definitions:
transform(), translate(), transform3d(), translate3d().
The Bad news are:
You cannot solve this problem, because it a bug within the browser.
I have some different android devices, all have different problems, one fix will break another device.
I think the bug will never be solved, because noone cares about the embedded browser since android 4.1 and the chrome.
If you can disble hardware accelertion, this may help.
The good news are:
There are rumors about an embeddable chrome-webview.
I started to write some blogposts about "the new IE":
http://christian-kuetbach.de/blog/post/14
When you have some clickable content like <a>, <input> or <area> and before this you have an absolutely positioned element with a bigger z-index, there is the wrong behavior of 'click-through'.
I click on the area where the clickable element is behind the front element. In other browsers there is the right behavior that the click does not go through the front element. But only in Android Browser you can click through the front element and activate the element behind. This is a known bug and you cannot avoid it. It's even in newer versions (I test on 2.3.3 in the official Android emulator).
There are some workarounds described in some forums but none of them worked for me.
I tried to put an <iframe> or an <a> between front and back
I tried to change the DOM so maybe the browsers state is refreshed
I tried to have the back elements be positioned as well
None worked
I'm especially having problems with the image map's area elements.
Has anyone had the same issue and managed to work around it?
I'm specifically interested in solutions which are tested against image maps.
I am wondering about a few things here. First, what is the purpose of having an overlaid image and using the image maps? I see you're including jQuery - can you use the hover event with jQuery to change the orientation of the images and do the swap? What about attaching to the click event for the image map, and checking to see if the lightbox is open. If it is, then return false;.
Just trying to think out loud. Sometimes another take on it can be helpful.
This is a quick blindfolded reply, so let me know if I should expand/fix it further. The general idea being a CSS class for both the hover and focus events that disables pointer interaction.
yourElementClass:focus, yourElementClass:hover {
pointer-events: none;
}
Actually I've managed to avoid it by moving the objects below to let them be not visible.
But in cases similar to yours the only workaround that actually works is to manage all the clicks in jquery (especially the ones on the background) and to bind/unbind the clicks events on needs.
there are also some things that could help on some version/mobiles (but do not solve the problem)
the above item has background:rgba(0,0,0,0.1);
you should put a gif or png as background of the above element (as well as the background color as point 1)
using thouchstart instead of click as bind event sometimes helps.
the actual version of android/browser are not affected with this bug (or at least it never happen to me) but it could be nice to know the affected versions. If someone has a list.
I am writing a PhoneGap app on Android. I am trying to stay pure HTML+CSS+JS, without calling specific PhoneGap APIs. So the app is somewhat an embedded web page, more or less.
The page has some "buttons" on it, which are actually table cells with some CSS attributes (among which cursor: pointer) and an onClick function.
I have noticed that when I touch a button, it "flashes" for a second or so, then its corresponding action is performed. By the way, I don't like this very much, since it causes a delay in the UI.
Some of the "buttons" activate a menu. I handle the menu by making visible a semi-opaque black div that covers the whole screen, and above it a centered div containing a table containing the menu items. (the black div and the centered div are hidden, normally).
The problem is that when I touch a menu item, it does not flash; one of the underlying buttons flashes instead (that is, one of those that at the moment are covered by the semi-opaque black div, and are supposed to be inactive). Nevertheless, the correct action is performed, in other words the onClick function of the menu item gets called, not the one of the flashing button .
So my question is two-fold:
1) Is there a simple way to make the right item flash (I mean the menu item instead of the underlying, semi-covered button)?
2) Is there a simple way to totally disable button flashing, so that the UI would speed-up and problem 1 be solved too?
Many thanks
You should be using the touch events, which are supported on Android WebKit. This will prevent the select + touch behaviour that you're seeing on your HTML elements that the onClick event causes.
Android versions past Android 1.5 support touch events such as touchstart and touchend. I recommend using them, and reading Apple's documentation (yes, I know it's weird, but Google's Web App documentation is still poor with respect to touchevents.)