[draft] Web Applications Working Group Charter

The mission of the Web Applications Working Group (WebApps WG) is to produce specifications that facilitate the development of client-side web applications.

Join the WebApps Working Group

Charter Status See the group status page and detailed change history.
Start date [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved)
End date [dd monthname yyyy] (Start date + 2 years)
Chairs Léonie Watson (TetraLogical), Marcos Cáceres (Apple), Diego González (Microsoft), Marijn Kruisselbrink (Google)
Team Contact Xiaoqian Wu (0.25 FTE), Michael[tm] Smith (0.1 FTE)
Meeting Schedule Teleconferences: topic-specific calls will be held when needed.
Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year.

Motivation and Background

Specifications produced by the WebApps Working Group enable developers to create web applications that work across a wide range of platforms and devices, and for a broad diversity of users, by addressing matters of accessibility, device independence, internationalization, privacy, and security.

Scope

The scope of the WebApps Working Group is:

The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or a similar incubation phase. If the Working Group decides to add new Recommendation-track deliverables then it will recharter with changes to change its deliverables.

Deliverables

Updated document status is available on the group publication status page.

Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.

Normative Specifications

The WebApps Working Group will deliver the following normative specifications. More information about these specifications can be found in the detailed list of Deliverables.

Specification Description
File API This specification provides an API for representing file objects in web applications, as well as programmatically selecting them and accessing their data.
Gamepad Defines a low-level interface that represents gamepad devices.
Image resource This document defines the concept of an "image resource" and a corresponding WebIDL ImageResource dictionary. Web APIs can use the ImageResource dictionary to represent an image resource in contexts where an HTMLImageElement is not suitable or available (e.g., in a Worker).
Indexed Database API 3.0 This document defines APIs for a database of records holding simple values and hierarchical objects. Each record consists of a key and some value. Moreover, the database maintains indexes over records it stores. An application developer directly uses an API to locate records either by their key or by using an index. A query language can be layered on this API. An indexed database can be implemented using a persistent B-tree data structure.
Service Workers The core of this specification is a worker that wakes to receive events. This provides an event destination that can be used when other destinations would be inappropriate, or no other destination exists.
Pointer Lock 2.0 This specification defines an API that provides scripted access to raw mouse movement data while locking the target of mouse events to a single element and removing the cursor from view. This is an essential input mode for certain classes of applications, especially first person perspective 3D applications and 3D modeling software.
Push API An API that provides Web applications with scripted access to server-sent application data.
Screen Orientation Defines APIs to read screen orientation state and to lock the screen orientation to a specific state.
Web Application Manifest This specification defines a manifest, which provides developers with a centralized place to put metadata about a web application.
Web Share API This specification defines an API for sharing text, links and other content to an arbitrary destination of the user's choice.
UI Events This specification defines the Document Object Model Events Level 3, a generic platform- and language-neutral event system which allows registration of event handlers, describes event flow through a tree structure, and provides basic contextual information for each event. The Document Object Model Events Level 3 builds on the Document Object Model Events Level 2 [DOM2 Events].
UI Events KeyboardEvent code values This specification defines the values for the KeyboardEvent.code attribute, which is defined as part of the UI Events Specification. The code value contains information about the key event that can be used to identify the physical key being pressed by the user.
UI Events KeyboardEvent key Values This specification defines the key attribute values that must be used for KeyboardEvent's key attribute, which is defined as part of the UI Events Specification.
Web Locks API This document defines a web platform API that allows script to asynchronously acquire a lock over a resource, hold it while work is performed, then release it. While held, no other script in the origin can acquire a lock over the same resource. This allows contexts (windows, workers) within a web application to coordinate the usage of resources.
Badging API This specification defines an API that allows installed web applications to set an application badge, which is usually shown alongside the application's icon on the device's home screen or application dock.
Contact Picker API An API to give one-off access to a user’s contact information with full control over the shared data. It's a joint deliverable with the Devices and Sensors Working Group
Screen Wake Lock API This document specifies an API that allows web applications to request a screen wake lock. Under the right conditions, and if allowed, the screen wake lock prevents the system from turning off a device's screen. It's a joint deliverable with the Devices and Sensors Working Group.
Device Orientation and Motion This specification defines several new DOM event types that provide information about the physical orientation and motion of a hosting device. It's a joint deliverable with the Devices and Sensors Working Group.
Geolocation The Geolocation API provides access to geographical location information associated with the hosting device. It's a joint deliverable with the Devices and Sensors Working Group.

