4 ms·

I don't understand why putting the <input> inside the <label> is so unpopular. It completely avoids these problems and you don't need to come up with a unique i

by wmil 2y ago

I don't understand why putting the <input> inside the <label> is so unpopular. It completely avoids these problems and you don't need to come up with a unique id to use with 'for'.

myfonj 2y ago
I don't think it is "unpopular", the contrary in fact. It's just the best practice to stick to bronze-age standards, since reportedly there are still couple of assistive technologies that do not interpret the new perfectly valid and standardised pattern [1]: > Both Dragon Naturally Speaking for Windows, and Voice Control for macOS and iOS, don’t recognize implicit association, so the [nesting input inside label without explicit for-id reference] wouldn’t work. Naturally Speaking was reportedly acquired by a company named "Microsoft", and Voice Control have some connections to that "Apple" company. [1] https://www.tpgi.com/should-form-labels-be-wrapped-or-separate/#:~:text=Both%20Dragon%20Naturally%20Speaking%20for%20Windows%2C%20and%20Voice%20Control%20for%20macOS%20and%20iOS%2C%20don%E2%80%99t%20recognize%20implicit%20association,work%2e https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...
- jermaustin1 2y ago
  Is that not what the ARIA standards are for?
  - phatskat 2y ago
    I don’t think so, correct me if I’m wrong: an ARIA attribute that might fit here would be aria-labelledby (sic), but per MDN > Note that while using aria-labelledby is similar in this situation to using an HTML <label> element with the for attribute, there are some very important differences. The aria-labelledby attribute only defines the accessible name. It doesn't provide any of <label>'s other functionality, such as making clicking on the labeling element activate the input it is associated with. That has to be added back in with JavaScript. The best compromise would be to both wrap the input inside the label _and_ use the “for” attribute. Typically, it’s best to use elements and controls that are already accessible, as ARIA is more intended to give additional accessibility to components that might not be traditionally accessible, or that require more robust accessibility control.
    - jermaustin1 2y ago
      Having done a lot of accessibility consulting in the past (granted it was a long time ago now), we were instructed to use the aria-label attribute to provide the same text as the label. Since I do mostly asp.net mvc, I created a bunch of "Accessible" extension methods off the HtmlHelper object. <%: Html.AccessibleCheckbox("MyCheckbox", label: "My Checkbox") %> This would output something like: <label><input type="checkbox" name="MyCheckbox" aria-label="My Checkbox" /> My Checkbox</label> This is a bad example since the primary reason for not giving IDs is because it is a dynamically created checkbox inside a loop or some other partial view that you might not know if it is a unique ID for the page or not.
      - phatskat 2y ago
        Ah interesting, I figured that a properly set and identified label element would suffice - I haven’t noticed our sniffer complaining yet we also strictly use the for attribute and don’t wrap controls that I’m aware of. Thanks for the insight!
- jmull 2y ago
  That's an argument for continuing to add the "for" and "id" attributes (or for making the association is some other way accessibility software understands)... But not for keeping the input outside of the label.
  - myfonj 2y ago
    True. Maybe I've not put it clear: neither the article nether me were arguing for separated elements. The so called best practice here is exactly as you put it: nest the elements but (sadly) duplicate the relation in attributes, in order to make the two screen readers / voice controls happy. I've brought up it here just because parent comment stated what perhaps majority of developers believe: > [nesting] completely avoids [possible gaps in the UI areas] and you don't need to come up with a unique id to use with 'for'. As for separated elements here, I can imagine scenarios when we need them too (for example if you need to shuffle them in some way, or intend to use a pseudo element of the label), but as noted, it is rarely best solution and requires way more scrutiny and complexity.
jermaustin1 2y ago
This is how I've been doing it for at least 15 years (maybe 20, by now?). It's also much cleaner syntax for the typical use case of checkboxes/radio buttons. Put the label around the input, then put a span for the text if you want some styling for the text. You can even make the label display:flex and handle the positioning of the text that way.
speleding 2y ago
If you use a Rails helper to create a checkbox it puts a hidden field next to it with the "off" value to ensure something always gets POSTed back. I assume other frameworks do the same. If you put a <label> element around those two input fields, it's no longer valid HTML. This is not a problem for radio buttons, but I suspect a few people have been bitten by this and do it "just to make sure". In the same way, adding a semi-colon at the end of a line of JavaScript is rarely useful but people put them everywhere because they don't know when it's needed exactly (granted that one is a bit tricker to remember).
nsonha 2y ago
Because of the dogma of semantic web

