The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: firstname.lastname@example.org, email@example.com
This questionnaire was open from 2011-05-03 to 2011-05-13.
4 answers have been received.
Jump to results for question:
From the wiki
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)
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.
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.
UAAG 2.0 3.10.8 Don't Move Focus
|Accept the proposal||2|
|Recommend changes (see comments field)||1|
|The proposal needs more discussion (see comments field)|
|Disagree with the proposal|
|Neutral - will accept the consensus of the group||1|
|Responder||3.4.1 Avoid Unpredictable Focus||Comments 3.4.1|
|Simon Harper||Accept the proposal||Although I don't think we need this many examples.|
|Greg Lowney||Accept the proposal||Low priority, but starting the title with "Avoid" makes it sound like the user agent should avoid doing something, when the SC really says the user agent should allow the user to avoid something. Alternative titles might be "Allow avoiding unpredictable focus changes" or "Avoiding unwanted focus changes", "Allow blocking unwanted focus changes", etc.|
|Markku Hakkinen||Recommend changes (see comments field)||There a few small typos that should be corrected, but in general I accept the proposal.|
|Jim Allan||Neutral - will accept the consensus of the group|
From the wiki:
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)
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.
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.
|Accept the proposal||2|
|Recommend changes (see comments field)||1|
|The proposal needs more discussion (see comments field)||1|
|Disagree with the proposal|
|Neutral - will accept the consensus of the group|
|Responder||3.4.2 Avoid Side Effects of Navigation||Comments 3.4.2|
|Simon Harper||Accept the proposal|
|Greg Lowney||The proposal needs more discussion (see comments field)||Note that this was previously 1.9.11 rather than 1.9.1.|
An alternative title might be "Allow navigation without side effects", if "Avoid..." sounds like its saying the user agent must avoid doing side effects, while it really only requires the user agent to allow the user to navigate without side effects.
I'd appreciate people comparing this to the equivalent success criterion in ISO 9241.171, which has some differences, particularly the exception for display-only changes. It reads:
9.3.14 Separate keyboard navigation and activation
Software shall allow users to move the keyboard focus without triggering any effects other than the presentation of information (e.g. scrolling or pop-ups that do not change the focus or selection). An explicit keystroke or similar user action shall be provided to trigger any other user-initiated effect.
NOTE 1 This does not preclude the provision of additional navigation techniques that do cause effects, such as changing selection.
NOTE 2 This is particularly important for users who cannot see the entire screen at one time, and so would have to explore the user interface by navigating through all available user interface objects. In some cases, they would not be aware of any side effects caused by such navigation.
NOTE 3 Software does not meet this provision if a user cannot exit a data entry field without entering or change data because moving the keyboard focus to the field causes an effect (triggering a mandatory data entry mode). See also 8.1.
EXAMPLE 1 A user presses the “Tab” key to move from a button to a set of checkboxes. When the first checkbox acquires the keyboard focus, it does not become activated. Activation requires a separate step, such as pressing the spacebar.
EXAMPLE 2 In addition to using the mouse to make selections from a list, the user can also use the arrow keys to move through items in a list, selecting them by hitting the space bar. In lists that allow multiple selections, the user can hold down the control key in combination with the arrow keys to move through the list, hitting the space bar for each item that the user wants to select.
|Markku Hakkinen||Recommend changes (see comments field)||If typos fixed, I'm okay.|
|Jim Allan||Accept the proposal|
Everybody has responded to this questionnaire.