Spellcheck suggestions interfere with contenteditable editing
OS: macOS 14.0 · Device: Desktop or Laptop MacBook Pro · Browser: Safari 17.0 · Keyboard: US
Open case →Scenario
Native spellcheck interfering with editing
Browser spellcheck underlines and may mutate DOM or fire input-adjacent updates—conflicting with custom dictionaries, code blocks, and IME composition.
accessibility
Scenario ID
scenario-spellcheck-interference
Details
Browser spellcheck underlines and may mutate DOM or fire input-adjacent updates—conflicting with custom dictionaries, code blocks, and IME composition.
Related Cases
References
- MDN:
spellcheck
Scenario flow
Visual view of how this scenario connects to its concrete cases and environments. Nodes can be dragged and clicked.
Variants
Each row is a concrete case for this scenario, with a dedicated document and playground.
| Case | OS | Device | Browser | Keyboard | Status |
|---|---|---|---|---|---|
| ce-0068-contenteditable-with-spellcheck | macOS 14.0 | Desktop or Laptop MacBook Pro | Safari 17.0 | US | draft |
Cases
Open a case to see the detailed description and its dedicated playground.
Related Scenarios
Other scenarios that share similar tags or category.
Tags: spellcheck
Accessibility Foundations: Screen Readers, ARIA, and the AX-Tree
Ensuring contenteditable editors are navigable for assistive technology users through proper ARIA mapping and engine synchronization.
5 cases
Tags: contenteditable
role="textbox" and screen reader behavior with contenteditable
Assistive technologies map contenteditable to textbox-like semantics when authors use role=textbox or aria-multiline—conflicts with actual HTML semantics and browser AX trees can confuse announcements.
1 case
Tags: contenteditable
Browser extensions interfering with contenteditable (Grammarly and others)
Extensions inject overlays, mutate DOM, or listen to input for grammar and translation—breaking framework-controlled editors, selection restoration, and IME composition boundaries.
1 case
Category: accessibility
Keyboard navigation accessibility issues in contenteditable
Keyboard navigation in contenteditable elements must comply with WCAG 2.1.1 (Keyboard) and 2.1.2 (No Keyboard Trap) requirements. The Tab key typically moves focus out of contenteditable, while arrow keys move the caret. Custom keyboard handling must ensure all functionality is keyboard-operable and focus remains visible.
0 cases
Category: accessibility
Voice and speech-driven input in contenteditable lacks a stable editing contract
OS voice typing, Web Speech API, and assistive voice tools insert or mutate contenteditable without the same event sequence as keyboard or IME. Caret position, selection, and composition events are inconsistent across platforms, which breaks editors that assume beforeinput/input/composition alignment.
1 case
Comments & Discussion
Have questions, suggestions, or want to share your experience? Join the discussion below.