Why is aria-readonly allowed for checkboxes and radios?

[scottaohara]

Leaving aside that HTML mentions that readonly is only for text editable form controls, the aria-readonly attribute is introduced with the following text:

Indicates that the element is not editable, but is otherwise operable.

Regarding checkboxes and radio buttons, they can only be toggled as checked or not (and mixed re: checkboxes). So if their state cannot be edited, then they are not operable.

I understand the argument of wanting to be able to expose a non-editable checkbox, for example, on a confirmation screen where other form controls are present, but in a read only state. But why couldn't this be done with a disabled checkbox (native disabled attribute or aria-disabled) which is more accurate of the control's state? Even if the argument is "we would want the checkbox to be fosusable and not styled as disabled", aria-disabled has that covered since it won't automatically style or remove the checkbox out of the focus order by default.

Beyond thinking that aria-readonly should not be allowed on radios and checkboxes, I'd also say it thus should not be allowed on radiogroup.

[patrickhlauke]

It also makes me wonder what a text entry field that is "not editable, but otherwise operable" actually lets users do, from an "operable" point of view - is it really just that it's focusable, or am I missing some other operation here? being able to select all the text when navigating with keyboard (not possible when disabled, but for mouse users it's possible even then)

[joanmarie]

I think the difference is:

• something which is readonly has a valid value which might be of interest/relevance to the user; the user just cannot change it.
• something which is disabled has an irrelevant/ignored/unused value because it is associated with something missing/unsupported

Example: An "enable bluetooth" checkbox where one needs administrative privs to toggle its state

• On a machine where there is a bluetooth adapter, but the user lacks administrative privs: readonly
• On a machine where there is no bluetooth adapter present: disabled

[patrickhlauke]

then why is this not possible in actual HTML? this would imply that you can only properly convey this using ARIA, not native HTML semantics

[patrickhlauke]

also, i don't think the value of disabled fields is necessarily irrelevant/ignored (though now thinking...do disabled fields take part in form submission?).

if anything, this is making me think a change in actual HTML is needed first and foremost...

[jnurthen]

To echo @joanmarie this is really common in enterprise software. Read only is often used when in either a non edit mode where the user consciously needs to toggle a control in order to be able to edit data, or when the user doesn't have the privilege to edit that particular piece of data. Disabled implies that the value is not relevant.

IMO HTML should support this but does not. I'm certainly not in favour of any changes to ARIA here - I know it would break a lot of current applications.

[patrickhlauke]

Disabled implies that the value is not relevant.

debatable. to me it would just imply that i can't interact with it, not that its value may be incorrect/arbitrary/rubbish.

so, who's brave enough to take the above rationales to the HTML WG/WHATWG and propose that readonly should also apply to non-text form controls?

[patrickhlauke]

and note this note in https://html.spec.whatwg.org/multipage/input.html#the-readonly-attribute

