From the wiki

Proposed http://www.w3.org/WAI/UA/work/wiki/Keyboard,_Focus,_and_Navigation_Restructuring:

3.4.1 Avoid Unpredictable Focus [formerly 3.4.2, before that 5.4.2, and 1.9.10, broadened]: The user can prevent focus changes that are not a result of explicit user request. (Level A)

Intent:

Users need to know that navigation in a web page is going to start in a predictable location and move in a predictable fashion. If a page moves the initial focus to somewhere other than the beginning of the page, the user may not realize they have skipped over some content, especially if they can only see a small portion of the page at a time. Similar problems may occur if the content or user agent automatically move the focus while the user is reading or entering data on a page. If the focus moves without the user recognizing it, they can easily end up entering data in an incorrect field or taking other unintentional actions. Users can also become confused or disoriented when a window scrolls when they haven't requested it. This is particularly problematic for users who can only see a small portion of the document, and thus have to use more effort to determine their new context. Such users also are more likely to continue typing, not immediately realizing that the context has changed. Users for whom navigation is time consuming, tiring, or painful (including those using screen readers or with impaired dexterity) may also need more work to return to the area where they want to work. While we recognize it may improve accessibility for some users on some pages to have the page to set focus to specific link or field when the page loads, it can also be detrimental for some users, and therefore users needs to be in control of this behavior.

Examples:

1. Jerome has loaded a page that sets its default focus to a search box. Because he wants to read the content of the page, rather than starting by entering data, it take additional him scrolling to get to the content that was not in the search box. To prevent this, he adjusts his browser's settings to disable the automatic focus change on this page.

2. Jessica users a screen enlarger, and loads a page that contains instructions followed by a form. If the page automatically moves the keyboard focus to the form, she may not realize there were instructions. To avoid this problem, she sets an option to prevent default focus changes.

3. James uses speech recognition. He speaks his credit card number by saying several digits and, if needed, Tab keys, in a single phrase. He needs to know ahead of time whether it is necessary to include the Tab command in the phrase.

4. Joey is filling in a Web form that asks for his phone number using three separate fields. When she types the three digits of her area code into the first field, the browser automatically moves the focus to the second field. This can be a problem for two reasons, first because if Joey is not looking at the screen she does not realize that the focus has moved for her, and so she presses the Tab key to move it manually, not realizing that this now puts the focus on the third field rather than the the second. It can also pose a problem if Joey realizes that she typed one digit incorrectly in the area code field, because when she presses Shift+Tab to return and edit that field, the browser or content script checks the number of digits that have been entered, and seeing that it is three, automatically moves the focus once again, preventing her from editing the number. To avoid these problems, Joey goes to her browser's Preferences dialog box and checks the box that prevents focus changes that she has not explicitly requested.

5. Justine uses a keyboard macro to execute a multistep command at a specific location. The focus changes without her control, so the command fails or executes with unpredictable results.

Related Resources:

UAAG 2.0 3.10.8 Don't Move Focus

Summary

Details

From the wiki:

Proposed

3.4.2 Avoid Side Effects of Navigation [former 1.9.1, before that 3.11.11, changed] : The user can move the keyboard focus to or from any enabled element without causing the user agent to take any further action. (Level A)

Intent

People do not expect side effects when moving the keyboard focus. If users fail to notice side effects, they could end up doing something disastrous, and this is especially likely for users of assistive technology who cannot see changes happening elsewhere on the screen. Users may also find it confusing or disorienting if the effect causes unexpected focus movement or changes in context. If the user agent does implement side effects to keyboard navigation, it is recommended that it provide a user preference setting to disable them. However, in some cases it may be more appropriate to provide a separate navigation mechanism that avoids side effects, such as allowing the user to hold down the Ctrl key while navigating to avoid changing selection or choice.

Note: It may not be possible for the user agent to detect or prevent side effects implemented by scripts in the content, but the user agent is required to prevent side effects that are under its control.

Examples

Murray uses a screen enlarger that allows him to see the element with the focus and a small area around it. He explores a dialog box by repeatedly pressing the Tab key to move to, and read, each control in succession, although he has to use the arrow keys to navigation between options in an option group. On this platform moving the focus to an option control automatically chooses that option, making it cumbersome for him because of the need to reset the choice to its original state afterward. Fortunately, the platform also has a convention that holding down the Ctrl key while navigating will move the focus without changing selection or option choice, so Murray uses this while exploring. His Web browser implements its own form controls and navigation mechanisms rather than using the platform's infrastructure, but it also implements this Ctrl-key mechanism for users like Murray.

Related Resources:

N/A

Summary

Details