Manual Testing

Given the limitation of automated testing, you'll need to learn a few manual tests and checks to perform in order to better evaluate web accessibility. This lesson will introduce you to a few ways to check for features that automated checkers cannot. 

Tab Key Navigation Test

The Tab Key Navigation test is often used with the "Select All" test (discussed on the next page) to confirm whether items that were not selected are keyboard operable, but this test can also be used on its own. Place the cursor at the very start of the HTML content (sometimes tricky), or in the browser’s location field or address bar, then press the Tab key repeatedly and watch as the cursor moves through the content of the page. Make the following observations:

1. Are you able to see the cursor’s area of  focus as you move through elements of the page? If not, this will violate Guideline 2.4.7 Focus Visible (Level AA). When reporting on the issue, recommend adding a focus indicator so it is possible to visually follow the cursor as it moves through the page.
2. As you navigate with the Tab key through elements on the page, do all functional elements such as links, buttons or forms receive focus? If not, those elements that do not receive focus are going to be inaccessible to some people, violating Guideline 2.1.1 Keyboard (Level A).
   
   
   • These elements are often custom features built with non-standard HTML and JavaScript. In such cases you can recommend the use of standard HTML where possible or suggest the developer add keyboard focus for the element by adding tabindex=”0” to the HTML, and add keyboard events, in addition to the existing mouse events, to the programming that controls the functionality of the feature.
     
     
   • Note: Avoid applying tabindex=”0” to every element on a page - to do so makes tabbing through a page more cumbersome as it takes longer to get to the main elements on a page as the user must tab through every single item. Reserve this for all functional elements (links, buttons, forms).
     
     
3. When navigating with the Tab key through elements of the page, is the path followed through these elements the standard left to right, top to bottom sequence? If the cursor’s focus jumps around, moving to places on the page outside where you might logically expect the cursor to go by viewing the layout of elements on the page, it may violate Guideline 2.4.3 Focus Order (Level A). By default the focus order will be standard, so in cases where the order is irregular, it is because the developer has purposely changed the order. You may recommend removing the irregular tab sequence or adjusting it to follow a more meaningful path.
   
   
4. While navigating with the Tab key through menus, and other features that one can operate with a mouse, do these features also operate with a keyboard? If they do not, they will be inaccessible to those who use only a keyboard to move through Web content. In the figure below, the submenus that drop down when one of the main navigation elements is clicked cannot be opened with a keypress. These types of menus may use the arrow keys to open and navigate through submenus, or they may operate using the Tab key. Arrow keys are preferred, though Tab key navigation will satisfy the success criteria associated with keyboard operability.

For drop down menus of this sort, also watch for Tab key navigation moving through the items in the submenus, but the submenus not visibly opening. This will be confusing for low vision keyboard users who are following the focus indicator to keep track of where they are within the page.

Figure: Scenario in which the drop down menus only function with a mouse click

“Select All” Test

The “Select All” test can help identify elements in Web content that are not keyboard accessible. The key command for Windows is Ctrl-A, and for Mac is Command-A.

How to Perform a “Select All” Test

After pressing the "select all" key command for the operating system you are using to select the content of a webpage, scan over the page looking for elements that are not selected. In the two screenshots below, the first has nothing yet selected, and the second is the result of pressing the "select all" key combination.

Compare “Before Select All” above, with “After Select All” below and notice the elements that do not have the grey background colour in the latter version.

Before Select All

Figure: Screenshot prior to selecting to compare with the screenshot below

After Select All

Figure: Screenshot after selecting showing elements that do not appear to be selected

In the second screenshot, the Feedback tab located on the right does not appear to be selected and are missing the blue background colour that appears when other elements are selected. That tab should be investigated further to see if is keyboard operable. The appearance of not being selected does not necessarily mean such elements are not keyboard operable, but warrants further testing. This testing can be done by using the Tab Key Navigation test described on the previous page. Using Tab key navigation you can confirm that the Feedback tab on the right is indeed not keyboard operable. It may then be appropriate to identify the tab as a potential barrier when reporting on the site. Do search the screen for other ways to get to the Feedback form. There may be an accessible alternative elsewhere on the page, in which case it may be acceptable for the Feedback tab to be inaccessible, as long as the alternative is relatively easy to access.

Code Examination and Repair

Once you have discovered a potential barrier, you can identify where the problem is occurring in the HTML markup. In the screenshot below, the feedback tab (1) on the right of the screen is examined by right clicking and choosing "Inspect Element with Firebug" (2) if you have Firebug installed, otherwise choose “Inspect Element” further up the menu. You will notice the code associated with the feature is highlighted in the code window (3) to the lower left. Click on the Edit button (4) to edit that HTML to test possible solutions.

Figure: Steps to examine and modify code to test potential accessibility solutions

In the case above, the Tab Key Navigation test revealed that the Feedback tab would not receive focus, thus could not be operated with a keyboard. A simple fix for this is to add tabindex=”0” to the main element containing the tab. Once added, without reloading the page, the Tab Key Navigation test is conducted again to see if the tab now takes keyboard focus. It does, though it is still not possible to operate the tab, which requires modifying the associated JavaScript.

Figure: Result of adding tabindex="0"

After clicking the Edit button, the selected code from above is opened for editing. In this case tabindex=”0” has been added to test whether this adds keyboard focus to the Feedback tab (which it does).

For a look at other tools for examining code, watch the following video on the Debugging accessibility with Chrome DevTools (13:17).

• High Contrast Testing Links to an external site. (from WebAIM)
• Using VoiceOver to Evaluate Web Accessibility Links to an external site. (WebAIM) – on a Mac computer or iOS devices
• Using NVDA to Evaluate Web Accessibility Links to an external site. (WebAIM) – Free screen reader for WinPC systems
• Mobile Accessibility Testing Guide for Android and iOS Links to an external site. (TGi)
• TGi Color Contrast Analyzer Links to an external site. (CCA)
• Color Contrast Testing with ColorPick Eyedropper Links to an external site.