Well-deployed technologies

An increasing share of mobile devices relies on touch-based interactions. While the traditional interactions recognized in the Web platform (keyboard, mouse input) can still be applied in this context, a more specific handling of touch-based input is a critical aspect of creating well-adapted user experiences, which Touch Events in the DOM (Document Object Model) enable.

The Vibration API lets mobile developers take advantage of haptic feedback to create new form of interactions (e.g. in games).

Mobile devices follow their users everywhere, and many mobile users rely on them to remind them or notify them of events, such as messages: the Web Notifications specification enables that feature in the Web environment.

The hardware constraints of mobile devices, and their different usage context can make mobile users experience similar barriers to people with disabilities. These similarities in barriers mean that similar solutions can be used to cater for them, making a Web site accessible both for people with disabilities and mobile devices a natural goal (as detailed in Relationship between Mobile Web Best Practices and WCAG).

The WCAG and UAWG Working Group provide guidance on mobile accessibility in how Web Content Accessibility Guidelines (WCAG) and other WAI guidelines apply to mobile — that is, making websites and applications more accessible to people with disabilities when they are using mobile phones and a broad range of other devices.

WAI-ARIA provides semantic information on widgets, structures and behaviors hooks to make Web applications more accessible, including on mobile devices.

Technologies in progress

The Pointer Events Working Group has made good progress on an alternative approach to handle user input, Pointer Events, that allows to handle mouse, touch and pen events under a single model. It provides a complementary and more unified approach to the currently more widely deployed Touch Events.

In particular, the CSS property touch-action that lets filter gesture events on elements is gaining traction beyond implementations of Pointer Events.

The early proposal for an Input Device capabilities API would provide information about a given “mouse” event comes from a touch-capable device.

As more and more content gets rendered as long scrollable lists, more and more logic is attached to scrolling events, and the quality of the user experience of these actions is highly dependent on their performances. The CSSOM View Module determines when scrolling events get fired, and let developers specify the type of scrolling behavior they want.

The proposed work on CSS Scroll Snap Points adds greater ability to control the behavior of panning and scrolling by defining points to which an app view would snap when the user moves through the page.

The CSS will-change property is also available to indicate to browsers that a given part of the page will be soon scrolled to and should be pre-rendered.

The Push API makes it possible for server-side notifications to alert the user, even if the browser is not running.

Whether users are speaking commands to their apps or working with them through non-haptic interactions, they risk seeing the screens turned off automatically by their devices screensaver. An early proposal for a Wake Lock API would let developers signal the needs to keep the screen up in these circumstances.

FeatureSpecificationMaturityCurrent implementations
Touch-based interactionsPointer Events - Level 2WD

In development
indevelopment in firefox

shipped in chromeshipped in edge

touch-action in Pointer Events - Level 2WD

shipped in firefoxshipped in chromeshipped in edge

Input Device CapabilitiesED


Smooth scrollingCSSOM View ModuleWD


CSS Scroll Snap Module Level 1CR

shipped in firefoxshipped in edgeshipped in safari

CSS Will Change Module Level 1CR

Under consideration
consideration in edge

shipped in firefoxshipped in chromeshipped in safari

NotificationPush APIWD

In development
indevelopment in edge

shipped in firefoxshipped in chrome

Screen wakeWake Lock APICR


Exploratory work

Mobile devices, and mobile phones in particular, are also in many cases well-suited to be used through voice-interactions; the Speech API Community Group developed a JavaScript API to enable interactions with a Web page through spoken commands. Speech synthesis is well supported across browsers. Support for speech recognition is still underway.

The Input Method Editor (IME) API provides Web applications with scripted access to an IME (input-method editor) associated with a hosting user agent. Editorial support is required for this specification to move forward.

FeatureSpecificationGroupImplementation intents
Speech-based interactionsSpeech synthesis in Web Speech APISpeech API Community Group

shipped in firefoxshipped in chromeshipped in edgeshipped in safari

Speech recognition in Web Speech APISpeech API Community Group

Under consideration
consideration in edge

experimental in firefox

shipped in chrome

Input methodInput Method Editor APIWeb Platform Working Group

shipped in edge

Discontinued features

Intent-based events
As the Web reaches new devices, and as devices gain new user interactions mechanisms, it seems useful to allow Web developers to react to a more abstract set of user interactions: instead of having to work in terms of “click”, “key press”, or “touch event”, being able to react to an “undo” command, or a “next page” command independently of how the user instructed it to the device. The IndieUI Events specification was an attempt to address this need. The work has been discontinued for now, due to lack of support from would-be implementers.