[Bug]: The <fluent-radio> component doesn't have the default slot

[HcySunYang]

Component

Radio

Package version

3.0.0-beta.62

@microsoft/fast-element version

2.0.0

Environment

System: OS: Windows 11 10.0.22631 CPU: (16) x64 AMD EPYC 7763 64-Core Processor Memory: 49.15 GB / 63.95 GB Browsers: Edge: Chromium (129.0.2792.89) Internet Explorer: 11.0.22621.3527

Current Behavior

There is no default slot in the component:

So the following use case doesn't work:

Expected Behavior

The following code should be working well

Reproduction

https://stackblitz.com/edit/typescript-1yytph?file=package.json,index.ts

Steps to reproduce

just open the repro link to see what happens

Are you reporting an Accessibility issue?

None

Suggested severity

High - No workaround

Products/sites affected

No response

Are you willing to submit a PR to fix?

no

Validations

• [x] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [x] The provided reproduction is a minimal reproducible example of the bug.

[chrisdholt]

Thanks for the feedback here, it's definitely appreciated! We can definitely look at the ergonomics for radiogroup - there are a few things that we're dealing with though:

1. If we slot text then the label must be within the component. The label being inside the component opens this up to other accessibility issues for other implementations - namely, where a radio and it's label are in different boxes. ARIA cannot be associated across shadow DOM trees - it just won't associate as they are different documents. While this is behind a flag in chromium, it's not fully supported broadly enough for inclusion in Fluent.

2. The fluent-radio itself has a role of radio, which means projecting content within it could mess with semantic structure. We'd need to validate if this is reasonable before supplying the ability to slot a label. In this case, the element would require a label element to slot as there is no current substitute for form association of labels with non HTML labels. We've proposed changes to the spec to support this, but that will lag.

3. DOM size - A slot likely won't come with much cost for all implementors, so if 2 above works as expected we could provide a default slot (label would still likely be required due to number 1 above).

All said, I do think that the ergonomics of radiogroup can improve - thanks for this and we'll take a look. @davatron5000 as FYI