Image courtesy of pixtawan at freedigitalphotos.net
23rd March 2016: Adding in the ESC (Escape) key which closes down dialogs popup windows. Very handy little way to avoid keyboard traps.
18th December 2015: A small update to the original blog... thanks to a colleague Johannes Oehl - one of our leading lights in Accessibility who reminded me that product development teams often gets asked to provide keyboard navigation for Power Users well before requests for other accessibility features.
As a 21st century professional working with touch screen and voice recognition software, keyboard navigation might seem a little old-fashioned. But hold that thought! Keyboard navigation actually provides some rather wonderful hidden benefits when it comes to working with cool technology, as well as being a core part of providing accessible user interfaces. Don’t believe me? Have a look at this YouTube video showing a custom Fiori app being operated via voice recognition software Dragon Natura....
Now here’s the really interesting point, this Fiori app was built using SAPUI5 version 1.28 – where we have keyboard navigation built-in but not yet screen reader capability (that came in with SAPUI5 version 1.30). While the video shows a custom app, this app is built using standard SAPUI5 controls and capabilities. Nothing special has been done to make it “Dragon friendly” or to set it up with special voice recognition capabilities.
The second thing worth noticing is that even though we are talking about accessibility, Dragon Naturally Speaking is marketed to able people as hands-free software. Although it’s great that people with disabilities can use it as well, this is one of many scenarios where it’s very easy to show that accessibility makes a better UX for everyone.
So how exactly does keyboard navigation help enable cool technology? Time for a short history lesson in the joy of keyboards.
Computer Keyboards – still going strong
Despite the development of alternative input devices, such as the mouse, touchscreen, pen devices, character recognition and voice recognition, the keyboard remains the most commonly used device for direct (human) input of alphanumeric data into computers.
In earlier days of computing people experimented with a number of different ways of inputting data and commands. Some of the more memorable approaches which made it all the way into the corporate environment were paper tape and punch cards. These were viable but somewhat painful...if you ever get the chance ask SAP Mentor graham.robinson to tell you his war story of dropping a box of critically important and carefully ordered punch cards from a moving vehicle involved in a car accident while crossing over the Sydney Harbour Bridge! Over time the best, i.e. most viable, answer came slightly from left field by re-purposing a mechanical device, the typewriter, as a computer keyboard.
Even with all the more modern alternatives available, keyboards remain the most popular device for direct entry of data. So much so that every smartphone and tablet includes an on-screen keyboard, and many provide physical keyboards as accessories.
You might have noticed in the video that Dragon uses the mouse as well – but it’s a lot slower (3 commands to position the cursor on one element). And while mouse grid control works for speech recognition software it doesn’t necessarily work for other devices or people – if you can’t see the mouse or the grid, it’s not much help.
This blog nicely summarizes why keyboards are still very popular even with the proliferation of mouse, touch, and voice recognition software.
What are the advantages of using a computer keyboard?
Now for the purposes of including keyboard navigation in your Fiori app, it’s not overly important to understand how keyboards physically work, but if you are interested in a little more background, have a look at this:
From an accessibility and a cool technology viewpoint what is important about keyboards is that they are:
- Fast
- Accurate
- Reliable
- And most importantly of all… ubiquitous
These characteristics mean keyboards – or rather re-using keyboard switch-control behaviours – has become a de-facto way of integrating all sorts of specialist software and non-keyboard input devices into computers without requiring the end user to do lots of extra work. The end user can essentially plug and play.
Internet of Things is still comparatively new, but computer-connected devices are not. For decades, people with disabilities and accessibility professionals have been creating and using specialized devices and other assistive technologies to work with computers. Such as Sip-and-Puff devices that were invented in 1961 for people who were unable to use their limbs or hands, originally developed to operate simple light switches and later refined to operate keyboards.
If you are interested in assistive technology, these blogs show a concise history of such devices.
Assistive Technology - from ancient to modern times
Design for Life: the evolution of Assistive Technology
So once again it’s great that including accessibility features helps make a better UX for everyone, and even for a lot of extra software and devices we might not have considered in our UX planning.
In fact, a good way of looking at why we should use accessibility generally, is that accessibility makes your app so robust lots of software and devices you’ve never even thought of can use your app.
Of course if we are serious about accessibility we need to know who relies on keyboard navigation, so that - as a minimum - we can include them appropriately in our development testing plans.
Who really needs Keyboard Navigation
Quite a lot of people with disabilities rely on keyboard navigation, including:
- People with visual impairments – they can’t see the mouse or the mousepointer, they can’t feel exactly where they are on a touch screen, they may use a Braille keyboard
- People with low vision – it may be easier for them to use the keyboard than to use a mouse or touch screen
- People missing hands or limbs – through accident or genetic defects, they may use a Sip-and-Puff device or some other assistive technology
- People with motor impairments – it may be very painful or difficult to use mouse or touch screens
- People with tremors – they may not have sufficient fine motor control to use a mouse or touch screen
All of the above are people who may find using a computer mouse or touch screen difficult, painful or impossible.
And one more a little left of field:
- People with attention or short term memory issues – such as Attention Deficit Disorder, or they may be side effect of other disabilities
While people with attention or memory issues may be able to use the mouse or touch screen, one of the important aspects of keyboard navigation for them is being able to see which keyboard element is in focus at any time. Because people with attention or memory issues may have difficulty remembering where they are on the screen between one click and the next.
You can find more detail on keyboard navigation issues and how they impact certain types of disabilities on webaim.org
Who else does this help
Power Users! Power users LOVE keyboard navigation.
Because if you have a list of 120 invoices to pump into the system, it's so much quicker to keep your hands firmly on the keyboard and use [TAB] or arrow keys or some other hot key combination to move from field to field and just keep typing ...
... rather than to swap from keyboard to mouse to keyboard to mouse and back again. Sure you might have a trackpad on your laptop but that still means changing from a typing movement to a sliding movement and back again... and don't get me started on those tiny little pointing sticks they put on modern laptops... not at all comfortable or fast for regular use.
But pressing keys - that's easy, fast, and if you use them often they are so easy commit to muscle memory. Just think how easy it is for most of us to find [ALT+TAB] or even [CTRL+ALT+DELETE].
How Fiori keyboard navigation works
Keyboard navigation enables you to act on any actionable control in the app by using the keyboard alone. A good goal for keyboard navigation is aim to be able to operate the app using only the [TAB] key, the arrow [LEFT ← , UP ↑ , RIGHT → , DOWN ↓ ] keys, the [SPACE] bar, and the [ENTER] key. Of course you still use the normal letter, number, and special character keys when entering text.
However it is possible and may be convenient to provide additional shortcut keys. For instance with Fiori apps, if you want to traverse the app in reverse order, you can use [SHIFT+TAB] instead of [TAB]. Also if there are lot of controls and you have them in logical groups you can use [F6] to navigate to the next group. Very common actions may be worth a specific key, such as going to the Detail view of an item [F2]. Sometimes specific controls need extra keys, such as shortcuts to move to the top [HOME] of bottom [END] of a table or list control.
The information and detail on what keys are used in standard controls has been expanded in the documentation of each successive version of SAPUI5, starting from version 1.28.
The major information about which keys are used generally and which additional keys apply to specific controls can be found in the SAPUI5: UI Development Toolkit for HTML5, in the section Developing Content > Developing SAPUI5 Controls > Accessibility Aspects for SAPUI5.
As new SAPUI5 controls are added, the documentation is updated, so I’ll simply list the major keys and their major behaviours to be aware of here. For specifics, make sure you read the documentation... especially if you want to create your own controls!
Key | Purpose |
TAB | Forward navigation – move to the next control |
SHIFT+TAB | Backward navigation – move to the previous control |
SPACE | If the element is selectable, toggle the select/deselect, e.g. to turn on/off a checkbox If the element is not selectable, trigger the event, e.g. trigger the action associated with a button |
ENTER | Trigger the event, e.g. trigger the action associated with a button |
F6 | Group navigation - move to the next control after the group |
SHIFT+F6 | Group navigation – move to the previous control before the group |
UP arrow | Move to the previous item within a control, e.g. to traverse the items in a list |
LEFT arrow | Move to the left within a control, e.g. to traverse the columns in a row of a table, or to move to the next left tab in a tab bar |
DOWN arrow | Move to the next item within a control, e.g. to traverse the items in a list |
RIGHT arrow | Move to the right within a control, e.g. to traverse the columns in a row of a table, or to move to the next right tab in a tab bar |
PAGE UP | Move up a page within a control, e.g. to traverse the items in a list |
PAGE DOWN | Move down a page within a control, e.g. to traverse the items in a list |
HOME | Focus on the first item within a control, e.g. to traverse the items in a list |
END | Focus on the last item within a control, e.g. to traverse the items in a list |
DELETE | If delete is possible, trigger deletion of an item within a control, e.g. to delete a row of a list |
F2 | If the item has a Detail event, trigger the Detail event |
CTRL+A | If items of a control are selectable, toggle select/deselect of all items |
F4 | Open a Value Help dialog |
| ESC | The Escape key is a quick way to close down a dialog pop-up. In other words the standard way to close a web browser window works too. |
You can try these out for yourself on any Fiori app – such as those in the Fiori Demo Cloud Trial Edition, or apps you have built yourself such as the SAPUI5 Walkthrough Tutorial in the SAPUI5: UI Development Toolkit for HTML5. It’s worth understanding how keyboard navigation behaves for different controls. Notice particularly how the cursor focus is shown - you should be able to see a subtle dotted line around the control in focus.
Let’s see how this works by demonstrating it on one of the most popular apps: Fiori My Inbox, which uses the common Master List/Detail pattern. You can try this for yourself in the demo trial version, just open up the My Inbox app to start.
Using a desktop device, and starting with the cursor in your browser’s address bar (where you enter the URL), this is the flow you should see when you start by pressing [TAB]…
The first button selected is the Home button in the App Header. You can see the dotted line around the Home icon like this:
Keep pressing [TAB] to move left to right through the rest of the buttons in the App Header.
Once you reach the last button in the App Header, the next press of [TAB] takes you into the Master List pane of the inbox where all the tasks to be actioned are listed.
The first button in the header of the Master List pane is the Navigation button that takes you back to the Launchpad. Keep pressing [TAB] and we move to the other button in the Master List pane header - the multi-select icon - and then to the Search field. Here we can just type in what we want to search and as we start to type the list is automatically filtered to only those tasks matching our search. Note: To clear your search you just press [BACKSPACE] as per normal.
From the Search, the next [TAB] takes you to the selected task in the Master List. You are now in a list control, so to select a different task you use the [UP] and [DOWN] keys to find the task you want to select, and then press [SPACE] or [ENTER] to select it.
Press [TAB] from the selected task and you then cycle left to right through the buttons in the footer of the Master List - Sort, Filter, Group By.
From the Master List pane footer, the next [TAB] press takes you into the header of the Detail pane and positions you on the only field in the Detail header that is actionable – the user link. If you want to see details of the user just press [SPACE] to open the Employee dialog. You can press [ESC] to exit the employee dialog.
From the Detail pane header, the next [TAB] press positions you on the first icon of the icon tab bar. Use the [LEFT] and [RIGHT] arrows to move to the other tab icons. Note that when you are pressing [RIGHT] on the rightmost icon it stays on that icon, and similarly when you press [LEFT] on the leftmost icon it stays on that icon. That’s important for users and cool tech to know where the icons start and end. Once you’ve decided which icon tab you want to enter, press [SPACE] or [ENTER] to open the corresponding tab.
Within a tab, the next [TAB] will take you to the first actionable element in that tab. It’s interesting to go to the Comments tab to understand how keyboard navigation works when you have elements that dynamically change their active/inactive status.
As you enter the Comments tab, pressing [TAB] takes you into the control for entering a new comment. At this point the new comment is empty – no text has been entered yet - and the comment Submit button (shown as a Right Arrow icon) is inactive. If you do not enter a comment and press [TAB] the cursor moves to the next control in the Comments tab, i.e. the list of previous comments.
However, if you start to type in comment text, the Submit button becomes active, and then pressing [TAB] takes you to the Submit button.
If the tab doesn’t have any actionable elements, or when you are on the final actionable element of the tab, pressing [TAB] takes you to the buttons in the footer area of the Detail pane, such as Approve, Reject, Claim etc.
Finally when you have reached the rightmost button in the Detail pane, pressing [TAB] moves you to the buttons in the App Footer, such as Terms of Use, Copyright, etc.
If keyboard navigation doesn’t appear to be working, check the app is running on at least SAPUI5 version 1.28, and check if there are any specific keys for that control. And don’t forget to try both the [TAB] and the arrow [LEFT, RIGHT, UP, DOWN] keys … sometimes what you may think are separate controls are actually part of the same control, such as tab icons in a tab bar.
How to include this in my Fiori app
The most important consideration is to put away your mouse and make sure the entire app can be operated via the keyboard.
The good news here is there’s not much you need to do – provided you are on at least SAPUI5 version 1.28 - SAPUI5 is already giving you so much out of the box.
The most important thing to do is to make sure you are using SAPUI5 version 1.28 or higher!
Other than that it’s largely about what you should avoid doing.
There are 3 rules of thumb to keep in mind:
- Don’t mess with the cursor focus
- Don’t override the tab order
- Don’t over-automate
Don’t mess with the cursor focus
It is possible to change the cursor focus, e.g. using JavaScript, but the problem with this is that it creates inconsistent behaviours in your app. And really it shouldn’t be necessary if you have a good design.
If you find someone is asking you to implement or has already implemented a change in cursor focus, then there’s a couple of ways to counteract this sort of, most probably, bad design.
- Check that the app flows in a logical reading order appropriate for the role/task. If the flow is correct then keyboard navigation will also flow naturally to match that.
- Check that the app is specific to a particular role/task combination – if the cursor focus is a compromise between 2 groups of users with competing requirements, that’s arguably a bad compromise. Better to split to 2 apps.
Don’t override the tab order
The default tab order follows the logical reading order. Again if you find someone is asking you to implement or has already implemented a change in tab order, this is arguably bad design. Similar to cursor focus, check the flow of the app, and that the app is correctly aimed at a specific role/task combination.
Don’t over-automate
What tends to happen in these situations, is people misunderstanding the point of cursor focus and keyboard navigation. The thinking goes something like this…
- Saving clicks is good
- So if I automatically trigger the action when a user lands on the button that saves another click so that’s good too, right?
Wrong!
Remember why we need to be able to see cursor focus – so that people with attention and memory issues can see where they are up to. Just because they happened to land on a button or control does not necessarily mean they want to trigger or enter it. In fact, by “jumping the gun” and immediately triggering the control you are actually creating inconsistencies that introduce confusion for users (“how did I get here?!”) and are likely to break the accessibility of your app.
Further instructions for developers can be found in the SAPUI5: UI Development Toolkit for HTML5, in the section:
Developing Apps > Accessibility > Keyboard Handling
You should also check the General Recommendations for Accessibility, as criteria for the focus and tab order are listed there. For instance you will find these pieces of advice in the documentation for SAPUI5 version 1.32:
- Overriding code, for example the keyboard tab order, will impact the correct handling and may break the accessibility of the whole application.
- When opening or closing a dialog or navigating between pages, the focus should stay on the same control as it was on before opening or navigating. If the control no longer exists, the focus should be put on its parent (for example, if the control was inside an action sheet, set the focus on the button which opened the action sheet).
By the way, if you are using OpenUI5 rather than SAPUI5 the documentation, links, and considerations are much the same as for SAPUI5, at least for controls delivered by SAP. That’s because accessibility is part of SAPUI5’s Product Standard and Acceptance Criteria. Of course, for controls contributed to OpenUI5 by other sources, encourage them to include accessibility aspects such as keyboard navigation.
Important Note: Just because SAPUI5 has accessibility as part of its Product Standard and Acceptance Criteria doesn't mean that every control supports accessibility to the same degree. This is partly historical - controls created in early versions of SAPUI5 may not be accessibility-aware - and partly due to the speed of innovation - new controls generally need to focus on working first, and may add accessibility as a second step. The safest controls to choose for accessibility support are those in the sap.m library. For other controls, make sure you test them out before you rely on them too heavily, and if they don't behave as you expect, use the usual support channels to request improvement or to be directed to an appropriate alternative control.
Don’t forget other tech needed by your Fiori app
Any good developer will always consider the whole solution, not just the code they are working on.
With keyboard navigation, there are two main considerations to keep in mind:
- Consider how your app will be launched, what are the key strokes you will need to actually launch your app
- If your app happens to use other technology within it, you need to make sure you have enabled keyboard navigation for that also
Launching your app
For example, in Fiori Launchpad, the tile catalog provides support for keyboard navigation, including:
Key | Purpose |
Arrow [LEFT, RIGHT, UP, DOWN] keys | Move between the tiles in a catalog category |
[SPACE] | Enter a tile |
[PAGE UP], [PAGE DOWN] | Move to the first tile of the previous catalog category, or of the following catalog category. |
[HOME], [END] | Move between the first tile and the last tile in the tile catalog |
[ALT+0] | Displays a list of keyboard short cuts |
Web browser hosting your app
You may also need to know keyboard navigation of the web-browser you are using:
Other software used by your app
And keyboard accessibility for other technologies you are calling in your app, such as:
Keyboard accessibility for Google maps
Keyboard accessibility for Adobe Documents
If you liked this blog, you may also be interested in
My previous blogs on Fiori and Accessibility:
Accessibility & Fiori - High Contrast Black theme
Accessibility #GAAD & Fiori - Beyond High Contrast Black
And just as an aside… a perennial complaint/bugbear for keyboard users… the reason behind the QWERTY keyboard.
- SAP Managed Tags:
2 Comments