WICG specifications

Depending on the WICG progress, including interest from multiple implementers, the Group may also produce W3C Recommendation-track documents for the following documents:

Specification Description
File and Directory Entries API This specification documents web browser support for file and directory upload by drag-and-drop operations. It introduces types representing directories with methods for asynchronous traversal, and extends HTMLInputElement and DataTransferItem.
Web Share Target An API that allows websites to declare themselves as web share targets, which can receive shared content from either the Web Share API, or system events (e.g., shares from native apps).
Haptics An API allowing web applications to interface with haptic actuators, such as vibration motors found on gamepad controllers, and potentially other devices that provide haptic feedback.
User-Agent Client Hints This document defines a set of Client Hints that aim to provide developers with the ability to perform agent-based content negotiation when necessary, while avoiding the historical baggage and passive fingerprinting surface exposed by the venerable User-Agent HTTP header.
Background Fetch An API to handle large uploads/downloads in the background with user visibility.

Other Deliverables

Other non-normative documents may be created such as, use case and requirements documents, implementation reports, and Best Practices documents, to support web developers when designing applications.

Timeline

All specifications produced by the WebApps Working Group are expected to progress during this charter period. The charter does not include a detailed timeline for each specification because such information is speculative and easily becomes inaccurate. However, a rough estimation of completion is available in the detailed list of Deliverables when possible.

The Working Group home page will link to a more comprehensive page with detailed status and estimated completion time for each specification.

Note that the WICG Specifications, if adopted, have an estimated time of completion of 2 years.

Success Criteria

In order to advance beyond Candidate Recommendation, each normative specification is expected to have at least two independent interoperable implementations of every feature defined in the specification, where interoperability can be verified by passing open test suites, and two or more implementations interoperating with each other. In order to advance beyond Candidate Recommendation, each normative specification must have an open test suite of every feature defined in the specification.

There should be testing plans for each specification, starting from the earliest drafts.

Each specification must have an accompanying test suite, which is ideally developed in parallel to the specification. The test suite will be used to produce an implementation report before the specification advances beyond Candidate Recommendation.

Each specification should contain separate sections detailing all known security and privacy implications for implementers, Web authors, and end users.

Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximising accessibility in implementations.

This group is expected to be guided by the following documents:

All new features should have expressions of interest from at least two potential implementors before being incorporated in the specification.

Coordination

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review.

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

W3C Groups

The work of the WebApps Working Group touches on the work of many other W3C Working and Interest Groups. Where appropriate, the WebApps Working Group will coordinate with the relevant Working or Interest Groups, per the W3C Process.

Devices and Sensors Working Group
The Web Application Working Group will coordinate with the Devices and Sensors Working Group regarding the Contact Picker API, the Screen Wake Lock API, the Device Orientation and Motion and the Geolocation.

External Organizations

The WebApps Working Group may also coordinate with the following organizations:

ECMA TC39
For co-ordination on topics relating to JavaScript.
Internet Engineering Task Force (IETF)
For co-ordination on topics relating to internet protocols.
Web Hypertext Application Technology Working Group (WHATWG)
For co-ordination on topics relating to the web platform.

Participation

To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group. There is no minimum requirement for other Participants.

The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication. The group also welcomes non-Members to make technical contributions for ongoing work, provided they agree to the terms of the W3C Patent Policy.

The Chairs should periodically look through the non-Members who have contributed to the Working Group or the Web Platform Incubator Community Group and consider whether each one should be invited to participate as an Invited Expert. If a non-Member contributor would like to participate in meetings, they are encouraged to apply to be an Invited Expert.

