Keyboard navigation has always been an important part of complex business applications and, over all, it will always be a minimum accessibility requirement, as stated in the Working Drag on ARIA Practices. Power-users prefer to navigate an application with keystrokes instead of switching between keyboard and mouse, as lifting the hand off the keyboard to move the mouse cursor is considered time lost.
With the new version of the FOEX Plugin Framework that we plan to release soon, we’ll upgrade to Sencha ExtJS 6 which comes with improved accessibility features. Therefore, our users will be able to navigate their applications with ease, by using only the keyboard if they choose so.
Let’s talk about keyboard navigation in a bit more detail for a moment. The component’s focusability is determined by the DOM that the component produces upon render.
Many elements can naturally receive focus (e.g. input fields), while others can use the tabIndex attribute. All in all, it is important to remember that ExtJS components have a focusable property that indicates whether that component is able to receive it. There are two ways in which you can shift the focus between elements: mouse clicks or keystrokes:
- setting the focus by using the mouse is straightforward, as whenever a mouse click occurs (mousedown event) the focus is set on the clicked element, if this element is focusable.
- on the other hand, the keyboard provides multiple ways of changing the focus, with the TAB key acting as the primary way of doing it.
Unlike the mouse pointer, there is a slight drawback when using the TAB key to set the focus on every element, as some although they are focusable, are not tabbable. However, this should not have a negative impact on the user experience, rather it should make the accessibility provided through the keyboard easier (there is no need to tab through every item on a page).
Currently these are the keys used for the keyboard navigation:
TAB – moves the focus to the next tabbable element
SHIFT+TAB – moves the focus to the previous tabbable element
LEFT, RIGHT, UP, DOWN arrow keys – allow navigation between the child elements, e.g. the cells in a grid or radio button groups
CTRL + RIGHT, CTRL + LEFT (CMD + RIGHT, CMD + LEFT on Mac) – expands and collapses nodes in the grid and tree.
Of course, there are some cases where it’s not very obvious how the focus-setting should work. Let’s take an example from our FOEX Documentation application:
FOEX v3.0 keyboard navigation focus to window (Focus when Show is set to Yes)
Have you noticed the behaviour?
After clicking a row in the grid, a new window containing all the record’s details appears. However, the new window blocks the focus, which means that a user cannot focus the grid again with the keyboard keys without first closing the window by hitting the ESC key.
It would not be such a big problem if the user wanted to edit that one record, but what if he needed to look through all the records using the DOWN arrow key and see the details under each record in the window?
Notice that at the beginning of this example I used the phrase “clicking a row”. If the user tried to navigate through the grid using the arrow keys, then every time he changed the record the detail window would pop up. This would result in a “never-ending” sequence combination of ESC, DOWN, ESC, DOWN keystrokes.
One may ask: is this the behaviour which I want?
For particular cases, like the one I just talked about, we look into providing alternative solutions, so that you can customize your keyboard navigation experience.
FOEX v3.0 keyboard navigation new setting
In FOEX v3.0 we’re adding a new setting called Focus when Shown that will allow you to choose where the focus should be kept:
- if you set it to Yes, then a user should expect a keyboard navigation behaviour like the example above
- if you set it to No, then a user should expect a keyboard navigation behaviour like the one shown at the end of this article
In the new release, your window widget the settings will look like this:
In case the window is not modal, (because modal windows should always mask all the underlying elements), you can select whether the window should receive focus when it is moved to the very top of the display hierarchy or the focus should stay where it was before, opening the window.
If we look at our grid example above, this would mean that once a row is clicked (or focused using the keyboard), the window is opened but the focus is kept on the grid. Now, the user can navigate through the rows without pressing the ESC button between row changes.
FOEX v3.0 keyboard navigation focus on grid (Focus when Show is set to No)
To summarise, starting with FOEX v3.0 you’ll be able to customize the keyboard navigation experience by using a new setting, Focus when Shown.
Based on our example:
- set it to Yes, to move the focus to the new window
- set it to No, to keep the focus on the grid
Do you have a technical question about FOEX or want good tips for improving your application? We’ve launched this series of How To articles to help improve your FOEX applications even more.