Focus and Point of Regard

The concept of point of regard is an accessibility term related to focus. The current definition for point of regard is a descriptive term, not a functional definition with normative requirements for implementation in browsers.

Considerations for Functional Definition

• How is point of regard changed?
  • How does the user change it?
  • How is it changed automatically (e.g. normal flow of reading)?
  • How can it be changed dynamically (e.g. via a message or notification, or new option)?
• Does point of regard ever change event flow (e.g. are any events ever sent to the point of regard rather than the focused element)?
• How does selection affect focus or point of regard?

User Agent Accessibility Guidelines 1.0

Definition

UAAG 1.0 glossary, point of regard

Point of regard

The point of regard is a position in rendered content that the user is presumed to be viewing. The dimensions of the point of regard may vary. For example, it may be a point (e.g., a moment during an audio rendering or a cursor position in a graphical rendering), or a range of text (e.g., focused text), or a two-dimensional area (e.g., content rendered through a two-dimensional graphical viewport). The point of regard is almost always within the viewport, but it may exceed the spatial or temporal dimensions of the viewport (see the definition of rendered content for more information about viewport dimensions). The point of regard may also refer to a particular moment in time for content that changes over time (e.g., an audio-only presentation). User agents may determine the point of regard in a number of ways, including based on viewport position in content, content focus, and selection. The stability of the point of regard is addressed by guideline 5 and checkpoint 9.4.

Guideline 5. Ensure user control of user interface behavior

UAAG 1.0 glossary, Guideline 5

Checkpoints: 5.1, 5.2, 5.3, 5.4, 5.5

Ensure that the user can control the behavior of viewports and user interface controls, including those that may be manipulated by the author (e.g., through scripts).

Control of viewport behavior is important to accessibility. Unexpected changes to the point of regard — what the user is presumed to be viewing — may cause users to lose track of how many viewports are open, or which viewport has the current focus. If carried out automatically, these changes might go unnoticed (e.g., by some users with blindness) or be disorienting (e.g., to some users with a cognitive disability). This guideline includes requirements for control of opening and closing viewports, the relative position of graphical viewports, changes to focus, and inadvertent form submissions. Checkpoints: 5.1, 5.2, 5.3, 5.4, 5.5

Ensure that the user can control the behavior of viewports and user interface controls, including those that may be manipulated by the author (e.g., through scripts).

Control of viewport behavior is important to accessibility. Unexpected changes to the point of regard — what the user is presumed to be viewing — may cause users to lose track of how many viewports are open, or which viewport has the current focus. If carried out automatically, these changes might go unnoticed (e.g., by some users with blindness) or be disorienting (e.g., to some users with a cognitive disability). This guideline includes requirements for control of opening and closing viewports, the relative position of graphical viewports, changes to focus, and inadvertent form submissions.

9.4 Restore viewport state history

Checkpoint 9.4

9.4 Restore viewport state history (P1)

Techniques for checkpoint 9.4

For user agents that implement a viewport history mechanism, for each state in a viewport's browsing history, maintain information about the point of regard, content focus, and selection.

When the user returns to any state in the viewport history (e.g., via the "back button"), restore the saved values for the point of regard, content focus, and selection.

Normative inclusions and exclusions

The viewport history associates values for these three state variables (point of regard, content focus, and selection) with a particular document object. If the user returns to a state in the history and the user agent retrieves new content, the user agent is not required to restore the saved values of the three state variables.

Conformance profile labels: Selection

Document Object Model (DOM) Level 3 Events

DOM3 Events

DOM3 Events defines several event types around focus:

• blur event
• focus event
• focusin event
• focusout event
• DOMFocusIn event
• DOMFocusOut event

Definition of Focus

DOM3 Events glossary, focus

focus

Focus is a special state of receptivity and concentration on an particular element or other event target within a document. Each element has different behavior when focused, depending on its functionality, such as priming the element for activation (as for a button or hyperlink) or toggling state (as for a checkbox), receiving text input (as for a text form field), or copying selected text. For more details, see Document Focus and Focus Context.

Document Focus and Focus Context

DOM3 Events, Section 5.2.2.2

This event module includes event types for notification of changes in document focus. Depending on the environment, document focus may be distinct from user agent focus and operating system focus; this is referred to as focus context. For example, in a typical desktop browser environment, the operating system context focus might be on one of many different applications, one of which is the browser; when the browser has focus, the user can shift the application context focus (such as with the tab key) among different browser user interface fields (e.g., the Web site location bar, a search field, etc.) before or after achieving document focus; once the document itself has focus, sequential shifting of focus will step through the focusable elements in the document. The event types defined in this specification deal exclusively with document focus, and the event target identified in the event details must only be part of the document or documents in the window, never a part of the browser or operating system, even when switching from one focus context to another.