Participants in the group are required (by the W3C Process) to follow the W3C Code of Conduct.

Working mode

The Chairs and Editors will assess support from web platform implementers or web application or framework developers to ensure that substantial changes are supported by more than a single member before adoption.

Moreover, at least two web platform implementers must support a substantive change before it can be made to a specification. This is enforced by a pull request template on GitHub, which Editors must fill out as a public record before a substantive contribution can be merged. The template will require implementers to give public support for a change/fix/feature and, where possible, provide a link to a public bug tracker for an implementation.

Communication

Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.

Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Web Applications Working Group home page.

Most Web Applications Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.

This group primarily conducts its technical work on the public mailing list public-webapps@w3.org (archive), and on GitHub issues. The public is invited to review, discuss and contribute to this work.

The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.

Decision Policy

This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs.

This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote) and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (Version of 15 May 2025). To promote the widest adoption of Web standards, W3C seeks to issue Web specifications that can be implemented, according to this policy, on a Royalty-Free basis. For more information about disclosure obligations for this group, please see the licensing information.

Licensing

This Working Group will use the W3C Software and Document license for all its deliverables.

About this Charter

This charter has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Charter History

Note:Display this table and update it when appropriate. Requirements for charter extension history are documented in the Charter Guidebook (section 4).

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 4.3, Advisory Committee Review of a Charter):

Charter Period Start Date End Date Changes
Initial Charter 14 May 2019 31 May 2021 none
Rechartered 15 December 2020 31 May 2021 New Patent Policy
Charter Extension 1 June 2021 30 April 2022 none
Rechartered 14 April 2022 14 April 2024
  • Stopped Working on the HTML Accessibility API Mappings (AAM) spec;
  • Remove Clipboard API and Events, ContentEditable, Selection API, and Input Events from the Deliverables.
  • Add WebIDL to the charter as a possible Deliverable.
Rechartered 21 February 2024 28 February 2026
  • Add the Screen Wake Lock API, the DeviceOrientation Event Specification, the Geolocation API as joint deliverables with the W3C Devices and Sensors Working Group.
  • Drop the WebIDL spec.
  • The ARIA in HTML spec has been moved to the ARIA Working Group.
Rechartered [dd monthname yyyy] [dd monthname yyyy]
  • The Intersection Observer specification has been moved to the CSS Working Group.
  • Add Service Workers to the charter as a Deliverable.
  • The File and Directory Entries API specification and the Background Fetch specification have been added to the list of WICG specifications as potential group deliverables, while the Cookie Store specification has been removed.

Change log

Changes to this document are documented in this section.

History of this WG

The WebApps Working Group was a predecessor to the Web Platform Working Group (which remains active to work on specifications that are pertinent to the discussions relating to a collaboration agreement between the W3C and the WHATWG). The remaining specifications have been transferred from the Web Platform Working Group to the WebApps Working Group, so that progress can continue to be made on those specifications while the W3C and WHATWG negotiations are ongoing.

In addition, specifications that have been successfully incubated in the Web Platform Incubator Community Group (WICG) have been transferred to the WebApps Working Group.

Detailed list of Deliverables

The following is the list of non-retired specifications produced by the Web Applications Working Group under the W3C Patent Policy.

Web Locks API

This document defines a web platform API that allows script to asynchronously acquire a lock over a resource, hold it while work is performed, then release it. While held, no other script in the origin can acquire a lock over the same resource. This allows contexts (windows, workers) within a web application to coordinate the usage of resources.

Draft state: Working Draft

Expected completion: CR - Q2 2026; REC - Q4 2026

Adopted Draft: Web Locks API, https://www.w3.org/TR/2023/WD-web-locks-20230105/, 5 January 2023

Exclusion Draft: Web Locks API, https://www.w3.org/TR/2023/WD-web-locks-20230105/, 5 January 2023, Exclusion Draft began on 05 Jan 2023; ended on 04 June 2023.

Exclusion Draft Charter: https://www.w3.org/2022/04/webapps-wg-charter.html

Contact Picker API

An API to give one-off access to a user’s contact information with full control over the shared data.

