Testing for keyboard accessibility using Internet Explorer


For many users, including users with upper-body motor disabilities and blind users, the keyboard is the only way to interact with and to navigate within a web page or web application. And keyboard accessibility also tends to increase usability, generally, by improving the efficiency of movement through and interaction with an application.

The purpose of the keyboard access testing is to ensure that keyboard users can fully perform all of a web page's or applications's potential tasks and operations accurately and with certainty.

Ideally, application developers should be testing keyboard accessibility during the Quality Assurance phase of application development. Unfortunately, many application developers/vendors do not perform thorough keyboard accessibility testing, and the result is inaccessibility of their application to keyboard users.

In this test we want to find out:

  1. If all user interface controls can be operated with the keyboard only, and
  2. If the element with keyboard focus is styled to make it easily and consistently identified in the graphical rendering.


  • No additional accessibility testing tool is required
  • Tester can see the real keyboard behavior in action
  • Testing does not require deep knowledge of accessibility

May help to have a list of Internet Explorer keystrokes available, including F6 or Cntrl + Tab (move through frames), F1 (Help), Alt + F4 (close current window) and Cntrl + F5 (Refresh page) so that you can move effectively through web page or application.


  • Requires manual testing — no automated way to perform the test
  • Can be time consuming

Step 1: Identify major functions/features of the application/page


Define all major and typical use scenarios for the application. For example, some major functions of a web-based e-mail application are viewing/navigating in the e-mail summary page, composing a new e-mail and adding a file attachment, replying/forwarding an e-mail, and adding/deleting/modifying an entry in the addressbook, etc.

Step 2: Disable pointing device


Either disable or disconnect your pointing device (mouse, trackpad, trackpoint, etc.).

Optionally, you can merely not use such devices; however, it is likely a fuller appreciation of potential problems will come from being entirely unable to use such devices.

Step 3: Use the keyboard to complete each defined task from beginning to end


Proposal (Ken P): Merge the three keyboard navigation pages into one and provide in this section a "key" to browser differences. This section would differentiate default behaviors of IE (focusable embedded objects), Firefox (normative behaviors), Chrome and Safari (until recently, tab browsing off by default), and Opera (a completely different keyboard model). And this section would give a basic keystroke reference for Opera or point to that page on the opera web site.

  1. Can you complete all the operations effectively and with expected keystrokes?

    Examples and behaviors to be aware of, by category of page/page-content

    • Web pages, including examples of rich controls commonly found in web pages:
      • As the user tabs through a web page, focus should move to all clickable elements and elements should be able to be activated via the enter key (links followed, pop-ups popped-up, expandable areas expanded/collapsed, etc.).
      • Tab key presses should move the user forward in the DOM. Shift-tab should go backward in the DOM.
      • When the user is interacting with a grouping of radio buttons in a form, the default/first button should be reached via a tab key press from the previous element and then up and down or right or left arrow keys should move between elements in the grouping.
      • When the user focuses a drop-down/select menu in a form, up and down or right and left arrow keys should move between items in the select. And, depending on the browser, either an ALT + arrow key or an Enter should expand the select menu visually.
      • When the user is interacting with a fly-out menu in a web site navigation bar, tab key presses should expand the sub-menus and move sequentially through all items. Ideally, arrow keys should allow the user to navigate between top-level menu items and down into the sub-menus.
      • A tab panel should receive focus to its first tab and subsequent tab key presses should move, in order, to the other tabs. An Enter key press should activate the currently focused tab. Another acceptable model is that the tab panel group receives focus via the tab key and arrow key presses move between tabs.
      • A slider in a web page (for example, on a video player) should receive focus via a tab key press from the previous focusable DOM element. Once focused, right/left and up/down arrow keys should move the slider bar scrubber right and left.
    • Web applications:
      • The user should be able to tab to a rich control, for instance a toolbar, in an application. Once the control has focus, arrow keys should navigate its contents and a subsequent tab key press should move to the next major rich control or application pane/panel.
      • It is common practice in Windows desktop applications to have the F6 key move between major control regions in an application. It is worth testing to see if this common practice is available in web applications in which there are distinct regions of controls, for example, in a web-based email application
      • The developer should be aware that many web applications implement their own keyboard shortcuts. A prime example is Gmail, which has a long list of keyboard shortcuts. The developer should test to see if these shortcuts work uniformly across browsers and determine if they conflict with any expected browser keyboard shortcuts — for instance, Ctrl + R should reload the browser window and should not be "redefined" by a web application to have a different function.
      • For the expected keyboard interactions of web application rich controls/widgets, see the AOL Developer Network DHTML Style Guide.
    • Embedded objects/applications:
      • Embedded objects/applications include controls and applications implemented in Flash, Silverlight, and Java/JavaFX.
      • Most browsers cannot focus embedded objects/applications solely via the keyboard. A key exception is Internet Explorer, which can focus Flash and Silverlight applications via tab key press.
      • Once in an object or application (regardless of how you got there, via mouse click or keyboard), the developer should test to ensure that the control/application does not "trap the keyboard," that is, prevent the user from tabbing or shift-tabbing out of the control/application.
  2. Does the visual styling of the element with keyboard focus change clearly and consistently throughout the application?


    • Do links show an outline or do they show other obvious visual highlight when focused?
    • Is it visually obvious that form controls have the focus when tabbed to?
    • Do items in a toolbar display focus through obvious visual changes?
    • Do tabs in a tab panel show obvious visual focus when focused and/or activated
    • Does the slider in a slider bar show cursor focus when tabbed to and manipulated

Rules Evaluated with this Technique

Rules evaluated with Keyboard Testing of Basic Links, Forms and Scripting

All links, form controls and other interactive elements on the page must be able to receive keyboard focus (i.e. the TAB key on many browsers).


All links, form controls and other interactive elements (i.e. Flash, Java Applets, Javascript widgets) on the page must not trap keyboard focus.


The functions or actions of the links, form controls or other interactive elements must be operable with the keyboard.


When a links, forms controls and other interactive elements receive focus their visual styling should change to make it easy to identify which element has focus