Skip to main content Skip to Table of Contents
U.S. flag

An official website of the United States government

Baseline for Documents

2. Focus

Accessibility Requirements

  • WCAG SC 2.4.3 Focus Order – If a document can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
  • WCAG SC 2.4.7 Focus Visible – Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
  • WCAG SC 3.2.1 On Focus – When any user interface component receives focus, it does not initiate a change of context.

Test Method Rationale

Manually navigating or controlling document components by keyboard-only will enable a tester to identify when there is no visual differentiation between a focused item and the rest of the document or content. Using the keyboard to navigate facilitates inspection of focus order.

Limitations, Assumptions, or Exceptions

  • Some interface components (e.g., screen text for form filling instructions), which are not normally considered interactive, may be in the tab order. Such interface components should receive a visible indication of focus when the user navigates to them using a keyboard.
  • Loss of visible focus should not occur while manually shifting focus through the page (using the TAB or arrow keys). However, when a function that moves the focus is executed (such as an internal page link or hidden content is revealed), it may be necessary to manually shift focus once with the keyboard before focus becomes visible again. This is not considered a failure.
  • Focus may be moved to a control either via the keyboard (e.g., tabbing to a control) or the mouse (e.g., clicking on a text field). Moving the mouse over a control does not move the focus unless scripting implements this behavior.
  • While it may be a common best practice, Focus Order is not required to move left to right, top to bottom.
  • Focus order includes forward and backward navigation.
  • Without exception, focus must shift to modal dialog boxes and remain within the dialog box until the box is closed by the user.
  • For some types of controls, clicking a control may also activate the control (e.g., button), which may, in turn, initiate a change in context. Controls that are clearly labeled and intended to initiate a change in context do not fail under this test.
  • This test evaluates 3.2.1 On Focus using only the keyboard to avoid unintentional activation of controls with a mouse.
  • Changes of context are major changes in content that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously. Changes in context include changes of:
    1. User agent
    2. Viewport
    3. Focus
    4. Content that changes the meaning of the page
      • Note: A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).
      • Examples: Opening a new window, moving focus to a different component, going to a new document or window (including anything that would look to a user as if they had moved to a new document) or significantly re-arranging the content of a page/screen are examples of changes of context.

2.A Test Procedure for Focus Visible

Baseline Test ID: 2.A-FocusVisible

Identify Content

Keyboard accessible interface components (e.g., links, form fields, drop-down menus, show/hide content, tree views, and pop ups).

Test Instructions

  1. Use the keyboard to navigate through each interface component.
  2. Check that a visible indication of focus is provided when focus is on the interface component. The focus indicator must not be limited; when the keyboard focus is shown it must remain. [SC 2.4.7]

Test Results

If any of the above checks fail, then Baseline Test 2.A-FocusVisible fails.

2.B Test Procedure for Focus Order

Baseline Test ID: 2.B-FocusOrder

Identify Content

Keyboard accessible document components (links, form fields, drop-down menus, show/hide content, tree views, and pop ups, etc.) that have a meaningful sequence of navigation.

Test Instructions

  1. Use the keyboard to navigate through document components.
    1. Use the keyboard to activate trigger controls that reveal hidden content (menus, dialogs, expandable tree list, etc.).
      1. Check that the revealed focusable content is included in the focus order. [SC 2.4.3]
      2. Advance the focus through the revealed content.
    2. Use the keyboard to close/hide the revealed content.
      1. Check that focus is returned to the trigger control. It is acceptable to Shift+ TAB once or use an arrow key to move the focus backward to the trigger control. [SC 2.4.3]
  2. Check that the focus order preserves the meaning and usability of the page. [SC 2.4.3]

Test Results

If any of the above checks fail, then Baseline Test 2.B-FocusOrder fails.

2.C Test Procedure for On Focus

Baseline Test ID: 2.C-OnFocus

Identify Content

Keyboard accessible document components (links, form fields, drop-down menus, show/hide content, tree views, and pop ups, etc.).

Test Instructions

  1. Use the keyboard to move focus to and navigate through each interactive document component (including form drop-down lists and form fields).
  2. Check that when a document component receives focus, it does not initiate an unexpected change of context. [SC 3.2.1]
    • Forms submitted automatically when a component receives focus
    • New document window or browser launched when a component receives focus
    • Focus is moved to another component

Test Results

If any of the above checks fail, then Baseline Test 2.C-OnFocus fails.

Advisory: Tips for Streamlined Test Processes

  • The clarity of visible focus is subjective, and the minimum level is the application’s (or OS platform’s) default display setting for indicating focus. Applications may also represent visual focus differently in specific situations.
  • This test may be performed simultaneously with Baseline 1: Keyboard Access.
  • No focus modifications should be enabled in the test environment during testing. Some testing tools will add a visible outline around elements that receive focus. While testing tools may help testers to track focus, any markup provided by a testing tool should not be used as an indicator of visible focus for meeting this requirement.
  • Given the variability in how applications may present visual focus in specific situations, test reports should include details about testing environment, including application and version.
  • Tab order that initially appears illogical may still meet this requirement due to an application-specific business logic.
  • It may be useful to combine these tests with tests for keyboard navigation and visible focus.
  • It may be useful to provide instructions about what “modal dialog boxes” are and how they should behave.

WCAG 2.2 Techniques

The following sufficient techniques and/or common failures were considered when developing this test procedure for this baseline requirement:

All Baseline Tests for Documents