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.

You are here: browser/composer front-end test cases > Keyboard navigation > Tabbing

Keyboard Navigation: Tabbing

Maintained by: Sarah Liberman

This document outlines tests for tabbing through both web page content and UI elements of the application (aka, the chrome, widgets).

What is expected behavior? Tabbing moves focus between focusable content as well as interface elements. In addition, tabbing is cyclical, not linear --you should be able to tab through focusable items over and over.

Visually, focus can be seen as:

a dotted box around web page links and form elements (aka, "focus ring")
a dotted outline around the (interior) border of a frame (also "focus ring") to denote the active frame in a frameset --but only via keyboard navigation
a thicker, black outline around the (interior) border of a window's pane, as in the Mailnews 3pane or Address Book windows
a blinking cursor in a form's textarea or textfield, or within a textfield in a widget (eg, at the end of the URL bar, inside the textfield of the Find dialog, etc.)
an active highlighted effect for an item in a outline, tree view, list or content in a textfield. Note that this differs from an item that's highlighted but not in focus --such things appear as greyed out (aka, "disabled, inactive").

All tests, unless otherwise noted, assume use of the Tab key and Shift+Tab key combination. Shift+Tab should behave similarly to Tab, hitting focusable elements except moving in the opposite direction. The term "focusable content" refers to items such as links, image links and form elements. The terms "content area" and "document" are used synonymously to refer to the web page (as opposed to the browser's interface elements, like a toolbar or menu).

In addition to [Shift]+Tab, there are other keyboard shortcuts pertaining to navigation:

Control+Tab and Shift+Control+Tab move between panes in a window or frames within a framed browser document. A couple of examples:
- Framed browser page: Cycle through all of the frames/iframes (as defined in the frameset's source) then to the URLbar.
- Mailnews 3pane: Cycle through message pane, folder pane, Quicksearch textfield, then thread pane.
F6 and Shift+F6 act the same as [Shift]+Ctrl+Tab.
Control+PageUp and Control+PageDown move between tabs in both tab browser and dialogs which use the tabbed UI (eg, Cookie Management), to the previous and next tabs, respectively.
Toggling caret browsing mode is done by either the Insert key or Control+Shift+K. Having caret browsing on allows the user to see precisely (with a caret, |) where focus is in the document --whether the user uses the mouse to click somewhere in the content, or uses the keyboard to get to a focusable element.
Alt+PageUp and Alt+PageDown (Option+PageUp and Option+PageDown) go through the tabs in the Sidebar, up and down, respectively. The Sidebar needs to be open and in focus for these to work.

Open issues

There are several bugs which currently affect how tabbing works. Check out these bugs for more details.

Bug 83552: Focus and tabbing navigation issues (meta bug --see dependency tree)
Bug 55416: Location field (URL bar) focus issues (meta bug --see dependency tree)
Bug 66597: Caret browsing and focus position main bug
Bug 170871: Need front-end pref UI for setting default tabbing behavior
Bug 169767: Default tabbing settings conflict with tabbing within application (XUL) windows
Bug 171003: Tabbing goes over linked images twice, rather than once

Outline

Here are test outlines for tabbing navigation in some well-known features.

Tabbing preferences
Browser content: no frames
Browser content: frames
Mailnews 3pane window
Preferences dialog
Other features, dialogs and windows, etc.

In addition, the matrix below would be another way to get a good functional test overview for tabbing navigation. (Best done where tabbing to all focusable elements is set.)

What?	[Shift]+Tab	[Shift]+Ctrl+Tab	[Shift]+F6	Ctrl+PageUp/PageDown	Caret browsing	Find in page
Non-framed page: simple and complex		124946: Unshifted shortcut broken	124946	see tab browser
Framed page				see tab browser
Form controls in page				n/a		n/a
Tab browser: non-framed and framed pages				120148: Focus ring lost if caret browsing off
Caret browsing: toggle with Insert or `Ctrl+Shift+K`					n/a
Mailnews 3pane window				n/a
Preferences window					n/a	n/a
Sidebar ( where time permits)	48251: No keyboard access to Sidebar					n/a

Tabbing preferences

Bug 140612 was implemented to allow a user to choose which focusable objects the tab key will focus. There's no front-end yet (see bug 170871), but you can modify your own prefrence in the prefs.js file within your profile directory. Here are the following choices:

pref("accessibility.tabfocus", 1);
// 1 focuses textfields only
// 2 focuses form controls other than textfields
// 3 focuses all form elements
// 4 focuses only links (including linked-images)
// 7 focuses both form controls *and* links

IMPORTANT. The default settings differ among the platforms. On Win32 and unix, it's set to 7 (form elements and links). However, on Mac OS, it's set to 1 (only textfields) --which currently causes navigation issues due to bug 169767.

Browser content: no frames

Simplest case: no focusable content. For example, http://hopey.mcom.com/tests/simple-html.html on an internal server.

Start with focus in the URL bar. Both Tab and Shift+Tab should move focus to content area.
Start with focus in the content area. Both Tab and Shift+Tab should move focus to the URL bar (see also bug 28583).

Pages with focusable content. Tabbing should go through all focusable content, which includes links, image links and HTML form elements. Ideally, a focus ring should appear around each focusable element, too. For example, see bug 105742 for image links or button images, or the issues under section F for form elements.Then after going to the last focusable item in a page, the next tab should return you to the URL bar. Right now this just places the cursor, but bug 28583 would have it so that the URL bar contents are selected with the returning tab.

Start with focus in the URL bar.
1. Tab should first go to the document, then the first focusable item, through to the last focusable item, then back to the URL Bar.
2. Shift+Tab should start with the last focusable item, through the other focusable items in reverse order (with respect to A1), to the document level, then back to the URL bar.
As time permits, but do at least a couple of these situations. Test without actively setting focus anywhere: In all of these cases, focus should initially be in the content area --see bug 103758. Thus tabbing should begin with the first focusable element, except for the cases in E and G, and about:blank.
1. A page loaded by following a link
2. From a new browser window (File > New, or accel+N) --note bugs 87946 and 37638
3. Upon startup (home page set to a particular URL)
4. A page loaded via a link into a new window (context menu, or middle+mouse+click)
5. A page loaded from a link in a mail message
6. http://about:blank loaded: focus should actually be in the URL bar.
Start with focus in the page content, near the top (good with caret browsing on!). Tab results should be the same as A1. Ditto for A2.
As time permits. Start with the last focusable item in the page. Tab should first go to the URL bar, then proceed like A1. Ditto for A2.
Test with a page that purposely sets focus in the content (eg, the textfield https://bugzilla.mozilla.org / or http://google.com/) vs a page which doesn't (eg, http://www.mozilla.org/ ).
Web page form elements: tabbing moves through each form element, in the order as written in the source. Note, however: For radiobuttons, tabbing will only go to the selected item in a radiogroup. Need to use the Up/Down arrow keys to change the selection, which will also change focus accordingly. Sample test pages:
1. Viewer test #8. Internal server copy at http://hopey.mcom.com/tests/ test8.html
2. Bugzilla query page, http://bugzilla.mozilla.org/query.cgi
3. Bug 52815: Shouldn't need an extraneous tab for moving between input type="file".
4. Bug 64165: Should indicate (display) focused listbox.
5. Bug 81398 : Tab cycle order through form elements (90355 was dup'd in favor of this one).
As time permits . Tabbing in a page which uses TABINDEX. Internal test at http://hopey.mcom.com/tests/tabindex.html
Bug 68332 : Tabbing shouldn't be affected by CSS float property.

Browser content: frames and iframes

As currently implemented, Tab and Shift+Tab will go through each frame and iframe in a frameset as well as each frame's focusable content. The order of movement between frames is determined by how the HTML source was written: outermost frames are first, with the innermost (most nested) ones last; likewise for sibling frames: the order of focus follows the order in which the frames are described in the source. A note about the focus ring here: When you access a frame or an iframe via a keyboard shortcut, the focus ring will appear. Once you start to scroll or move through a frame's/iframe's content, however, the focus ring will go away. Moreover, mouse-clicking to make a frame/iframe active will not display the focus ring there; see bug 102052. Some examples of framed documents to use:

Viewer test #9, which contains both frames and iframes. Internal server copy at http://hopey.mcom.com/tests/test9.html
http://www.wired.com/
http://www.faqs.org/
Tinderbox page has an iframe displaying the port build status: http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey

Test outline:

Start with focus in the URL bar.
1. Tab should make the 1st frame active (not the main frameset document), then go to the 1st focusable item, then cycle through the rest of the focusable items in that frame. Repeat for the remaining frames. After the last focusable item, tab should return focus to the URL bar.
2. Shift+Tab should start with the last focusable item in the last frame, then continue backwards through the focusable content in the last frame (opposite direction with regards to A1).
As time permits, but do at least a couple of these situations. Test without actively setting focus anywhere: Initially, focus won't be visually obvious because it will be in the frameset document --you'll need to hit Tab to (visually) activate a given frame.
1. A page loaded by following a link --such as, say, http://www.faqs.org/
2. Upon startup (home page set to a URL with frames) --note bug 103758
3. From a new browser window (File > New, or accel+N), if the home page is set to a URL with frames --note bugs 87946 and 37638
4. A framed page loaded via a link into a new window (context menu, or middle+mouse+click) --again, assuming the link takes you to a framed page, like http://www.wired.com/ ;)
5. A framed page loaded from a link in a mail message
Start with focus in the 1st frame. Tab should be the same as A1, except that initial focus will the the 1st frame (not the URL bar), of course.
As time permits. Start with focus on the last focusable item in the last frame. Tab should jump to URL bar.
Bug 86931 (not implemented): Should automatically focus the largest frame as frameset loads.

Mailnews 3pane window

As currently implemented, [Shift]+Tab goes through all panes and focusable content/widgets, which includes links and so forth that might be in the message pane. [Shift]+Ctrl+Tab and [Shift]+F6, on the hand, only goes through the panes and the Quicksearch textfield.

Start upon opening the 3pane window.
Start with focus in the thread pane.
Start with focus in the message pane, with or without focusable content.
Start with focus in the folder pane.
Start with focus in the Quicksearch textfield.

Preferences dialog

The Preferences dialog is one of several complex dialogs in the application where tabbing between UI elements is important. Note about radiobuttons: tabbing will only go to the selected item in a radiogroup. Need to use the Up/Down arrow keys to change the selection, which will also change focus accordingly.

Start upon opening the Preferences dialog. Initially focus will be on a highlighted item in the Category tree on the left side.
1. Tab should jump to the first focusable element in the right-hand pane, go through the remaining widgets, then the OK / Cancel / Help buttons at the bottom, from left to right, then back to the category item.
2. Shift+Tab should jump to the buttons (Help on Unix and Win32, Mac) starting with the rightmost button, then cycle as in A1 but in reverse order.
Start with focus in a widget within one of the panels, eg, the Location textfield in the Navigator panel.
As time permits. Test tab cycling in all panels.

Other windows, features, etc.

As time permits. Verify that tabbing plays nicely with type ahead find. As time permits. Ideally, tabbing should work in all UI elements of all dialogs and other windows. More commonly-used dialogs and windows are of course likely to get more QA exposure. Here are several which come to mind --testing would (should?) be done by the QA engineer who owns the given component.

Other Mailnews-related dialogs:
1. Mailnews Account Settings dialog
2. Mailnews compose window
3. Mailnews standalone window
Address Book window
Editor-related dialogs
Sidebar. Known accessibility issues covered in bug 48251 and 89148
Open Web Location dialog
XUL file picker dialog (unix)
Helper application (downloading) dialog
Download progress dialog
Find in Page dialog
Wizards: Profiles, Mailnews, etc.
Page Info window
View Source window
Bookmarks window
History window
Javascript console
Security-related dialogs: Cookies, Images, Password Manager, PSM, etc.
Form Manager dialogs
Language-oriented dialogs

Mozilla