5 ms·

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

by jamamp 2y ago

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.

lelandfe 2y ago
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 https://a11ysupport.io/tests/html_label_element_implicit ...but it does look worse than explicit: https://a11ysupport.io/tests/html_label_element_explicit https://a11ysupport.io/tests/html_label_element_explicit
- swatche 2y ago
  The spec says either way (https://www.w3.org/TR/html401/interact/forms.html#h-17.9 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 2y ago
    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-labels-implicitly 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 2y ago
      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 2y ago
        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 2y ago
        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_implicit.html https://a11ysupport.io/tests/html/html_label_element_implici...
        extra88 2y ago
        They must have fixed it in Safari 18. I'm running macOS 14.6.1 and at the beginning of the month it didn't work but I also just tried it and now it does.
      - acka 2y ago
        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/ https://www.freedomscientific.com/products/software/jaws/ [2] https://webaim.org/blog/jaws-license-not-developer-friendly/ https://webaim.org/blog/jaws-license-not-developer-friendly/
- chenmike 2y ago
  There’s no reason you can’t do both, and indeed some a11y linters recommend doing that
- oxidant 2y ago
  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.
tshaddox 2y ago
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 2y ago
> 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 2y ago
  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 2y ago
    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.

by jamamp 2y ago

lelandfe 2y ago

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 https://a11ysupport.io/tests/html_label_element_implicit ...but it does look worse than explicit: https://a11ysupport.io/tests/html_label_element_explicit https://a11ysupport.io/tests/html_label_element_explicit

swatche 2y ago
The spec says either way (https://www.w3.org/TR/html401/interact/forms.html#h-17.9 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 2y ago
  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-labels-implicitly 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 2y ago
    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 2y ago
      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 2y ago
        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_implicit.html https://a11ysupport.io/tests/html/html_label_element_implici...
        extra88 2y ago
        They must have fixed it in Safari 18. I'm running macOS 14.6.1 and at the beginning of the month it didn't work but I also just tried it and now it does.
    - acka 2y ago
      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/ https://www.freedomscientific.com/products/software/jaws/ [2] https://webaim.org/blog/jaws-license-not-developer-friendly/ https://webaim.org/blog/jaws-license-not-developer-friendly/
chenmike 2y ago
There’s no reason you can’t do both, and indeed some a11y linters recommend doing that
oxidant 2y ago
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.

tshaddox 2y ago

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 2y ago

> 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 2y ago
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 2y ago
  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.