Keyboard Only Access and Focus Indicator Test
This test checks that all tasks can be accomplished without a mouse, using only the keyboard. You will also verify that an indicator of focus is always shown. You will also note any unexpected focus order behavior.
Many users find it difficult or impossible to use a mouse to interact with a web page. This includes those with a mobility impairment and those who are blind or have limited vision. Also, many people who use laptops prefer using keys to using a trackpad.
Keyboard access relies on knowing where the focus is. Well designed dialogs have a focus order. The user expects to use the tab key to advance to each element of interaction in the dialog, and use other keys, such as arrows, space bar and Enter, to interact. Compliant applications show an indicator, such as a dashed box or change of color, to show an element has focus. If the focus is not shown, the user must guess where it is, and may get lost. Therefore, compliance requires that the focus is always shown.
You must perform this test on a laptop or desktop computer running Windows using Microsoft Internet Explorer version 8 (IE8) or later.
You must have a way to disable the mouse. The preferred way to do this is unplug the mouse. Most computers with a USB mouse are tolerant of unplugging the mouse. Some mice have an on/off switch. You can also take the mouse and place it out of reach, such as behind the computer.
The reason you must disable the mouse is to remove all temptation and possibility of cheating! Using a mouse is second nature to most of us, and testers find they sometimes unconsciously switch to mouse mode.
If you are testing on a laptop or device with a built-in trackpad or touchscreen, you must find another way to prevent yourself from using it. Some trackpads have a setting to turn them off.
Start an approved browser on an approved operation system (see preparation).
Key in the URL of the page to be tested.
Phase 1: Understand the features and tasks
Using the mouse, move over each element that appears it might be active and able to be interacted with. Buttons, links, and other elements. Pay special attention to a mouse pointer changing from arrow to an indicator you can click. (On windows, this is a pointing hand)
Watch also for other features that appear when you move over an element. The image below shows a feature that only appears on mouseover on the new FamilyTree on FamilySearch.org.
Phase 2: Test all features and tasks without the mouse
Now that you know all the things you can do with the mouse, test to see that all features and tasks can be done without the mouse.
Start an approved browser on an approved operation system (see preparation). Please restart the browser, for a fresh start.
Disable the mouse.
Type in, or select from history, the URL of the assigned page to test.
Did you disable the mouse?
Press the tab key as many times as necessary to move from the browser tool bars into the displayed web page.
Press the tab key and advance one focusable page element at a time. Each time you press the tab key, look for something new to indicate focus. If the focus indicator disappears it is a bug. If you can’t see focus anywhere on the page, it is failure to show focus bug. If you discover focus is shown, but on an unexpected part of the page, it is an illogical focus order bug. Continue through the entire page until pressing Tab takes you back to the top. This chain of elements you visited is call the tab ring or focus order.
Hints: 1. Tab moves forward through the tab ring 2. Shift+Tab moves backward through the tab ring 3. If it looks like the focus has disappeared, you can Shift+Tab back and Tab forward again to check that it really disappears. 4. When you can’t see the focus, note the failure, then press tab again. Repeat. Until you see the focus appear. You do not need to figure out where the focus was during those missing steps. A developer or lead tester will do that.
Pay attention to any items from Phase 1 that had function, but never got mouse focus. We will focus on these items in the next Phase.
Phase 2b: Test widget keyboard operation
Best practices uses other keys, such as arrow keys, in addition to the tab key to navigate. Modern websites use widgets, such as dropdowns, sliders, menus, tool bars, and media players as pieces in the larger page. The convention is that the user tabs to a widget, then uses arrow keys to move within the widget, and Enter (or spacebar) to make a selection.
In this phase you will see that each element that receives focus allows the user to fully interact with the element, without using the mouse.
Navigate to each element in the tab ring.
On each element, take the action of that element. If it is a link or button, press Enter to actually go to the link or activate the button. Hint: Alt+Left arrow will be a handy key combination to go back to the previous page. (You did disable the mouse, right?) If it is an input field, type some content into the field. Can you see a cursor? Does the cursor respond to arrows? If it is a dropdown list, try Alt+ Down arrow, Down arrow, or Enter to get it to open. If it is a menu, try Enter to open it. Then make sure you can get to every item in the menu using Tab or arrow keys. If it is a slider, use arrow keys to put focus on the slider and arrow keys to move the slider.
Each subelement must also indicate focus as you interact. If it does not, it is a bug.
During this phase, make note of any element or sub element you can’t reach by the keyboard. Sometimes what looks like a major element, such as a toolbar button, is not in the main tab ring, but rather one of a set of buttons. To get to them, sometimes you tab to the first one in the set, and then use arrow keys to move to one of the others in the set. (IE8’s own toolbar is this way). If you can get there with any key and it shows a focus indication, then that part passes the test.
Once you get to the end of the tab ring, and you have explored the function of each element and access to each subelement, check your list of elements that weren’t in the tab ring. Open a bug for any element that couldn’t be reached by the keyboard.
Some important points: 1. If you do a related page to one you previously worked on, you don’t have to retest links that look the same as the first page. If they work on one page, they almost always work on another page. 2. If you can’t get something to work the way you expect, but you can see another way to do the same thing on the page, decide whether it is easy enough to figure out the alternate way. For example, if special options appear on mouse over, but those same special options can be be done through a menu that tests OK, then you probably don’t need to write a bug. That’s called equivalent facilitation, and it’s an acceptable way to provide accommadation.
Phase 3: Complete the documentation
Write up your bugs. Inform your coordinator that you completed a page, and bug IDs you created.