KRadioButton: Improve flexibility and accessibility of labels

[MisRob]

Product

Kolibri

Example: choosing a new super admin when changing facility

Desired behavior

(1) KRadioButton can receive HTML label content

So that we can easily use components to render label content, for example, this radio button label

can't be provided as mere text as it's generated by KLabeledIcon component:

<KLabeledIcon :icon="isCoach ? 'coach' : 'person'" :label="user.full_name" />

(2) KRadioButton uses explicit labels

• Explicit labels are labels that are linked to input via its id passed to <label>'s for attribute.

• In support of (3)

• Explicit labels are said to work better in regards to a11y:

  Generally, explicit labels are better supported by assistive technology. (W3C)

(3) <label> can be defined outside of KRadioButton

<label for="firstname">First name:</label>
<KRadioButton id="firstname" />

• To be able to work with <label> the same way we'd work with it when using it together with the native <input> that KRadioButton models:

<label for="firstname">First name:</label>
<input type="text" name="firstname" id="firstname">

• To have control in regards to <input> and <label> order
• For more flexibility when dynamically switching between KCheckbox and KRadioButton when the label is the same without the need to duplicate label code (useful especially for more complex labels that are generated by other components):

<KCheckbox v-if="allowMultiple" id="select-user" />
<KRadioButton v-else id="select-user" />
<label for="select-user">
   <KLabeledIcon :icon="isCoach ? 'coach' : 'person'" :label="user.full_name" />
</label>

• For this to work, we also need to be able to pass id to KRadioButton so that we can use it in for attribute of label.

Summary

Label content could be provided in several ways

(a) Simple text via the label property
(b) HTML content via slot
(c) Independently of KRadioButton

In regards to (a) and (b), when <label> would be rendered inside of KRadioButton, we'd use explicit labels. To achieve explicit labels support for (c), KRadioButton will need to receive its inside input's id from outside via a prop.

Current behavior

• KRadioButton only supports passing text for the label via the label property
• It uses implicit labels (<input> wrapped in <label> without having these two linked with id and for)

The Value Add

• Flexibility, efficiency
• Explicit labels improve accessibility

Possible Tradeoffs

• In more advanced use-cases (b) and (c), developers would need to make sure not to forget about label text truncation instead of relying on internal text truncation that works when label text is provided via the label property.
• Since there would be more ways to label radio button, we couldn't throw an error anymore when currently required label property would not be provided which is helpful to make sure we don't forget to label

However, I think there's no need to limit ourselves in regards to supporting more complex scenarios. To solve this, I'd suggest that in documentation, we encourage (a) whenever possible, provide usage examples, and include truncation and a11y warnings for other use-cases.

[nucleogenesis]

Since there would be more ways to label radio button, we couldn't throw an error anymore when currently required label property would not be provided which is helpful to make sure we don't forget to label

could we check in mounted whether the slot or prop are used and if neither are, throw an error - if even if only in dev?

[MisRob]

@nucleogenesis Yes, that's a good idea

[MisRob]

In light of #350, this tradeoff

In more advanced use-cases (b) and (c), developers would need to make sure not to forget about label text truncation instead of relying on internal text truncation that works when label text is provided via the label property.

may not be tradeoff, but actually the desired behavior

[MisRob]

Assigning myself to update requirements here