ACTION-438: Create another intent example for 3.11.1

        ACTION-438: Create another intent example for 3.11.1 that talks through what happens when the UA displays a Web page for the first time. That is, focus is on the document as a whole so pressing Space scrolls, pressing tab move to the first focusable element, etc.

Draft that may be too complex, but is useful for thinking about these things:

    * When a Web browser loads and renders a page in its normal "viewing" mode, the keyboard focus is initially on the entire contents of the viewport displaying that page. In this mode there is initially no text cursor, although the browser should at least provide the option to display a focus cursor indicating the entire content of this viewport, such as a dotted rectangle around its inside border. At this point the user can press keys that apply to the entire page, such as keys to scroll the viewport (arrow, page up, page down, home, end, and Space keys) or display the page's shortcut menu.  The user can also press keys to move the focus to another viewport or to an element within this viewport. An example of moving to an element within the viewport would be pressing the Tab key, which moves the focus to the first focusable element within the page. If that happens certain keys might take a new behaviors, such as arrow keys moving a caret in a text field or changing
    selection in a list instead of scrolling the entire viewport. Examples of keys that move to another viewport would be pressing Alt+D to move to the address bar, Alt to move to a menu bar, or Ctrl+Tab to move to a navigation pane. Sometimes the same keystroke may move within the viewport or to another viewport depending on context; for example, when the focus is on the entire viewport, pressing Tab may move to the first focusable element within the viewport while Shift+Tab moves to the previous viewport in the tab order, usually the search or address fields. (If the focus were on the last focusable element in the viewport, these functions could typically be reversed, with Shift+Tab moving to the previous focusable element, while Tab moves to the next viewport.)

    * When a Web browser loads and renders a page in its "editing" mode (also called "caret browsing mode"), the keyboard focus is initially on the first focusable element (according to the normal navigation order) within the viewport, rather than on the viewport as a whole. Because text is focusable when in editing mode, the focus would typically be shown as a text cursor placed immediately before the first text or graphics. In this case, pressing arrow, page down, and similar keys would move the caret within the viewport rather than scrolling the entire viewport. Other keys would probably behave the same as they would in reading mode, including keys to move between viewports and a key to display the shortcut menu (as having the text cursor with no selection typically behaves the same as having no text cursor). If the first element in the document is a control rather than text or an image, the focus would start on the control if it's a simple control such as a check box, or
    within the control if it's a complex control such as a text input field or list box; in either case the focus would be indicated by a caret or cursor appropriate for the type of control.


Some thoughts on focus and caret browsing:

Unfortunately, there are many aspects of keyboard navigation for which there are no universally accepted standards. Key examples of this are how to move focus between an entire viewport and elements within it, and how to scroll a viewport rather than moving the focus within it.

Worse, browsers seem to implement caret browsing in extremely idiosyncratic fashion. When Firefox 3.1 loads a Web page in editing mode, the focus is initially on the entire page, pressing the right, left, up, page down, or page upkeys have no effect whatsoever, while pressing the down arrow key moves the focus to the last element within the page--behavior which frankly makes no sense to me. Of course, that's better than Chrome, which has no caret browsing whatsoever. Internet Explorer 8 loads a page with focus on the entire viewport, pressing up or down arrow keys, or page up or page down, scrolls the viewport, and to actually begin caret browsing one has to press some Tab keys to move to an element in the normal tab order, and only then can you use arrow keys to move through text, even though all text is technically focusable in caret browsing mode and therefore could be included in the tab order. This means that a Web page with no elements that are normally in the tab 
order, such as links, seems to be impossible to navigate with IE's caret browsing. In addition, there are strange cases such as element you can get out of with left arrow but not right arrow (such links at the top of as http://blogmines.com/blog/2009/07/15/what-is-caret-browsing-in-internet-explorer-8/ in IE8), and often arrow keys skip over large portions of the content, and IE frequently beeps when navigating with no explanation as to why, and all browsers take you to things that are invisible under normal circumstances... It is all extremely discouraging. In my opinion, using a Web browser in editing mode should be essentially no different from using a word processor, and yet the former remains much more complicated, inconsistent, confusing, and (from a user's perspective) buggy.

     Greg