Mods and implementing details for 5.4.1 and 5.4.2

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