Label widgets should have a 'for' attribute associating them with their controls.

[MariuszJurowicz]

Description labels should be associated with their controls with the for attribute.

---

Original title: The CheckboxWidget could have the ability to render label on the left
According to twosigma/beakerx#6057

Maybe Checkbox widget can have the possibility of rendering it's description as regular DescriptionWidget label?

[jasongrout]

When we made the change, we looked at various OS guidelines for checkboxes, and every one (Windows, OS X, Gnome, etc.) had the description of the checkbox on the right of the checkbox. That's why we made the change. What are your thoughts? I think we made a mistake originally by putting the description to the left of the checkbox.

[jasongrout]

Is the concern about the placement of the description, or about the DOM structure of the checkbox, or something else?

[MariuszJurowicz]

It's mostly the DOM structure. That forces to use the css hacks to place the label on the left side in our case (Or to overwrite the render method of the CheckboxView). In our case if we have form with every label on the left side, the standalone checkbox looks weird with the label on the right.

[jasongrout]

The DOM structure was designed so that the label would be semantically associated with the checkbox for accessibility (screen readers, etc.) and so that clicking on the label could toggle the checkbox (ironically, this was done at a TS sprint: #1346). In fact, we need a better solution for the other description widgets so that their labels are also associated with their controls too.

[scottdraves]

While it's certainly true that the standard and default position should have the label on the right, we happen to have an API that requires the opposite. Maybe not commonly enough needed to support. We just wrote our own. No worries if it's considered out of scope.

[MariuszJurowicz]

Yes, and I'm wondering what about the for attribute? Isn't it enough for describing the input - label reference? You can use it in every case to create the labeled control elements.

[jasongrout]

I'm wondering what about the for attribute? Isn't it enough for describing the input - label reference?

Yes, I think so. We would also need to check to see if that also enables the browser click-on-label-to-toggle-checkbox. If it's semantically equivalent (I think it is), then I wouldn't be opposed to a PR changing the DOM structure to have a label for attribute.

[jasongrout]

(especially if such a PR added it for other description widgets)

[MariuszJurowicz]

Yes, the labeled control elements like checkboxes, radios, inputs etc. are toggled (or focused in some cases) by the click on it's label https://www.w3.org/WAI/tutorials/forms/labels/.
The only rule is to assign the id attribute to the controlled element. But it's not an issue here as the single widget has it's own id eg. the model_id.

[jasongrout]

The model id wouldn't work, since that is shared across views. We also can't use the backbone view id, since that is likely to be duplicated across different notebooks on the same page in JupyterLab. We'd probably need to generate a new view uuid.

[jasongrout]

I'll update the description to have label widgets with a for attribute associating them with their controls.