Radio Button

[leolopes]

Just opening this issue to tell I'm going to start research work for the "radio" component. This is the link for the document draft: https://docs.google.com/document/d/1-TyGOSOcyV4VOqNyUDjEQLjrtssI8cd2-BVld9cJtlo/edit?usp=sharing

Any contributions are welcome :)

[leolopes]

Today I started the document by making a list of references to all the concepts that remind of radio buttons in many design systems.

After that I started a spreadsheet inventory to list all the concepts related to each of the components.

The main points that are still not clear to me and maybe should be better defined in this beginning are:

• whether we should work with the concept of Radio Buttons or Radio Groups (or both separately). In my document you can see that design systems are not consistent with this naming convention, in a variety of ways.
• whether I should list every property that every design system declares as "concepts", or maybe only list concepts that seem more relevant.

If you look at the spredsheet, even though I have for now listed Ant Design's concepts alone, the list of concepts is already big and has the added complexity of being divided by "radio buttons" and "radio button groups".

I would like any suggestion you might have for how I should handle it further.

[gregwhitworth]

@leolopes moving the discussion around radio from discord to here:

I would appreciate your input, because though radios look similar to checkboxes, it seems they are a bit more complex

Can you expound? I would expect there to be an additional section for how radio groups are tied together via the name attribute but most of the additional behaviors should be very similar outside of potentially a containing element to hold the group (assuming this is consistent across UAs/OSes/Design Systems). I have opinions on having the containing element for the group but that should be in a different issue.

[chrisdholt]

@leolopes moving the discussion around radio from discord to here:

I would appreciate your input, because though radios look similar to checkboxes, it seems they are a bit more complex

Can you expound? I would expect there to be an additional section for how radio groups are tied together via the name attribute but most of the additional behaviors should be very similar outside of potentially a containing element to hold the group (assuming this is consistent across UAs/OSes/Design Systems). I have opinions on having the containing element for the group but that should be in a different issue.

There is a bit of nuance here I think depending how this is implemented, specifically as it relates to accessibility and behavior depending on how these are built. While the browser ties inputs with a type of radio together using the name attribute, per the spec, ARIA radios behave different and are tied together by being a child of a radiogroup. Depending on how this is built I would expect a bit of difference between the implementation.

[leolopes]

I think the radio button is more complex than the checkbox because the checkbox is "standalone", while the radio button represents an option amongst other options.

I see the radio button much like a "single choice select". They could almost be the same component with different appearances. In this sense, I mostly see the radio button as being part of a host component (the radio button group).

By @chrisdholt 's answer, it's also evident that even well defined specifications differ in how they implement the component, let alone the different ways the other design systems do.

If I personally were to define the specs for radio buttons, I would work from one level up, and consider the radio button group as the actual component, comprised of two or more radio buttons.

If I'm not mistaken, the W3C specs for the radio buttons allow for standalone radio buttons, but I simply see no purpose in that. Perhaps you do?

[leolopes]

I updated the preliminary inventory with three other design systems: https://docs.google.com/spreadsheets/d/1addPff5gfeAIRvCeVTnT0GUD1IesCQYO8JmFzlum2Ug/edit?usp=sharing

You can see there I divided the concepts between radio buttons and radio button groups. You can see by my comments that I have many doubts on where I should list each property, or whether I should list some of them at all.

I'll keep doing this, however. Maybe when I have inventoried several design systems, I can have a clearer picture, and then I'll be able to triage concepts and come to a simpler list, like the one that is provided for the checkbox.

[leolopes]

As I keep listing the design systems' options for Radio/RadioGroups, I only strenghten my belief that we should treat Radio Button Groups as the actual component, instead of Radio Buttons (with maybe a host Radio Group Component).

The two main reasons are:

• a very weak use case for a single, standalone, radio button;
• and the fact that most of the time the radio buttons inherit properties from the group, like name, style, onChange behavior, etc.

