Behavior of disabled with input type=radio and option is unclear

[JAWS-test]

disabled is actually intended to prevent an element from being operated. However, if a radiobutton is disabled and checked, it can be operated by activating another radiobutton that is in the same group (this is how Chrome and Firefox behave and I haven't found anything in the specification that explicitly forbids or allows this behavior).

Possible solutions:

• disabled is only allowed for radiobuttons that are not checked.
• disabled is only allowed on the radiobutton group, but not on the single radiobutton.
• disabled on a checked radiobutton leads to the fact that the entire group can no longer be operated, thus is disabled.

The same problem occurs with <option> in <select>, where <option> has the attributes selected and disabled

[deltragon]

I have never stumbled over this with radio buttons, but I do have a use-case for the <select>:
An option used to be valid, and was selected for this particular form, but has since become invalid for new instances of whatever is being edited.
It makes sense to communicate this with a disabled and selected <option>, but also allow (or even encourage) the user to switch to one of the still valid options.
I could see this same use-case also applying to radio buttons.

[JAWS-test]

If this is meaningful behaviour, that the status of a disabled and selected option can be changed in a drop-down list or radio button group, then this should at least be described in the specification as an exception for disabled. I have not found anything about this in the specification.

In addition, in deviation from the standard, it would then have to be regulated that not the checked radio button receives the keyboard focus, but the first radio button that is not disabled. Otherwise, the radio button group can be operated with the mouse, but not with the keyboard (the problem occurs in Firefox, but not in Chrome).

[domenic]

The behavior is pretty clear from the spec, and not something we can change at this point given how many sites rely on the existing behavior. Perhaps an explanatory note would help clarify that disabled="" only prevents certain modifications, not all modifications (e.g. not programmatic modifications or indirect modifications of the sort you describe)?

[JAWS-test]

@domenic

Perhaps an explanatory note would help clarify that disabled="" only prevents certain modifications, not all modifications (e.g. not programmatic modifications or indirect modifications of the sort you describe)?

That would be good

[JAWS-test]

@domenic

The problem is that a radio button that is checked and disabled can only be operated with the mouse (by clicking on other radio buttons in the group), but not with the keyboard, because the group does not receive the keyboard focus. This is therefore a serious violation of WCAG SC 2.1.1.

The problem now occurs in Firefox, Chrome and Edge.

[annevk]

In data:text/html,<select><option%20selected%20disabled>1<option>2</select> I can select 2 using the keyboard in Safari just fine.

In data:text/html,<form><input%20type=radio%20checked%20disabled%20name=x><input%20type=radio%20name=x></form> I can't however.

However, I don't think there's anything in the HTML Standard that mandates the second input is not keyboard accessible however. So I don't see how this is an issue with HTML.

[JAWS-test]

@annevk Do I understand correctly that all browsers have a bug here because the disabled radio buttons do not receive focus with the keyboard?

[gormonn]

I just ran into the same problem.
Keyboard accessibility doesn't work for a switch if the selected item is disabled.

In this case, you will not be able to access the radio group from the keyboard.