HTML

Living Standard — Last Updated 10 September 2025

1. 6 User interaction
   1. 6.1 The hidden attribute
   2. 6.2 Page visibility
      1. 6.2.1 The VisibilityStateEntry interface
   3. 6.3 Inert subtrees
      1. 6.3.1 Modal dialogs and inert subtrees
      2. 6.3.2 The inert attribute
   4. 6.4 Tracking user activation
      1. 6.4.1 Data model
      2. 6.4.2 Processing model
      3. 6.4.3 APIs gated by user activation
      4. 6.4.4 The UserActivation interface
      5. 6.4.5 User agent automation
   5. 6.5 Activation behavior of elements
      1. 6.5.1 The ToggleEvent interface
      2. 6.5.2 The CommandEvent interface
   6. 6.6 Focus
      1. 6.6.1 Introduction
      2. 6.6.2 Data model
      3. 6.6.3 The tabindex attribute
      4. 6.6.4 Processing model
      5. 6.6.5 Sequential focus navigation
      6. 6.6.6 Focus management APIs
      7. 6.6.7 The autofocus attribute
   7. 6.7 Assigning keyboard shortcuts
      1. 6.7.1 Introduction
      2. 6.7.2 The accesskey attribute
      3. 6.7.3 Processing model
   8. 6.8 Editing
      1. 6.8.1 Making document regions editable: The contenteditable content attribute
      2. 6.8.2 Making entire documents editable: the designMode getter and setter
      3. 6.8.3 Best practices for in-page editors
      4. 6.8.4 Editing APIs
      5. 6.8.5 Spelling and grammar checking
      6. 6.8.6 Writing suggestions
      7. 6.8.7 Autocapitalization
      8. 6.8.8 Autocorrection
      9. 6.8.9 Input modalities: the inputmode attribute
      10. 6.8.10 Input modalities: the enterkeyhint attribute
   9. 6.9 Find-in-page
      1. 6.9.1 Introduction
      2. 6.9.2 Interaction with details and hidden=until-found
      3. 6.9.3 Interaction with selection
   10. 6.10 Close requests and close watchers
       1. 6.10.1 Close requests
       2. 6.10.2 Close watcher infrastructure
       3. 6.10.3 The CloseWatcher interface

6 User interaction

6.1 The hidden attribute

All HTML elements may have the hidden content attribute set. The hidden attribute is an enumerated attribute with the following keywords and states:

The attribute's missing value default is the Not Hidden state, and its invalid value default is the Hidden state.

When an element has the hidden attribute in the Hidden state, it indicates that the element is not yet, or is no longer, directly relevant to the page's current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user. User agents should not render elements that are in the Hidden state.

The requirement for user agents not to render elements that are in the Hidden state can be implemented indirectly through the style layer. For example, a web browser could implement these requirements using the rules suggested in the Rendering section.

When an element has the hidden attribute in the Hidden Until Found state, it indicates that the element is hidden like the Hidden state but the content inside the element will be accessible to find-in-page and fragment navigation. When these features attempt to scroll to a target which is in the element's subtree, the user agent will remove the hidden attribute in order to reveal the content before scrolling to it by running the ancestor revealing algorithm on the target node.

Web browsers will use 'content-visibility: hidden' instead of 'display: none' when the hidden attribute is in the Hidden Until Found state, as specified in the Rendering section.

  <h1>The Example Game</h1>
  <section id="login">
   <h2>Login</h2>
   <form>
    ...
    <!-- calls login() once the user's credentials have been checked -->
   </form>
   <script>
    function login() {
      // switch screens
      document.getElementById('login').hidden = true;
      document.getElementById('game').hidden = false;
    }
   </script>
  </section>
  <section id="game" hidden>
   ...
  </section>

The hidden attribute must not be used to hide content that could legitimately be shown in another presentation. For example, it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar. It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.

Elements that are not themselves hidden must not hyperlink to elements that are hidden. The for attributes of label and output elements that are not themselves hidden must similarly not refer to elements that are hidden. In both cases, such references would cause user confusion.

Elements and scripts may, however, refer to elements that are hidden in other contexts.

Elements in a section hidden by the hidden attribute are still active, e.g. scripts and form controls in such sections still execute and submit respectively. Only their presentation to the user changes.