Draft state: Working Draft

Expected completion: CR - Q4 2026

Adopted Draft: Contact Picker API9, https://www.w3.org/TR/2024/WD-contact-picker-20240708/, 08 July 2024

Exclusion Draft: Contact Picker API, https://www.w3.org/TR/2022/WD-contact-picker-1-20221220/, 20 December 2022, Exclusion Draft began on 20 Dec 2022; ended on 19 May 2023.

Exclusion Draft Charter: https://www.w3.org/2022/04/webapps-wg-charter.html

Badging API

This specification defines an API that allows installed web applications to set an application badge, which is usually shown alongside the application's icon on the device's home screen or application dock.

Draft state: Working Draft

Expected completion: CR - Q2 2026; REC - Q4 2026

Adopted Draft: Badging API, https://www.w3.org/TR/2023/WD-badging-20230503/, 03 May 2023

Exclusion Draft: Badging API, https://www.w3.org/TR/2023/WD-badging-20230406/, 06 April 2023, Exclusion Draft began on 06 Apr 2023; ended on 03 September 2023.

Exclusion Draft Charter: https://www.w3.org/2022/04/webapps-wg-charter.html

File API

This specification provides an API for representing file objects in web applications, as well as programmatically selecting them and accessing their data.

Draft state: Working Draft

Expected completion: CR - Q2 2026; REC - Q3 2026

Adopted Draft: File API, https://www.w3.org/TR/2024/WD-FileAPI-20241204/, 04 December 2024

Exclusion Draft: File API, https://www.w3.org/TR/2013/WD-FileAPI-20130912/, 12 September 2013, Exclusion Draft began on 13 Sep 2013; ended on 11 November 2013.

Exclusion Draft Charter: https://www.w3.org/2012/webapps/charter/

Gamepad

Defines a low-level interface that represents gamepad devices.

Draft state: Working Draft

Expected completion: CR - Q1 2026; REC - Q2 2026

Adopted Draft: Gamepad, https://www.w3.org/TR/2025/WD-gamepad-20250710/, 10 July 2025

Exclusion Draft: Gamepad, https://www.w3.org/TR/2012/WD-gamepad-20120529/, 29 May 2012, Exclusion Draft began on 29 May 2012; ended on 26 October 2012.

Exclusion Draft Charter: https://www.w3.org/2012/webapps/charter/

Image Resource

This document defines the concept of an "image resource" and a corresponding WebIDL ImageResource dictionary. Web APIs can use the ImageResource dictionary to represent an image resource in contexts where an HTMLImageElement is not suitable or available (e.g., in a Worker).

Draft state: Working Draft

Expected completion: CR - Q2 2026; REC - Q3 2026

Adopted Draft: Image Resource, https://www.w3.org/TR/2021/WD-image-resource-20210604/, 04 June 2021

Exclusion Draft: Image Resource, https://www.w3.org/TR/2020/WD-image-resource-20200507/, 07 May 2020, Exclusion Draft began on 07 May 2020; ended on 04 October 2020.

Exclusion Draft Charter: https://www.w3.org/2019/05/webapps-charter.html

Indexed Database API 3.0

This document defines APIs for a database of records holding simple values and hierarchical objects. Each record consists of a key and some value. Moreover, the database maintains indexes over records it stores. An application developer directly uses an API to locate records either by their key or by using an index. A query language can be layered on this API. An indexed database can be implemented using a persistent B-tree data structure.

Draft state: Working Draft

Expected completion: CR - Q2 2026; REC - Q4 2026

Adopted Draft: Indexed Database API 3.0, hhttps://www.w3.org/TR/2025/WD-IndexedDB-3-20250703/, 03 July 2025

Exclusion Draft: Indexed Database API 3.0, https://www.w3.org/TR/2021/WD-IndexedDB-3-20210311/, 11 March 2021, Exclusion Draft began on 11 Mar 2021; ended on 08 August 2021.

Exclusion Draft Charter: https://www.w3.org/2020/12/webapps-wg-charter.html

Service Workers

