Content · Web Development · HTML

HTML aria-readonly Accessibility Attribute: Reference and Examples

A clear, practical aria reference to aria-readonly. Learn when to use it, see working HTML, and avoid common mistakes.

1 views Published Oct 19, 2026 Updated Oct 19, 2026 Admin

ARIA attributes help assistive technologies understand information that is not always obvious from a custom interface. The aria-readonly attribute reports that a custom input or widget cannot be edited.

What it communicates


Reports that a custom input or widget cannot be edited. This information becomes part of the accessibility representation of the page, so it may help people using screen readers or other assistive tools.

An ARIA attribute does not usually change what you see on screen. It also does not automatically add keyboard handling, validation, or scripted state changes.

Example with accessible markup


<section>
    <div role="textbox" aria-readonly="true" tabindex="0">Final score: 95</div>
</section>

Reading the example


Notice the aria-readonly setting and the element or role it describes: textbox. If the value refers to another element, that other element needs a matching id.

For regular inputs use HTML readonly, which also enforces the editing restriction.

When is it appropriate?


Use aria-readonly when this information is genuinely needed and the chosen role supports it. Before adding ARIA, check whether a native HTML element already expresses the same meaning. Native buttons, forms, tables, and progress controls usually need less custom code.

If a script changes the state of the interface, update the ARIA state at the same time. The screen reader’s description and the visible behavior should always agree.

Quick accessibility test


Try the example using only your keyboard. Inspect the accessibility tree and check whether the role, name, and state are what you expect. For an interactive control, confirm that the actual behavior matches its announced state.

Common Beginner Mistakes


  • For regular inputs use HTML readonly, which also enforces the editing restriction.
  • Adding ARIA to an element that already has the right native semantics, without a clear reason.
  • Changing the visual state of an interface without updating its ARIA state.

Key Takeaways


  • aria-readonly reports that a custom input or widget cannot be edited.
  • For regular inputs use HTML readonly, which also enforces the editing restriction.
  • Correct native HTML comes first; ARIA fills gaps rather than replacing working behavior.
Share this resourceSend this page to someone who may find it useful.