One could argue that if a single button inside a group has a disabled state, while the others don't, we could treat buttons as components, with their own properties. However, this would make the select's option tag as much of a candidate to be a standalone component, which I don't think is the case.

[gregwhitworth]

I agree overall, I think that there could be a starting anatomy here even if you simply scope it to the control and the indicator. To be somewhat selfish - I would like that scoped anatomy sooner than later as I'm putting together a proposal for an indicator pseudo element and that specific aspect of the indicator part and label are the same across checkbox and radio from what I can see.

[leolopes]

the control and the indicator

Hello @gregwhitworth, do you mean the actual radio input (the circle) and the label?

I would like that scoped anatomy

What do you mean exactly by the "anatomy"? Do you mean the same thing as the anatomy referenced here? https://open-ui.org/components/checkbox.research#anatomy

If so, it's fairly simple. I would basically propose the following:

• Radio Button Group (the actual component)
  • Radio Button (at least two required)
  • Checked Indicator (input)
  • Label (optional)
  • Radio Button
  • ...
  • ...

Either way, I'll keep looking into the design systems list all possible properties before doing a triage.

[leolopes]

Let me rectify: a label for the whole group seems very important, thus:

• Radio Button Group (the actual component)
  • Group Label
  • Radio Button (at least two required)
  • Checked Indicator (input)
  • Label (optional)
  • Radio Button
  • ...
  • ...

[leolopes]

I have finished the analisys of all the design systems' properties, and now I'm going to use both the WAI-ARIA specs and the recurrence of properties among the design systems to propose a more to the point specification.

[gregwhitworth]

Thanks for this - looking forward to it. And btw - with regards to the scoped anatomy I'm referring to this part:

• Radio Button
  • Checked Indicator (input)
  • Label (optional)

This was the aspect that I was referring to being similar to checkbox. And thus the proposal I'm making being the same. For sure all of the behaviors given that they need to be tied together, etc will impact the overall anatomy so thank you for the time spent on this.

[leolopes]

Because of the need of tying the radio buttons together, I think the "Group Label" should be included in the basic anatomy, specially when we have more than one option.

In case the final proposal allows groups with a single option, the group label could be optional.

[chrisdholt]

Because of the need of tying the radio buttons together, I think the "Group Label" should be included in the basic anatomy, specially when we have more than one option.

In case the final proposal allows groups with a single option, the group label could be optional.

In the case of the Group Label being included in the anatomy, I think we'll want to ensure we articulate that a visual label is not technically required. The label for the group could be visible or it could be applied via an aria-label (5th bullet). A label of some sort is required, but its not always required as part of the anatomy.

[leolopes]

Coming back after a while, I've been reading a bit further and found this:

A document must not contain an input element whose radio button group contains only that element. W3 HTML Specs

I think we can safely assume the requirement of more than one radio input in each group, relegating single option inputs to the checkbox type.

I'll be finishing the research untill wednesday and include a preliminary proposal. Then I'll ask for some feedback on Discord.

[korenevskiy]

Hello mentor @leolopes . I ran into the problem of radio buttons located in tables. I will describe a problem that I personally encountered. And I know that every developer faces it without exception. I have a table on the page (<table>) with fields. I will not write the table itself, but I will write its fields for an example.

<input name="name[]" type='text'><input name="on[]" type='radio' value='on'><input name="on[]" type='radio' value='off'>
<input name="name[]" type='text'><input name="on[]" type='radio' value='on'><input name="on[]" type='radio' value='off'>
<input name="name[]" type='text'><input name="on[]" type='radio' value='on'><input name="on[]" type='radio' value='off'>

For example, I simplified the number of simple text fields. But as is usually the case,there are the fields phone, email, and the rest. As you can see, if you send the form to the server, you will get a multidimensional array of data with names, phone numbers, and emails. But with the radio button field, everything is completely different. You cannot create a group of radio buttons for a single row in a table. All radio buttons are linked together with each other. To solve this problem, you have to resort to JS for placing indexes in the attribute of the name of radio buttons. And it's very hard. At the same time, for other types of fields, everything works without JS out of the box. I would like everything to work out of the box with radio buttons as well. There was an idea to group the radio buttons of each line in a specific tag. But it also requires HTML refinement. But I came up with the idea of LABEL, on the one hand it works like a radio button, on the other hand it has all the advantages of a regular field. And it does not require putting indexes using JS. The full idea is described here https://github.com/whatwg/html/issues/6463