The core of this specification is a worker that wakes to receive events. This provides an event destination that can be used when other destinations would be inappropriate, or no other destination exists.

Draft state: Candidate Recommendation Draft

Expected completion: CRS - Q1 2026

Adopted Draft: Service Workers, https://www.w3.org/TR/2025/CRD-service-workers-20250306/, 2025-03-06

Exclusion Draft: Service Workers, https://www.w3.org/TR/2019/CR-service-workers-1-20191119/, 2019-11-19, Exclusion Draft began on 2019-11-19 and ended on 2020-01-18.

Exclusion Draft Charter: https://www.w3.org/2017/08/sw-charter.html

Pointer Lock 2.0

This specification defines an API that provides scripted access to raw mouse movement data while locking the target of mouse events to a single element and removing the cursor from view. This is an essential input mode for certain classes of applications, especially first person perspective 3D applications and 3D modeling software.

Draft state: Working Draft

Expected completion: CR - Q3 2026; REC - Q4 2026

Adopted Draft: Pointer Lock 2.0, https://www.w3.org/TR/2024/WD-pointerlock-2-20240617/, 17 June 2024

Exclusion Draft: Pointer Lock 2.0, https://www.w3.org/TR/2016/WD-pointerlock-2-20161122/, 22 November 2016, Exclusion Draft began on 22 Nov 2016; ended on 21 April 2017.

Exclusion Draft Charter: https://www.w3.org/2016/11/webplatform-charter.html

Push API

An API that provides Web applications with scripted access to server-sent application data.

Draft state: Working Draft

Expected completion: CR - Q2 2026; REC - Q4 2026

Adopted Draft: Push API, https://www.w3.org/TR/2024/WD-push-api-20240903/, 03 September 2024

Exclusion Draft: Push API, https://www.w3.org/TR/2012/WD-push-api-20121018/, 18 October 2012, Exclusion Draft began on 18 Oct 2012; ended on 17 March 2013.

Exclusion Draft Charter: https://www.w3.org/2012/webapps/charter/

Screen Orientation

Defines APIs to read screen orientation state and to lock the screen orientation to a specific state.

Draft state: Working Draft

Expected completion: REC - Q4 2026

Adopted Draft: Screen Orientation, https://www.w3.org/TR/2023/WD-screen-orientation-20230809/, 09 August 2023

Exclusion Draft: The Screen Orientation API, https://www.w3.org/TR/2012/WD-screen-orientation-20120522/, 22 May 2012, Exclusion Draft began on 22 May 2012; ended on 19 October 2012.

Exclusion Draft Charter: https://www.w3.org/2012/webapps/charter/

Web Application Manifest

This specification defines a manifest, which provides developers with a centralized place to put metadata about a web application.

Draft state: Working Draft

Expected completion: CR - Q1 2026; REC - Q3 2026

Adopted Draft: Web Application Manifest, https://www.w3.org/TR/2025/WD-appmanifest-20250505/, 05 May 2025

Exclusion Draft: Manifest for web apps and bookmarks, https://www.w3.org/TR/2013/WD-appmanifest-20131217/, 17 December 2013, Exclusion Draft began on 17 Dec 2013; ended on 16 May 2014.

Exclusion Draft Charter: https://www.w3.org/2012/webapps/charter/

UI Events

This specification defines the Document Object Model Events Level 3, a generic platform- and language-neutral event system which allows registration of event handlers, describes event flow through a tree structure, and provides basic contextual information for each event. The Document Object Model Events Level 3 builds on the Document Object Model Events Level 2 [DOM2 Events].

Draft state: Working Draft

Expected completion: CR - Q4 2026

Adopted Draft: UI Events, https://www.w3.org/TR/2024/WD-uievents-20240907/, 07 September 2024

Exclusion Draft: Document Object Model (DOM) Level 3 Events Specification, https://www.w3.org/TR/2012/WD-DOM-Level-3-Events-20120906/, 06 September 2012, Exclusion Draft began on 6 Sep 2012; ended on 5 November 2012.

Exclusion Draft Charter: https://www.w3.org/2012/webapps/charter/

