Meeting minutes
<masonf> (because I forgot)
una: anchor pos explainer is out! Take a look
<una> https://
<una> https://
#251
<una> Here's that explainer to take a look at later: https://
leo: started researching radio buttons, thought it would be as simple as a checkbox. Radio buttons, they work kind of like select boxes. Allow us to choose one option from a set of options. While the checkboxes only allow us to set a bool value for one input. The radio buttons, they are mostly a different layout for a select box. They allow us to choose from several options, only one. Main diff being layout allows us to decide where
we want to make the info readily available for user to see, or maybe we want to compress every option in a single line (select box)
leo: radio buttons have quirks that select box doesn't have. Radio buttons could have a similar structure than select box. Could have a tag for a radio button group, and a different tag for every option in the group, a label for the options, much like select box. Could slap an attr to a select box and have it behave visually like a radio group, logic is so similar. However, would lose flexibility radio buttons give us. Could break
the component apart, place the radio buttons all over the page and have them bound together by the name attr, even though they are visually apart
leo: if we tried to change the structure of the HTML of a radio button group to like a select box, we would lose this flexibility. Radio button grouping is a little weird. When we talk about labels, every input field has its own label. Could bind w/ for attr. When we're talking about the radio buttons, we're not talking about the group, we're talking about each option. It's like we have a select box and label each option. We don't
have label for the group. Would need fieldset w/ legend. While this is ok, this is a diff use for the fieldset. Grouping a single input result instead of different inputs. All part of a single possible choice.
leo: wouldn't be a big problem but there are some cases where we can make semantic differential scale, can build a table with a question in each row, each column has a radio button that represents an answer to that question. If we actually use tables, we don't have anywhere to put the fieldset. Would have to make the whole table a fieldset. But if we need a single table w/ all the inputs, then we miss a place to put a fieldset for
the radio buttons. This is kind of an edge case but we see this type of layout a lot, presume other situations where we have to retain the flexibility of the radio button groups, we have to make an HTML structure that would actually allow us to group them not with fieldsets. Need something other than just the name attr. And maybe this would make it less repetitive. Maybe wouldn't need to repeat the value for every instance of the
input field
<bkardell_> I think x-forms was like this
leo: [presenting] could have a structure similiar to select box, but that would limit flexibility. Can't use fieldsets for each row because we'd break the table apart. Need some binding to group the table as a whole. Table cell with question and inputs with labels bound by name attr, the only thing that binds them with the question is the [table semantics] Could have special tag for group label that has an attr that binds it to the
name attr of all the radio buttons. Or we could have, as suggested on the issue, maybe have only one input field that represents the selected choice. The radio button would actually be the question. The value of the whole group would be set on this input. The answers would be a use for the <option> element. Bound to input by attr. This would allow us to always try to target the input tag to get the value.
leo: question we have is, if we're creating components for it, should we have a rigid structure like <radioGroup> (like select box), or retain flexibility and propose another way to bind a label to the actual input group.
leo: Greg said maybe we can have both
chrisdholt: great, ton of research. One thing that stands out to me, I think this is a complicated issue but things like the name attr would work well for binding inputs together, but then we'd have to consider impl from ARIA and ARIA radios. We associate ARIA radios under a radiogroup component because of our requirements. Those end up being different, unique bit is we can't bind with the name...throwing a little bit of gasoline on
this, but it's something tha needs to be addressed. Came up with checkbox, input type checkbox and ARIA checkbox, they're different beasts in some sense. Holistic solution needs to be flexible
gregwhitworth: how do his options don't fit into what you outlined?
chrisdholt: ARIA spec says that ARIA radio needs to be child of radiogroup. AT expects direct descendent. The platform obfuscated some of the pain of association. Associating using w/ name attr. Platform has special magic we don't get to use that causes this problem
gregwhitworth: the reason I said I recommend both, I agree w/ flexibility aspect that you'd outlined, need a grouping mechanism that provides flexibility that allows authors to sprinkle things in a DOM structure that's not strict. That said, large/common paradigm of radio groups that could be a common component
gregwhitworth: why is name not necessarily still sufficient for cross dom structure binding?
chrisdholt: it's not an actual input, it's an ARIA radio
gregwhitworth: so the binding doesn't magically happen for you
chrisdholt: yeah...we have some requirements that pushed us into the ARIA direction. Both implementations exist and are valid, one has benefits the other doesn't?
bkardell_: if you were trying to do this with ARIA in a table, the label you can do with an ARIA attr, but the grouping is the million dollar question
chrisdholt: from AT standpoint, each direct child of radiogroup would have a role of radio. We're blocked by this scenario because we're not inputs
<gregwhitworth> chrisdholt do you have a public bug on that blocking issue?
leo: wasn't thinking about ARIA but that makes the problem a little bit bigger
leo: was looking at consistency aspect, labels and fieldsets are used in an inconsistent way when we're talking about radio buttons. This doesn't click with me very well. We could have ARIA work w/o a parent HTML tag. Wouldn't have solution for the whole group. This is the basic problem we have here. Implementation is outside of the scope of my work. IDK how to do this.
bkardell_: this is a problem for a lot of controls, right?
gregwhitworth: yeah binding comes up everywhere
gregwhitworth: it seems like the crux here is the binding is only available on an input. The labeling aspect is a different question, whether rigid or flexible, I imagine group would agree we generally want flexibility
<gregwhitworth> melanierichards: I was curious to see
<gregwhitworth> melanierichards: this is just a subset of the problems we're trying to solve
<gregwhitworth> melanierichards: is there a different way to solve the root problem?
<gregwhitworth> melanierichards: chrisdholt you said you have reqs that require you to reach for aria-role rather than the HTML input?
<gregwhitworth> melanierichards: maybe we unblock that rather than making name= work on everything?
<gregwhitworth> melanierichards: we'd want to have something aria specific solution
<gregwhitworth> chrisdholt: yeah it's just frustrating because the platform just handles it with input radios
<gregwhitworth> chrisdholt: there's a disconnect with custom elements
<gregwhitworth> chrisdholt: I would love some way to logically group things that aren't direct descendants in the DOM
<gregwhitworth> chrisdholt: I can handle keyboarding, form association, etc
<gregwhitworth> chrisdholt: but the minute that role of radio is not a direct descendant of radio group a11y is out the window and nothing I can do
<gregwhitworth> chrisdholt: use input that is native
<gregwhitworth> chrisdholt: that's not an option for us
<gregwhitworth> chrisdholt: tough
gregwhitworth: would be cool to have that blocking use case somewhere, ultimately it is that grouping mechanism we want to solve
<gregwhitworth> +1 to that una
una: really good points, I do think a part of what we are trying to solve is building accessibility in. Ways we can work around this with some kind of binding tag, maybe not inside in the radiogroup but in sibling elements...this is not a new pattern to have this tag, we can provide that here. Maybe best practices. Tag maybe not the primary option because it would add complexity for other use cases
gregwhitworth: agree, should do both. Thing I want to make sure is captured, Chris is blocked in some other way and maybe it needs a new issue or Chris can pile on this issue.
una: good next step would be a proposal of what these both look like
<chrisdholt> It's noted in the issue (very early on) - I can add more if need be
<chrisdholt> Unfortunately I've got to drop for an internal sync. Thanks all! This is a tough problem but agree it's definitely solveable, especially with this group.
<chrisdholt> On the CSS note - if I need these represented *in* the table, that loses the semantics needed to represent for AT as well.
<chrisdholt> OK, that's all!
<chrisdholt> Thanks!
leo: there are some advantages to radioGroup tag. Could set a lot of attrs to radioGroup to have it laid out in a different way. We could maybe do all of this with CSS. Hmm. I'm not sure. The way some of the design systems use this kind of structure, options work like radio buttons, maybe larger, smaller, vertical, horizontal, but the way they've abstracted it, that could be achievable in CSS. So this one just makes the grouping
simpler
gregwhitworth: that would be why we'd go do this. Just have people reach for radiogroup. Understand limitations, they're probably majority use case though. Technically we could achieve layouts like the one you've shown w/o table.
gregwhitworth: checkbox group could work the same way, very prevalent, but there's no binding mechanism in any meaningful way other than rolling yourself. I think this is technically the proposal for the anatomy if you presume the group mechanism exists.
una: I think the grouping is fine, what we're not seeing yet is the solution for the disjoint radios. Not as much an a11y problem as a a declaration problem. How to declaratively have non-sibling radios a part of the same grouping. How do we tell the DOM this is a group, don't let more than one be selected?
leo: this proposal of Sergei's, I could see...we have an input, and the <option>s would work like radio and label at the same time. Clicking on them would populate the value of the input.
leo: we could maybe have this implemented in an accessible way
leo: the fact that this is on input could make it easier to handle with JS, only one place to look at for options. So I actually like this one. Radio input is the main Q, and the options are handles for this input field.
leo: I have no idea how this would translate to HTML, would need new HTML
una: yeah that new HTML is what we should think about next
gregwhitworth: how complicated would it be to say, "name attr binds any element that has the same name"
gregwhitworth: would potentially come back w/ spec text and maybe start by saying I would make name work with any element, and how the browser knows what to bind is based on that model that already exists.
gregwhitworth: re-spec'ing how name binding works for radios today, but with any element
una: next steps to spec out a solution
gregwhitworth: leo, ping me on Discord, I'm happy to help
bkardell_: what does it mean to bind in this case? There's form value/submission, there's key bindings, role bindings...it would be great if you had a shorthand for this that didn't require you to bolt on a thousand ARIA things.
present?
<bkardell_> doh I was going to add something to clarify for the minutes - I'll add them to the issue
<bkardell_> basically just that ^ by this I mean for example that if you do all of these things without talking about the patterns that make radio buttons in the sequential focus order and arrow keys and things, even still you have to resort to js too - that would be really sad too