[leolopes]

Hello @korenevskiy , how are you?

It seems like the problem you are facing is not exactly related to the radio buttons structure or style itself, rather automating the way you set indexes for their names. Or at least how to handle the data on the server. To be honest, I'm not sure exactly why would you need JS for this.

@gregwhitworth could confirm this, but I think it isn't exactly the scope of work for Open UI.

Thanks for your message anyway!

[korenevskiy]

Hello @korenevskiy , how are you?

It seems like the problem you are facing is not exactly related to the radio buttons structure or style itself, rather automating the way you set indexes for their names. Or at least how to handle the data on the server. To be honest, I'm not sure exactly why would you need JS for this.

<input name="on[0]" type='radio' value='on'><input name="on[0]" type='radio' value='off'>
<input name="on[1]" type='radio' value='on'><input name="on[1]" type='radio' value='off'>

for each cell of the table in each of which there will be a group of radio buttons, you need to put indexes, this is required so that the names of the radio buttons are different. Indexes need to be set in JS when the user dynamically creates rows in the table. And also arrange the indexes each time after sorting and dragging the rows with the mouse among themselves. Do you consider radio buttons in terms of function, style, or data? My example makes simple fields look like radio buttons, in terms of function and data, but not style.

<input type="hidden"  name="on" >
<label value="on">On</label>
<label value="off">Off</label>

or

<input type="text"  name="on" readonly>
<label value="on">On</label>
<label value="off">Off</label>

With this layout, this code shows itself exactly the same as the radio button. I'm just looking for support for my idea. But this is provided that you liked my idea.

[leolopes]

Hi @korenevskiy , I'm sure you face a challenge on your work that deserves a good solution, and I hope we can help.

I'm not sure, however, if the problem you are trying to solve with the setting of indexes is actually under the scope of the project, and I'm also not sure how the code examples you presented as the solution solve the problem. Maybe you could explain a little more how the code would work.

In any case, talking about tables, you made me realize I was not accounting for radio buttons displayed in a tabular layout. I will surely make a note about it on the research document and ask for feedback on how this could be solved.

[korenevskiy]

There is a table. Each table cell contains a field. When sending the form with the fields in the table to the server. On the server, you need to get an array of values. For brevity, I will replace the table cells with square brackets.

[<input name='user[]' type='text'>][<input name='phone[]' type='text'>][<input name='mail[]' type='text'>]
[<input name='user[]' type='text'>][<input name='phone[]' type='text'>][<input name='mail[]' type='text'>]
[<input name='user[]' type='text'>][<input name='phone[]' type='text'>][<input name='mail[]' type='text'>]

As you can see, all field names have square brackets without indexes. This allows you to get an array of values on the server. But how to create a radio button in a table cell by analogy? So that each row is interpreted as a separate array value?

[<input name='edu[]' type='radio' value='school'><input name='edu[]' type='radio' value='high'>...]
[<input name='edu[]' type='radio' value='school'><input name='edu[]' type='radio' value='high'>...]
[<input name='edu[]' type='radio' value='school'><input name='edu[]' type='radio' value='high'>...]

All radio buttons are linked together and the server gets only one value.

In order for the server to receive the values of radio buttons in the same way as other field types, it is necessary that the fields in this column have one for each row similar to the Hidden or text type. For such a field, we specify the name in education [] as usual. And then the server receives the data array as usual.

[<input type="text"  name="edu[]" readonly>]
[<input type="text"  name="edu[]" readonly>]