UI Events KeyboardEvent code Values

This specification defines the values for the KeyboardEvent.code attribute, which is defined as part of the UI Events Specification. The code value contains information about the key event that can be used to identify the physical key being pressed by the user.

Draft state: W3C Recommendation

Adopted Draft: UI Events KeyboardEvent code Values, https://www.w3.org/TR/2025/REC-uievents-code-20250422/, 22 April 2025

Exclusion Draft: UI Events KeyboardEvent code Values, https://www.w3.org/TR/2023/CR-uievents-code-20230530/, 30 May 2023, Exclusion Draft began on 30 May 2023; will end on 29 July 2023.

Exclusion Draft Charter: https://www.w3.org/2022/04/webapps-wg-charter.html

UI Events KeyboardEvent key Values

This specification defines the key attribute values that must be used for KeyboardEvent's key attribute, which is defined as part of the UI Events Specification.

Draft state: W3C Recommendation

Adopted Draft: UI Events KeyboardEvent key Values, https://www.w3.org/TR/2025/REC-uievents-key-20250422/, 22 April 2025

Exclusion Draft: UI Events KeyboardEvent key Values, https://www.w3.org/TR/2023/CR-uievents-key-20230530/, 30 May 2023, Exclusion Draft began on 30 May 2023; will end on 29 July 2023.

Exclusion Draft Charter: https://www.w3.org/2022/04/webapps-wg-charter.html

Web Share API

This specification defines an API for sharing text, links and other content to an arbitrary destination of the user's choice.

The available share targets are not specified here; they are provided by the user agent. They could, for example, be apps, websites or contacts.

Draft state: W3C Recommendation

Adopted Draft: Web Share API, https://www.w3.org/TR/2023/REC-web-share-20230530/, 30 May 2023

Exclusion Draft: Web Share API, https://www.w3.org/TR/2022/CR-web-share-20220830/, 30 August 2022, Exclusion Draft began on 30 Aug 2022; ended on 29 October 2022.

Exclusion Draft Charter: https://www.w3.org/2022/04/webapps-wg-charter.html

Screen Wake Lock API

This document specifies an API that allows web applications to request a screen wake lock. Under the right conditions, and if allowed, the screen wake lock prevents the system from turning off a device's screen.

Draft state: Working Draft

Expected completion: REC - Q4 2026

Adopted Draft: Screen Wake Lock API, https://www.w3.org/TR/2024/WD-screen-wake-lock-20241024/, 24 October 2024

Exclusion Draft: Wake Lock API, https://www.w3.org/TR/2017/CR-wake-lock-20171214/, 14 December 2017, Exclusion Draft began on 14 Dec 2017; ended on 12 February 2018.

Exclusion Draft Charter: https://www.w3.org/2016/03/device-sensors-wg-charter.html

Device Orientation and Motion

This specification defines several new DOM event types that provide information about the physical orientation and motion of a hosting device.

Draft state: Candidate Recommendation Draft

Expected completion: REC - Q4 2026

Adopted Draft: Device Orientation and Motion, https://www.w3.org/TR/2025/CRD-orientation-event-20250212/, 12 February 2025

Exclusion Draft: Device Orientation and Motion, https://www.w3.org/TR/2024/CR-orientation-event-20241121/, 21 November 2024, Exclusion Draft began on 2024-11-21 and ended on 2025-01-20.

Exclusion Draft Charter: https://www.w3.org/2024/01/webappswg-charter-2024.html

Geolocation

The Geolocation API provides access to geographical location information associated with the hosting device.

Draft state: W3C Recommendation

Adopted Draft: Geolocation API, https://www.w3.org/TR/2025/REC-geolocation-20250711/, 11 July 2025

Exclusion Draft: Geolocation API, https://www.w3.org/TR/2022/CR-geolocation-20220217/, 17 February 2022, Exclusion Draft began on 17 Feb 2022; ended on 18 April 2022.

Exclusion Draft Charter: https://www.w3.org/2020/11/das-wg-charter.html

Notes

List of Notes produced by the Web Applications Working Group.