You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

You are here: browser/composer front-end test cases > Test documentation for keyboard navigation

Test Documentation for Keyboard Navigation

Maintained by: Sarah Liberman

Keyboard navigation is a core aspect of accessibility which Mozilla and Netscape are attempting to achieve. This feature is of particular importance to users who have repetitive-stress injuries (RSI) or other disabilities, or who are simply weary of depending on mouse use.

What will & will NOT be tested

Mind you, given that the parts of the test outline is still under development (as are the keyboard navigation specifications ;), what's covered here is subject to change. Testing should cover the following areas.

  • Keyboard accelerators: aka, keyboard hotkeys, such as Control+Q to quit.
  • Keyboard mnemonics: aka, application-defined access keys, such as menu access keys and dialog access keys. Specific menu access keys for the toplevel menus are defined in the menu UI specification. For example, a simple mnemonic would be to use the menu access keys for Quit in Mozilla for Win32:
    1. Press Alt+F key to dropdown the File menu.
    2. Hit, but don't hold down, the Q key.
  • Navigation through the application's UI elements (chrome). This would include tabbing between the content area, Sidebar, URLbar, etc.
  • Navigation through the web page's content (links, form elements, images).
  • Making sure that focus is set (and displayed, where applicable) in a sensible manner, such that the above can function properly.
  • Test on three major platforms --namely Linux/unix, Macintosh and Win32.

Testing keyboard navigation will primarily focus on the Navigator application, as opposed to other component/areas, for the time being. The following areas are unlikely to be covered.

  • Mac OS does not menu or dialog access keys.
  • Composer (editor), depending on time contraints.
  • Mail & Newsgroups, depending on time constraints.
  • Web page-defined (content) access keys, depending on time constraints.
  • Keyboard-modified mouse actions, depending on time constraints.
  • 3rd party products like Chatzilla, XMLterm, etc.
  • Alternative input/output devices, such as braille readers, screen readers, etc.

Issues, references & bug information

There are several issues concerning keyboard accessibility in Mozilla -- which you should keep in mind during either testing or casually use:

  • There has been/is/will be disagreement as to what "expected" or "sensible" or "correct" behavior should be with respect to defining specific keyboard features.
  • There are open issues that impede keyboard navigaton, including but not limited to focus: inconsistent/annoying focus behavior, not displaying focus [eg, active frame, focus outliner, etc.], disappearing focus...

Here are the accessibility documents (including specifications) under active development:

The current UI specifications for toplevel and context menus now display accelerators and access keys:

Interested in participating, or have questions/comments/whatnot concerning keyboard navigation or other accessibility issues? Join the mailing list! To subscribe:

  1. Send email to mozilla-accessibility-request@mozilla.org
  2. In the Subject header of the email, enter subscribe

Here are a couple of major issues that hinders testing:

  • Bug 83552: Focus and tabbing navigation issues
  • Bug 55416: Location field (URL bar) focus issues
  • Bug 68841: access keys for XUL checkboxes and radiobuttons not implemented
  • Bug 169045: Pref UI for controlling keyboard navigation (meta bug --see dependency tree)
  • Bug 30088: Meta bug for typeahead find

However (again), the link outlining bugs on our radar provides a handy way of viewing the current "hot bugs" in this area:

http://mozilla.org/projects/ui/accessibility/access-radar.html

The corresponding Bugzilla component is Keyboard Navigation in the Browser product. However,other keyboard navigation bugs could be found in other products and components where the access keyword is denoted.

In addition, here are some relevant Bugzilla links. FYI: Some of the features described in this plan may or may not be listed under the Preferences component, so if you don't find what you're looking for here, you may need to do a query which covers other components/parameters. Conversely, some bugs from features not covered by this plan might show up in the queries below.

Test coverage & outline

