3 ms·

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

by 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.

by myfonj 2y ago

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.