JavaScript Element ariaReadOnly Property

Beginner
⏱️ 10 min read
📚 Updated: Jul 2026
🎯 5 Examples
🚀 5 Try-it labs
Baseline
Instance property

What You’ll Learn

Element.ariaReadOnly is an instance property that reflects the aria-readonly attribute. Learn the true and false tokens, how read-only differs from disabled, and how to get or set the property from JavaScript—with five examples and try-it labs.

01

Kind

Instance property

02

Type

String

03

Values

true · false

04

Reflects

aria-readonly

05

Status

Baseline widely

06

Common with

role="textbox"

Introduction

Sometimes a field should be visible and focusable, but users must not change its value—a locked form preview, a calculated total, or a confirmed address. That is read-only, not disabled.

aria-readonly carries that signal. ariaReadOnly is the JavaScript reflection of that attribute.

JavaScript
const el = document.getElementById("txtBoxInput");
console.log(el.ariaReadOnly); // "true"
el.ariaReadOnly = "false";
💡
Beginner tip (MDN)

Where possible, use an HTML <input type="text"> or a <textarea> with the native readonly attribute. Prefer ARIA read-only mainly for custom widgets (for example a role="textbox"). Keep real editing behavior in sync with the token.

Understanding the Property

MDN: the ariaReadOnly property of the Element interface reflects the value of the aria-readonly attribute, which indicates that the element is not editable, but is otherwise operable.

  • Reflected attribute — mirrors aria-readonly.
  • Get / set — readable and writable string.
  • Two tokenstrue, false.
  • Baseline — widely available since October 2023 (MDN).

📝 Syntax

JavaScript
ariaReadOnly

Value

A string with one of the following values:

ValueMeaning (MDN)
"true"The user cannot change the value of the element.
"false"The user can set the value of the element.
⚠️
Read-only vs disabled

Read-only: focusable and operable, but not editable. Disabled (see ariaDisabled): not operable. Pick the state that matches the real interaction.

📋 MDN Example Shape

MDN starts with a contenteditable textbox marked aria-readonly="true", then unlocks it to "false":

JavaScript
<div id="txtboxMultilineLabel">Enter the tags for the article</div>
<div
  role="textbox"
  id="txtBoxInput"
  contenteditable="true"
  aria-multiline="true"
  aria-labelledby="txtboxMultilineLabel"
  aria-readonly="true"
></div>
JavaScript
let el = document.getElementById("txtBoxInput");
console.log(el.ariaReadOnly); // "true"
el.ariaReadOnly = "false";
console.log(el.ariaReadOnly); // "false"

When ariaReadOnly is "true", also block edits in script (or turn off contenteditable) so the real behavior matches what assistive technologies announce.

⚡ Quick Reference

GoalCode / note
Readel.ariaReadOnly
Lock editingel.ariaReadOnly = "true"
Allow editingel.ariaReadOnly = "false"
Prefer when possible<input readonly> / <textarea readonly>
Typical rolerole="textbox"
MDN statusBaseline Widely available

🔍 At a Glance

Four facts about Element.ariaReadOnly.

Kind
get / set

Instance

Type
string

true / false

Reflects
aria-readonly

Attribute

Baseline
widely

Oct 2023+

Examples Gallery

Examples follow MDN Element: ariaReadOnly. Labs use a custom textbox so you can safely read and write the property.

📚 Getting Started

Read the reflected value and follow MDN’s update.

Example 1 — Read ariaReadOnly

Log whether a custom textbox is read-only.

JavaScript
const el = document.getElementById("txtBoxInput");
console.log(el.ariaReadOnly);

// HTML includes: role="textbox" aria-readonly="true"
Try It Yourself

How It Works

The property returns the attribute string. If the attribute is missing, many browsers return null.

Example 2 — MDN Update to "false"

MDN: unlock the textbox so the user can edit.

JavaScript
let el = document.getElementById("txtBoxInput");
console.log(el.ariaReadOnly); // "true"
el.ariaReadOnly = "false";
console.log(el.ariaReadOnly); // "false"
Try It Yourself

How It Works

Assigning the property updates the reflected aria-readonly attribute so assistive technologies know whether the value can be changed.

📈 Lock Editing, Attribute Sync & Snapshot

Practice marking fields read-only and verify reflection.

Example 3 — Set "true" on a Textbox

Create a contenteditable textbox and lock it as read-only.

JavaScript
const box = document.createElement("div");
box.setAttribute("role", "textbox");
box.setAttribute("contenteditable", "true");
box.setAttribute("aria-label", "Confirmed address");
document.body.appendChild(box);

box.ariaReadOnly = "true";
console.log({
  ariaReadOnly: box.ariaReadOnly,
  attr: box.getAttribute("aria-readonly")
});
Try It Yourself

How It Works

Pair role="textbox" with a clear accessible name. Prefer <input readonly> or <textarea readonly> in real pages when you can.

Example 4 — Property vs getAttribute

Confirm the attribute stays in sync after a write.

JavaScript
const el = document.createElement("div");
el.setAttribute("role", "textbox");
el.setAttribute("contenteditable", "true");
el.setAttribute("aria-readonly", "true");
el.setAttribute("aria-label", "Tags");
document.body.appendChild(el);

