Web checklist

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 (link resides outside of ibm.com).

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.

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 (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 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:

   For additional information, refer to the WCAG 2.0 examples of providing a submit button to initiate a change of context (link resides outside of ibm.com).

   Required unit tests for general development technique 1

   Perform the following unit test.

   • Locate all the form controls or any content that requires user input and manually confirm that a button is provided that a user can access with the keyboard to submit the user input for each form.

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 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 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 (link resides outside of ibm.com).

   Required unit tests for general development technique 2

   Perform the following unit tests.

   • Locate the form controls in the content.
   • Identify any content in which changing the setting of a form control results in a change of context.
   • Manually confirm that there is an explanation of actions that will occur when the control is changed and that the information is provided to the user before they activate the control.

Back to top

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 (links reside outside of ibm.com) 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 <span> element is placed next to the button markup and is read by a screen reader, but is not visible to 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.

   Required unit tests for Dojo development technique 2

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

Back to top

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 (links reside outside of ibm.com).