2046107 - Ship DOM-based EditContext

Status: ASSIGNED

(Core :: DOM: Editor, enhancement, P3)

Description

[Leo Tenenbaum [:ltenenbaum]]

We are planning to ship first just EditContext for non-<canvas> elements, since there are fewer accessibility concerns.

Comment 1

[Leo Tenenbaum [:ltenenbaum]]

Description:
Integrating sophisticated editing features into web applications has historically presented challenges for developers. While the web platform offers basic text and HTML editing through elements like <input>, <textarea>, or the contenteditable attribute, these often fall short of developers' advanced requirements. However, since receiving text input requires a focused editable element, developers are forced to embed a hidden editable element on their page. This creates a disconnect and complexity: users interact with the app's visible custom editor, but input is actually processed by event handlers on the hidden element and then mirrored into the custom view. This indirect approach adds complexity and can lead to conflicts as developers contend with the browser's default editing behaviors in the hidden contenteditable element.
EditContext is an API to address this class of issues. It enables the text input services of the OS (IME support, emoji picking, handwriting recognition panel, etc.) without needing an editable element in the DOM to be focused.
An EditContext can be associated with either a canvas or a non-canvas element. If it is associated with a canvas, rendering the text and managing the selection/caret becomes the responsibility of the web app. We’re still not sure how accessibility will be handled for canvas-based EditContext, so we hope to start by shipping just non-canvas (“DOM-based”) EditContext.

How do we test this?
Flip the preference ‘dom.editcontext.enabled’ to true
Try editing with The MDN EditContext demo, or one of the following sites currently using EditContext (for these, it would be best to compare with EditContext enabled vs disabled):

• Google Docs
• Older versions of CodeMirror such as https://strudel.cc/
• The Monaco code editor. (I’m particularly concerned about this one since they are only using the EditContext for text input while rendering the content elsewhere, and don’t seem to have any special accessibility handling.)

When will this ship? H2 2026
Tracking bug/issue: bug 2046107 (this one)
Design documents (e.g. Product Requirements Document, UI spec): https://w3c.github.io/edit-context/
Engineering lead: Simon Pieters, Leo Tenenbaum
Product manager: Hsin-Yi Tsai (Engineering Manager)

Please describe the accessibility guidelines you considered and what steps you've taken to address them:
We’ve filed accessibility-related spec issues upstream: #136 on improving the explainer's accessibility discussion, and #139 on canvas EditContext, and prototyped a fallback-content approach for canvas EditContext. And we've already had some helpful early discussion with the accessibility team in slack. Based on that discussion, there seems to be a shared sense of concern around the current API design's interaction with assistive technologies, as reflected in the issues tracked above. However, the majority of the accessibility issues are for canvas-based EditContext, and we are hoping that DOM-based EditContext can be made accessible without changes to the spec. What we'd really like to understand is this: what does the current DOM-based implementation need to improve on, accessibility-wise?

Describe any areas of concern to which you want the accessibility team to give special attention:

• Is the caret/selection in an EditContext editor communicated correctly to assistive technologies?
• Do content updates applied in an EditContext editor appear in the accessibility tree with the right notifications?
• Is IME composition state conveyed in a comparable way to contenteditable?
• Are there any other gaps or regressions versus contenteditable that we should fix before shipping?