5 ms·
There is goodness to putting your label tag, with the for attribute that points to the input, AFTER the input tag in the DOM that you may not be aware of! Here
by EdSharkey 10y ago
There is goodness to putting your label tag, with the for attribute that points to the input, AFTER the input tag in the DOM that you may not be aware of!
Here are some selectors you can use with that setup:
input + label { ... }
input ~ label { ... }
input:checked + label { ... }
input:checked ~ label { ... }
Those selectors let you style the label based on the STATE of the checkbox, and they work all the way back to IE7. This stateful CSS is very powerful because you can make the input tag visibly hidden and style your label tag to appear as a custom widget or checkbox - and have it look different when toggled. Take a look at html5 boilerplate's visuallyhidden CSS class to see a particularly ninja way of hiding an element. Think of what can you achieve with just CSS and markup that maybe you needed jQuery or JavaScript to achieve in the past!
By the way, using the visuallyhidden class is the ideal way of hiding a tabbable element like a checkbox while keeping it adjacent in the flow to its related elements. This method of hiding is especially kind to low vision users of your site who use tab to navigate your forms.
From an accessibility standpoint, having label-with-for is helpful to screen readers of varying quality out in the wild. label-with-for ensures the screen readers will never be mistaken about which label goes with which checkbox.
.visuallyhidden, input:checked, label-with-for, and the +, ~, and > combinators, plus WAI-ARIA attributes can be used to make visually appealing, yet accessible, widgets without JavaScript.
- nostrademons 10y agotracker1 has a sibling thread with an alternate formulation that achieves this but still has the label as a parent of the checkbox: https://news.ycombinator.com/item?id=12307236 https://news.ycombinator.com/item?id=12307236
- jessaustin 10y agoThanks for all this; I was hoping for some replies like this when I posted my comment. I guess I haven't needed to hide stuff in precisely that way. Of course there's no parent selector in CSS, but if we have something like this: <label><input type="checkbox" name="cb"> <span>My checkbox label</span></label> then we can have this: label input:checked + span { ... } Maybe that <span> is more sinfully extravagant than a "for" attribute, but it seems DRYer to me. [EDIT:] It seems sibling comment had the same idea while I was testing this on the other tab.
- EdSharkey 10y agoRight, the span in this case is an extra tag that you don't need. Nesting an input tag under label has always struck me as having ambiguous meaning. Are you saying that the checkbox "belongs to" the label, or maybe "is a child of" label? Shouldn't it be the other way around, if anything? One of the accessibility guidelines of the WCAG is that content in your markup MUST flow in the same direction as it is rendered on your page. This is recommended so that screen readers will read the page aurally in the same way as a sighted-user would read the page visually. If you follow that guideline, then placing your input tag before the associated label tag in the DOM usually makes sense because that is a common visual ordering for those elements. The 'for' attribute in the label tag has semantic value that the span doesn't, you're just adding that span so that you can use the CSS combinators. If I squint, you're DRY, but once I unsquint I think YAGNI. :) Seriously though, it really is a social good to strive to make your page content accessible both stylistically (for the low vision users, color blind users, etc.) and semantically (for the screen reader users).
- jessaustin 10y agoISTM checkboxes are the only input type for which it's more natural for the label to come after the input. An input inside a label has had an unambiguous meaning for decades. Why haven't screen readers caught up?
- EdSharkey 10y agoIt's not a matter of screen readers catching up, it's a matter of blind folks not having the latest tech or being stuck on an ancient version of a screen reader/browser combo. They maybe don't have helpful IT resources in their lives or money to help them upgrade? It's actually a big bummer. There is virtue in making pages that gracefully degrade but still deliver the goods on legacy platforms. I believe the :checked pseudo-selector is only useful on radio and checkbox. It's just serendipitous that the common visual ordering matches the useful DOM element ordering for CSS styling in those cases. I would expect label to come earlier in the DOM for other types of form elements so we could be compliant with the WCAG and we would still rely on the for attribute to link the two tags together for the screen readers.