So, how to test keyboard navigation?

  • Keyboard accelerators. Also known as hotkeys, these shortcuts require the concurrent use of an accelerator key with another key.
    • To see what keyboard accelerators are available, dropdown the toplevel menus.
    • On Win32, the accelerator is by default the Control key. On Mac OS, it is the Command key. On Linux/unix, Mozilla (and Netscape 6.x) uses Control by default.
    • For example, to test the hotkey for opening a new browser window on Mac OS (Command+N), you'd hold down the Command key then hit the 'n' key.
  • Keyboard access keys (mnemonics). Access keys are denoted in UI elements --primarily menus at this time-- as underlined letters. They provide another shorthand to commands and UI elements, especially those that lack a specific hotkey.
    • To see what menu access keys are available, please go to the following UI specifications:
    • At this time, access keys are only available on Linux/unix and Win32. Currently unavailable on Macintosh (9.x or 10.x) due to OS limitations and bugs.
    • To test on Win32 (with default settings), hit (press then release) the Alt key, then the appropriate letter key. For example, to open the Preferences dialog:
      1. hit Alt, which will focus the menubar at File
      2. hit the 'e' key, which will dropdown the Edit menu
      3. hit the 'e' key again, which will select the Pre ferences item and launch it
    • To test on Linux/unix (with default settings), hold down the Alt key, the hit the appropriate letter key. For example, to open the Preferences dialog:
      1. hold down the Alt key and hit the 'e' key, which will dropdown the Edit menu
      2. hit the 'e' key again, which will select the Preferences item and launch it
  • Navigation through the application's UI elements (chrome) . This is frequently done by hitting the Tab key, Control+Tab, and some other shortcuts. The tabbing QA document describes what to do.
  • Navigation through the web page's content. Currently only the Tab key has been implemented in Mozilla (and Netscape) to navigate through the content. The tabbing QA document has further information.
  • Making sure that focus is set (and displayed) in a sensible manner, such that the above can function properly. A fine way to test this is to go through both the tabbing and scrolling test documents.

Acceptance tests

The most basic (baseline functional, acceptance) testing would include:

  • Making sure that the most common keyboard accelerators work.
  • Making sure that menu and dialog access keys work.
  • Ability to tab through the browser's chrome and the web page content [primarily links and form elements].

Functional tests

Good functional testing would include:

  • Testing more keyboard accelerators and other shortcuts, other than the most basic ones.
  • Making sure menu and dialog access keys aren't redundant, and work as expected for common features. Access keys are documented in the UI specs for both toplevel menus and context menus.
  • Make sure tabbing through chrome (UI elements, widgets) and content works sensibly. The tabbing tests page outlines this, as well as some basic focus tests. This would include:
    • Being able to tab through the chrome and content areas of the browser, both framed and non-framed content.
    • If time permits. Tabbing through other browser-related windows and dialogs.
    • If time permits. Tabbing through the mailnews 3pane window, editor window, mail standalone window, mail compose window...
  • Make sure keyboard scrolling of content and focus work sensibly. The tests for scrolling page outlines this.

So, what are ALL the keyboard shortcuts available in Mozilla and Netscape? Rather than having an outline/list the tests here, using Aaron's interactive keyboard map provides an excellent way to organize and describe the expected behavior of keyboard shortcuts. Here's a link, which opens another browser window:

http://mozilla.org/projects/ui/accessibility/mozkeyplan.html

However, you should remember:

  1. The top from displays a full 101-key keyboard. The bottom frame lists description of the shotcuts, ie, whether a given one has an implemented function, as well as its expected behavior.
  2. Top frame: when you press or mouse over any keys, their color will go from white to light blue.
  3. After you press a key[s], the bottom frame should jump to its description.
  4. At the same time as pressing the key[s], the expected behavior for the shortcut should then occur. This is dependent on which product your using, of course. Immediate results will be browser-oriented, since the map is in a browser window. You'll need to open a separate editor, mail 3-pane, or mail composer window to see how the shortcut works in those products.

Stress, boundary and negative tests, etc.

The sky is almost the limit here, heh. Tests in these areas will be covered as time permits.

  • Verifying all keyboard accelerators.
  • Verifying all access keys.
  • Basic web page-defined access keys.
  • Changing keybindings, namely the accelerator and access keys. Instructions for doing this are at http://mozilla.org/unix/customizing.html#accelkey. Unix would be the most common place to do this, eg, to change back to using the Alt key, but it might not be limited to that platform, afaik...
    • the ui.key.accelKey (integer) preference sets the primary accelerator modifier key, such as Control on Win32.
    • the ui.key.menuAccessKey (integer) preference sets the modifier key for access key usage, such as Alt on Win32.
    • the ui.key.menuAccessKeyFocuses (boolean) preference; when 'true', pressing and releasing (not holding down) the menu access key will shift focus to the menu system and highlight the first toplevel menu.
  • Other keybinding customization. For details and instructions, see http://mozilla.org/unix/customizing.html#keys .
  • Compare application-based access keys vs web page-based access keys. Again, this might not be limited to the Unix platform.
  • Very rapid/very slow keyboard access (performance).
  • Uncommon/esoteric keyboard shortcuts.
  • Insane/bogus keyboard shortcuts.

Ad hoc & regression testing

Ad hoc testing is covered by users in the Internet community, as well as casual use. Due to time constraints, regression testing will encompass:

  • Verification of Resolved (Fixed ones get priority) bugs as they come in.
  • Periodic verification (eg, milestone deadlines) of Big Issues to make sure they're still fixed. This would go hand in hand with the usual acceptance testing that occurs during those periods.
  • Ad hoc testing with daily builds.