I am developing an application for the desktop with Flutter. I had to implement the form with multiple input fields. I really need to make the whole focus flow and I have used the FocusNode class to move from one input field to another. Everything is based on the submit event, so when I hit the Enter button on the keyboard it moves to the next field. It is pretty ok, but I have to change it from Enter key to Tab key which is more natural for the desktop users. Have you got any idea what can I do here to achieve such a result? Is there a way to trigger the submit event by different key (than Enter)?
This bug is for making it easy to bind keys to actions. Once that's complete, one of the intended use cases is to add tab support for form field navigation. There's been a lot of work in that area recently, so I wouldn't recommend putting time into working around this yourself.
Related
I want to know if there is any way to navigate Dialog components by pressing the Enter Key in the same manner natively implemented by the TAB key?
Though I haven't tried it by handling the keyDown and keyUp events certainly it seems doable. Though you may not be able to intercept the browser produced dialog boxes this way and other dialogs created using Window.alert(). How are you creating the dialogs ?
The tab key is the browser doing the work of changing focus - nothing special needs to be added, you'll find that tab works on any form on the internet (except where explicitly disabled for some reason...).
To move focus with the enter key, you must listen for the onkeydown event (focus change via tab also occurs onkeydown, so selecting this for consistency), check if it was the enter key, and if so, move focus to the next element in the list.
Typical tab focus behavior involves the browser checking the tabIndex of the elements on the page, and finding the next element on the page with a higher tabIndex, or the nearest subsequent sibling/cousin element. I don't have a method to implement this easily, so instead I'm going to focus on just going to the next widget.
GXT 3's FormPanelHelper has some handy methods to look for all Fields - this code could be used as a basis for non-GXT fields as well. Track all FocusEvent and BlurEvent from the fields found in the dialog, and use that to always track the currently focused field. Add a key handler to the dialog itself, to capture all key events, and check if one is the enter key. If so, figure out what the next field is from the currently focused field, and invoke .focus() on it - this will trigger the focus handler described above, so your bookkeeping will be updated correctly.
And as #eliran-m noted, consider leaving the tab key alone - don't get in the way of users navigating the way they are used to. Adding new functionality might be a good thing, but taking away expected behavior probably isn't.
I need to focus a text input into the Facebook login popup. I am using a virtual keyboard to simulate a physical one, but when I click a key, the text input lose focus and the letter is not written into the field.
How could I maintain the focus in the text input?
I'm not sure if creating your own virtual keyboard is a smart idea since all mobiles already have one in there, you just need to set useSoftKeyboard in Flex.
Also, you can always remove focusability to your components by setting focusEnabled and hasFocusableChildren to false.
I finally came to another solution... Using getElementsByTagName('theElementID'), I could get a reference to the textInputs in the browser, and I could modify its attributes...
For example,
emailStringObject =this.html.htmlLoader.window.document.getElementById('email');
emailStringObject.value="example#correo.com"
I have an application, that uses the MultiSelectionModel, and it works great, but I need the site I'm developing to work on mobile devices, and so I can't use the keyboard to assist in selecting the elements (since it doesn't exist). EX: On the desktop I just hold ctrl and click on all the element that I want to select.
So on the mobile device, I would like to modify the default behavior of the MultiSelectionModel so that when you click on a CellList item, it toggles the selection state of that item.
I have looked through the source for it and cannot see anyway to implement the behavior that I need. (Mobile MultiSelection).
Whether you add a checkbox column or not, you'll have to add a cell preview handler. The easiest way to define one is to use DefaultSelectionEventManager, either using a checkbox manager in combination with a checkbox column, or creating a custom one (you'd map a click event into a toggle action).
You can see it used, the checkbox variant, in the GWT Showcase; it uses the setSelectionModel overload with two arguments to add the CellPreviewEvent.Handler at the same time.
Just adding an extra checkbox column would be a more user friendly solution.
I am trying to find the most usable/accessible way to implement a simple form dropdown list which will sort a list of products by pice and alphabetical order.
In your opinion is the dropdown more usable when there is a button that governs its submission or when it automatically submits onchange of the dropdown?
The research I have read is both for and against such methods and there is a variery of implementations on the web so interest to hear the thoughts of the community.
Thanks in advance
As a blind computer user either method works fine. I find that having a button to click is slightly easier for me then the onchange event firing. I wouldn't say it's a big enough difference to take into account though assuming the majority of your users will not be disabled. If your targeting specifically blind users I would not use the onchange event.
So long as you do not change focus or navigate to another page when the selection changes, either approach should work. The classic example of a problem dropdown is where it contains a list of other pages on the site, and navigates as soon as the selection changes. This prevents a keyboard user from using the list; they can't browse it, and can't navigate to any pages beyond the first selection, since it's impossible to navigate past those. So in cases where focus changes or the page navigates as a consequence, having a separate action (eg. Go button, or handling enter) to cause the navigation to take place is essential. This is likely where the advice you've read is coming from.
In this case, however, it sounds as though you are just updating content elsewhere on the page, and not changing focus or doing navigation. Simply resorting existing content should be fine.
Depends on your users and their respective expectations and the context in which it's presented.
As a blanket, general statement, you should have the drop down accompanied by very obvious submission button. That is the safer approach.
If you are refreshing page data or if the focus moves away after the dropdown option is selected, you should use a button to be accessible. If you fire the event on change, blind or keyboard-only users will not be able to use the dropdown menu at all if they are on windows with ie and chrome (so added together, a majority of the people on windows). As soon as they use the arrows to scroll down and make a selection, the first option they hit will be selected and the page data will refresh or the focus will move, making it impossible for them to navigate or select the second option, third option, etc. Below is a thorough explanation with examples so you can see what I mean.
Designers definitely don't like the buttons, but if you are blind and on chrome/ie, it is impossible to use a lot of dropdowns without it. I'm guessing Jared uses firefox or a mac.
http://pauljadam.com/blog/javascript/onchange-event-on-a-select-inputjump-menu-accessibility-problems/
I am building a little registration page that is going to be accessed via an iPad at a sales office as a kiosk. When I first received the page from the web design company I noticed that the way they set it up was the labels of the input fields appear inside the field (like a watermark). The watermark is cleared out once you focus on the field and then restored if there is no value when you blur off the field.
I noticed that they had a couple password fields in the page that was showing the words PASSWORD and RETYPE PASSWORD in them. I don't want people's password exposed in the Sales Office, however changing the fields to type password means that the watermark labels become masked.
Since they were using jQuery to do the watermark in the input fields, I found another jQuery solution that would swap out the TEXT input field for a PASSWORD input field on focus. When I tested it on my PC in Safari it worked like a charm. However when I was testing the page with my iPhone I noticed that the jQuery field swap on focus only works if I click on the field with my finger. If I am using the on screen keyboard and clicking NEXT to get the field, then the field doesn't get swapped and the on screen keyboard goes away. I have to physically click the field to get the swap to fire. Is there some other even that I can use to trigger the swap instead of focus?
$('#txtRetypePassword-clear').focus(function() {
$('#txtRetypePassword-clear').hide();
$('#txtRetypePassword-password').show();
$('#txtRetypePassword-password').focus();
});
Of course as soon as I posted, I did a little more reading on DiveIntoHTML5.ep.io and saw that HTML5 supports "placeholders" so I thought to myself, I wonder if you can put a placeholder on a PASSWORD input field. YOU CAN!
So I get to rip out all that jQuery because HTML5 supports everything the page was trying to do!