- From: Greg Lowney <gcl-0039@access-research.org>
- Date: Fri, 26 Feb 2010 15:10:58 -0600
- To: W3 UA list <w3c-wai-ua@w3.org>
Suggested rewrite of 5.4.1 with important note and modified examples: (Original 5.4.1: Control default focus: A user agent provides a mechanism for setting global configuration of whether web pages can set default focus.) 5.4.1 The user has a global option to disable recognized mechanisms used by web pages to specify default focus. (@@ Issue: Is there a *recognized* way to set the default focus? Or are we expecting the user agent to block all javascript attempts to set the keyboard focus, or during initial page load? Or should we remove this and delegate to WCAG 2.4.3. If the UA blocks all attempts to move focus, would that break pages?) * Intent of Success Criterion 5.4.x: Users need to know that navigation in a web page is going to start in a predictable location. While we recognize that it may be desirable for accessibility to set focus to specific link on a page other than the first link, the user needs to be in control of this feature. * Examples of Success Criterion 5.4.x: o Example: the page has a default focus to search box, the user has to take additional scrolling or navigation to get to the content that was not in the search box. The user may want to set their page so it follows the default behavior of starting with the keyboard input focus at the top of the page, rather than the search box. o Example: The user loads a page that contains instructions followed by a form. If the page automatically moves the keyboard focus to the form, a user relying on a screen reader or screen enlarger may not realize there were instructions. To avoid this problem, the user sets an option to prevent default focus changes.* Related Resources for Success Criterion 5.4.x: o NA Minor rewrite of 5.4.2 with new Intent and Examples: (Original 5.4.2: Unpredictable focus: Don't move the focus without telling the user. Provide a global option to block uninitiated focus changes.) 5.4.2 Unpredictable focus: Don't move the focus without telling the user, and provide a global option to block focus changes that are not initiated by the user. * Intent of Success Criterion 5.4.x: Users can become confused or disoriented when the 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. * Examples of Success Criterion 5.4.x: o A speech user issues a command to execute at a specific location, and the focus changes without the user's control, so the command fails or executes with unpredictable results. o The user is entering a phone number in a form that uses a separate field for the three-digit area code. When they finish typing the third digit, the form automatically moves the keyboard focus to the next field, but the user, not realizing this, is already pressing the Tab key to move the focus. The result is that the keyboard focus is moved out of the second field, which is left blank. o The users clicks on a button in a form, which recognizes they have entered invalid data. The page then moves to the keyboard focus to the field containing the error, and scrolls the window to make that visible. * Related Resources for Success Criterion 5.4.x: o UAAG 2.0 3.10.8 Don't Move Focus
Received on Friday, 26 February 2010 21:11:26 UTC