[jamamp]

I think the article has good sentiments about it. Actually using your application a lot helps polish it down a ton.

However, wouldn't putting the input inside of the label (before the label text) be a better solution than fiddling too much with CSS and flexbox? It's more foolproof to ensure clicks within the label activate the input, and eliminates the need for the "for" reference.

[tshaddox]

That’s what I generally do as well, but sometimes I don’t like how it leads to empty space that is part of the clickable area. This will happen if you have a label tag with the label text above the input (and the label text is much narrower than the input widget). This isn’t a huge problem, but it always bugs me.

[philo23]

> However, wouldn't putting the input inside of the label (before the label text) be a better solution

The one potential downside to doing it the way you describe is (assuming the same CSS flexbox layout) now all the white space on the right side of the label acts the same as clicking the radio/checkbox. Which is almost like the opposite problem to the original issue.

This might actually be a good thing for some designs/contexts, but not always. For example, on mobile it might lead to miss-clicks while trying to scroll past the <label>s

[bastawhiz]

That's only true if you let your labels be as wide as the parent container.

> on mobile it might lead to miss-clicks while trying to scroll past the <label>s

You can scroll on mobile by swiping over the text of a label itself without activating the input; this isn't generally a concern.

[philo23]

Well with the CSS in the post they would end up as wide as their parent. If you made it an inline flex box then yes, that wouldn’t be an issue.

> You can scroll on mobile by swiping over the text of a label itself without activating the input; this isn't generally a concern.

Generally speaking yes, but there’s still a chance of triggering it by touching the whitespace by mistake. Whereas if it wasn’t the full width it just wouldn’t be possible to begin with.

[lelandfe]

label>input instead of label+input. This is called an implicit label - time was, there were concerns about screen readers that couldn't interpret them.

I don't know how bad that is in practice: https://a11ysupport.io/tests/html_label_element_implicit

...but it does look worse than explicit: https://a11ysupport.io/tests/html_label_element_explicit

[swatche]

The spec says either way (https://www.w3.org/TR/html401/interact/forms.html#h-17.9), but I agree with putting the input inside the label for the acessibility and avoiding the blank space issue.

[lelandfe]

The HTML spec doesn't speak much on a11y guidelines. Here's what the W3's WAI says https://www.w3.org/WAI/tutorials/forms/labels/#associating-l...

> Whenever possible, use the label element to associate text with form elements explicitly

> [..]

> In some situations, form controls cannot be labeled explicitly... Generally, explicit labels are better supported by assistive technology

...but people have been saying that for like 15 years now, I don't know how big of a deal those failures are. That'd be a good blog post

[dumbo-octopus]

Parent link says NVDA, VoiceOver, and JAWS all support the implicit way. That’s the industry standard suite to support, they’re all free and available across all platforms.

If some company makes a shoddy half baked solution for sale (looking at you, Dragon), and they don’t understand basic HTML that has been standardized for years, that’s not my problem. The same way I don’t only use the subset of web technologies that the AOL Premium web browser supports for $10 bucks a month.

[extra88]

Yes, all the screen readers handle implicit labels just fine. As the a11ysupport.io tests show, it's Voice Control software that fails, not just Dragon NaturallySpeaking but also the built-in Voice Control in macOS.

I think the implication is these voice control programs aren't using the accessibility tree built by the browser but parsing the DOM themselves, poorly. It's not really surprising for Dragon since it does hardly anything in a browser without its browser extension installed and extensions don't have access to the accessibility tree. It's more surprising for macOS Voice Control.

[dumbo-octopus]

Voice Control also works perfectly fine, I just tested it myself on their provided sample. Say "select your name" on this page: https://a11ysupport.io/tests/html/html_label_element_implici...

[acka]

JAWS isn't free[1]. Using the trial version for accessibility testing goes against its EULA[2].

[1] https://www.freedomscientific.com/products/software/jaws/

[2] https://webaim.org/blog/jaws-license-not-developer-friendly/

[dumbo-octopus]

Ah, I got it mixed with Orca. NVDA is the thing to target in Windows.

[chenmike]

There’s no reason you can’t do both, and indeed some a11y linters recommend doing that

[oxidant]

Put the input inside the label and still use "for" on the label. No way to test right now but that's what I usually do.