10. Continuity of User's Place

Do not change the user’s location (e.g. place on the page, page/url, frame, window or user agent) as follows:

• When the user moves to (on focus, on mouse over, on touch start) or away from (on blur, on mouse out, on touch end) any element including form control options
• OR When the user changes the setting of a UI control, unless each option can be reached by the keyboard without selecting it and it is clear what will happen when the setting is changed

Rationale

If the user’s place in the media changes unexpectedly, it can be disorienting for any user and particularly disorienting for those with cognitive disabilities.

For keyboard access users, such a change can also mean a significant amount of effort to get back to where they wished to be. As such, for these users, it is particularly frustrating if they cannot control when such changes take place.

For screen reader users, such a change often means a change in the reading location. This can be confusing during an auditory experience. (Imagine your voice mail jumping from the middle of one message to the beginning of another message in the same person’s voice.) For this reason, the user’s place on the page should not change unexpectedly.

Even if some user action triggers the change, the situation is little better if the change is unexpected or unavoidable. (Imagine your voice mail jumping from the middle of one message to the beginning of another message each time you move your mobile phone.)

Warning or alert boxes that appear suddenly and suddenly gain focus are acceptable, if they are designed to interrupt activities for all users and are easy to dismiss. (Continuing with the voice mail analogy from above, the following message from your voice mail system wouldn’t be confusing, after all: “Alert: The voice mail system will be down for the next fifteen minutes. Please call back after 12 pm.“)

General Techniques

1. If you change the user’s place in the media in order to provide a warning or alert:

   • begin the message with text that identifies the message as a warning or alert

     ~AND~

   • provide a way to dismiss the message (For example, you might provide a “Close this Alert Box” button.)

     ~AND~

   • if possible, return the user to where they were on the page before the alert occurred.
2. When hiding (removing) content that currently has focus, avoid an unexpected change in location by moving focus to some natural position just before or just after the dynamic content in the normal reading order.
3. It is the user’s perception of their location that is important in this guideline. As such, do not unexpectedly change the content around the user’s location to such an extent that they would believe they are on a new page or in a new location on the page.

Technology Specifics

HTML | XHTML | CSS | JavaScript

1. Several of the techniques for Pearson Guideline 6 also speak to this issue.
2. If you find that active elements are not in the ideal order when using the tab key to move through the page, correct this by adjusting reading order See - Pearson Guideline 4. Do not use JavaScript to force particular changes in focus. For example, if you have three active elements on the page (A, B and C) that should be in that order, using JavaScript to move focus to C when B receives the blur event will violate this guideline. This would cause unexpected changes in focus as keyboard navigation must work both forwards (tab) and backwards (shift + tab). A user might trigger blur on B when moving backwards through the page, hoping to reach A, but this type of JavaScript would bring the user back to C.

Testing

Testing technique	Description
Tools	Test for this while you are testing keyboard access Pearson Guideline 6.
Output	If there is an error, you’ll find that you are moved suddenly to a new location while trying to reach controls or while trying to reach options within controls.
Analysis	This type of error occurs when a user is suddenly and unexpectedly brought to a new location, assuming that this is not done to bring attention to an alert dialog message. This is such a bad user experience, that it is rarely present for mouse users. However, since keyboard access is tested less, this happens occasionally for keyboard access users.

Related Guidelines

WCAG 2.0 A - SC 3.2.1 On Focus:

When any component receives focus, it does not initiate a change of context. (Level A)

WCAG 2.0 A - SC 3.2.2 On Input:

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. (Level A)