In the "elements" view, upon right-clicking on a specific element, the Google Chrome devtools provide you with two different "focus" options for focusing on the element in the HTML form.
Force state :focus
Focus
What is the difference between them?
Related
I have a reactiveForm that has a few reactiveTextFields with validation and a reactive dropdown menu.
The goal is to allow the user through the browser(mobile will have different behavior) be able to tab through the fields and inside the drop down be able to type on their keyboard and have the drop down filter results.
The tabbing focus is working correctly i'm not sure the best approach to adding a gesture/key detector widget(What widget to even use here).
Any suggestions or links to docs would be helpful thanks!
I have seen several behaviors:
No element is focused.
The close icon (usually at top right of overlay) is focused.
Some other element inside of the overlay is focused.
If conforming to ADA / ARIA standards, should any element be in focus?
The current recommend behavior is to focus the first focusable element in the dialog. However, there has been some debate on that implementation recently as it poses problems for users who use screen magnification software and screen readers.
in cases where the focus on display moves to a control at the bottom of the dialog a few negative things happen:
For a screen magnifier user the focus moves to the control, due to the viewport containing only a small portion of the dialog content (typical magnifcation 400-600%) only the bottom part of the content is viewed, unlike the top of the dialog, the bottom content offers no context. users have to navigate around to get an idea of what is going on.
For an SR user (such as JAWS) only the content of the focused element is announced, users have to navigate around the content to get an idea of what is going on.
The debate doesn't appear to be settled, but consensus is growing towards a new recommendation:
If any element in the dialog has the autofocus element, focus that element.
Otherwise focus the dialog itself using tabindex=-1 and outline: none.
Focusing the dialog element itself allows screen readers to read the contents of the dialog to the user, giving them context right away, and a screen magnifier will start at the top left corner of the dialog so they can start reading it from the beginning.
I have a multi-page form, using a vertical tabs UI, in redux-form, and I'd like to track the current tab selection in the redux-form store.
What's the best way of doing this?
I would track the current tab selection outside of redux-form, but I've integrated redux-form with redux-undo, and I'd really like for undoing a form change to go back to the tab of the modified control.
I tried using a selected redux-form field, but this means that changing the selected tab marks the form as dirty.
From reading the docs, I could probably use reducer.plugin to add arbitrary properties to the redux-form store, but I don't see any documentation of which arbitrary property names are "safe," and I'd have to update the plugin for every form that should behave this way.
Any ideas?
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 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.