Brief Note on aria-readonly Support

TL;DR: Support for aria-readonly is nearly non-existent for the roles I tested. Should you need it, you cannot rely on it. You will be better off revising the pattern where you think you need it.

For some background, the aria-readonly property:

Indicates that the element is not editable, but is otherwise operable. See related aria-disabled.

This means the user can read but not set the value of the widget. Readonly elements are relevant to the user, and application authors SHOULD NOT restrict navigation to the element or its focusable descendants. Other actions such as copying the value of the element are also supported. This is in contrast to disabled elements, to which applications might not allow user navigation to descendants.

It does not belong on native HTML elements, but if used then the browser should override it by the native readonly attribute. It is meant for non-native implementations of the roles checkbox, combobox, grid, gridcell, listbox, radiogroup, slider, spinbutton, and textbox.

I opted to test on only the checkbox, combobox, listbox, and radiogroup roles. I skipped the remainder because they were not part of my use case, but you should definitely test on your own if you plan to use them. I suspect support will not be much better.

Added 21 November 2022: Since I was asked on Twitter why an ARIA checkbox allows a read-only property when a native checkbox does not, I want to clarify that why is outside the scope of this “brief” post. Instead, go read the discussion on the ARIA spec on GitHub: #1309 Why is aria-readonly allowed for checkboxes and radios?

Testing Results

This is not meant to indicate if the browser / screen reader combination is adhering to the specification. Instead the table only indicates if the read-only property is conveyed.

The browser and screen reader combinations represent the generally recommended pairings for the platform (which is similar to the most common pairings).

Testing Results
Browser / Screen Reader 1. Uses aria-readonly with radiogroup Role on a <fieldset> 2. Uses aria-readonly with radiogroup Role 3. APG Combobox with aria-readonly on the combobox and listbox Roles 4. APG Listbox with aria-readonly 5. Native checkbox with aria-readonly 6. checkbox Role with aria-readonly
Firefox / NVDA Nope Nope Nope Nope Nope Yup 1
Chrome / JAWS Nope Nope Nope Nope Nope Nope
Edge / Narrator Nope Nope Nope Nope Nope Nope
Safari / VO / macOS Nope Nope Nope Nope Nope Nope
Chrome / TalkBack / Android Nope Nope Wut 2 Wut 2 Wut 2 Wut 2
Safari / VO / iPadOS Nope Nope Nope Nope Nope Nope
  1. announces as “read only”.
  2. announces as “disabled”, does not allow me to change despite lack of programmatic prohibition.

Only Firefox / NVDA honors aria-readonly in my samples, though only on the ARIA checkbox. TalkBack has taken a more interesting approach by considering the combobox, listbox, and checkbox all disabled.

NVDA / Firefox announces the ARIA checkbox as “read only”. It is the only combination that exposes it as I expect.

The Tests

I only put together six tests for four roles, so this is not thorough. You can build on these for your own use. Visit them at Codepen or view the debug version. Each passed checks (as appropriate) by the Nu HTML Checker and survived, as well as automated accessibility testing tools WAVE, Axe, and ARC (dismissing false positives).

I used the ARIA Authoring Practices scrollable listbox and select-only combobox patterns without modification, specifically choosing the patterns I see in more common use. This is not an endorsement of them.

None of the examples restrict interaction in any way except for example 6a. I wanted to know if preventing toggling could affect announcement in NVDA / Firefox (the only supporting combo). They are otherwise full operable controls whose values you can change.

I again encourage you to try your own combinations of patterns for testing.

See the Pen Testing aria-readonly by Adrian Roselli (@aardrian) on CodePen.

My testing suite:

Bugs

Some of the bugs currently open against browsers and screen readers:

Clearly more bugs are warranted, which I am sure I will get to.

2 Comments

Reply

I think the title of this one is wrong?

In response to Derik. Reply

Indeed it was. I got a ping on Mastodon shortly after I posted it and corrected (with a redirection). Thanks for the note!

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>