Failure of Success Criterion 4.1.2 due to the focus state of a user interface component not being programmatically determinable or no notification of change of focus state available

ID: F79

Technology: failures

Type: Failure

When to Use

All technologies

Description

Whether a user interface component has focus is a particularly important facet of its state. Many types of assistive technology rely on tracking the current keyboard focus. Screen readers will move the user's point of regard to the focused user interface component, and screen magnifiers will change the display of the content so that the focused component is visible. If assistive technology is not notified when focus moves to a new component, the user will become confused when they attempt to interact with the wrong component.

While user agents usually handle this functionality for standard controls, custom-scripted user interface components are responsible for using accessibility APIs to make focus information and notifications available.

Examples

A custom menu displays menu items by rendering them explicitly, handling mouse and key events directly and highlighting the currently selected menu item. The programmer does not expose the menu item that has focus via the Accessibility API, so assistive technology can only determine that focus is somewhere within the menu and cannot determine which menu item has focus.

Tests

Procedure

  1. Using the accessibility checker for the technology (or if that is not available, inspect the code or test with an assistive technology), check the controls to see if they expose the focus state through the accessibility API.
  2. Using the accessibility checker for the technology (or if that is not available, inspect the code or test with an assistive technology), check whether assistive technology is notified when focus moves from one control to another.

Expected Results

Resources