by wmil 2y ago

I don't understand why putting the <input> inside the <label> is so unpopular. It completely avoids these problems and you don't need to come up with a unique id to use with 'for'.

myfonj 2y ago

I don't think it is "unpopular", the contrary in fact. It's just the best practice to stick to bronze-age standards, since reportedly there are still couple of assistive technologies that do not interpret the new perfectly valid and standardised pattern [1]: > Both Dragon Naturally Speaking for Windows, and Voice Control for macOS and iOS, don’t recognize implicit association, so the [nesting input inside label without explicit for-id reference] wouldn’t work. Naturally Speaking was reportedly acquired by a company named "Microsoft", and Voice Control have some connections to that "Apple" company. [1] https://www.tpgi.com/should-form-labels-be-wrapped-or-separate/#:~:text=Both%20Dragon%20Naturally%20Speaking%20for%20Windows%2C%20and%20Voice%20Control%20for%20macOS%20and%20iOS%2C%20don%E2%80%99t%20recognize%20implicit%20association,work%2e https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...

jermaustin1 2y ago
Is that not what the ARIA standards are for?
- phatskat 2y ago
  I don’t think so, correct me if I’m wrong: an ARIA attribute that might fit here would be aria-labelledby (sic), but per MDN > Note that while using aria-labelledby is similar in this situation to using an HTML <label> element with the for attribute, there are some very important differences. The aria-labelledby attribute only defines the accessible name. It doesn't provide any of <label>'s other functionality, such as making clicking on the labeling element activate the input it is associated with. That has to be added back in with JavaScript. The best compromise would be to both wrap the input inside the label _and_ use the “for” attribute. Typically, it’s best to use elements and controls that are already accessible, as ARIA is more intended to give additional accessibility to components that might not be traditionally accessible, or that require more robust accessibility control.
  - jermaustin1 2y ago
    Having done a lot of accessibility consulting in the past (granted it was a long time ago now), we were instructed to use the aria-label attribute to provide the same text as the label. Since I do mostly asp.net mvc, I created a bunch of "Accessible" extension methods off the HtmlHelper object. <%: Html.AccessibleCheckbox("MyCheckbox", label: "My Checkbox") %> This would output something like: <label><input type="checkbox" name="MyCheckbox" aria-label="My Checkbox" /> My Checkbox</label> This is a bad example since the primary reason for not giving IDs is because it is a dynamically created checkbox inside a loop or some other partial view that you might not know if it is a unique ID for the page or not.
    - phatskat 2y ago
      Ah interesting, I figured that a properly set and identified label element would suffice - I haven’t noticed our sniffer complaining yet we also strictly use the for attribute and don’t wrap controls that I’m aware of. Thanks for the insight!
jmull 2y ago
That's an argument for continuing to add the "for" and "id" attributes (or for making the association is some other way accessibility software understands)... But not for keeping the input outside of the label.
- myfonj 2y ago
  True. Maybe I've not put it clear: neither the article nether me were arguing for separated elements. The so called best practice here is exactly as you put it: nest the elements but (sadly) duplicate the relation in attributes, in order to make the two screen readers / voice controls happy. I've brought up it here just because parent comment stated what perhaps majority of developers believe: > [nesting] completely avoids [possible gaps in the UI areas] and you don't need to come up with a unique id to use with 'for'. As for separated elements here, I can imagine scenarios when we need them too (for example if you need to shuffle them in some way, or intend to use a pseudo element of the label), but as noted, it is rarely best solution and requires way more scrutiny and complexity.

jermaustin1 2y ago

This is how I've been doing it for at least 15 years (maybe 20, by now?). It's also much cleaner syntax for the typical use case of checkboxes/radio buttons. Put the label around the input, then put a span for the text if you want some styling for the text. You can even make the label display:flex and handle the positioning of the text that way.

speleding 2y ago

If you use a Rails helper to create a checkbox it puts a hidden field next to it with the "off" value to ensure something always gets POSTed back. I assume other frameworks do the same. If you put a <label> element around those two input fields, it's no longer valid HTML. This is not a problem for radio buttons, but I suspect a few people have been bitten by this and do it "just to make sure". In the same way, adding a semi-colon at the end of a line of JavaScript is rarely useful but people put them everywhere because they don't know when it's needed exactly (granted that one is a bit tricker to remember).

nsonha 2y ago

Because of the dogma of semantic web