Unclear how to choose between checkbox and radio button as form display widget on list fields

Thanks for the initial work on the issue! I've applied and tested MR9507. A few observations and thoughts about the current implementation.

The description This widget uses radio buttons if the "Allowed number of values" is set to 1. If the number of allowed values is more than 1 or unlimited, checkboxes will be used. is currently placed on the Manage form display page. First, all the descriptions for the other widgets are of informational nature only, outlining the active settings of a widget, while the description for the list field is purely of instructional nature, telling the user how to set the widget to checkboxs or radio buttons.
It is also not clear at all where the "Allowed number of values" is set on this page. The widget doesn't have a settings button even. To someone unfamiliar with Drupal this might be a major source of confusion if the description is referring to a setting which is located on a completely different page.

Having that kind of information available in context on the field settings page when a field and content type is set up is sort of important imho. That was the reason why one of the initial suggestions in the steps to reproduce section was to place the description on the field settings page instead of the manage form display page.

On the other hand "just" moving the description over to the field settings page wouldn't solve this multipage problem and the ambiguity coming from the option label (Check boxes / radio buttons) on the select field either entirely.

If someone has deliberately set the "allowed number of values" on the field settings page to 1, then i consider it also potentially confusing still having a settings field label of Check boxes / radio buttons. At this point the desired widget was already chosen and you have no edit settings button available for that widget. So having a visual reassurance within the interface, in case 2 was set on the field settings page, so the select field label would just display Radio buttons, while if the value is set to 1 on the field settings the option would display Checkboxes instead.

On the other hand for someone who has not set up the content type and its fields it might be potentially confusing not seeing Checkboxes in case Radio buttons is the available option based on the settings made on the field settings page. That was one concern, I think @benjifisher voiced, when I've suggest using either checkboxes or radio buttons as the label depending on the settings on the field settings page during the ux meeting.

On the first look a simple problem, but on closer look a quite tricky one, if you are trying to provide clarity and situational awareness to the user. I wonder if it would make sense to file the issue for a usability review to discuss the problem in a group context. back then we just noticed and raised it while discussing and reviewing #3459246: Add a '#check_all' option for checkboxes element.

Usability review

We discussed this issue at #3567765: Drupal Usability Meeting 2026-01-23. The recording of the meeting: https://www.youtube.com/watch?v=s2MS9rYDHws. The attendees at the usability meeting were @pallavi singh3013, @rkoller, @simohell, and @the_g_bomb.

While our initial demoing and exploring of the different scenarios in the context of this issue, we've identified a potential follow-up.

Problem is, if you have a Selection list text field with only a single value, the cardinality set to two, the field set to required, and you have chosen on the Manage form display page the check boxes /radio buttons option for that field, that single checkbox is auto selected on the node edit form. Same for the cardinality of one, there the single radio button is getting auto selected without any set default value. With two available options on the field settings either with cardinality of one or two no option is getting preselected. That edge case with a single available option might pose a potential problem if options are added at a later point in the process. So it might be even a necessary step to let radio buttons and checkboxes have different behaviors, but that is out of scope for this issue and more suitable for a followup.

In regard of the proposed solution in the issue summary we've concluded that it won't be enough to have just a description underneath the cardinality setting on the field settings page, due to the fact that there are separate permissions with Administer fields and Administer form display. So it is possible that a user can have access to only the Manage form display page and in consequence the information in the description would be inaccessible to them. We've also decided against the idea to add a sentence in regard of the implications of the cardinality setting within the help text on the Manage form display page - the help text is not in close proximity to the widget row, plus within the help text the information can easily be missed if not read closely until the end.

We've had a clear consensus that the first touch point for the user can either be on the field settings page or on the Manage form display page, therefore each touch point needs to provide an explanation or some pointer/cue. We've agreed on the following proposed changes:

1. On the field setting page add a description to the Allowed number of values numbers field, explaining the implication of the chosen number - with a value of one leads to radio buttons on the node edit forms while anything >= 2 leads to checkboxes on node edit form. Unfortunately we haven't had time for word smithing during the meeting.
2. On the Manage form display page we have the problem that adding a description and or a link wouldn't work on field widget rows - there you usually have only the option to display the chosen settings in case there are any. So we came up with two options to stay sort of consistent. It has to be noted that we haven't had a strong preference towards one of following two approach, we wanted to put them up for discussion:
   • Keep one option called Check boxes/radio buttons (current state) and add an Edit field settings button plus display the current active type (either checkbox or radio button) as well as the active cardinality for the field. When clicking the edit button display a disabled numbers field displaying the active cardinality for the field plus a description pointing to the field settings page as the place to change the ui component from one type to the other
   • After the mixed label is potentially confusing the second suggestion is to have two dedicated options in the list, Check boxes and Radio buttons. There should also be an Edit field settings button plus the current active cardinality setting for the field should be displayed. Also displaying the active type (either checkbox or radio button) should be unnecessary here after the active type is equal to chosen option in the select list. Edit field settings button also display a disabled number field displaying the active cardinality for the field plus a description pointing to the field settings page as the place to change the ui component from to the other type.