My idea is to make a regular field work with the Text type or with the hidden type or with another type similar to radio buttons. . But how can you make the work of fields with the Text type or with the Hidden type work by analogy with radio buttons? This is my suggestion. I suggest writing a single text field instead of a group of radio buttons, but having multiple Labels with different values for the field. When the user clicks on the Label, the values are entered in the corresponding field field. I suggest making it possible to create labels for the text field with the values specified in the label body.

[<input type="text"  name="edu[]" readonly><label value="school">School</label><label value="high">High</label>]
[<input type="text"  name="edu[]" readonly><label value="school">School</label><label value="high">High</label>]

Thus, we get a text field that functions as a radio button.

1. I suggest embedding labels with variables in HTML by clicking on such a label, the value is entered in the field
2. I suggest linking the Label and the field according to the neighborhood principle. For example, if the FOR attribute is not specified in Label, then the label will be associated with the field that is next to but in front of it. This will allow you to avoid assigning unique IDs for each field located in the table.
3. I suggest adding the multiselect attribute to the select field, in order to be able to make multiple selections of values without pressing the CTRL button.
4. Such a label with a value will become an active element, similar to a button or link. Instead of a label, you can consider using a link or button. But in all cases, you need to make HTML changes so that the new analog of radiobuttons can work in the table.
5. I suggest adding a pseudo-class ::selected for LABEL for CSS styles. So that you can select such a LABEL if the LABEL and INPUT values match.

[korenevskiy]

In HTML, there is such a <A> tag, if you specify the grid and the element ID in the HREF attribute, then the page will rewind to this element. And what if the <A> tag is not rewound, but will put the values in the fields?

[<input type="text"  name="edu[]" readonly><a value="school">School</a><a value="high">High</a>]
[<input type="text"  name="edu[]" readonly><a value="school">School</a><a value="high">High</a>]

Or a variant with buttons, but in any case there should be a tag that should be able to pass values to the field without using JS.

<input type="text"  name="edu[]" readonly><button value="school">School</button ><button value="high">High</button >
<input type="text"  name="edu[]" readonly><button value="school">School</button ><button value="high">High</button >

Here I listed the possible solutions to the same problem.

[leolopes]

Hello @korenevskiy , I appreciate the effort put in showing your idea. I think I now understand what you mean. It goes, however, beyond of what I know about specs or even the scope of Open UI to be able to validade your idea. For this I would need help from other people from the community.

Personally, I think if radio buttons behaved in such a way, it could be helpful, but I don't know how far I would go to avoid simply placing indexes on the radio buttons' names.

I would appreciate your help commenting on the research document presented on the first post.

Thanks!

[korenevskiy]

Hello @leolopes. I have been doing layout and programming for a very long time. But I have difficulties with the English language. Can you tell me where I could post this idea? So that we can discuss it, find a better solution, approve it, and put it into production? How are new features added to the W3C? . I came up with my idea because I was faced with the stupidity of radio buttons. My idea is originally based on a radio button.

[leolopes]

Hi @korenevskiy , don't worry, I can understand you :) English is also not my first language.

Well, I think you did the right thing by posting your idea here and even creating a separate issue for it, and I think now it's time to wait and see if it gets the attention of other people... You can also advocate for your idea around, or even in the Open UI Discord Server: https://discord.com/invite/DEWjhSw

I am not very familiarized with the specification process, I'm still learning. @gregwhitworth has worked with this for longer and is basically leading the project, so he's a better source than I am.

[korenevskiy]

@leolopes I have read the document. You describe the problems that I also encountered. You suggest grouping radio buttons using special tags or using area-attributes. I also thought about this topic, I only thought about how to group using the tags <group>.

[<group><input name='edu[]' type='radio' value='school'><input name='edu[]' type='radio' value='high'>...</group>]
[<group><input name='edu[]' type='radio' value='school'><input name='edu[]' type='radio' value='high'>...</group>]
[<group><input name='edu[]' type='radio' value='school'><input name='edu[]' type='radio' value='high'>...</group>]

This is a great idea, but it doesn't solve the problem of placing elements in different parts of the layout.

