I have a form with 4 elements: name, phone, email, privacy policy accept.
On mobile when I click on an input element the keyboard opens up so I can type but when I'm finished and I click the privacy checkbox there is a jump in the page and this jump is surely caused by the keyboard disappearing, since it is not needed for the checkbox.
Is there a way to fix this issue? I mean: is there a way to keep the form still even when the keyboard disappears?
Thanks
Related
I want to create a popup next to some data that contains a few input fields. Let's pretend that the we have the following document structure
<input name="before-the-data" type="text />
<div id="the-data"><!-- presents some data --></div>
<input name="after-the-data" type="text />
When you tab forward from before-the-data the popover should open and focus should go to the first input in this popover. This popover is appended to the body kinda of like Modal from material-ui so that it lies above the rest of the content. Similarly the popover should open when you tab backwards from after-the-data.
The popover should behave as if it were inside #the-data for navigation purposes but the actual position would be at the end of <body> for presentation purposes.
To achieve this effect, I set tabindex="0" on #the-data and trigger opening the modal and shift focus into it. This works fine so far.
Now for the question: How do I best create the following effect?
You should be able to navigate back out of the modal. My idea was this: When focus shifts from it or the user clicks outside the modal, we close it and restore focus to the element that had focus before it opened up. This can be done with a simple onblur handler and a onclick on a backplane. To support tabbing, the resulting modal looks like this:
<div id="backplane" onclick="closeAndRestoreFocus()"
onfocusout="checkCloseAndRestoreFocus()">
<div id="beforecanary" onfocus="shiftFocusBefore()" tabindex="0"/>
<!-- popover content -->
<div id="aftercanary" onfocus="shiftFocusAfter()" tabindex="0"/>
</div>
You can see that I added two divs that you can tab to beforecanary and aftercanary. When they get focused they shift focus to before-the-data and after-the-data respectively, to simulate as if the popover was actually inside #the-data.
At this point, you hopefully have understood what I am trying to create. Thus, the question: How good is this approach in general with respect to accessibility and how can I make sure I follow best practices of WAI-ARIA?
we close it and restore focus to the element that had focus before it opened up
That might be considered a tab trap, 2.1.2 No Keyboard Trap. Isn't the element that had focus before the popup the #the-data? So if I tab from before-the-data to #the-data, the popup will open. If I press esc to close the popup (you didn't mention that esc would close the popup but it should), the focus goes back to #the-data, which will automatically open the popup again, won't it? (Because onfocus() ran again.)
If I just tab through the entire process, I think it would work. It's just the dismissing of the popup that causes the problem. Tabbing straight through everything would move focus from before-the-data to #the-data to the elements in the popup to after-the-data then to the rest of the page, right?
When tabbing backwards, from after-the-data to #the-data, is the focus moved into the last element in the popup? Since I'm tabbing backwards, it needs to be on the last item so that I can continue tabbing backwards through the popup and then to before-the-data.
The popover should behave as if it were inside #the-data for navigation purposes but the actual position would be at the end of <body> for presentation purposes.
If the popup is in the DOM at the end, that would not allow a natural tab order. You can certainly put it there but then you have to manage the tab order. It would be much simpler if the popup was truly part of #the-data. Then the browser handles the tab order naturally.
You also have to be careful with automatically opening a popup but it might be a violation of 3.2.1 On Focus. See "Example of a Failure: A help dialog". It sort of describes what you are doing but is a little different. In the failure example, focus is moving to an input field, and the popup opens automatically and the focus moves from the input to the popup. Your case is a little different because you move the focus off the input first (or before-the-data) and then the popup displays, which would not violate 3.2.1. I just wanted to point this out in case you change your interaction model.
So in summary, your current behavior is kind of like a skip link. Skip links are often implemented as "hidden" links that only become visible when you tab to them and allow you to jump to a location on the page. The fact that they become visible upon focus is how your popup works (since it too becomes visible when it receives focus). The difference is that skip links do not dismiss if you press esc. They do dismiss if you click outside of them. I think that's the behavior you're trying to mimic. If you ignore my comment earlier that esc should dismiss your popup, then you'll be ok. I only had that comment because it sounded like your popup was like a modal dialog.
I'm implementing Accessibility in my application. Here's the scenario :
I have 4 buttons arranged horizontally at the very top of the screen (Activity). On the click of a button, I'm launching an Alert Dialog which displays something to the user. With the alert being displayed, I will still be able to perform click operations on those 4 buttons at the top of the screen. When I turn ON TalkBack (Android Accessibility Service) in Android device and click on that button, alert is getting displayed but I'm unable to move the focus (a yellow rectangular box which will be there when TalkBack feature is turned ON in Android phone) to those 4 buttons. Please help!
Try to set the below properties to your buttons
android:importantForAccessibility="yes"
android:focusable="true"
You won't be able to do it with a dialog, you'll need to fake it with a View.
Perhaps you are using the wrong component which is why it sounds odd when you describe it? A picture of your design would help provide some context.
As #aardrian says, the alert dialog is modal and will (and does) block user input from the underlying UI. Clicking away from the dialog or pressing back will dismiss the dialog.
With TalkBack enabled, the user will be able to press the system back button, use the back gesture (swipe down, then left) or select an option within the dialog to dismiss it.
Try to integrate voice control into your application via Accessibility TalkBack
Define 4 buttons, Alert Dialog Box as objects, selected by voice:
button 1
button 2
...
...
I am studying the limitations of voice control of Android smartphone/ device in Blind Mode ( eyes-free)
I have a problem with my webapp.
Is there a way to hide the android keyboard on text input focus without losing the focus on the input?
Focus on page load works fine, because the field is focused and no keyboard is shown. I want the same behavior after re-focus on input.
Thank You
Maybe you should give keyboard customizing apps a try...might work. I personally prefer Redraw Keyboard, but there are many out there to choose from.
I've designed a contact form for my site that works properly on desktop. When trying to do some responsive programming, I realized that the first field in the form (Name) is not clickable. Clicking the button just takes you to the next field (Email). Anyone else experience this problem? It's happening on all mobile devices as far as I can tell.
The URL is envolverxlaunch.com and the form is on the bottom of the page.
Thanks!
Brandon
Just checked the DOM with the Chrome Dev-Tools in mobile emulate mode, and I have found that input and label element off the name field lays under the input and label element off the mailaddress. It overlaps, because the first input element has a huge margin-bottom, and some elements are not cleared. If you click on the name field, you hit the label off the email field.
We have a web based form that is displayed in a WebView in a UWP app. When data is entered into the form we haven't found a way to ensure that the input field with focus is in the visible area when the software keyboard is displayed so the input field with focus remains visible.
There seems to be some inconsistency in the built in behaviour as sometimes when setting focus on an input field (by tapping it) it will be scrolled into a visible position. Other times it remains hidden behind the keyboard.
In a XAML based UI this is easy to manage by adjusting the layout based on the Showing and Hiding events of InputPane.
We can do the same with content in a WebView to allow the control to be resized and ensure that it is possible to reach all content when scrolled but this doesn't ensure that the field with focus is not obscured when the keyboard is displayed.
Given this scenario is there a way to ensure that the focused control is visible when the keyboard is displayed?