Normally, a document always has a focused element, even if it is the document element itself, and a persistent focus ring; when switching between focus contexts, the document's currently focused element and focus ring normally remain in their current state; for example, if a document has three focusable elements, with the second element focused, when a user changes operating system focus to another application and then back to the browser, the second element will still be focused within the document, and tabbing will change the focus to the third element. A host language may define specific elements which might receive focus, the conditions under which an element may receive focus, the means by which focus may be changed, and the order in which the focus changes. For example, in some cases an element might be given focus by moving a pointer over it, while other circumstances might require a mouse click; some elements might not be focusable at all, and some might be focusable only by special means (clicking on the element), but not by tabbing to it. Documents may contain multiple focus rings. Other specifications may define a more complex focus model than is described in this specification, including allowing multiple elements to have the current focus.

HTML5

HTML5, section 7.3

7.3 Focus

When an element is focused, key events received by the document must be targeted at that element. There may be no element focused; when no element is focused, key events received by the document must be targeted at the body element, if there is one, or else at the Document's root element, if there is one. If there is no root element, key events must not be fired.

User agents may track focus for each browsing context or Document individually, or may support only one focused element per top-level browsing context — user agents should follow platform conventions in this regard.

Which elements within a top-level browsing context currently have focus must be independent of whether or not the top-level browsing context itself has the system focus.

When a child browsing context is focused, its browsing context container must also have focus.

When an element is focused, the element matches the CSS :focus pseudo-class.

7.3.1 Sequential focus navigation and the tabindex attribute

The tabindex content attribute allows authors to control whether an element is supposed to be focusable, whether it is supposed to be reachable using sequential focus navigation, and what is to be the relative order of the element for the purposes of sequential focus navigation. The name "tab index" comes from the common use of the "tab" key to navigate through the focusable elements. The term "tabbing" refers to moving forward through the focusable elements that can be reached using sequential focus navigation.

The tabindex attribute, if specified, must have a value that is a valid integer.

Each element has a tabindex focus flag. This flag is a factor that contributes towards determining whether an element is focusable, as described in the next section.

If the attribute is specified, it must be parsed using the rules for parsing integers. The attribute's values have the following meanings:

If the attribute is omitted or parsing the value returns an error.

The user agent should follow platform conventions to determine if the element's tabindex focus flag is set and, if so, whether the element can be reached using sequential focus navigation, and if so, what its relative order should be.

One valid reason to ignore the platform conventions and always allow an element to be focused (by setting its tabindex focus flag) would be if the user's only mechanism for activating an element is through a keyboard action that triggers the focused element. If the value is a negative integer

The user agent must set the element's tabindex focus flag, but should not allow the element to be reached using sequential focus navigation.

One valid reason to ignore the requirement that sequential focus navigation not allow the author to lead to the element would be if the user's only mechanism for moving the focus is sequential focus navigation. For instance, a keyboard-only user would be unable to click on a text field with a negative tabindex, so that user's user agent would be well justified in allowing the user to tab to the control regardless.

If the value is a zero

The user agent must set the element's tabindex focus flag, should allow the element to be reached using sequential focus navigation, and should follow platform conventions to determine the element's relative order.

If the value is greater than zero

The user agent must set the element's tabindex focus flag, should allow the element to be reached using sequential focus navigation, and should place the element in the sequential focus navigation order so that it is:

• before any focusable element whose tabindex attribute has been omitted or whose value, when parsed, returns an error,
• before any focusable element whose tabindex attribute has a value equal to or less than zero,
• after any element whose tabindex attribute has a value greater than zero but less than the value of the tabindex attribute on the element,
• after any element whose tabindex attribute has a value equal to the value of the tabindex attribute on the element but that is earlier in the document in tree order than the element,
• before any element whose tabindex attribute has a value equal to the value of the tabindex attribute on the element but that is later in the document in tree order than the element, and
• before any element whose tabindex attribute has a value greater than the value of the tabindex attribute on the element.

An element that has its tabindex focus flag set but does not otherwise have an activation behavior defined has an activation behavior that does nothing.

This means that an element that is only focusable because of its tabindex attribute will fire a click event in response to a non-mouse activation (e.g. hitting the "enter" key while the element is focused).

The tabIndex IDL attribute must reflect the value of the tabindex content attribute. Its default value is 0 for elements that are focusable and −1 for elements that are not focusable.

7.3.2 Focus management

An element is focusable if the user agent's default behavior allows it to be focusable or if the element has its tabindex focus flag set, but only if the element is either being rendered or is a descendant of a canvas element that represents embedded content.

User agents should make the following elements focusable as part of their default behavior, unless platform conventions dictate otherwise:

• a elements that have an href attribute
• link elements that have an href attribute
• button elements that are not disabled
• input elements whose type attribute are not in the Hidden state and that are not disabled
• select elements that are not disabled
• textarea elements that are not disabled
• command elements that do not have a disabled attribute
• Elements with a draggable attribute set, if that would enable the user agent to allow the user to begin a drag operations for those elements without the use of a pointing device
• Editing hosts
• Browsing context containers

In addition, each shape that is generated for an area element should be focusable, unless platform conventions dictate otherwise. (A single area element can correspond to multiple shapes, since image maps can be reused with multiple images on a page.)

The user agent may also make part of a details element's rendering focusable, to enable the element to be opened or closed using keyboard input. However, this is distinct from the details or summary element being focusable.

The focusing steps are as follows:

1. If the element is not in a Document, or if the element's Document has no browsing context, or if the element's Document's browsing context has no top-level browsing context, or if the element is not focusable, then abort these steps.
2. If focusing the element will remove the focus from another element, then run the unfocusing steps for that element.
3. Make the element the currently focused element in its top-level browsing context. Some elements, most notably area, can correspond to more than one distinct focusable area. If a particular area was indicated when the element was focused, then that is the area that must get focus; otherwise, e.g. when using the focus() method, the first such region in tree order is the one that must be focused.
4. The user agent may apply relevant platform-specific conventions for focusing widgets. Note: For example, some platforms select the contents of a text field when that field is focused.
5. Fire a simple event named focus at the element.

User agents must synchronously run the focusing steps for an element whenever the user moves the focus to a focusable element.

The unfocusing steps are as follows:

1. If the element is an input element, and the change event applies to the element, and the element does not have a defined activation behavior, and the user has changed the element's value or its list of selected files while the control was focused without committing that change, then fire a simple event that bubbles named change at the element.
2. Unfocus the element.
3. Fire a simple event named blur at the element.

When an element that is focused stops being a focusable element, or stops being focused without another element being explicitly focused in its stead, the user agent should synchronously run the focusing steps for the body element, if there is one; if there is not, then the user agent should synchronously run the unfocusing steps for the affected element only.

Note: For example, this might happen because the element is removed from its Document, or has a hidden attribute added. It would also happen to an input element when the element gets disabled.

7.3.3 Document-level focus APIs

document . activeElement
Returns the currently focused element.

document . hasFocus()
Returns true if the document has focus; otherwise, returns false.

window . focus()
Focuses the window. Use of this method is discouraged. Allow the user to control window focus instead.

window . blur()
Unfocuses the window. Use of this method is discouraged. Allow the user to control window focus instead.

The activeElement attribute on Document objects must return the element in the document that is focused. If no element in the Document is focused, this must return the body element.

When a child browsing context is focused, its browsing context container is also focused, by definition. For example, if the user moves the focus to a text field in an iframe, the iframe is the element with focus in the parent browsing context.

The hasFocus() method on Document objects must return true if the Document's browsing context is focused, and all its ancestor browsing contexts are also focused, and the top-level browsing context has the system focus. If the Document has no browsing context or if its browsing context has no top-level browsing context, then the method will always return false.

The focus() method on the Window object, when invoked, provides a hint to the user agent that the script believes the user might be interested in the contents of the browsing context of the Window object on which the method was invoked.

User agents are encouraged to have this focus() method trigger some kind of notification.

The blur() method on the Window object, when invoked, provides a hint to the user agent that the script believes the user probably is not currently interested in the contents of the browsing context of the Window object on which the method was invoked, but that the contents might become interesting again in the future.

User agents are encouraged to ignore calls to this blur() method entirely.

Historically the focus() and blur() methods actually affected the system focus, but hostile sites widely abuse this behavior to the user's detriment.

7.3.4 Element-level focus APIs

element . focus()
Focuses the element.

element . blur() 
Unfocuses the element. Use of this method is discouraged. Focus another element instead.
 
 Do not use this method to hide the focus ring if you find the focus ring unsightly. Instead, 
 use a CSS rule to override the 'outline' property. (Be aware, however, that this makes the 
 page significantly less usable for some people, especially those with reduced vision who use 
 focus outlines to help them navigate the page.)

 For example, to hide the outline from links, you could use:
 :link:focus, :visited:focus { outline: none; }

The focus() method, when invoked, must run the following algorithm:

1. If the element is marked as locked for focus, then abort these steps.
2. If the element is not focusable, then abort these steps.
3. Mark the element as locked for focus.
4. If the element is not already focused, run the focusing steps for the element.
5. Unmark the element as locked for focus.

The blur() method, when invoked, should run the focusing steps for the body element, if there is one; if there is not, then it should run the unfocusing steps for the element on which the method was called instead. User agents may selectively or uniformly ignore calls to this method for usability reasons.

For example, if the blur() method is unwisely being used to remove the focus ring for aesthetics reasons, the page would become unusable by keyboard users. Ignoring calls to this method would thus allow keyboard users to interact with the page.