el.ariaReadOnly = "false";
console.log({
  fromProperty: el.ariaReadOnly,
  fromAttribute: el.getAttribute("aria-readonly"),
  same: el.ariaReadOnly === el.getAttribute("aria-readonly")
});
Try It Yourself

How It Works

Prefer ariaReadOnly in script; keep the attribute for HTML markup.

Example 5 — Support Snapshot

Feature-detect and remember the native-control preference.

JavaScript
console.log({
  supported: "ariaReadOnly" in Element.prototype,
  allowed: ["true", "false"],
  tip: "Prefer input/textarea readonly when possible (MDN)",
  status: "Baseline Widely available (MDN)"
});
Try It Yourself

How It Works

Use ariaReadOnly when a custom textbox is required; otherwise lean on native readonly.

🚀 Common Use Cases

  • Custom textboxes that switch between locked preview and edit mode.
  • Confirmed values (address, email) that remain focusable for copy.
  • Calculated fields that must stay visible but not editable.
  • Design-system editors that cannot use native readonly.
  • Keeping script and markup aligned without manual setAttribute.

🔧 How It Works

1

You build an operable field

Often role="textbox" when native HTML is not used.

Widget
2

Set ariaReadOnly to true or false

Declare whether the value may change.

Declare
3

Match real editing behavior

Block or allow typing to match the announced state.

Behavior
4

Users know the field is locked or editable

AT announces read-only while focus and copy still work.

📝 Notes

  • Not Deprecated, Experimental, or Non-standard on MDN (Baseline Widely available).
  • Prefer native readonly on <input> / <textarea> when possible (MDN).
  • Keep editing behavior aligned with the true / false value.
  • Related: ariaPressed, ariaDisabled, ariaRelevant, JavaScript hub.

Browser Support

Element.ariaReadOnly is Baseline Widely available (MDN: across browsers since October 2023). Logos use the shared browser-image-sprite.png sprite from this project.

Baseline Widely available

Element.ariaReadOnly

String true / false — reflects aria-readonly for non-editable but operable widgets.

Baseline Widely available
Google Chrome Supported (ARIA reflection)
Yes
Microsoft Edge Supported (ARIA reflection)
Yes
Mozilla Firefox Supported (ARIA reflection)
Yes
Apple Safari Supported (ARIA reflection)
Yes
Opera Follow Chromium support
Yes
Internet Explorer No ariaReadOnly IDL — use setAttribute
No
ariaReadOnly Baseline

Bottom line: Use ariaReadOnly on custom widgets to declare a non-editable but operable state. Prefer native readonly when you can. Keep real editing behavior in sync with the value.

Conclusion

ariaReadOnly reflects aria-readonly so custom widgets can declare a non-editable but still operable state. Prefer native readonly when possible, and keep real editing behavior aligned with the announced token.

Continue with ariaRelevant, ariaPressed, ariaDisabled, or the JavaScript hub.

💡 Best Practices

✅ Do

  • Prefer native readonly when possible
  • Match editing behavior to true / false
  • Keep the field focusable when it is only read-only
  • Update the property when lock / unlock modes switch
  • Test with keyboard and a screen reader

❌ Don’t

  • Confuse read-only with disabled
  • Announce read-only while still allowing edits
  • Skip native controls just to use ARIA
  • Leave custom textboxes without an accessible name
  • Assume the property alone blocks typing

Key Takeaways

Knowledge Unlocked

Five things to remember about ariaReadOnly

Reflected aria-readonly string for non-editable but operable widgets.

5
Core concepts
📝 02

true / false

locked vs editable

Values
🔍 03

Prefer native

readonly attr

MDN
04

Baseline

widely available

Status
🎯 05

Not disabled

still operable

Rule

❓ Frequently Asked Questions

It reflects the aria-readonly attribute as a string, indicating that the element is not editable but is otherwise operable.
No. MDN marks Element.ariaReadOnly as Baseline Widely available (since October 2023). It is not Deprecated, Experimental, or Non-standard.
The strings "true" (the user cannot change the value) or "false" (the user can set the value).
Yes when possible. MDN recommends an HTML input with type="text" or a textarea (with the readonly attribute) because they have built-in semantics and do not require ARIA attributes.
Read-only means the value cannot be changed, but the control can still be focused and operated (for example copied or scrolled). Disabled means the control is not operable.
Yes. Reading and writing ariaReadOnly updates the reflected aria-readonly attribute. Keep actual editing behavior in sync with the value.
Did you know?

Setting ariaReadOnly = "true" does not automatically stop typing in a contenteditable div. The attribute informs assistive technologies; your script (or native readonly) must enforce the lock.

Next: ariaRelevant

Learn the reflected aria-relevant property for live region notifications.

ariaRelevant →

About the author

Mari Selvan M P
Mari Selvan M P 🔗

Developer, cloud engineer, and technical writer

  • Experience 12 years building web and cloud systems
  • Focus Full Stack Development, AWS, and Developer Education

I write practical tutorials so students and working developers can learn by doing—from databases and APIs to deployment on AWS.

5 people found this page helpful