But we must kill all the hares with one shot, not just one hare. Right? In the source data, we have 2 types of fields: this is the <input type="radio"> field, and the <input type="text"> field. If we combine these 2 fields, we get the <SELECT> field. But we want to get all the functions of both types of fields at once. . To what:

1. We can place radio buttons anywhere in the layout.
2. However, the <select> field cannot be placed in parts in different places on the site.
3. But the text fields can be placed anywhere on the site, but they don't work in a group, each text field is on its own.
4. But then they can create an array of data and do not work in groups. We need conrol:
5. Working in an array.
6. Working on groups.
7. Could work without indexes.
8. Could be placed in parts in any part of the layout. Thus, the idea boils down to the fact that you can place some tag that will take over this function , but set values for a regular field and anywhere in the layout and at the same time be linked by name.

That's why I came up with the idea of using Label | A | Button so that they take over the function of radio buttons.

You raised questions about the operation of radio buttons. But I believe that your questions are so complex that they cannot be applied to the previous radio buttons. Here, in fact, we are discussing a new type of field with new functions. This new type of field may have a similar syntax to existing fields. But nevertheless, we are trying to combine ideas in a new property and not compatible with the previous fields. We can't just redo an existing element, as backward compatibility must be maintained. This means that when we add a new property, we must also add a new syntax that will clearly tell us that this new syntax is not similar to the previous one, and only in this syntax will everything work according to the new rules.

. My idea is not to create complexity for grouping fields, since the selected value is still one. It is one per column in the table or it is one per row in the table. From this point of view, ordinary fields do a good job. This field is <input type="text" readonly> or <input type="hidden">. From the data point of view, these fields are completely satisfied. I'm sure of it. But I am not satisfied with the design and the ways of assigning data to these fields. . You tried to give a new function to radio buttons. But I'm asking you to find the boundary in the radio button functions. 1 side is data, and 2 side is layout-design. I wanted the field to work as a text field from a data point of view, and as a radio button from a design point of view. So let's immediately think about what will be pushed away from the data or from the layout? The text field creates data perfectly, so we can come up with labels and links for this text field that will look like radio buttons, but work like a different type of fields, i.e. they will be linked to the text field.

[korenevskiy]

@leolopes Initially, my idea was based on the <Label> tag, which sets the values of the field. It is closely similar in syntax. But now, I realized that even though Label is as similar as possible in syntax. But still, Label is just a selection of the field and nothing more, and the fact that the browser sets the focus to the field, it's just a bun. Label is still plain text. My suggestion is Label makes in the active element. And Label can't be the active element. The active elements are <A> and <Button>. But in terms of accessibility and features, <A> should be intended to go to another page. And <button> is intended for working with data and the program. This means that even though the Label is close to my suggestion in syntax, it is not correct. And the <button> tag is correct, the closest element in terms of accessibility. But then it turns out it will be a completely new button, a new type of button.

[leolopes]

Hello @korenevskiy, I'm sorry for my absence, but I have been completely busy lately, and just didn't have the brainpower to analyze programming related matters after my long days of work.

I read all you wrote, and I agree with your points. We may have come to a consensus about the problems that we face with radio buttons.

The problem is: because I don't have experience in creating HTML specs, and I'm also marginally involved with the Open UI project, I don't actually know how to proceed from now on.

I would gladly hear @gregwhitworth about it, my doubts being:

1. should we completely change how radio buttons are implemented, based on @korenevskiy 's suggestions?
2. in either case, what should we do next? We already have some study on my research document. It only lacks illustrations / screenshots and an in-depth proposal.

What should we do next?

[gregwhitworth]

@leolopes @korenevskiy here is what I'd like to do. I'd like to get the issues raised on a telecon but I'd like to distill this large thread down to the options available and possibly sub options. @leolopes hit on one of them in number 1. Outline the problem statement and then that question so we can discuss it on a call and get agreement based on the developer/end user impacts.

