When my app starts the first textbox has focus. This doesn't really matter when running on a desktop, but when it runs on a tablet it means the onscreen keyboard pops up and obscures half the screen.
How can I prevent any control having focus when the app first starts?
Place a button on your page with an earlier TabIndex:
<Button
IsHitTestVisible="False"
Opacity="0"
TabIndex="1" />
A few things to note:
Setting visibility to Collapsed doesn't work since the engine likes to focus the first Visible control
You need IsHitTestVisible="False" so users don't accidentally click it and it doesn't accidentally block clicks to anything else on the page.
Another control type could work, but it shouldn't be a TextBox since it would still bring up the virtual keyboard.
Setting IsTabStop="False" on your TextBox doesn't work since then it can't get focus at all.
I believe there is no way to simply remove focus other than setting IsTabStop to false on all controls, but the workaround might be to place an invisible control (e.g. UserControl with IsTabStop set to true and Opacity set to 0) with a lower tab index in your page.
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.
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?
I am using a full-screen flipview to allow a background to rotate behind a set of inputs. if you tap the input textbox, the SIP keyboard appears.
however, tapping outside of the textbox does not dismiss the keyboard as expected. I finally realized it is because of the flipview. I verified this by adding a 250 margin around the flipview. if i tap in the area covered by the control it still doesn't dismiss, but if I tap the areas covered by the margins (that is, outside the flipview) the SIP does dismiss as expected.
I tried setting IsTabStop to false and IsTapEnabled to false for the flipview, but the SIP still remains active unless i tap outside the flipview.
since we need the flipview to be full screen, I need to know if there is a way to disable the control so that it closes the keyboard.
can this be done? which property or event on the flipview can I leverage to make this happen?
aha, by handling the "tapped" event I did the old trick of disabling and enabling the flipview and sure enough the keyboard dismissed!
The Windows Dev Center states regarding the UseTouchAnimationsForAllNavigation property:
The XAML FlipView control supports three modes of navigation; touch-based, button-based and programmatic. When a user navigates by touch, the FlipView items scroll smoothly into view. When you set this property to true, the same navigation animation occurs whether the navigation is touch-based, button-based and programmatic.
I'm currently navigating from my page's code behind by assigning the SelectedItem property of the FlipView:
FlipView.SelectedItem = FlipView.Items.Last();
However, the swipe animation does not show. How can I enable it?
Meanwhile, I was able to solve this problem. I have a button that triggers the navigation to the next FlipViewItem. This button however was placed in a FlipViewItem.
With my setup (touch device), nothing happend. Then I tried clicking the button with the mouse and it worked. After I disabled UseTouchAnimationsForAllNavigation, it also worked using touch input. In my tests, I placed the button outside of the FlipView and it did work using animations.
Here's the problem: When tapping the button, the navigation animation tries to start (SelectedIndex is set correctly), but stopped because the user blocks the animation by still touching the button. So, the navigation is cancelled and SelectionChanged reports the current page.
The solution is to set ManipulationMode of the Button to All. After that, you can't flip the FlipViewItem when touching the button, but the animation executes and it works like charm.
I solved the same problem in a different way. As Chliebel said, it is because your finger is still touching the control, so flipview cannot animate. So I gave a small break after before navigating. By the time user would have released the finger and it works !!!
await Task.Delay(100);
flipView.SelectedIndex += 1;
For me, ChristiaanV's answer has helped:
Animation only occurs when you navigate to the previous or next item
in the FlipView.
So I've set up a while loop to set the selected index to the previous / next one until I reach the desired page.
Example Code:
If you'd like to reach the first page:
while(flipView.SelectedIndex > 0)
{
flipView.SetValue(FlipView.SelectedIndexProperty, flipView.SelectedIndex - 1);
}
Here's a compact solution I found, similar to Bhawk1990's:
//nb is the index you wish to get to.
if (nb > flipview.SelectedIndex)
while (flipview.SelectedIndex != nb)
flipview.SelectedIndex++;
else if (nb < flipview.SelectedIndex)
while (flipview.SelectedIndex != nb)
flipview.SelectedIndex--;
I spent a couple of days figuring out why touch animation does not work when I programmatically change FlipView selected item when UseTouchAnimationsForAllNavigation="True".
I found a setting which controls animation machine wide. Somehow this setting was disabled:
Settings->Visual options->Play animations in Windows
In my application I have a frame, with toolbar (the toolbar contains some actions).
I want the toolbar to be visible only when the window is focused.
So, I registered a windowFocusListener on the window.
The problem is-
when the window is not focused and I click on the place where a tool bar action should be- the action is performed.
This happens because the WindowFocusGained is called before the mouse button is released and when the mouse button released it calls the actionPerformed.
Does anybody has any idea for a work around for this problem?
Does anybody know how to determine wether the mouse button is clicked now?
You could add a MouseListener to the window, and check if the toolbar is visible in the mousePressed event. If the toolbar is not visible at the time the mouse is pressed, set a flag on the toolbar (something like "ignoreNextAction").
In the toolbar, check that flag in your actionPerformed event handler.
Reset the toolbar flag in the mouseReleased event on the window, so that the next click will work correctly.
This is assuming the mouseReleased event on the window happens after the actionPerformed on the toolbar (not sure about this). Worst case, you can work with a timer which resets the flag 50ms after the mouse event.
You could now only hide the toolbar when the window loses focus, but also disable all buttons with setEnabled(false), then re-enable on focus gain. Alternatively, synchronize setEnabled(..) with the visibility of the buttons (instead of the window focus).