You are here: browser/composer front-end test cases > Test documentation for keyboard navigation
Test Documentation for Keyboard NavigationMaintained 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.
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:
- Press Alt+F key to dropdown the File menu.
- 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.
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:
- Main accessibility page: the toplevel page for the Mozilla/Netscape accessibility project
- Keyboard UI FAQ and cross-reference: the planning FAQ and cross-reference page for keyboard navigation
- Keyboard map listing: the detailed keyboard assignment map specification (non-interactive)
- Interactive keyboard map: an interactive version of the map --however, you will need to run Mozilla (or Netscape 6.x) to use this
- Accessibility bug radar: a tabular outline of relevant keyboard navigation issues throughout Mozilla (and Netscape)
- Product requirements document: the marketing PRD for Netscape, which also contributes to Mozilla accessibility
The current UI specifications for toplevel and context menus now display accelerators and access keys:
- Toplevel menu spec lists list both access keys and accelerators.
- Context menu spec lists access keys.
Interested in participating, or have questions/comments/whatnot concerning keyboard navigation or other accessibility issues? Join the mailing list! To subscribe:
- Send email to email@example.com
- 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:
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.
- Bugs currently open (Unconfirmed, New, Assigned or Reopened) under Keyboard Navigation, sorted by severity.
- Bugs currently Resolved Fixed (but not yet verified by QA) under Keyboard Navigation, sorted by severity.
- Bugs currently Resolved as Duplicate, Works For Me, Invalid or Won't Fix under Keyboard Navigation, sorted by severity.
- Bugs currently open that are not in Keyboard Navigation but have access keyword, sorted by severity.
- Bugs currently Resolved Fixed that are not in Keyboard Navigation but have access keyword, sorted by severity.
- Bugs currently Resolved as Duplicate, WFM, Invalid or Won't Fix that are not in Keyboard Navigation but have access keyword, sorted by severity.
- Acceptance level (baseline functionality)
- Functional level
- Stress, boundary, negative, etc.
- Ad hoc and regression testing
So, how to test keyboard navigation?
Keyboard accelerators. Also known as hotkeys, these
shortcuts require the concurrent use of an accelerator key with another
- 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
- hit Alt, which will focus the menubar at File
- hit the 'e' key, which will dropdown the Edit menu
- 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
- hold down the Alt key and hit the 'e' key, which will dropdown the Edit menu
- 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.
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].
Good functional testing would include:
- Testing more keyboard accelerators and other shortcuts, other than the
most basic ones.
- Common shortcuts across applications (including the browser) are at http://mozilla.org/docs/end-user/moz_shortcuts.html
- Hotkeys which are seen from the toplevel menus are documented in the toplevel menu specification
- 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:
However, you should remember:
- The interactivity only works on Mozilla/Netscape 6.x. For a non-interactive page, go to http://mozilla.org/projects/ui/accessibility/mozkeylist.html
- That URL is a framed page. For a non-framed page, also go to http://mozilla.org/projects/ui/accessibility/mozkeylist.html
- Access keys are not included in mozkeylist.html.
- How to use the interactive map for testing:
- 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.
- Top frame: when you press or mouse over any keys, their color will go from white to light blue.
- After you press a key[s], the bottom frame should jump to its description.
- 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.
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 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.