Jump to Table of Contents Pop Out Sidebar

Input Modality

Editor’s Draft,

This version:
http://github.com/WICG/modality/modality.html
Issue Tracking:
GitHub
Editor:
(Google)

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:

:focusring {
  outline: 1px dotted red;
}

2. The :focusring pseudo-class

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:

When unfocussing an element:

When handling a keyboard event:

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:

Note, this is an informative note.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

Informative References

[SELECTORS-4]
Selectors Level 4 URL: https://drafts.csswg.org/selectors-4/