The hidden getter steps are:

1. If the hidden attribute is in the Hidden Until Found state, then return "until-found".

2. If the hidden attribute is set, then return true.

3. Return false.

The hidden setter steps are:

1. If the given value is a string that is an ASCII case-insensitive match for "until-found", then set the hidden attribute to "until-found".

2. Otherwise, if the given value is false, then remove the hidden attribute.

3. Otherwise, if the given value is the empty string, then remove the hidden attribute.

4. Otherwise, if the given value is null, then remove the hidden attribute.

5. Otherwise, if the given value is 0, then remove the hidden attribute.

6. Otherwise, if the given value is NaN, then remove the hidden attribute.

7. Otherwise, set the hidden attribute to the empty string.

An ancestor reveal pair is a tuple consisting of a node and a string.

The ancestor revealing algorithm given a node target is:

1. Let ancestorsToReveal be « ».

2. Let ancestor be target.

3. While ancestor has a parent node within the flat tree:

   1. If ancestor has a hidden attribute in the Hidden Until Found state, then append (ancestor, "until-found") to ancestorsToReveal.

   2. If ancestor is slotted into the second slot of a details element which does not have an open attribute, then append (ancestor's parent node, "details") to ancestorsToReveal.

   3. Set ancestor to the parent node of ancestor within the flat tree.

4. For each (ancestorToReveal, revealType) of ancestorsToReveal:

   1. If ancestorToReveal is not connected, then return.

   2. If revealType is "until-found":

      1. If ancestorToReveal's hidden attribute is not in the Hidden Until Found state, then return.

      2. Fire an event named beforematch at ancestorToReveal with the bubbles attribute initialized to true.

      3. If ancestorToReveal is not connected, then return.

      4. If ancestorToReveal's hidden attribute is not in the Hidden Until Found state, then return.

      5. Remove the hidden attribute from ancestorToReveal.

   3. Otherwise:

      1. Assert: revealType is "details".

      2. If ancestorToReveal has an open attribute, then return.

      3. Set ancestorToReveal's open attribute to the empty string.

6.2 Page visibility

A traversable navigable's system visibility state, including its initial value upon creation, is determined by the user agent. It represents, for example, whether the browser window is minimized, a browser tab is currently in the background, or a system element such as a task switcher obscures the page.

When a user agent determines that the system visibility state for traversable navigable traversable has changed to newState, it must run the following steps:

1. Let navigables be the inclusive descendant navigables of traversable's active document.

2. For each navigable of navigables in what order?:

   1. Let document be navigable's active document.

   2. Queue a global task on the user interaction task source given document's relevant global object to update the visibility state of document with newState.

A Document has a visibility state, which is either "hidden" or "visible", initially set to "hidden".

The visibilityState getter steps are to return this's visibility state.

The hidden getter steps are to return true if this's visibility state is "hidden", otherwise false.

To update the visibility state of Document document to visibilityState:

1. If document's visibility state equals visibilityState, then return.

2. Set document's visibility state to visibilityState.

3. Queue a new VisibilityStateEntry whose visibility state is visibilityState and whose timestamp is the current high resolution time given document's relevant global object.

4. Run the screen orientation change steps with document. [SCREENORIENTATION]

5. Run the view transition page visibility change steps with document.

6. Run any page visibility change steps which may be defined in other specifications, with visibility state and document.

   It would be better if specification authors sent a pull request to add calls from here into their specifications directly, instead of using the page visibility change steps hook, to ensure well-defined cross-specification call order. As of the time of this writing the following specifications are known to have page visibility change steps, which will be run in an unspecified order: Device Posture API and Web NFC. [DEVICEPOSTURE] [WEBNFC]

7. Fire an event named visibilitychange at document, with its bubbles attribute initialized to true.

6.2.1 The VisibilityStateEntry interface

The VisibilityStateEntry interface exposes visibility changes to the document, from the moment the document becomes active.

function wasHiddenBeforeFirstContentfulPaint() {
    const fcpEntry = performance.getEntriesByName("first-contentful-paint")[0];
    const visibilityStateEntries = performance.getEntriesByType("visibility-state");
    return visibilityStateEntries.some(e =>
                                            e.startTime < fcpEntry.startTime &&
                                            e.name === "hidden");
}

Since hiding a page can cause throttling of rendering and other user-agent operations, it is common to use visibility changes as an indication that such throttling has occurred. However, other things could also cause throttling in different browsers, such as long periods of inactivity.

[Exposed=(Window)]
interface VisibilityStateEntry : PerformanceEntry {
  readonly attribute DOMString name;                 // shadows inherited name
  readonly attribute DOMString entryType;            // shadows inherited entryType
  readonly attribute DOMHighResTimeStamp startTime;  // shadows inherited startTime
  readonly attribute unsigned long duration;         // shadows inherited duration
};

The VisibilityStateEntry has an associated DOMHighResTimeStamp timestamp.

The VisibilityStateEntry has an associated "visible" or "hidden" visibility state.

The name getter steps are to return this's visibility state.

The entryType getter steps are to return "visibility-state".

The startTime getter steps are to return this's timestamp.

The duration getter steps are to return zero.

6.3 Inert subtrees

See also inert for an explanation of the attribute of the same name.

A node (in particular elements and text nodes) can be inert. When a node is inert:

• Hit-testing must act as if the 'pointer-events' CSS property were set to 'none'.

• Text selection functionality must act as if the 'user-select' CSS property were set to 'none'.

• If it is editable, the node behaves as if it were non-editable.

• The user agent should ignore the node for the purposes of find-in-page.

Inert nodes generally cannot be focused, and user agents do not expose the inert nodes to accessibility APIs or assistive technologies. Inert nodes that are commands will become inoperable to users, in the manner described above.

User agents may allow the user to override the restrictions on find-in-page and text selection, however.

By default, a node is not inert.

6.3.1 Modal dialogs and inert subtrees

A Document document is blocked by a modal dialog subject if subject is the topmost dialog element in document's top layer. While document is so blocked, every node that is connected to document, with the exception of the subject element and its flat tree descendants, must become inert.

subject can additionally become inert via the inert attribute, but only if specified on subject itself (i.e., subject escapes inertness of ancestors); subject's flat tree descendants can become inert in a similar fashion.

The dialog element's showModal() method causes this mechanism to trigger, by adding the dialog element to its node document's top layer.

6.3.2 The inert attribute

The inert attribute is a boolean attribute that indicates, by its presence, that the element and all its flat tree descendants which don't otherwise escape inertness (such as modal dialogs) are to be made inert by the user agent.

An inert subtree should not contain any content or controls which are critical to understanding or using aspects of the page which are not in the inert state. Content in an inert subtree will not be perceivable by all users, or interactive. Authors should not specify elements as inert unless the content they represent are also visually obscured in some way. In most cases, authors should not specify the inert attribute on individual form controls. In these instances, the disabled attribute is probably more appropriate.

The following example shows how to mark partially loaded content, visually obscured by a "loading" message, as inert.

<section aria-labelledby=s1>
  <h3 id=s1>Population by City</h3>
  <div class=container>
    <div class=loading><p>Loading...</p></div>
    <div inert>
      <form>
        <fieldset>
          <legend>Date range</legend>
          <div>
            <label for=start>Start</label>
            <input type=date id=start>
          </div>
          <div>
            <label for=end>End</label>
            <input type=date id=end>
          </div>
          <div>
            <button>Apply</button>
          </div>
        </fieldset>
      </form>
      <table>
        <caption>From 20-- to 20--</caption>
        <thead>
          <tr>
            <th>City</th>
            <th>State</th>
            <th>20-- Population</th>
            <th>20-- Population</th>
            <th>Percentage change</th>
          </tr>
        </thead>
        <tbody>
          <!-- ... -->
        </tbody>
      </table>
    </div>
  </div>
</section>

The "loading" overlay obscures the inert content, making it visually apparent that the inert content is not presently accessible. Notice that the heading and "loading" text are not descendants of the element with the inert attribute. This will ensure this text is accessible to all users, while the inert content cannot be interacted with by anyone.

6.4 Tracking user activation

To prevent abuse of certain APIs that could be annoying to users (e.g., opening popups or vibrating phones), user agents allow these APIs only when the user is actively interacting with the web page or has interacted with the page at least once. This "active interaction" state is maintained through the mechanisms defined in this section.

6.4.1 Data model

For the purpose of tracking user activation, each Window W has two relevant values:

• A last activation timestamp, which is either a DOMHighResTimeStamp, positive infinity (indicating that W has never been activated), or negative infinity (indicating that the activation has been consumed). Initially positive infinity.

• A last history-action activation timestamp, which is either a DOMHighResTimeStamp or positive infinity, initially positive infinity.

A user agent also defines a transient activation duration, which is a constant number indicating how long a user activation is available for certain user activation-gated APIs (e.g., for opening popups).

The transient activation duration is expected be at most a few seconds, so that the user can possibly perceive the link between an interaction with the page and the page calling the activation-gated API.

We then have the following boolean user activation states for W:

Sticky activation

When the current high resolution time given W is greater than or equal to the last activation timestamp in W, W is said to have sticky activation.

This is W's historical activation state, indicating whether the user has ever interacted in W. It starts false, then changes to true (and never changes back to false) when W gets the very first activation notification.

Transient activation

When the current high resolution time given W is greater than or equal to the last activation timestamp in W, and less than the last activation timestamp in W plus the transient activation duration, then W is said to have transient activation.

This is W's current activation state, indicating whether the user has interacted in W recently. This starts with a false value, and remains true for a limited time after every activation notification W gets.

The transient activation state is considered expired if it becomes false because the transient activation duration time has elapsed since the last user activation. Note that it can become false even before the expiry time through an activation consumption.

History-action activation

When the last history-action activation timestamp of W is not equal to the last activation timestamp of W, then W is said to have history-action activation.

This is a special variant of user activation, used to allow access to certain session history APIs which, if used too frequently, would make it harder for the user to traverse back using browser UI. It starts with a false value, and becomes true whenever the user interacts with W, but is reset to false through history-action activation consumption. This ensures such APIs cannot be used multiple times in a row without an intervening user activation. But unlike transient activation, there is no time limit within which such APIs must be used.

The last activation timestamp and last history-action activation timestamp are retained even after the Document changes its fully active status (e.g., after navigating away from a Document, or navigating to a cached Document). This means sticky activation state spans multiple navigations as long as the same Document gets reused. For the transient activation state, the original expiry time remains unchanged (i.e., the state still expires within the transient activation duration limit from the original activation triggering input event). It is important to consider this when deciding whether to base certain things off sticky activation or transient activation.

6.4.2 Processing model

When a user interaction causes firing of an activation triggering input event in a Document document, the user agent must perform the following activation notification steps before dispatching the event:

1. Assert: document is fully active.

2. Let windows be « document's relevant global object ».

3. Extend windows with the active window of each of document's ancestor navigables.

4. Extend windows with the active window of each of document's descendant navigables, filtered to include only those navigables whose active document's origin is same origin with document's origin.

5. For each window in windows:

   1. Set window's last activation timestamp to the current high resolution time.

   2. Notify the close watcher manager about user activation given window.

An activation triggering input event is any event whose isTrusted attribute is true and whose type is one of:

• "keydown", provided the key is neither the Esc key nor a shortcut key reserved by the user agent;

• "mousedown";

• "pointerdown", provided the event's pointerType is "mouse";

• "pointerup", provided the event's pointerType is not "mouse"; or

• "touchend".

Activation consuming APIs defined in this and other specifications can consume user activation by performing the following steps, given a Window W:

1. If W's navigable is null, then return.

2. Let top be W's navigable's top-level traversable.

3. Let navigables be the inclusive descendant navigables of top's active document.

4. Let windows be the list of Window objects constructed by taking the active window of each item in navigables.

5. For each window in windows, if window's last activation timestamp is not positive infinity, then set window's last activation timestamp to negative infinity.

History-action activation-consuming APIs can consume history-action user activation by performing the following steps, given a Window W:

1. If W's navigable is null, then return.

2. Let top be W's navigable's top-level traversable.

3. Let navigables be the inclusive descendant navigables of top's active document.

4. Let windows be the list of Window objects constructed by taking the active window of each item in navigables.

5. For each window in windows, set window's last history-action activation timestamp to window's last activation timestamp.

Note the asymmetry in the sets of browsing contexts in the page that are affected by an activation notification vs an activation consumption: an activation consumption changes (to false) the transient activation states for all browsing contexts in the page, but an activation notification changes (to true) the states for a subset of those browsing contexts. The exhaustive nature of consumption here is deliberate: it prevents malicious sites from making multiple calls to an activation consuming API from a single user activation (possibly by exploiting a deep hierarchy of iframes).

6.4.3 APIs gated by user activation

APIs that are dependent on user activation are classified into different levels:

Sticky activation-gated APIs

These APIs require the sticky activation state to be true, so they are blocked until the very first user activation.

Transient activation-gated APIs

These APIs require the transient activation state to be true, but they don't consume it, so multiple calls are allowed per user activation until the transient state expires.

Transient activation-consuming APIs

These APIs require the transient activation state to be true, and they consume user activation in each call to prevent multiple calls per user activation.

History-action activation-consuming APIs

These APIs require the history-action activation state to be true, and they consume history-action user activation in each call to prevent multiple calls per user activation.

6.4.4 The UserActivation interface

Each Window has an associated UserActivation, which is a UserActivation object. Upon creation of the Window object, its associated UserActivation must be set to a new UserActivation object created in the Window object's relevant realm.

[Exposed=Window]
interface UserActivation {
  readonly attribute boolean hasBeenActive;
  readonly attribute boolean isActive;
};

partial interface Navigator {
  [SameObject] readonly attribute UserActivation userActivation;
};

navigator.userActivation.hasBeenActive

Returns whether the window has sticky activation.

navigator.userActivation.isActive

Returns whether the window has transient activation.

The userActivation getter steps are to return this's relevant global object's associated UserActivation.

The hasBeenActive getter steps are to return true if this's relevant global object has sticky activation, and false otherwise.

The isActive getter steps are to return true if this's relevant global object has transient activation, and false otherwise.

6.4.5 User agent automation

For the purposes of user-agent automation and application testing, this specification defines the following extension command for the Web Driver specification. It is optional for a user agent to support the following extension command. [WEBDRIVER]

The remote end steps are:

1. Let window be the current browsing context's active window.

2. Let consume be true if window has transient activation; otherwise false.

3. If consume is true, then consume user activation of window.

4. Return success with data consume.

6.5 Activation behavior of elements

Certain elements in HTML have an activation behavior, which means that the user can activate them. This is always caused by a click event.

The user agent should allow the user to manually trigger elements that have an activation behavior, for instance using keyboard or voice input, or through mouse clicks. When the user triggers an element with a defined activation behavior in a manner other than clicking it, the default action of the interaction event must be to fire a click event at the element.

element.click()

✔MDN

HTMLElement/click

Support in all current engines.

Firefox3+Safari6+Chrome9+

---

Opera10.5+Edge79+

---

Edge (Legacy)12+Internet Explorer5.5+

---

Firefox Android4+Safari iOS?Chrome Android?WebView Android4.4+Samsung Internet1.0+Opera Android11+

Acts as if the element was clicked.

Each element has an associated click in progress flag, which is initially unset.

The click() method must run the following steps:

1. If this element is a form control that is disabled, then return.

2. If this element's click in progress flag is set, then return.

3. Set this element's click in progress flag.

4. Fire a synthetic pointer event named click at this element, with the not trusted flag set.

5. Unset this element's click in progress flag.

6.5.1 The ToggleEvent interface

[Exposed=Window]
interface ToggleEvent : Event {
  constructor(DOMString type, optional ToggleEventInit eventInitDict = {});
  readonly attribute DOMString oldState;
  readonly attribute DOMString newState;
  readonly attribute Element? source;
};

dictionary ToggleEventInit : EventInit {
  DOMString oldState = "";
  DOMString newState = "";
};

event.oldState

Set to "closed" when transitioning from closed to open, or set to "open" when transitioning from open to closed.

event.newState

Set to "open" when transitioning from closed to open, or set to "closed" when transitioning from open to closed.

event.source

Set to the element which initiated the toggle, which can be set up with the popovertarget and commandfor attributes. If there is no source element, then it is set to null.

The oldState and newState attributes must return the values they are initialized to.

The source getter steps are to return the result of retargeting source against this's currentTarget.

DOM standard issue #1328 tracks how to better standardize associated event data in a way which makes sense on Events. Currently an event attribute initialized to a value cannot also have a getter, and so an internal slot (or map of additional fields) is required to properly specify this.

A toggle task tracker is a struct which has:

task

A task which fires a ToggleEvent.

old state

A string which represents the task's event's value for the oldState attribute.

6.5.2 The CommandEvent interface

[Exposed=Window]
interface CommandEvent : Event {
  constructor(DOMString type, optional CommandEventInit eventInitDict = {});
  readonly attribute Element? source;
  readonly attribute DOMString command;
};

dictionary CommandEventInit : EventInit {
  Element? source = null;
  DOMString command = "";
};

event.command

Returns what action the element can take.

event.source

Returns the Element that was interacted with in order to cause this event.

The command attribute must return the value it was initialized to.

The source getter steps are to return the result of retargeting source against this's currentTarget.

DOM standard issue #1328 tracks how to better standardize associated event data in a way which makes sense on Events. Currently an event attribute initialized to a value cannot also have a getter, and so an internal slot (or map of additional fields) is required to properly specify this.

6.6 Focus

6.6.1 Introduction

This section is non-normative.

An HTML user interface typically consists of multiple interactive widgets, such as form controls, scrollable regions, links, dialog boxes, browser tabs, and so forth. These widgets form a hierarchy, with some (e.g. browser tabs, dialog boxes) containing others (e.g. links, form controls).

When interacting with an interface using a keyboard, key input is channeled from the system, through the hierarchy of interactive widgets, to an active widget, which is said to be focused.

Keyboard events are always targeted at this focused element.

6.6.2 Data model

A top-level traversable has system focus when it can receive keyboard input channeled from the operating system, possibly targeted at one of its active document's descendant navigables.

A top-level traversable has user attention when its system visibility state is "visible", and it either has system focus or user agent widgets directly related to it can receive keyboard input channeled from the operating system.

User attention is lost when a browser window loses focus, whereas system focus might also be lost to other system widgets in the browser window such as a location bar.

A Document d is a fully active descendant of a top-level traversable with user attention when d is fully active and d's node navigable's top-level traversable has user attention.

The term focusable area is used to refer to regions of the interface that can further become the target of such keyboard input. Focusable areas can be elements, parts of elements, or other regions managed by the user agent.

Each focusable area has a DOM anchor, which is a Node object that represents the position of the focusable area in the DOM. (When the focusable area is itself a Node, it is its own DOM anchor.) The DOM anchor is used in some APIs as a substitute for the focusable area when there is no other DOM object to represent the focusable area.

The following table describes what objects can be focusable areas. The cells in the left column describe objects that can be focusable areas; the cells in the right column describe the DOM anchors for those elements. (The cells that span both columns are non-normative examples.)

<map id=wallmap><area alt="Enter Door" coords="10,10,100,200" href="door.html"></map>
...
<img src="images/innerwall.jpeg" alt="There is a white wall here, with a door." usemap="#wallmap">
...
<img src="images/outerwall.jpeg" alt="There is a red wall here, with a door." usemap="#wallmap">

A navigable container (e.g. an iframe) is a focusable area, but key events routed to a navigable container get immediately routed to its content navigable's active document. Similarly, in sequential focus navigation a navigable container essentially acts merely as a placeholder for its content navigable's active document.

One focusable area in each Document is designated the focused area of the document. Which control is so designated changes over time, based on algorithms in this specification.

Even if a document is not fully active and not shown to the user, it can still have a focused area of the document. If a document's fully active state changes, its focused area of the document will stay the same.

The currently focused area of a top-level traversable traversable is the focusable area-or-null returned by this algorithm:

1. If traversable does not have system focus, then return null.

2. Let candidate be traversable's active document.

3. While candidate's focused area is a navigable container with a non-null content navigable: set candidate to the active document of that navigable container's content navigable.

4. If candidate's focused area is non-null, set candidate to candidate's focused area.

5. Return candidate.

The current focus chain of a top-level traversable traversable is the focus chain of the currently focused area of traversable, if traversable is non-null, or an empty list otherwise.

An element that is the DOM anchor of a focusable area is said to gain focus when that focusable area becomes the currently focused area of a top-level traversable. When an element is the DOM anchor of a focusable area of the currently focused area of a top-level traversable, it is focused.

The focus chain of a focusable area subject is the ordered list constructed as follows:

1. Let output be an empty list.

2. Let currentObject be subject.

3. While true:

   1. Append currentObject to output.

   2. If currentObject is an area element's shape, then append that area element to output.

      Otherwise, if currentObject's DOM anchor is an element that is not currentObject itself, then append currentObject's DOM anchor to output.

   3. If currentObject is a focusable area, then set currentObject to currentObject's DOM anchor's node document.

      Otherwise, if currentObject is a Document whose node navigable's parent is non-null, then set currentObject to currentObject's node navigable's parent.

      Otherwise, break.

4. Return output.

   The chain starts with subject and (if subject is or can be the currently focused area of a top-level traversable) continues up the focus hierarchy up to the Document of the top-level traversable.

All elements that are focusable areas are said to be focusable.

There are two special types of focusability for focusable areas:

• A focusable area is said to be sequentially focusable if it is included in its Document's sequential focus navigation order and the user agent determines that it is sequentially focusable.

• A focusable area is said to be click focusable if the user agent determines that it is click focusable. User agents should consider focusable areas with non-null tabindex values to be click focusable.

Elements which are not focusable are not focusable areas, and thus not sequentially focusable and not click focusable.

When a user activates a click focusable focusable area, the user agent must run the focusing steps on the focusable area with focus trigger set to "click".

Note that focusing is not an activation behavior, i.e. calling the click() method on an element or dispatching a synthetic click event on it won't cause the element to get focused.

A node is a focus navigation scope owner if it is a Document, a shadow host, a slot, or an element which is the popover trigger of an element in the popover showing state.

Each focus navigation scope owner has a focus navigation scope, which is a list of elements. Its contents are determined as follows:

Every element element has an associated focus navigation owner, which is either null or a focus navigation scope owner. It is determined by the following algorithm:

1. If element's parent is null, then return null.

2. If element's parent is a shadow host, then return element's assigned slot.

3. If element's parent is a shadow root, then return the parent's host.

4. If element's parent is the document element, then return the parent's node document.

5. If element is in the popover showing state and has a popover trigger set, then return element's popover trigger.

6. Return element's parent's associated focus navigation owner.

Then, the contents of a given focus navigation scope owner owner's focus navigation scope are all elements whose associated focus navigation owner is owner.

The order of elements within a focus navigation scope does not impact any of the algorithms in this specification. Ordering only becomes important for the tabindex-ordered focus navigation scope and flattened tabindex-ordered focus navigation scope concepts defined below.

A tabindex-ordered focus navigation scope is a list of focusable areas and focus navigation scope owners. Every focus navigation scope owner owner has tabindex-ordered focus navigation scope, whose contents are determined as follows:

• It contains all elements in owner's focus navigation scope that are themselves focus navigation scope owners, except the elements whose tabindex value is a negative integer.

• It contains all of the focusable areas whose DOM anchor is an element in owner's focus navigation scope, except the focusable areas whose tabindex value is a negative integer.

The order within a tabindex-ordered focus navigation scope is determined by each element's tabindex value, as described in the section below.

The rules there do not give a precise ordering, as they are composed mostly of "should" statements and relative orderings.

A flattened tabindex-ordered focus navigation scope is a list of focusable areas. Every focus navigation scope owner owner owns a distinct flattened tabindex-ordered focus navigation scope, whose contents are determined by the following algorithm:

1. Let result be a clone of owner's tabindex-ordered focus navigation scope.

2. For each item of result:

   1. If item is not a focus navigation scope owner, then continue.

   2. If item is not a focusable area, then replace item with all of the items in item's flattened tabindex-ordered focus navigation scope.

   3. Otherwise, insert the contents of item's flattened tabindex-ordered focus navigation scope after item.

6.6.3 The tabindex attribute

The tabindex content attribute allows authors to make an element and regions that have the element as its DOM anchor be focusable areas, allow or prevent them from being sequentially focusable, and determine their relative ordering for 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 sequentially focusable focusable areas.

The tabindex attribute, if specified, must have a value that is a valid integer. Positive numbers specify the relative position of the element's focusable areas in the