Then if we agreed that things should be changed (and note we wouldn't change the current ones but probably define a new one to eventually replace them) what are the possible options and pros/cons.

in either case, what should we do next? We already have some study on my research document

Can you file a PR for this and get it into Open UI?

@leolopes @korenevskiy let me know if you have any questions.

[korenevskiy]

@leolopes Hello, my friend. It seems to me that we want to do the same thing, so you are my friend. I had a couple of attempts to publish the idea to the W3C. But I don't know much English, and I couldn't find the right way to publish on the site. . But let's discuss the ideas with you. Our tasks:

1. Short description.
2. Tasks that need to be solved with the help of our ideas.
3. Tasks that can be solved with the help of our ideas.

Tasks to be solved: -If we have a table with fields in each cell. That is, if we place radio buttons in the table cells, we must be sure that these radio buttons will be grouped inside each cell. At the same time, be sure that as many table cells contain radio buttons, the same amount of data should be in the array when sending the form, without using JS. Conditions:

1. Radio buttons should not be processed by JS.
2. Radio buttons must not contain an ID.
3. Radio buttons must have the name attribute with square brackets without an index (name= " user[]")
4. Radio buttons should only be able to be grouped inside a table cell(grid).
5. Such radio buttons should not be combined in the entire table!
6. Radio buttons must have a Label without the designation " FOR " and without specifying the ID of this radio button.

Decisions:

1. Radio buttons will not be grouped together, provided that the name contains square brackets without an index.
2. The label will use aliases for the attribute FOR. Example: <label for="_next">RadioLabel</label> or <label for = "_previous" >RadioLabel</label> which would mean that this <label> belongs to the next radio button tag or the previous tag.
3. To use a group of radio buttons in each table cell. We will try to use only one radio button in each cell of the table, since we already use the rule of the radio button whose name contains square brackets, we do not group. But then we need to place controls in the cells of the table with each radio button that will set the values of the radio button separately. I suggest this:

   <table>...
   <td>
   <input type=radio name= ' user[]'>
   <input type="for" for="_previous" value="Alice">
   <input type="for" for="_previous" value="Bob">
   </td>...
   </table>

   I came up with a new control with the FOR type. Whose task is simply to set a value in the field whose name is specified in the FOR attribute. But an alias is specified for the FORattribute. Similar to Label. I can also suggest using the A tag instead of the <INPUT> control. But then for the tag, you need to come up with a different syntax compatible with the A tag with similar functions. What suggestions do you have? Can you suggest other options to a colleague? The idea of writing the <group> tag is good, but let's think about how to add something new, while maintaining minimalism. Let's put 2 options on the scale.

   <table>...
   <td>
   <input type=radio name= 'user[]'>
   <input type="for" for="_previous" value="Alice">
   <input type="for" for="_previous" value="Bob">
   </td>...
   </table>

   VS

   <table>...
   <td>
   <group>
   <input type=radio  name="user" value="Alice">
   <input type=radio  name="user" value="Bob">
   </group>
   </td>...
   </table>

   And also think about all the advantages of each of the options, and all the disadvantages. Please what do you think about each of the options?

<table>...
<td>
    <input type=radio name= 'user[]'>
    <label for="_previous" value="Alice">
    <label for="_previous" value="Bob">
</td>...
</table>

There is also such an option. But it seems to me that this option has poor availability. And this option will be more difficult to implement than the first two. Since here the Label will actually no longer be a Label, but will be completely similar as controls. And so they are difficult to implement.

[leolopes]

@gregwhitworth Thank you for your answer. As soon as I can, I'll brush up the research document and outline the problem statement so it can be discussed on a telecon. I'll also prepare a PR, even though the document is not complete. I might contact you if I have questions on how better to do it.

@korenevskiy , thank you for advancing on the new code proposal, but by what @gregwhitworth said, I think we should first submit the problem to be analyzed by the rest of the contributors. I'll take your suggestions into consideration while outlining the problem, but I think I'll only give further tought on the actual code proposal after we have a feedback from the team. The first thing we need to do is have them understand why we are making this proposition :)

