To the extent possible under law, the editors have waived all copyright
and related or neighboring rights to this work.
In addition, as of 23 September 2016,
the editors have made this specification available under the Open Web Foundation Agreement Version 1.0,
which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0.
Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.
Abstract
This specification describes an extension to the :focus pseudoclass that allows developers to change focus behavior based on the input modality of the user interaction that led to the focus occurring.
1. Introduction
Focus rings highlight the current focus location. Particularly during keyboard
interactions, focus rings provide important feedback to the user by showing the
current interaction point. This is particularly important for accessibility use
cases where non-keyboard interactions are unavailable.
User agents employ a set of heuristics to decide when to show a focus ring.
For example, typically, selecting an element via the keyboard results in a
focus ring being displayed, while selecting an element via a mouse interaction
does not.
Unfortunately, focus rings are not easily stylable. While the :focus pseudo-class
has been available for some time, this matches every focussed element rather than
just those which the user agent chooses to highlight.
This specification introduces a new pseudo-class, :focusring, that matches an
element only when the user agent would choose to show a focus ring for that
element.
To change the focus ring style to a dotted red outline, without changing the
behavior of when a ring is shown:
The focusring pseudo-class, :focusring,
is a dynamic user action pseudo-class.
For native interaction elements, :focusring applies when the user agent would
choose to display a focusring in the absence of UA or author stylesheets.
For other elements, :focusring applies according to a heuristic that may
match the behavior of the UA for native button elements. An example heuristic
is included non-normatively in the appendix.
For example, most UAs choose to display focusrings on native text fields
whenever they are focussed, and on native buttons only when selected via
the keyboard.
Authors who build non-native interactive elements that are text-field like
in nature should consider adding a :focus rule to that element to
ensure a focusring is displayed whenever focussed, rather than only wen
the heuristic matches.
Appendix A: Example Heuristic for non-native elements
This appendix is non-normative.
A user agent might choose to use the following heuristic for deciding when
to apply :focusring to elements that are not native interaction elements:
When focussing an element:
if the last interaction was a keyboard event, and the interaction
was less than 100ms in the past, apply :focusring.
if a non-native element is focussed, apply :focusring to that element.
Conformance
Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
in the normative parts of this document
are to be interpreted as described in RFC 2119.
However, for readability,
these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative
except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples in this specification are introduced with the words “for example”
or are set apart from the normative text with class="example", like this:
This is an example of an informative example.
Informative notes begin with the word “Note”
and are set apart from the normative text with class="note", like this: