HTML Standard
User interaction
6.1
The
hidden
attribute
6.2
Page visibility
6.2.1
The
VisibilityStateEntry
interface
6.3
Inert subtrees
6.3.1
Modal dialogs and inert subtrees
6.3.2
The
inert
attribute
6.4
Tracking user activation
6.4.1
Data model
6.4.2
Processing model
6.4.3
APIs gated by user activation
6.4.4
The
UserActivation
interface
6.4.5
User agent automation
6.5
Activation behavior of elements
6.5.1
The
ToggleEvent
interface
6.6
Focus
6.6.1
Introduction
6.6.2
Data model
6.6.3
The
tabindex
attribute
6.6.4
Processing model
6.6.5
Sequential focus navigation
6.6.6
Focus management APIs
6.6.7
The
autofocus
attribute
6.7
Assigning keyboard shortcuts
6.7.1
Introduction
6.7.2
The
accesskey
attribute
6.7.3
Processing
model
6.8
Editing
6.8.1
Making document regions editable: The
contenteditable
content attribute
6.8.2
Making entire documents
editable: the
designMode
getter and setter
6.8.3
Best practices for in-page editors
6.8.4
Editing APIs
6.8.5
Spelling and grammar checking
6.8.6
Autocapitalization
6.8.7
Input modalities: the
inputmode
attribute
6.8.8
Input modalities: the
enterkeyhint
attribute
6.9
Find-in-page
6.9.1
Introduction
6.9.2
Interaction with
details
and
hidden=until-found
6.9.3
Interaction with selection
6.10
Close requests and close watchers
6.10.1
Close requests
6.10.2
Close watcher infrastructure
6.10.3
The
CloseWatcher
interface
User interaction
6.1
The
hidden
attribute
Global_attributes/hidden
Support in one engine only.
Firefox
No
Safari
No
Chrome
102+
Opera
No
Edge
102+
Edge (Legacy)
Internet Explorer
No
Firefox Android
Safari iOS
Chrome Android
WebView Android
Samsung Internet
Opera Android
Global_attributes/hidden
Support in all current engines.
Firefox
4+
Safari
5.1+
Chrome
10+
Opera
Edge
79+
Edge (Legacy)
12+
Internet Explorer
11
Firefox Android
Safari iOS
Chrome Android
WebView Android
4+
Samsung Internet
Opera Android
All
HTML elements
may have the
hidden
content attribute set. The
hidden
attribute is an
enumerated attribute
with the
following keywords and states:
Keyword
State
Brief description
hidden
hidden
Will not be rendered.
(the empty string)
until-found
hidden until found
Will not be rendered, but content inside will be accessible to
find-in-page
and
fragment navigation
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. This requirement may 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. In addition to removing the
hidden
attribute, an event named
beforematch
is also fired on the element before the
hidden
attribute is removed.
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
Because this attribute is typically implemented using CSS, it's also possible to override it
using CSS. For instance, a rule that applies 'display: block' to all elements will cancel the
effects of the
hidden
state. Authors therefore
have to take care when writing their style sheets to make sure that the attribute is still styled
as expected. In addition, legacy user agents which don't support the
hidden until found
state will have 'display: none'
instead of 'content-visibility: hidden', so authors are encouraged to make sure that their style
sheets don't change the 'display' or 'content-visibility' properties of
hidden until found
elements.
Since elements with the
hidden
attribute in the
hidden until found
state use 'content-visibility:
hidden' instead of 'display: none', there are two caveats of the
hidden until found
state that make it different
from the
hidden
state:
The element needs to be affected by
layout containment
in order to be
revealed by find-in-page. This means that if the element in the
hidden until found
state has a 'display' value of
'none', 'contents', or 'inline', then the element will not be revealed by find-in-page.
The element will still have a
generated box
when in
the
hidden until found
state, which means
that borders, margin, and padding will still be rendered around the element.
In the following skeletal example, the attribute is used to hide the web game's main screen
until the user logs in:

The Example Game

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
Navigator/userActivation
Firefox
No
Safari
16.4+
Chrome
72+
Opera
Edge
79+
Edge (Legacy)
Internet Explorer
No
Firefox Android
Safari iOS
Chrome Android
WebView Android
Samsung Internet
Opera Android
The
userActivation
getter steps are to return
this
's
relevant global object
's
associated
UserActivation
UserActivation/hasBeenActive
Firefox
No
Safari
16.4+
Chrome
72+
Opera
Edge
79+
Edge (Legacy)
Internet Explorer
No
Firefox Android
Safari iOS
Chrome Android
WebView Android
Samsung Internet
Opera Android
The
hasBeenActive
getter steps are to return
true if
this
's
relevant global object
has
sticky
activation
, and false otherwise.
UserActivation/hasBeenActive
Firefox
No
Safari
16.4+
Chrome
72+
Opera
Edge
79+
Edge (Legacy)
Internet Explorer
No
Firefox Android
Safari iOS
Chrome Android
WebView Android
Samsung Internet
Opera Android
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]
HTTP Method
URI Template
POST
/session/{
session id
}/window/consume-user-activation
The
remote end steps
are:
Let
window
be
current
browsing context
's
active window
Let
consume
be true if
window
has
transient activation
otherwise false.
If
consume
is true, then
consume user activation
of
window
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
()
HTMLElement/click
Support in all current engines.
Firefox
3+
Safari
6+
Chrome
9+
Opera
10.5+
Edge
79+
Edge (Legacy)
12+
Internet Explorer
5.5+
Firefox Android
4+
Safari iOS
Chrome Android
WebView Android
4.4+
Samsung Internet
1.0+
Opera Android
11+
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:
If this element is a form control that is
disabled
, then return.
If this element's
click in progress flag
is set, then return.
Set this element's
click in progress flag
Fire a synthetic pointer event
named
click
at this element, with the
not trusted flag
set.
Unset this element's
click in progress flag
6.5.1
The
ToggleEvent
interface
ToggleEvent/ToggleEvent
Support in all current engines.
Firefox
🔰 114+
Safari
17+
Chrome
114+
Opera
Edge
114+
Edge (Legacy)
Internet Explorer
No
Firefox Android
Safari iOS
Chrome Android
WebView Android
Samsung Internet
Opera Android
ToggleEvent
Support in all current engines.
Firefox
🔰 114+
Safari
17+
Chrome
114+
Opera
Edge
114+
Edge (Legacy)
Internet Explorer
No
Firefox Android
Safari iOS
Chrome Android
WebView Android
Samsung Internet
Opera Android
[Exposed=Window]
interface
ToggleEvent
Event
constructor(DOMString type, optional
ToggleEventInit
eventInitDict = {});
readonly attribute DOMString oldState;
readonly attribute DOMString newState;
};

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.
ToggleEvent/oldState
Support in all current engines.
Firefox
🔰 114+
Safari
17+
Chrome
114+
Opera
Edge
114+
Edge (Legacy)
Internet Explorer
No
Firefox Android
Safari iOS
Chrome Android
WebView Android
Samsung Internet
Opera Android
ToggleEvent/newState
Support in all current engines.
Firefox
🔰 114+
Safari
17+
Chrome
114+
Opera
Edge
114+
Edge (Legacy)
Internet Explorer
No
Firefox Android
Safari iOS
Chrome Android
WebView Android
Samsung Internet
Opera Android
The
oldState
and
newState
attributes must return the values they are
initialized to.
toggle task tracker
is a
struct
which has:
task
task
which fires a
ToggleEvent
old state
A string which represents the
task
's event's value for
the
oldState
attribute.
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
Consider an HTML application running in a browser tab running in a graphical environment.
Suppose this application had a page with some text controls and links, and was currently showing
a modal dialog, which itself had a text control and a button.
The hierarchy of focusable widgets, in this scenario, would include the browser window, which
would have, amongst its children, the browser tab containing the HTML application. The tab itself
would have as its children the various links and text controls, as well as the dialog. The dialog
itself would have as its children the text control and the button.
If the widget with
focus
in this example was the text control in
the dialog box, then key input would be channeled from the graphical system to ① the web
browser, then to ② the tab, then to ③ the dialog, and finally to ④ the text
control.
Keyboard
events
are always targeted at this
focused
element.
6.6.2
Data model
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
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.
Document
is a
fully active descendant of
a top-level traversable with user attention
when
is
fully active
and
'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.)
Focusable area
DOM anchor
Examples
Elements that meet all the following criteria:
the element's
tabindex value
is non-null, or the element is determined by the
user agent to be focusable;
the element is either not a
shadow host
, or has a
shadow root
whose
delegates focus
is
false;
the element is not
actually disabled
the element is not
inert
the element is either
being rendered
delegating its rendering to its
children
, or
being used as relevant canvas fallback content
The element itself.
iframe
dialog

, sometimes
href="">
(depending on platform conventions).
The shapes of
area
elements in an
image map
associated with an
img
element that is
being rendered
and is not
inert
The
img
element.
In the following example, the
area
element creates two shapes, one on each
image. The
DOM anchor
of the first shape is the first
img
element, and the
DOM anchor
of the second shape is the second
img
element.

...

...

The user-agent provided subwidgets of elements that are
being rendered
and are not
actually disabled
or
inert
The element for which the
focusable area
is a subwidget.
The
controls in the user
interface
for a
video
element, the up and down buttons in a spin-control
version of

