Hi,
As of today, the component uses the selected/defaultSelected props, while, as per standard, radio buttons should use checked (<input type="radio"> - HTML | MDN)
The fact that the component uses selected here causes issue with third-party library integration such as the form RVF (https://www.rvf-js.io/) that sets the defaultChecked property (and not the defaultSelected).
As Polaris web components try to stay as close as possible to native forms, this inconsistency should be solved right now while Shopify can still do breaking changes 
1 Like
@Anthony_Frehner sorry to ping you on this but I can see that the Polaris is now nearly stable, but this issue has not been adressed. Could you please have a look at this one? This would be a breaking change so I think you should tackle this one asap before you can’t do any other breaking change. The way this component works is not following the spec and is an outlier here.
I believe ChoiceList specifically went with selected because the design of a ChoiceList isn’t always associated with a checkbox or a radio button. Sometimes they look like tiles in a grid, sometimes they’ll look like grouped buttons with an active state. Our admin design doesn’t have those (yet), but other surfaces like Checkout could.
I don’t agree on that @Anthony_Frehner . ChoiceList is implemented using radio buttons and should therefore be consistent here. Radio/checkbox buttons use checked, select use selected.
The way they visually display has nothing to do with how they are technically implemented. In this case this will cause a lot of incompatibilities with validation libraries (such as RVF) that assumes (rightfully) that checkbox/radio are using the checked prop.
2 Likes
+1
this is causing a lots of pain with Reach Hook Form also
@Anthony_Frehner I want to re-iterate on this one: the current component is NOT spec compliant (which is a pity considering how all other components are closely following the spec). Please change that before it is too late and everybody rely on this 
Another issue @Anthony_Frehner with those is that as per spec, the name should also be supported on indiviudal (as this is how it happens), and the name should not be required with the (although, for convenience purpose, you could keep it and replicate internally).
The correct usage of this component should therefore be:
<s-choice-list label="Foo">
<s-choice name="XX" value="v" checked>Value</s-choice>
</s-choice-list>