WICG / modality

Experimenting with being explicit about user modality
Other
36 stars 26 forks source link

Deprecated: Please look at https://github.com/wicg/focus-ring/ instead.

Archived content below.


Based on a conversation between Alice Boxhall, Brian Kardell and Marcy Sutton, this prototype attaches/manages metadata in the form of a modality attribute to the body, as a way to allow authors to experiment with adapting style based on the user's active input modality (i.e., how they are interacting with the UI right now).

Demo

Rationale

There are many instances in which it would be useful for authors to understand the user's current interaction modality and be able to adapt the UI with better accomodations. The motivating example is :focus where the status quo is quite problematic:

To deal with this:

API Proposal

/* override UA stylesheet if necessary */
:focus {
  outline: none;
}

/* establish desired focus ring appearance for appropriate input modalities */
:focusring {
  outline: 2px solid blue;
}

:focusring matches native elements that are

  1. focussed; and
  2. would display a focus ring if only UA styles applied

Additionally, :focusring matches non-native elements as if they were native button elements.

Example heuristic

The heuristic used to decide the current modality should not be defined normatively. An example heuristic is to update modality on each style recalc: if the most recent user interaction was via the keyboard; and less than 100ms has elapsed since the last input event; then the modality is keyboard. Otherwise, the modality is not keyboard.

Implementation Prototype

The tiny keyboard-modality.js provides a prototype intended to achieve the goals we are proposing with technology that exists today in order for developers to be able to try it out, understand it and provide feedback. Simply speaking, it sets a modality=keyboard attribute on body if the script determines that the keyboard is being used. Similarly, the attribute is removed if the script determines that the user is no longer using the keyboard. This allows authors to write rules which consider the input modality and style appropriately. Note that the prototype does not match the proposed API - it is intended to give developers a feel for the model rather than to provide a high-fidelity polyfill.

It also simulates how the default UA styles would be adjusted by appending the following style as the first rule in the page, which disables the focus ring unless modality is set to keyboard:

body:not([modality=keyboard]) :focus {
    outline: none;
}

(This is added in a <style> element with the ID "disable-focus-ring", to allow easy removal if different behaviour is desired.)

How it works

The script uses two heuristics to determine whether the keyboard is being used:

Custom elements may use the supports-modality attribute to provide a whitelist of supported modalities; any element without this whitelist is considered to support all modalities. Only elements which only support keyboard modality will trigger the modality=keyboard attribute on <body>.