I'll get back to you

[leolopes]

Hello, @gregwhitworth , sorry for my delay. I've been struggling to find time.

I have re-analyzed the whole discussion and then updated the document: https://docs.google.com/document/d/1-TyGOSOcyV4VOqNyUDjEQLjrtssI8cd2-BVld9cJtlo/edit?usp=sharing

I kept the old explanations, because they still make sense, and then added the two main approaches under the "Proposed Anatomy" subtitles, where I explain what alternatives we face and what should be discussed.

Do you think it is enough for you to discuss on a telecon? Or do you want me to first make a PR? I understand the PR should fall under the "Analysis" menu, like this page, am I right? https://open-ui.org/components/datepicker.research

In the case I must make a PR, I presume I should include the problem to be discussed, right?

Thanks

[gregwhitworth]

@leolopes this is awesome, I would like to land that Google Doc into analysis, additionally the spreadsheet converted to a markdown table (there are online converters).

I pinged you via chat but can you bring the section that is "The Problem" and down into the Github Issue rather than referencing an external doc. I would like to discuss radio in general on the call as there are a few things here:

1. General anatomy of the radio input (not group)
2. Grouping options
3. Required indicator (generalize this?)

[leolopes]

As asked by @gregwhitworth, the following is the research problem laid out so we can discuss. Reading the rest of the document and discussion on this issue is still important to understand how we got to this, but the following can be enough.

Proposed Anatomy - by tag hierarchy

This section shows the proposed visual constituents for the Radio Button Group, which is here considered to be the actual component, while the radio buttons are a part of the group.

• Radio Button Group (the actual component)
  • Group Label (functions as a label for the whole group)
  • Required Indicator
    • Radio Button (at least two required)
      • Checked Indicator (input)
      • Label (optional)
    • Radio Button
      • ...
    • ...

The problem

The above anatomy is regular enough to be assembled in a way similar to (but more complex than) a <select>. Attributes set on the group would allow the developer to set the whole group as "disabled", "readonly", vertically or horizontally laid out, types of display (like buttons, radio buttons, combobox, etc), and attributes set on the radio buttons would set their specific states, as we do with <option> tags. It is important to understand that the function of radio buttons is almost the same as a select tag, and this is why the comparison makes sense.

However, by being so regular and requiring a specific HTML structure, we would lose structural flexibility. For this, here is another proposal.

Proposed Anatomy - by attribute binding

If the above proposal would accept other nodes as valid children, or at least a set of attributes that could replace some of the nodes (eg. an aria-label to replace the "Group Label"), the flexibility could be reestablished, by allowing the construction of more complex layouts, eg. semantic differential scales.

This could be achieved by combining table elements with radio button inputs and grouping attributes.

The problem

One could say it’s exactly the same behavior we have nowadays, because the radio buttons are bound together by the name attribute. However, the current structure still depends on a fieldset tag to visually group and label the collective of radio buttons, and this requirement prevents us from doing that exact table layout with actual tables, because we can’t use the fieldsets to group rows and put a legend inside it as well.

Today, the structure of such semantic differential scale could be represented like this:

Question	Answer 1	Answer 2	...
(table cell)	(input name=1)(label)	(input name=1)(label)	...
(table cell)	(input name=2)(label)	(input name=2)(label)	...

Each field has its label (or could have an aria-label), but the group itself has no formal label. This could be solved by having a way of binding a label to a group by using attributes, like this:

Question	Answer 1	Answer 2	...
(groupLabel labels=1)	(input name=1)(label)	(input name=1)(label)	...
(groupLabel labels=1)	(input name=2)(label)	(input name=2)(label)	...

The above case creates a new tag (or an unsemantic tag with a new aria-attribute) that labels the whole group by referring to its name.

Another alternative would be:

Question	Answer 1	Answer 2	...
(input name=1)	(option group=1)	(option group=1)	...
(input name=1)	(option group=3)	(option group=2)	...

