Contenteditable not recognized as editable by screen readers without ARIA
OS: Any Any · Device: Desktop or Laptop Any · Browser: Chrome Latest · Keyboard: US
Open case →Scenario
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.
accessibility
Scenario ID
scenario-accessibility-screen-reader-role-textbox
Details
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.
Related Cases
References
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-0323-accessibility-screen-reader-role-textbox | Any Any | Desktop or Laptop Any | Chrome Latest | 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: aria, screen-reader
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
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
Tags: contenteditable
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.
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.