Phenomenon
By default, elements with contenteditable="true" are not automatically recognized as editable text fields by assistive technologies like screen readers. Without proper ARIA attributes, screen reader users may not understand that the element is editable or how to interact with it.
Reproduction example
- Create a contenteditable div without ARIA attributes.
- Test with a screen reader (NVDA, JAWS, VoiceOver).
- Observe that screen reader may not announce it as editable.
- Add
role="textbox"and other ARIA attributes. - Test again to see improved announcements.
Observed behavior
- Not announced as editable: Screen readers may not identify contenteditable as input field.
- No label: Without
aria-labeloraria-labelledby, purpose is unclear. - Keyboard navigation: May not be properly focusable without
tabindex. - Multiline not indicated: Screen readers may not know it supports multiple lines.
- Read-only state: Cannot indicate read-only state without
aria-readonly.
Expected behavior
- Screen readers should announce contenteditable as an editable text field.
- Element should be properly focusable via keyboard.
- Purpose and capabilities should be clearly communicated.
- Multiline support should be indicated when applicable.
Analysis
Contenteditable is a generic HTML attribute that doesn’t carry semantic meaning for assistive technologies. ARIA attributes are needed to provide the necessary context and behavior information.
Workarounds
- Add
role="textbox"to identify as text input:<div contenteditable="true" role="textbox"></div> - Add
tabindex="0"for keyboard focusability. - Provide accessible name with
aria-labeloraria-labelledby:<div id="label">Enter comments:</div> <div contenteditable="true" role="textbox" aria-labelledby="label"></div> - Indicate multiline with
aria-multiline="true":<div contenteditable="true" role="textbox" aria-multiline="true"></div> - Use
aria-readonly="true"for read-only state. - Test with multiple screen readers to ensure compatibility.