In this case the label is the actual input, and it could have an appearance of a simple text. The answers, on the othter hand, could be an alternative use for the <option> tag, with an attribute to reference the name of the input. Selecting an option would change the value of the input.

To be discussed

The two main approaches presented above should be analysed in order to decide

• In the first case:
  • whether the first, more rigid proposal should be developed;
  • or maybe even create an attribute to the <select> tag that would make it behave visually like radio buttons
• Or, in the second case, strive for flexibility and:
  • propose modifications to the labeling of the current radio buttons;
  • or change the tags used to create them, like in the last example.

[leolopes]

On june 3th we had a Telecon to address the possible ways to handle the radio buttons. The telecon's minute is here: https://www.w3.org/2021/06/03-openui-minutes.html

The key points I took from it are:

• We should make two proposals: a rigid one, based on an hierarchy similat to select, and a more flexible one, with inputs and labelling being bound by attributes.
• @chrisdholt told us that the ARIA impementation requires the radio buttons to be direct children of a radiogroup , which affects mainly the flexible proposal, making it less flexible, in a sense.
• @una and @gregwhitworth would still like to see the flexible proposal bound by attributes / tags, and have accessibility be thought around it, because it's so important to have it built in the Open UI components.
• @gregwhitworth would like the name attribute to be the standard way to bind things (even though "binding" might mean different things depending on context.
• Even having both proposals, probably the rigid one would be the most used by devs, because it is the more frequent use case and will be easier for them to implement.
• @bkardell mentioned that we should also have to worry about keybord navigation, order of focus, etc.

@gregwhitworth at a point mentioned that maybe we could make the semantic scale layout work with the rigid proposal (because CSS would be able to layout it very freely), but still, I think if we want to account for other kinds of really "disjointed" layouts, we should have a flexible proposal so as to not demand a tag hierarchy.

Based on that all, and on my current knowledge, I'll be making both HTML proposals and PR to the repository. I will probably, however, end it on the HTML and have the other discussions (AT, ARIA, A11Y) be made after we have something more concrete to analyze.

[leolopes]

I created a PR for the proposal. I would like the community to validate the basic idea before going further. If no one makes any remarks before it's merged, I'll still leave it as a draft on the website for a while, open to criticism, before creating the full proposal.

[korenevskiy]

In the draft, you need to place short examples of sentences and a brief description of these examples. So that participants do not have to run through the links. Thank you for your active participation.

[leolopes]

Hi @korenevskiy , what sentences do you mean exactly? Thanks

[korenevskiy]

Examples of HTML code with the display of new attributes and properties.

[leolopes]

@korenevskiy Oh, those are on the Pull Request

[korenevskiy]

@korenevskiy Oh, those are on the Pull Request

I was once on a forum where they ask questions to solve problems. They told me there. If you (me) want your question to be solved? Then lay out your attempts to solve the problem. So that people can see that your problem is important to you, so that people can see the code in which they can solve errors. So that the help of knowledgeable people requires a minimum of effort to help me. . After such a remark to me, I made conclusions. In order for the social cause to move, it is necessary not only to identify the problem. This is not enough. But it is also necessary to show a solution that will make life better. Because for many, this problem is not a problem and they are not able to see the best opportunities. . That is why I wrote above possible solutions. That is, it is necessary not to show the problem as a critic. And it is necessary to conduct a professional sale, with the promotion of ideas. I'm just not indifferent to the problem of radio buttons. Therefore, it seems to me that actions without ready-made examples are generally ineffective. And I want a result from the community in this matter.

[leolopes]

@korenevskiy , yes, I agree with you, that's why those proposals were studied, created, and put on the Pull Request, so that the community can see, comment and contribute.

[korenevskiy]

@leolopes
I want to ask you for your advice. Do you think this is something worthwhile or not an interesting idea at all. Here ... Manage GRID cell as FLEX.

[leolopes]

Hi @korenevskiy , I'm going to take a look and let you know if I have any idea ;)

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.