Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.


Rationale

The purpose of this checkpoint is to ensure that when a user changes a setting in the user interface or inputs a value, it does not cause an automatic change of context. A change of context is not showing new content, it is a change in meaning that can disorient a user, such as a change in focus. For a broader definition of what it means to change the context, refer to WCAG 2.0 definition of a change of context.

On a Web page, for example, a change of context can occur if a screen reader user selects an item in a list and a new page opens based on the selection. As a result of the change in context, the user may not be aware that the new page opened, which may cause confusion or incorrect results. Another common example of a context change is when information on a form changes based on the selection of a radio button. A sighted user may see the new content, but visually impaired users may not see the content. If a screen reader user cannot reasonably be expected to understand what will happen when they activate or use a user interface control, they need to be notified in advance.

Required development and unit test techniques


To comply with this checkpoint, you must meet at least one of the following techniques.

These techniques are defined in WCAG 2.0 Level A Success Criterion 3.2.2.

  1. Submit button: Provide a Submit button to initiate a change of context.
  2. Change to a form control: Describe the actions that will occur once a user changes a form control, which results in a change of context.

Note: The examples presented in the techniques are not exhaustive. They are meant to illustrate the spirit of this checkpoint.

General examples

1. Submit button: Provide a submit button to initiate a change of context.

To comply with this technique, you must implement all of the following examples.

When you provide a Submit or Go button to initiate a change, it is clear to all users that activating the button will cause a change of context.

General example 1

An AJAX-based search application may make use of a left sidebar to allow the user to apply filters to the search results.

Instead of automatically reloading the results when a checkbox is selected to narrow the filter, the user is given a Submit or Reload results button. When this button is pressed, the search results are updated with the correct filters in place.

General example 2

Navigating through a drop-down menu must not cause a change of context until the user selects a button to indicate a selection has been made.

In the example below, when a user navigates through the drop-down menu, they are not taken to a new page until they select the Go button. If the user has to move to a new page as they navigate through the list, it is a failure of this checkpoint.

Select country: dropdown box example

For additional information, refer to the WCAG 2.0 examples of providing a submit button to initiate a change of context.

Required unit tests for general development technique 1

Perform the following unit test.

2. Change to a form control: Describe the actions that will occur once a user changes a form control, which results in a change of context

To comply with this technique, you must implement the following example.

General example 3

Using the same scenario as general examples for technique #1, an AJAX-based search application makes use of a left sidebar to allow the user to apply filters to the search results.

In this example, the developer does not want to add a Submit button because of a lack of screen space or other design constraints. Instead, the developer adds text in the left navigation window preceding the filter selection to notify the user that choosing a selection will refresh the search results. The text is also programmatically made available to the screen reader so that a screen reader user will hear it each time they traverse the left sidebar, prior to making filter selections.

For additional information, refer to WCAG 2.0 examples of describing what will happen before a change to a form control that causes a change of context to occur is made.

Required unit tests for general development technique 2

Perform the following unit tests.


Dojo examples

For techniques where there are no specific examples for your technology, please use the general examples as a guide to implement a particular technique.

1. Submit button: Provide a submit button to initiate a change of context.

There are no specific examples for implementing this technique in Dojo. Use the general examples as a guide.

2. Change to a form control: Describe the actions that will occur once a user changes a form control, which results in a change of context.

Dojo example 1

The Dojo Dialog and TooltipDialog widgets expose proper role information to assistive technologies. However, some screen readers do not consistently announce when a Dialog or TooltipDialog appears. Therefore, it is important to provide a text message near a dialog trigger element to notify a screen reader user that a dialog will appear.

For example, the following markup renders a Dojo button. When the button is clicked, a Dojo popup dialog appears, which allows the user to change a password. The text message in the ]]> element is placed next to the button markup and is read by a screen reader, but is not visible to sighted users.

The change password button causes a popup dialog to appear containing a field to enter your old password and two fields to enter a new password.
]]>

The access]]> attribute in the ]]> element is a CSS class selector that hides the span text from sighted users. See hiding content using style sheets to see how the access]]> class selector is defined.

Required unit tests for Dojo development technique 2

Refer to the required unit tests for general development technique 2.


Recommended development techniques

Although you are not required to implement the recommended development techniques in order to comply with this checkpoint, you should review these techniques because they can improve the accessibility and usability of the application.

Recommended example 1

Inform the user that clicking on certain links or areas of a window will open pop-up windows or change the active window. An unexpected change in context can be confusing to screen reader users, as well as people with cognitive disabilities that have difficulty perceiving visual content. Providing a warning allows the user to decide it they want to leave the current window, as well as assist them in finding their way back to the previous location.

In this example the warning about opening the Web content in a new window is described in the name or label of the control:

<a href="servers.html" target="_blank">IBM servers (opens in new window)</a>

Refer to the WCAG 2.0 examples of giving users advanced warning when opening a new window.


©2012, 2013 IBM Corporation

Last updated February 1, 2012.

W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/
Consortium for Informatics and Mathematics, Keio University), All Rights Reserved.