, the part of a
details
element's rendering that enables the element to be opened or closed using
keyboard input.
The scrollable regions of elements that are
being rendered
and are not
inert
The element for which the box that the scrollable region scrolls was created.
The CSS
'overflow'
property's 'scroll' value typically creates
a scrollable region.
The
viewport
of a
Document
that has a non-null
browsing context
and is not
inert
The
Document
for which the
viewport
was created.
The contents of an
iframe
Any other element or part of an element determined by the user agent to be a focusable area,
especially to aid with accessibility or to better match platform conventions.
The element.
A user agent could make all list item bullets
sequentially
focusable
, so that a user can more easily navigate lists.
Similarly, a user agent could make all elements with
title
attributes
sequentially focusable
, so that their
advisory information can be accessed.
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:
If
traversable
does not have
system focus
, then return
null.
Let
candidate
be
traversable
's
active
document
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
If
candidate
's
focused area
is non-null, set
candidate
to
candidate
's
focused area
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:
Let
output
be an empty
list
Let
currentObject
be
subject
While true:
Append
currentObject
to
output
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
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
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
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.
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
Being
focusable
is a statement about whether an element can be focused
programmatically, e.g. via the
focus()
method or
autofocus
attribute. In contrast,
sequentially
focusable
and
click focusable
govern how the user agent responds to user
interaction: respectively, to
sequential focus navigation
and as
activation behavior
The user agent might determine that an element is not
sequentially focusable
even
if it is
focusable
and is included in its
Document
's
sequential
focus navigation order
, according to user preferences. For example, macOS users can set
the user agent to skip non-form control elements, or can skip links when doing
sequential
focus navigation
with just the
Tab
key (as opposed to using both the
Option
and
Tab
keys).
Similarly, the user agent might determine that an element is not
click focusable
even if it is
focusable
. For example, in some user agents, clicking on a
non-editable form control does not focus it, i.e. the user agent has determined that such
controls are not click focusable.
Thus, an element can be
focusable
, but neither
sequentially
focusable
nor
click focusable
. For example, in some user agents, a
non-editable form-control with a negative-integer
tabindex value
would not be
focusable via user interaction, only via programmatic APIs.
When a user
activates
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 in the
popover showing state
which also has a
popover
invoker
set.
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:
If
element
's parent is null, then return null.
If
element
's parent is a
shadow host
, then return
element
's
assigned slot
If
element
's parent is a
shadow root
, then return the parent's
host
If
element
's parent is the
document element
, then return the
parent's
node document
If
element
is in the
popover showing
state
and has a
popover invoker
set, then return
element
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.
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.
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:
Let
result
be a
clone
of
owner
's
tabindex-ordered focus navigation scope
For each
item
of
result
If
item
is not a
focus navigation scope owner
, then
continue
If
item
is not a
focusable area
, then replace
item
with all of the items in
item
's
flattened tabindex-ordered focus navigation
scope
Otherwise, insert the contents of
item
's
flattened tabindex-ordered
focus navigation scope
after
item
6.6.3
The
tabindex
attribute
Global_attributes/tabindex
Support in all current engines.
Firefox
1.5+
Safari
4+
Chrome
1+
Opera
Edge
79+
Edge (Legacy)
12+
Internet Explorer
Yes
Firefox Android
Safari iOS
Chrome Android
WebView Android
Samsung Internet
Opera Android
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
sequential focus
navigation order
, and negative numbers indicate that the control is not
sequentially focusable
Developers should use caution when using values other than 0 or −1 for their
tabindex
attributes as this is complicated to do correctly.
The following provides a non-normative summary of the behaviors of the
possible
tabindex
attribute values. The below
processing model gives the more precise rules.
omitted (or non-integer values)
The user agent will decide whether the element is
focusable
, and if it is,
whether it is
sequentially focusable
or
click focusable
(or both).
−1 (or other negative integer values)
Causes the element to be
focusable
, and indicates that the author would prefer
the element to be
click focusable
but not
sequentially focusable
. The
user agent might ignore this preference for click and sequential focusability, e.g., for
specific element types according to platform conventions, or for keyboard-only users.
Causes the element to be
focusable
, and indicates that the author would prefer
the element to be both
click focusable
and
sequentially focusable
. The
user agent might ignore this preference for click and sequential focusability.
positive integer values
Behaves the same as 0, but in addition creates a relative ordering within a
tabindex-ordered focus navigation scope
, so that elements with higher
tabindex
attribute value come later.
Note that the
tabindex
attribute cannot be used to make
an element non-focusable. The only way a page author can do that is by
disabling
the element, or making it
inert
The
tabindex value
of an element is the value of its
tabindex
attribute, parsed using the
rules for parsing
integers
. If parsing fails or the attribute is not specified, then the
tabindex
value
is null.
The
tabindex value
of a
focusable area
is the
tabindex
value
of its
DOM anchor
The
tabindex value
of an element must be interpreted as follows:
If the value is null
The user agent should follow platform conventions to determine if the element should be
considered as a
focusable area
and if so, whether the element and any
focusable areas
that have the element as their
DOM anchor
are
sequentially focusable
, and if so, what their relative
position in their
tabindex-ordered focus navigation scope
is to be. If the element
is a
focus navigation scope owner
, it must be included in its
tabindex-ordered focus navigation scope
even if it is not a
focusable
area
The relative ordering within a
tabindex-ordered focus navigation scope
for
elements and
focusable areas
that belong to the same
focus navigation scope
and whose
tabindex value
is null should be in
shadow-including tree order
Modulo platform conventions, it is suggested that the following elements should be considered
as
focusable areas
and be
sequentially
focusable
elements that have an
href
attribute
button
elements
input
elements whose
type
attribute are
not in the
Hidden
state
select
elements
textarea
elements
summary
elements that are the first
summary
element child of a
details
element
Elements with a
draggable
attribute set, if that would
enable the user agent to allow the user to begin drag operations for those elements without
the use of a pointing device
Editing hosts
Navigable containers
If the value is a negative integer
The user agent must consider the element as a
focusable area
, but should omit
the element from any
tabindex-ordered focus navigation scope
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 control 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 allow the element to be considered as a
focusable area
and
should allow the element and any
focusable areas
that have
the element as their
DOM anchor
to be
sequentially focusable
The relative ordering within a
tabindex-ordered focus navigation scope
for
elements and
focusable areas
that belong to the same
focus navigation scope
and whose
tabindex value
is zero should be in
shadow-including tree order
If the value is greater than zero
The user agent must allow the element to be considered as a
focusable area
and
should allow the element and any
focusable areas
that have
the element as their
DOM anchor
to be
sequentially focusable
, and
should place the element — referenced as
candidate
below — and the
aforementioned
focusable areas
in the
tabindex-ordered focus navigation scope
where the element is a part of so that,
relative to other elements and
focusable areas
that belong
to the same
focus navigation scope
, they are:
before any
focusable area
whose
DOM anchor
is an element whose
tabindex
attribute has been omitted or whose value, when parsed,
returns an error,
before any
focusable area
whose
DOM anchor
is an element whose
tabindex
attribute has a value equal to or less than zero,
after any
focusable area
whose
DOM anchor
is an element whose
tabindex
attribute has a value greater than zero but less than
the value of the
tabindex
attribute on
candidate
after any
focusable area
whose
DOM anchor
is an element whose
tabindex
attribute has a value equal to the value of the
tabindex
attribute on
candidate
but that is
located earlier than
candidate
in
shadow-including tree order
before any
focusable area
whose
DOM anchor
is an element whose
tabindex
attribute has a value equal to the value of the
tabindex
attribute on
candidate
but that is
located later than
candidate
in
shadow-including tree order
, and
before any
focusable area
whose
DOM anchor
is an element whose
tabindex
attribute has a value greater than the value of the
tabindex
attribute on
candidate
HTMLElement/tabIndex
Support in all current engines.
Firefox
1+
Safari
3.1+
Chrome
1+
Opera
12.1+
Edge
79+
Edge (Legacy)
18
Internet Explorer
🔰 5.5+
Firefox Android
Safari iOS
Chrome Android
WebView Android
Samsung Internet
Opera Android
12.1+
The
tabIndex
IDL
attribute must
reflect
the value of the
tabindex
content attribute. The
default value
is 0 if the element is an
area
button
frame
iframe
input
object
select
textarea
, or
SVG
element, or is a
summary
element that is a
summary for
its parent details
. The
default value
is −1 otherwise.
The varying default value based on element type is a historical artifact.
6.6.4
Processing model
To
get the focusable area
for a
focus target
that is either an element
that is not a
focusable area
, or is a
navigable
, given an
optional string
focus trigger
(default "
other
"), run the first
matching set of steps from the following list:
If
focus target
is an
area
element with one or more shapes that are
focusable areas
Return the shape corresponding to the first
img
element in
tree
order
that uses the image map to which the
area
element belongs.
If
focus target
is an element with one or more scrollable regions that are
focusable areas
Return the element's first scrollable region, according to a pre-order, depth-first
traversal of the
flat tree
[CSSSCOPING]
If
focus target
is the
document element
of its
Document
Return the
Document
's
viewport
If
focus target
is a
navigable
Return the
navigable
's
active
document
If
focus target
is a
navigable container
with a non-null
content navigable
Return the
navigable container
's
content navigable
's
active document
If
focus target
is a
shadow host
whose
shadow root
's
delegates focus
is
true
Let
focusedElement
be the
currently focused area of a top-level
traversable
's
DOM anchor
If
focus target
is a
shadow-including inclusive ancestor
of
focusedElement
, then return
focusedElement
Return the
focus delegate
for
focus target
given
focus
trigger
For
sequential focusability
, the
handling of
shadow hosts
and
delegates focus
is
done when constructing the
sequential focus navigation order
. That is, the
focusing steps
will never be called on such
shadow
hosts
as part of sequential focus navigation.
Otherwise
Return null.
The
focus delegate
for a
focusTarget
, given an optional string
focusTrigger
(default "
other
"), is given by the following steps:
If
focusTarget
is a
shadow host
and its
shadow root
's
delegates focus
is false,
then return null.
Let
whereToLook
be
focusTarget
If
whereToLook
is a
shadow host
, then set
whereToLook
to
whereToLook
's
shadow
root
Let
autofocusDelegate
be the
autofocus delegate
for
whereToLook
given
focusTrigger
If
autofocusDelegate
is not null, then return
autofocusDelegate
For each
descendant
of
whereToLook
's
descendants
, in
tree
order
Let
focusableArea
be null.
If
focusTarget
is a
dialog
element and
descendant
is
sequentially focusable
, then set
focusableArea
to
descendant
Otherwise, if
focusTarget
is not a
dialog
and
descendant
is a
focusable area
, set
focusableArea
to
descendant
Otherwise, set
focusableArea
to the result of
getting the focusable area
for
descendant
given
focusTrigger
This step can end up recursing, i.e., the
get the focusable area
steps might return the
focus delegate
of
descendant
If
focusableArea
is not null, then return
focusableArea
It's important that we are
not
looking at the
shadow-including descendants
here, but instead only
at the
descendants
Shadow
hosts
are instead handled by the recursive case mentioned above.
Return null.
The above algorithm essentially returns the first suitable
focusable
area
where the path between its
DOM anchor
and
focusTarget
delegates focus at any shadow tree boundaries.
The
autofocus delegate
for a
focus target
given a
focus
trigger
is given by the following steps:
For each
descendant
descendant
of
focus target
, in
tree order
If
descendant
does not have an
autofocus
content attribute, then
continue
Let
focusable area
be
descendant
, if
descendant
is a
focusable area
; otherwise let
focusable area
be the result of
getting the focusable area
for
descendant
given
focus trigger
If
focusable area
is null, then
continue
If
focusable area
is not
click focusable
and
focus
trigger
is "
click
", then
continue
Return
focusable area
Return null.
The
focusing steps
for an object
new focus target
that is either a
focusable area
, or an element that is not a
focusable area
, or a
navigable
, are as follows. They can optionally be run with a
fallback
target
and a string
focus trigger
If
new focus target
is not a
focusable area
, then set
new
focus target
to the result of
getting the focusable
area
for
new focus target
, given
focus trigger
if it was
passed.
If
new focus target
is null, then:
If no
fallback target
was specified, then return.
Otherwise, set
new focus target
to the
fallback
target
If
new focus target
is a
navigable container
with non-null
content navigable
, then set
new focus target
to the
content
navigable
's
active document
If
new focus target
is a
focusable area
and its
DOM
anchor
is
inert
, then return.
If
new focus target
is the
currently focused area of a top-level
traversable
, then return.
Let
old chain
be the
current focus chain of the top-level traversable
in which
new focus
target
finds itself.
Let
new chain
be the
focus chain
of
new
focus target
Run the
focus update steps
with
old chain
new chain
and
new focus target
respectively.
User agents must
immediately
run the
focusing steps
for a
focusable area
or
navigable
candidate
whenever the
user attempts to move the focus to
candidate
The
unfocusing steps
for an object
old focus target
that is
either a
focusable area
or an element that is not a
focusable area
are as
follows:
If
old focus target
is a
shadow host
whose
shadow root
's
delegates focus
is true,
and
old focus target
's
shadow root
is a
shadow-including inclusive ancestor
of the
currently focused area of a
top-level traversable
's
DOM anchor
, then set
old focus target
to
that
currently focused area of a top-level traversable
If
old focus target
is
inert
, then return.
If
old focus target
is an
area
element and one of its shapes is
the
currently focused area of a top-level traversable
, or, if
old focus
target
is an element with one or more scrollable regions, and one of them is the
currently focused area of a top-level traversable
, then let
old focus
target
be that
currently focused area of a top-level traversable
Let
old chain
be the
current focus chain of the top-level traversable
in which
old focus
target
finds itself.
If
old focus target
is not one of the entries in
old
chain
, then return.
If
old focus target
is not a
focusable area
, then return.
Let
topDocument
be
old chain
's last entry.
If
topDocument
's
node navigable
has
system focus
, then
run the
focusing steps
for
topDocument
's
viewport
Otherwise, apply any relevant platform-specific conventions for removing
system
focus
from
topDocument
's
node navigable
, and run the
focus
update steps
given
old chain
, an empty list, and null.
The
unfocusing steps
do not always result in the focus changing, even
when applied to the
currently focused area of a top-level traversable
. For
example, if the
currently focused area of a top-level traversable
is a
viewport
, then it will usually keep its focus regardless until another
focusable area
is explicitly focused with the
focusing steps
The
focus update steps
, given an
old chain
, a
new chain
, and a
new focus target
respectively, are as
follows:
If the last entry in
old chain
and the last entry in
new chain
are the same, pop the last entry from
old chain
and the last entry from
new chain
and redo this step.
For each entry
entry
in
old chain
, in order, run
these substeps:
If
entry
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 (such that it is different to what it was when the
control was first focused), then:
Set
entry
's
user validity
to true.
Fire an
event
named
change
at the element, with the
bubbles
attribute initialized to true.
If
entry
is an element, let
blur event target
be
entry
If
entry
is a
Document
object, let
blur event target
be
that
Document
object's
relevant global object
Otherwise, let
blur event target
be null.
If
entry
is the last entry in
old chain
, and
entry
is an
Element
, and the last entry in
new
chain
is also an
Element
, then let
related blur target
be the last entry in
new chain
. Otherwise, let
related blur
target
be null.
If
blur event target
is not null,
fire a focus event
named
blur
at
blur event target
, with
related blur target
as the related target.
In some cases, e.g., if
entry
is
an
area
element's shape, a scrollable region, or a
viewport
, no
event is fired.
Apply any relevant platform-specific conventions for focusing
new focus target
(For example, some platforms select the contents of a text control when that control is
focused.)
For each entry
entry
in
new chain
, in reverse
order, run these substeps:
If
entry
is a
focusable area
, and the
focused area of the
document
is not
entry
Set
document
's
relevant global object
's
navigation API
's
focus changed during ongoing
to true.
Designate
entry
as the
focused area of the document
If
entry
is an element, let
focus event target
be
entry
If
entry
is a
Document
object, let
focus event target
be
that
Document
object's
relevant global object
Otherwise, let
focus event target
be null.
If
entry
is the last entry in
new chain
, and
entry
is an
Element
, and the last entry in
old
chain
is also an
Element
, then let
related focus target
be the last entry in
old chain
. Otherwise, let
related
focus target
be null.
If
focus event target
is not null,
fire a focus event
named
focus
at
focus event target
, with
related focus target
as the related target.
In some cases, e.g. if
entry
is an
area
element's shape, a scrollable region, or a
viewport
, no event is fired.
To
fire a focus event
named
at an element
with a given
related target
fire an event
named
at
, using
FocusEvent
, with the
relatedTarget
attribute initialized to
the
view
attribute initialized to
's
node document
's
relevant global object
, and the
composed
flag
set.
When a key event is to be routed in a
top-level traversable
, the user agent must
run the following steps:
Let
target area
be the
currently focused area of the top-level traversable
Assert
target area
is not null, since key events are only routed
to
top-level traversables
that have
system
focus
. Therefore,
target area
is a
focusable area
Let
target node
be
target area
's
DOM anchor
If
target node
is a
Document
that has a
body element
, then let
target node
be
the body
element
of that
Document
Otherwise, if
target node
is a
Document
object that has a non-null
document element
, then let
target node
be that
document
element
If
target node
is not
inert
, then:
Let
canHandle
be the result of
dispatching
the key event at
target
node
If
canHandle
is true, then let
target area
handle the key event.
This might include
firing a
click
event
at
target node
The
has focus steps
, given a
Document
object
target
are as follows:
If
target
's
node navigable
's
top-level
traversable
does not have
system focus
, then return false.
Let
candidate
be
target
's
node navigable
's
top-level traversable
's
active document
While true:
If
candidate
is
target
, then return true.
If the
focused area
of
candidate
is a
navigable container
with a non-null
content
navigable
, then set
candidate
to the
active
document
of that
navigable container
's
content
navigable
Otherwise, return false.
6.6.5
Sequential focus navigation
Each
Document
has a
sequential focus navigation order
, which orders some
or all of the
focusable areas
in the
Document
relative to each other. Its contents and ordering are given by the
flattened
tabindex-ordered focus navigation scope
of the
Document
Per the rules defining the
flattened tabindex-ordered focus navigation
scope
, the ordering is not necessarily related to the
tree order
of the
Document
If a
focusable area
is omitted from the
sequential focus navigation
order
of its
Document
, then it is unreachable via
sequential focus
There can also be a
sequential focus navigation starting point
. It is initially
unset. The user agent may set it when the user indicates that it should be moved.
For example, the user agent could set it to the position of the user's click if
the user clicks on the document contents.
User agents are required to set the
sequential focus navigation starting
point
to the
target element
when
navigating
to a fragment
When the user requests that focus move from the
currently focused area of a top-level
traversable
to the next or previous
focusable area
(e.g. as the default
action of pressing the
tab
key), or when the user requests that focus
sequentially move to a
top-level traversable
in the first place (e.g. from the
browser's location bar), the user agent must use the following algorithm:
Let
starting point
be the
currently focused area of a top-level
traversable
, if the user requested to move focus sequentially from there, or else the
top-level traversable
itself, if the user instead requested to move focus from
outside the
top-level traversable
If there is a
sequential focus navigation starting point
defined and it is
inside
starting point
, then let
starting point
be the
sequential
focus navigation starting point
instead.
Let
direction
be
forward
if the user requested the
next
control, and
backward
if the user requested the previous control.
Typically, pressing
tab
requests the next control, and pressing
shift
tab
requests the previous control.
Loop
: Let
selection mechanism
be
sequential
if the
starting
point
is a
navigable
or if
starting point
is in its
Document
's
sequential focus navigation order
Otherwise,
starting point
is not in its
Document
's
sequential focus navigation order
; let
selection mechanism
be
DOM
Let
candidate
be the result of running the
sequential navigation search
algorithm
with
starting point
direction
, and
selection
mechanism
as the arguments.
If
candidate
is not null, then run the
focusing steps
for
candidate
and return.
Otherwise, unset the
sequential focus navigation starting point
If
starting point
is a
top-level traversable
, or a
focusable area
in the
top-level traversable
, the user agent
should transfer focus to its own controls appropriately (if any), honouring
direction
, and then return.
For example, if
direction
is
backward
, then the last
sequentially focusable
control before the browser's rendering area would be the
control to focus.
If the user agent has no
sequentially focusable
controls — a kiosk-mode
browser, for instance — then the user agent may instead restart these steps with the
starting point
being the
top-level traversable
itself.
Otherwise,
starting point
is a
focusable area
in a
child
navigable
. Set
starting point
to that
child navigable
's
parent
and return to the step labeled
loop
The
sequential navigation search algorithm
consists of the following steps. This
algorithm takes three arguments:
starting point
direction
and
selection mechanism
Pick the appropriate cell from the following table, and follow the instructions in that
cell.
The appropriate cell is the one that is from the column whose header describes
direction
and from the first row whose header describes
starting point
and
selection mechanism
direction
is
forward
direction
is
backward
starting point
is a
navigable
Let
candidate
be the first
suitable sequentially focusable area
in
starting point
's
active document
, if any; or
else null
Let
candidate
be the last
suitable sequentially focusable area
in
starting point
's
active document
, if any; or
else null
selection mechanism
is
DOM
Let
candidate
be the first
suitable sequentially focusable area
in the
home document
following
starting point
, if any; or else null
Let
candidate
be the last
suitable sequentially focusable area
in the
home document
preceding
starting point
, if any; or else null
selection mechanism
is
sequential
Let
candidate
be the first
suitable sequentially focusable area
in the
home sequential focus navigation order
following
starting point
, if any; or else null
Let
candidate
be the last
suitable sequentially focusable area
in the
home sequential focus navigation order
preceding
starting point
, if any; or else null
suitable sequentially focusable area
is a
focusable area
whose
DOM anchor
is not
inert
and is
sequentially
focusable
The
home document
is the
Document
to which
starting point
belongs.
The
home sequential focus navigation order
is the
sequential focus
navigation order
to which
starting point
belongs.
The
home sequential focus navigation order
is the
document
's
sequential focus navigation order
, but is only used when the
starting point
is in that
sequential focus navigation order
(when it's not,
selection mechanism
will be
DOM
).
If
candidate
is a
navigable container
with a non-null
content
navigable
, then let
new candidate
be the result of running the
sequential navigation search algorithm
with
candidate
's
content
navigable
as the first argument,
direction
as the second, and
sequential
as the third.
If
new candidate
is null, then let
starting point
be
candidate
, and return to the top of this algorithm. Otherwise, let
candidate
be
new candidate
Return
candidate
6.6.6
Focus management APIs
dictionary
FocusOptions
boolean
preventScroll
= false;
boolean
focusVisible
};
documentOrShadowRoot
activeElement
Document/activeElement
Support in all current engines.
Firefox
3+
Safari
4+
Chrome
2+
Opera
12.1+
Edge
79+
Edge (Legacy)
12+
Internet Explorer
6+
Firefox Android
Safari iOS
Chrome Android
WebView Android
37+
Samsung Internet
Opera Android
12.1+
ShadowRoot/activeElement
Support in all current engines.
Firefox
63+
Safari
10+
Chrome
53+
Opera
Edge
79+
Edge (Legacy)
Internet Explorer
No
Firefox Android
Safari iOS
Chrome Android
WebView Android
Samsung Internet
Opera Android
Returns the deepest element in the document through which or to which key events are being
routed. This is, roughly speaking, the focused element in the document.
For the purposes of this API, when a
child navigable
is focused, its
container
is
focused
within its
parent
's
active
document
. For example, if the user moves the focus to a text control in an
iframe
, the
iframe
is the element returned by the
activeElement
API in the
iframe
's
node document
Similarly, when the focused element is in a different
node tree
than
documentOrShadowRoot
, the element returned will be the
host
that's located in the same
node
tree
as
documentOrShadowRoot
if
documentOrShadowRoot
is a
shadow-including inclusive ancestor
of the focused element, and null if not.
document
hasFocus
()
Document/hasFocus
Support in all current engines.
Firefox
3+
Safari
4+
Chrome
2+
Opera
Edge
79+
Edge (Legacy)
12+
Internet Explorer
5.5+
Firefox Android
Safari iOS
Chrome Android
WebView Android
37+
Samsung Internet
Opera Android
Returns true if key events are being routed through or to the document; otherwise, returns
false. Roughly speaking, this corresponds to the document, or a document nested inside this one,
being focused.
window
focus
()
Window/focus
Support in all current engines.
Firefox
1+
Safari
1+
Chrome
1+
Opera
12.1+
Edge
79+
Edge (Legacy)
12+
Internet Explorer
4+
Firefox Android
Safari iOS
Chrome Android
18+
WebView Android
Samsung Internet
Opera Android
12.1+
Moves the focus to the window's
navigable
, if any.
element
focus
([ {
preventScroll
: true } ])
HTMLElement/focus
Support in all current engines.
Firefox
1.5+
Safari
3+
Chrome
1+
Opera
8+
Edge
79+
Edge (Legacy)
12+
Internet Explorer
5.5+
Firefox Android
Safari iOS
1+
Chrome Android
WebView Android
Samsung Internet
Opera Android
10.1+
Moves the focus to the element.
If the element is a
navigable container
, moves the focus to its
content
navigable
instead.
By default, this method also scrolls the element into view. Providing the
preventScroll
option and setting it to true
prevents this behavior.
element
blur
()
HTMLElement/blur
Support in all current engines.
Firefox
1.5+
Safari
3+
Chrome
1+
Opera
8+
Edge
79+
Edge (Legacy)
12+
Internet Explorer
5.5+
Firefox Android
Safari iOS
1+
Chrome Android
WebView Android
Samsung Internet
Opera Android
10.1+
Moves the focus to the
viewport
. Use of this method is discouraged; if you want
to focus the
viewport
, call the
focus()
method on
the
Document
's
document element
Do not use this method to hide the focus ring if you find the focus ring unsightly. Instead,
use the
:focus-visible
pseudo-class to override the
'outline'
property, and provide a different way to show what element is focused. Be aware that if an
alternative focusing style isn't made available, the page will be significantly less usable for
people who primarily navigate pages using a keyboard, or those with reduced vision who use focus
outlines to help them navigate the page.
For example, to hide the outline from
textarea
elements and instead use a
yellow background to indicate focus, you could use:
textarea:focus-visible { outline: none; background: yellow; color: black; }
The
activeElement
attribute's getter must
run these steps:
Let
candidate
be the
DOM anchor
of the
focused area
of this
DocumentOrShadowRoot
's
node
document
Set
candidate
to the result of
retargeting
candidate
against this
DocumentOrShadowRoot
If
candidate
's
root
is not this
DocumentOrShadowRoot
then return null.
If
candidate
is not a
Document
object, then return
candidate
If
candidate
has a
body element
, then
return that
body element
If
candidate
's
document element
is non-null, then return that
document element
Return null.
The
hasFocus()
method on the
Document
object, when invoked, must return the result of running the
has focus steps
with the
Document
object as the argument.
The
focus()
method, when
invoked, must run these steps:
Let
current
be this
Window
object's
navigable
If
current
is null, then return.
Run the
focusing steps
with
current
If
current
is a
top-level traversable
, user agents are encouraged
to trigger some sort of notification to indicate to the user that the page is attempting to gain
focus.
Window/blur
Support in all current engines.
Firefox
1+
Safari
1+
Chrome
1+
Opera
12.1+
Edge
79+
Edge (Legacy)
12+
Internet Explorer
4+
Firefox Android
Safari iOS
Chrome Android
WebView Android
Samsung Internet
Opera Android
12.1+
The
blur()
method steps
are to do nothing.
Historically, the
focus()
and
blur()
methods actually affected the system-level focus of the
system widget (e.g., tab or window) that contained the
navigable
, but hostile sites
widely abuse this behavior to the user's detriment.
The
focus(
options
method on elements, when invoked, must run the following steps:
If the element is marked as
locked for focus
, then return.
Mark the element as
locked for focus
Run the
focusing steps
for the element.
If the value of the
focusVisible
dictionary member of
options
is true, or is not present but in an
implementation-defined
way
the user agent determines it would be best to do so, then
indicate focus
If the value of the
preventScroll
dictionary member of
options
is false, then
scroll the element
into view
given "auto", "center", and "center".
Unmark the element as
locked for focus
The
blur()
method, when
invoked, should run the
unfocusing steps
for the element on which the method was
called. 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.
6.6.7
The
autofocus
attribute
The
autofocus
content attribute allows the author to indicate that an element is to be focused as soon as the
page is loaded, allowing the user to just start typing without having to manually focus the main
element.
When the
autofocus
attribute is specified on an element
inside
dialog
elements or
HTML elements
whose
popover
attribute is set, then it will be focused when the dialog or
popover becomes shown.
The
autofocus
attribute is a
boolean
attribute
To find the
nearest ancestor autofocus scoping root element
given an
Element
element
If
element
is a
dialog
element, then return
element
If
element
's
popover
attribute is not in the
no popover state
, then return
element
Let
ancestor
be
element
While
ancestor
has a
parent element
Set
ancestor
to
ancestor
's
parent element
If
ancestor
is a
dialog
element, then return
ancestor
If
ancestor
's
popover
attribute is not in
the
no popover state
, then return
ancestor
Return
ancestor
There must not be two elements with the same
nearest ancestor autofocus scoping root
element
that both have the
autofocus
attribute
specified.
Each
Document
has an
autofocus candidates
list
initially empty.
Each
Document
has an
autofocus processed flag
boolean, initially
false.
When an element with the
autofocus
attribute specified
is
inserted into a document
, run the
following steps:
If the user has indicated (for example, by starting to type in a form control) that they
do not wish focus to be changed, then optionally return.
Let
target
be the element's
node document
If
target
is not
fully active
, then return.
If
target
's
active sandboxing flag set
has the
sandboxed automatic features browsing context flag
, then return.
For each
ancestorNavigable
of
target
's
ancestor navigables
: if
ancestorNavigable
's
active document
's
origin
is not
same origin
with
target
's
origin
, then return.
Let
topDocument
be
target
's
node navigable
's
top-level traversable
's
active
document
If
topDocument
's
autofocus processed flag
is false, then
remove
the element from
topDocument
's
autofocus candidates
, and
append
the element to
topDocument
's
autofocus candidates
We do not check if an element is a
focusable area
before storing it
in the
autofocus candidates
list, because even if it is not a focusable area when it
is inserted, it could become one by the time
flush autofocus candidates
sees it.
To
flush autofocus candidates
for a document
topDocument
, run these
steps:
If
topDocument
's
autofocus processed flag
is true, then
return.
Let
candidates
be
topDocument
's
autofocus
candidates
If
candidates
is empty
, then
return.
If
topDocument
's
focused area
is not
topDocument
itself, or
topDocument
has non-null
target element
, then:
Empty
candidates
Set
topDocument
's
autofocus processed flag
to true.
Return.
While
candidates
is not
empty
Let
element
be
candidates
[0].
Let
doc
be
element
's
node document
If
doc
is not
fully active
, then
remove
element
from
candidates
, and
continue
If
doc
's
node navigable
's
top-level
traversable
is not the same as
topDocument
's
node navigable
then
remove
element
from
candidates
and
continue
If
doc
's
script-blocking style sheet set
is not
empty
, then return.
In this case,
element
is the currently-best candidate, but
doc
is not ready for autofocusing. We'll try again next time
flush
autofocus candidates
is called.
Remove
element
from
candidates
Let
inclusiveAncestorDocuments
be a
list
consisting of the
active document
of
doc
's
inclusive
ancestor navigables
If any
Document
in
inclusiveAncestorDocuments
has non-null
target element
, then
continue
Let
target
be
element
If
target
is not a
focusable area
, then set
target
to
the result of
getting the focusable area
for
target
Autofocus candidates
can
contain
elements which are not
focusable
areas
. In addition to the special cases handled in the
get the focusable
area
algorithm, this can happen because a non-
focusable area
element with
an
autofocus
attribute was
inserted into a document
and it never became focusable, or
because the element was focusable but its status changed while it was stored in
autofocus candidates
If
target
is not null, then:
Empty
candidates
Set
topDocument
's
autofocus processed flag
to true.
Run the
focusing steps
for
target
This handles the automatic focusing during document load. The
show()
and
showModal()
methods of
dialog
elements also processes the
autofocus
attribute.
Focusing the element does not imply that the user agent has to focus the browser
window if it has lost focus.
Global_attributes/autofocus
Support in one engine only.
Firefox
🔰 1+
Safari
🔰 4+
Chrome
79+
Opera
66+
Edge
79+
Edge (Legacy)
No
Internet Explorer
🔰 10+
Firefox Android
Safari iOS
Chrome Android
WebView Android
79+
Samsung Internet
Opera Android
57+
The
autofocus
IDL attribute must
reflect
the
content attribute of the same name.
In the following snippet, the text control would be focused when
the document was loaded.


The
autofocus
attribute applies to all elements, not
just to form controls. This allows examples such as the following: