Web checklist

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.

The purpose of this checkpoint is to ensure that changing the setting of user interface controls or supplying values for input controls does not cause an automatic change of context. Note that a change of context is not the same as simply showing new content. To better understand change of context, please review the definition of a change of context (link resides outside of ibm.com) from the WCAG 2.0 document.

For example, if selecting an item in a list causes a new page to load based on that selection, someone using a screen reader may not know that a change has occurred. Another common example is having information on a form change based on the value of a radio button. Visually you may see additional content or different content displayed, but those changes may not be seen by someone using a screen reader. If a screen reader user can't reasonably be expected to understand what will happen when they activate or use a control, they need to be notified in advance.

Back to top

Compliance with this checkpoint requires at least one of the following techniques be met.

These techniques are defined in the Level A Success Criterion for item 3.2.2 from the WCAG 2.0 checklist (link resides outside of ibm.com).

1. Submit button: Provide a submit button to initiate a change of context.
2. Change to a form control: Describe what will happen before a change to a form control that causes a change to context to occur is made.

Examples for general developers

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

To comply with this technique at least one of the following examples must be implemented.

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.

Example 1

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

Instead of auto-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.

Example 2

In the example below, when the user navigates through the drop-down list, they are not taken to a new page until the go button is pressed. Causing the user to move to a new page as they arrow through the list would be a failure of this checkpoint.

Select country:

For more information, please see WCAG 2.0 examples of providing a submit button to initiate a change of context (link resides outside of ibm.com).

Back to top

2. Change to a form control: Describe what will happen before a change to a form control that causes a change to context to occur is made.

To comply with this technique at least one of the following examples must be implemented.

Example 3

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

In this case, the developer does not wish to add a submit button, due to a lack of screen space or other design constraints. Instead, the developer uses hidden text in the left navigation window to notify a screen reader user that choosing a selection will refresh the search results. Although this text is hidden from the sighted user, the screen reader user will hear it each time they traverse the left side bar, prior to making filter selections.

Refer to WCAG 2.0 examples of describing what will happen before a change to a form control is made (link resides outside of ibm.com).

Back to top

Examples for Dojo developers

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 techniques for Dojo.

2. Change to a form control: Describe what will happen before a change to a form control that causes a change to context to occur is made.

To comply with this technique at least one of the following examples must be implemented.

Example 4

The Dojo Dialog and TooltipDialog (link resides outside of ibm.com) widgets expose proper role information to assistive technologies. However, prior to version 10, JAWS does 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 to enable changing a password. The text message in the span element is placed next to the button markup and is read by a screen reader but not seen by sighted users.

<span class="access" id="passMsg">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.</span>
<button dojoType="dijit.form.Button" onclick="dijit.byId('dialog1').show()">Change Password</button>

The access attribute in the span 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.

Back to top

The following test tools and techniques are required to test this checkpoint.

1. Test tools
2. Required accessibility verification test techniques

Back to top