Checkbox and Radio inputs inside labels about mini.css HOT 3 CLOSED

This is an interesting suggestion. I'll check for conflicts and, if none exist, will try to implement it in v2.1. The class might not even be required, making it even simpler to use and remember.

from mini.css.

I just now got to dealing with this issue, sorry for the delay.

I was thinking of moving the inputs inside the labels, but this might have undesirable implications in terms of accessibility and/or mnemonics for people who use mini.css. I will look into this further in the following days and give you an update.

If you have the time, could you please provide me with an example of a web framework that could be a culprit causing this problem? Just for research!

from mini.css.

After some quick research, it seems like most people prefer explicit labeling of form controls, rather than implicit. Many of the sources I found state that implicit labeling can be a problem for screen readers. In fact, MDN states the following:

A widget can be nested inside its <label> element but even in that case, it is considered best practice to set the for attribute because some assistive technologies do not understand implicit relationships between labels and widgets.

Most ARIA guidelines I have found suggest using explicit over implicit labeling, at least for the time being. In fact, the latest draft of WCAG 2.0 doesn't even mention implicit labeling in its techniques (WCAG 2.0, H44).

Based on the fact that accessibility comes before compliance with web frameworks and seeing as most of the other CSS toolkits and frameworks use explicit labeling for most of their elements, I am closing the issue for now. If, at some point, implicit labeling becomes the norm, I would be glad to reopen the issue and change the way mini.css implements the checkbox and radio button components' labels.

from mini.css.