Software checklist

Checkpoint 2.1: Visual focus indicator for objects

Provide a visual focus indicator that moves among interactive objects as the input focus changes. This focus indicator must be programmatically exposed to assistive technology.


Rationale

Even if the software provides keyboard access so users can navigate the software, that isn't enough if you don't know where you are. Keyboard users must be able to see the current focus point to know what to do. Imagine typing if you could not see the caret (insertion bar). Assistive technology (e.g., screen reader, screen magnifier) needs to know the position and contents of the visual focus indicator, so it can describe, magnify or manipulate the object for the user.

When editing, the caret or insertion bar is the visual focus. As a blind user moves the focus with the arrow keys, a screen reader must know the position of that focus so that it can echo the current character, word or line. Similarly, as a user tabs around a dialog, a screen magnifier needs to follow the visual focus.


Required development techniques


The following techniques are the minimum required to meet Checkpoint 2.1 from the IBM Software Accessibility Checklist:

  1. Software must provide support for a visual focus indicator that responds to user input.
  2. Software must programmatically expose the focus information to assistive technology.

Examples for Microsoft Windows developers

1. Software must provide support for a visual focus indicator that responds to user input.

Example 1

When using standard Windows controls, no additional work is required to provide visual focus. Windows notifies assistive technology when a window gets focus by using the Microsoft Active Accessibility (MSAA) interface, window hooks, and window messages.

Example 2

Object focus can also be provided by positioning the system caret on the focus object. The system caret is the blinking vertical bar that the user sees when editing text. The caret can be placed anywhere on the screen, made any shape or size, and even made invisible. If the system caret is made invisible, it can be moved to indicate the focus location to assistive technology without disturbing what the user sees on the screen. This technique will expose the focus to assistive technology; but there must still be a visual indication of the focus object.

2. Software must programmatically expose the focus information to assistive technology.

Example 3

Software that creates custom controls must support the Microsoft Active Accessibility (MSAA) to expose the object focus location.

Software must call NotifyWinEvent whenever the focus moves to an object that does not correspond to an entire window. It must handle the WM_GETOBJECT message when that is used to query the focus object. COM objects representing screen elements must also support the accSelection property. For more information about MSAA, refer to the Microsoft Active Accessibility Web site.

Examples for Eclipse developers

1. Software must provide support for a visual focus indicator that responds to user input.

Example 4

When using the Eclipse Standard Widget Toolkit no additional programming is required to provide visual focus. SWT notifies assistive technology when a window gets focus through the org.eclipse.swt.accessibility package support.

2. Software must programmatically expose the focus information to assistive technology.

Example 5

In Eclipse, custom controls should call Control.getAccessible().setFocus() whenever the custom control sets focus to one of its internal items. This will notify Active Accessibility of a focus change.

Please note you should never call Control.forceFocus() because this can result in a widget having focus that does not have a focus indicator and does not respond to keyboard input. It is better to call Control.setFocus() however even this should not be called without good reason because it is confusing to have the focus change randomly and independent of the user's actions. And finally, calling Control.setFocus or Control.forceFocus is not the equivalent to the NotifyWinEvent described for non-Eclipse applications in example provided for Software developers for this technique.

Examples for Java developers

See the examples to implement system settings using Java Swing.

Examples for GNOME developers

The GNOME Accessibility Project is developing a suite of software services and support to make the GNOME user environment accessible. The Accessibility Framework includes an Accessibility Toolkit Application Programming Interface and an Assistive Technology Service Provider Interface. Visit the GNOME Accessibility Project for more information.

Examples for iOS developers

iOS supports visual focus when VoiceOver is active. iOS supports the caret in editable fields regardless of VoiceOver use.

1. Software must provide support for a visual focus indicator that responds to user input.

Example 6

When using the standard iOS controls, developers must set the accessibility attribute of the control.

In Interface Builder, this is done by selecting the Accessibility checkbox Enabled. This is found on the Identity Inspector tab.

This can be done programmatically with the setIsAccessibilityElement and setAccessibilityLabel methods:

[self.myButton setIsAccessibilityElement:YES]; [self.myButton setAccessibilityLabel: @"label text for button"];

2. Software must programmatically expose the focus information to assistive technology.

Example 7

In iOS, developers can customize the look of widgets easily. These will retain accessibility behavior. Developers must ensure that any modifications must still meet font size and contrast settings requirements, including background images. Alternatively, the application can provide a way to change or turn off custom colors and background images.

Software that creates custom controls must implement the UI Accessibility Protocol and provide meaningful accessibility attributes including the object label, focus location, accessibility enabled status, value, traits (roles), and status changes Developers should refer to the Accessibility Programming Guide for iOS. (PDF, 1.2MB)

A training module on accessibility for custom controls on iOS is available on iTunesU. Search for Stanford University Course CS193D “Developing Apps for iOS”, 2010 Sessions, Lecture 18 “Accessibility on iOS: Make an App for Everyone”. Guest lecturer Chris Fleizach, Apple Accessibility Development team.

Required test techniques

Test the software to ensure that it complies with accessibility requirements.

Methodology

The Accessibility test of this checkpoint requires both visual verification and the use of a screen reader. Testing using the keyboard verifies the visual focus indicator moves between each object and control as the input focus changes. Testing using a screen reader verifies an assistive technology is able to follow the keyboard focus.

All objects and controls in the application must meet the pass criteria described in the Test techniques table below for this checkpoint to be satisfied.

Required test software

Install the following software to test this checkpoint.

Test techniques

The following test techniques are required to verify this checkpoint.
Please note that each screen reader may provide object information in a different manner to the end user.

Perform the following steps to verify the accessibility of each object in the current window.

Action Result
1 Navigate using only the keyboard to move between objects and controls, and verify there is a visible focus indicator at all times.
Pass:Fail:
Record the pass/fail result from the keyboard test above and proceed to Step 2 below.
2 Verify that the screen reader can follow the keyboard focus when navigating between the objects and controls in the current window.
Pass:Fail:
Record the result returned from the screen reader test and proceed to Step 3 below.
3 For each object in the application's interface, determine whether the object satisfies the accessibility requirement of this checkpoint using the results of Steps 1 and 2 above, and the pass/fail criteria described for this step.

Note: Every object in the application must satisfy the pass criteria in order for the application to pass this checkpoint.
Pass:Fail:


©2009, 2013 IBM Corporation

Last updated August 22, 2013.