The difference between disabled and readonly is that read-only controls can still function, whereas disabled controls generally do not function as controls until they are enabled. This is spelled out in more detail elsewhere in this specification with normative requirements that refer to the disabled concept (for example, the element's activation behavior, whether or not it is a focusable area, or when constructing the entry list). Any other behavior related to user interaction with disabled controls, such as whether text can be selected or copied, is not defined in this standard.

Only text controls can be made read-only, since for other controls (such as checkboxes and buttons) there is no useful distinction between being read-only and being disabled, so the readonly attribute does not apply.

[jnurthen]

@patrickhlauke I do not have the energy for that fight. Note - I've always read the "Incidental" exception for inactive text controls to mean that the value is incidental so does not need to be able to be discerned.

[patrickhlauke]

I know it would break a lot of current applications

are there a lot of applications out in the wild that use aria-readonly on checkboxes/radio buttons/fieldsets?

[jnurthen]

I know it would break a lot of current applications

are there a lot of applications out in the wild that use aria-readonly on checkboxes/radio buttons/fieldsets?

Yes. Probably mostly require logins so any scans will not pick them up.

[scottaohara]

Quickly testing this out on a native checkbox and a div role=checkbox

• voiceover does not announce readonly in either safari (macos or ios) or chromium.
• Talkback + firefox does not announce read only state.
• Talkback + Chrome announces readonly checkboxes as "disabled"
• NVDA + IE11 & Chromium announce "read only" for both.
• NVDA + Firefox only announces 'read only' when on a role=checkbox, and not the native element.
• JAWS with Firefox, IE11 and Chromium do not announce readonly state.
  • Firefox only exposes readonly state on element with role=checkbox (though it is not announced on either)
• chromium (macOS and Windows) shows the 'aria-readonly' attribute in the accessibility dev panel, but not seeing anything meaningful exposed at the platform api level for firefox/chromium

So unless someone is using NVDA, or TalkBack with Chrome, seems like it's already pretty unreliable?

[JAWS-test]

I came across the problem with aria-readonly for radio buttons and checkboxes in SAP applications, but I can imagine that other frameworks also use it.

[vdh]

Can somebody please clarify what makes text type so special that it and only it is allowed to be read only, and no other input type is allowed to be? The phrase "there is no useful distinction between being read-only and being disabled" could be argued against text fields just as easily, couldn't it? IMO, either "read only" is a valid concept across all inputs regardless of type, or it's invalid across all? What's with the special treatment?

[stes-acc]

I came across the problem with aria-readonly for radio buttons and checkboxes in SAP applications, but I can imagine that other frameworks also use it.

This is absolutely nothing special in real life business applications and used for decades in applications where special user roles allow only reading access to fields and values, including checkboxes and radio button groups.

[patrickhlauke]

but the point is: do all those real life business applications use aria-readonly or do they use disabled on the markup. and if it's so common why is the HTML spec itself not allowing readonly on these input, but ARIA does.

[stes-acc]

I cannot comment for HTML reasons but for the reasons above it is in ARIA.. And it should be in HTML, too, because it just makes sense.

Readonly and disabled are NOT identical with respect of element/control interaction. This MAKES a difference and justifies an additional state that allows this.

Just because something is uncommon does not mean that it does not come in handy. Readonly Radiobutton groups still can be navigated by keyboard to get actual values set. For disabled RBs this can be accomplished in virtual modes, too but having keyboard operation active for value reading is an alternative way to get this.

Other example: You cannot open a disabled combo but a readonly combo you still can if you are interested in available values.

[patrickhlauke]

So again, this is a change that should happen at HTML level. ARIA is just for AT, it shouldn't introduce semantics that are generally useful, but only for AT users.

[MelSumner]

I'm late to this party- but since the issue is still open I'll comment.

Disabled on a form element means that the data won't be submitted to the server with the rest of the form. Read-only on a form element means that the data will be submitted to the server with the rest of the form.

I'd say that's a strong enough reason for leaving things as they are (or even highlighting them for developer education).

[patrickhlauke]

so, who's brave enough to take the above rationales to the HTML WG/WHATWG and propose that readonly should also apply to non-text form controls?

i may have to put my flame-retardant underpants on and do it, it seems...

[patrickhlauke]

xref https://github.com/whatwg/html/issues/2311#issuecomment-813110695

[brennanyoung]

This is a very interesting discussion. I'm facing a concrete use case where aria-readonly seems to capture the semantics we need better than aria-disabled, although I will admit that the distinction is so fine that the attribute appears poorly specified.

It's a multiple choice quiz, made of check boxes. Text for each question includes something like "Select all that apply and then Submit". User does so, and then the question is "locked" (i.e. the checkboxes become "read only"). The right/wrong answers are indicated. (Oh, I wish we had aria-description already). In this state, the checkboxes are "not editable, but otherwise (in the other state) operable".

Clicking "retry" unlocks the checkboxes. making them operable again.

Is this any different from aria-disabled? I don't know. It feels different to me because you're browsing your previous input, rather than interacting with operable controls. Some clarification of when to use one, and when to use the other would be very helpful.

I'm alarmed to read that aria-readonly is not well-supported across configurations, and it's telling that some configurations report it as "disabled".

[stes-acc]

Other examples are for instance temporarily locked controls due to parallel access of annother thread (multi-user edit scenarios) or different access levels for users of transactions etc.

Readonly is there for a reason.

If this turns to a shootout "why do we need readonly state at all and why can't disabled be used used for everything" - this is annother discussion.

[patrickhlauke]

i would recommend bringing up these points over on the WHATWG html discussion https://github.com/whatwg/html/issues/2311 because it feels fundamentally wrong and dirty to me that this sort of pattern can be expressed in ARIA, but not in regular HTML. have the shootout there ...

[estelle]

My understanding is that readonly isn't supported on <input of type=checkbox value="foo"> and <input of type="radio" value="bar"> because the value of the input is read-only. Readonly has to do with whether the value of a form control is editable or not, not whether or not it is selectable.

That said, it is very confusing to have aria-readonly supported on checkboxes and radios in ARIA but not have readonly supported on those elements in HTML

[jordan-cutler]

Hey all, kinda similar to this topic, does anyone know of / point me in the right direction for a good pattern for displaying form results back to a user such that the whole form is disabled but not with disabled styles (so it looks like a normal form but the user can't change the values)?

Would this depend on if we would want the elements we display back to the user to be tabbable?

If tabbable: Use aria-readonly on our checkboxes / radios and prevent changing the checkbox/radio value via JS If not tabbable: Set everything to disabled and set the styles to be the default styles?

Does this seem right? Also if there's a better place to post this, let me know. I'm equally confused as other folks on aria-readonly vs readonly vs disabled

[JAWS-test]

@lehighjcut

Your question would be better placed in its own issue, and probably at https://github.com/w3c/aria-practices/issues rather than here.

The question is not easy to answer. The different markups have their advantages (+) and disadvantages (-):

disabled

• disabled usually does not have sufficient contrasts to be easily recognizable (-)
• disabled is however well distinguishable from operable form fields (+)
• disabled suppresses JS event handlers (-)
• disabled has its own color in the High Contrast Mode of Windows and is therefore always well recognizable (+)
• disabled does not get the focus with the keyboard, i.e. the value cannot be copied (-)
• no unnecessary navigation steps with the keyboard (+)
• disabled is not transmitted when submitting a form (-)
• disabled is perceptible with the screen reader with the virtual cursor, but not in an application region (role=application) (-)

readonly

• readonly may only be used for input fields (-)
• readonly has sufficient contrast to the background (+)
• readonly is visually indistinguishable from editable input fields (contrasts too poor) (-)
• readonly has no own color in the high contrast mode of Windows and is therefore not recognizable (-)
• readonly gets the focus with the keyboard, i.e. the value can be copied (+)
• readonly can lead to many unnecessary navigation steps with the keyboard (-)
• readonly is transmitted when submitting a form (+)
• readonly is perceptible with the screen reader even in application mode (+)

aria-readonly

• like readonly, but is allowed on more form elements, but also not on all (see https://w3c.github.io/aria/#aria-readonly, https://github.com/w3c/html-aria/issues/384#issuecomment-986078496) (-)
• aria-readonly does not always work reliably with the screen reader (see https://github.com/FreedomScientific/VFO-standards-support/issues/592) (-)

text

Another possibility would be to display non-editable form data in text form, e.g. as a list (one name-value pair in each list entry) or in table form (2 columns)

Advantages would be:

• no limitation of form field types
• sufficient contrast to the background
• clearly distinguishable from operable form fields
• own color in Windows High Contrast Mode, thus clearly distinguishable from operable form fields
• no unnecessary navigation steps with the keyboard

Disadvantages:

• is not transmitted when the form is submitted
• does not receive the focus, thus not copyable
• not perceptible with screen reader in application mode
• change of layout compared to the original form

[sivakusayan]

Sorry if I'm mistaken here, as I am still fairly new to the world of accessibility. However, if it's true that ARIA supports the notion of read-only checkboxes, how exactly are these semantics supposed to be expressed in UIAutomation? As far as I know, the Checkbox doesn't seem to have any documented IsReadOnly property, and IToggleProvider, the only UIAutomation pattern the Checkbox supports, doesn't have any IsReadOnly property either. Contrast this with the ValuePattern which does have such a property.

I noticed this problem by opening this codepen in Chrome, then comparing the IAccessible2 tree (outputted using their tree dump tool) and the UIAutomation tree (which I inspected using Accessibility Insights for Windows). In the IAccessible2 tree the checkbox had read-only semantics, but it didn't in the UIAutomation tree. Assuming this logic is correct, does there need to be a change in the UIAutomation API? Or is there hesitance due to this not being supported in HTML?

[jnurthen]

https://w3c.github.io/core-aam/#mapping_nodirect states the following "In Microsoft UIA, use the AriaRole and AriaProperties properties to expose semantics that are not directly supported in the control type."

When inspecting a checkbox in UIA I see the following: AriaProperties readonly=true;expanded=false;multiline=false;multiselectable=false;required=false

So while this isn't ideal, the property is still being exposed by the API. However AT would need to look for this specific property in order to implement it - and when I checked Narrator it doesn't appear to do so.

I really think we should specify in core-aam places where attributes aren't mapped in the standard way otherwise I don't think we can be surprised when AT don't implement them. I don't know off-hand if this is a one-off where things aren't specified or if this is a more prevalent issue.

[sivakusayan]

Thanks for the clarification @jnurthen . I see that for properties like aria-busy, the AAM explicitly calls out that UIA exposes the property through AriaProperties.busy. So maybe that should be called out for aria-readonly as well.

I don't want to derail this discussion, so I'll spin this off into a separate thread.

[scottaohara]

reposting from issue #2306 , by @LaurenceRLewis :

ARIA readonly testing on checkbox

Summary HTML readonly is not permitted on Checkbox ARIA aria-readonly is permitted on checkbox. The user can read but not set the value.

when creating checkboxes with role="checkbox" the aria-readonly attribute is supported according to MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-readonly#:~:text=However%2C%20when%20creating%20checkboxes%20with%20role%3D%22checkbox%22%20the%20aria%2Dreadonly%20attribute%20is%20supported.

Note that testing completed below does not support this MDN statement!

Specifications

WHATWG HTML Living Standard 4.10.5.3.3 The readonly attribute https://html.spec.whatwg.org/multipage/input.html#the-readonly-attribute Only text controls can be made read-only, since for other controls (such as checkboxes and buttons) there is no useful distinction between being read-only and being disabled, so the readonly attribute does not apply. ARIA 1.2 Specification aria-readonly property https://www.w3.org/TR/wai-aria-1.2/#aria-readonly Indicates that the element is not editable, but is otherwise operable. 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.

Actual behaviours tested for aria-readonly

Test environment https://cdpn.io/pen/debug/eYwgvvW

Chrome: 127.0.6533.100 JAWS 2023 Result: Checkbox can be checked and nothing is spoken to the user in regard to being read only. aria-readonly is ignored with and without role checkbox.

Firefox: 129.0 JAWS 2023 Result: Checkbox can be checked and nothing is spoken to the user in regard to being read only. aria-readonly is ignored with and without role checkbox.

Chrome: 127.0.6533.100 NVDA 2024 Results: "What interactions are available? check box not checked read only" Checkable. Applies to both HTML checkbox and ARIA role checkbox.

Firefox: 129.0 NVDA 2024 Results: WIthout an explicit role set "What interactions are available? check box not checked" aria-readonly is ignored. If role checkbox is set. "I have an explicit and implicit role! check box not checked read only" . The readonly is exposed to the accessibility tree

iOS 17.6 - VoiceOver - Safari Results: Ignored in both cases.

macOS Sonoma 14.5 - VoiceOver - Safari Results: Ignored in both cases.

Android 14 - TalkBack Results Both cases are announced as 'disabled'