5 ms·

Right, 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 s

Right, 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 ago
ISTM 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 ago
  It'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.
  - jessaustin 10y ago
    Implicit label association was documented in 1997. [0] It is unlikely that screen reader software from that time is still in use; is anyone still using Windows 95? Web developers have at times been fairly ruthless in ending support for e.g. IE 8 based on empirical measures of browser use. [1] Blind users are already a relatively small percentage of all users, and the quality of available "opt-in" screen reader surveys seems a bit lacking, so it seems possible that the problems you describe are actually experienced by very few people. The other possibility would be that commercial reader distributors in "maintenance mode" spend more time lobbying accessibility organizations and discouraging the use of standards-compliant free software than they do maintaining their own software. Whatever the case, ISTM developers who care about blind users might better use their time helping to improve the screen reading capabilities of standards-compliant browsers rather than redefining standards to coincide with the capabilities of outmoded screen readers. Just my two cents; clearly I don't care as much about this stuff as you do. Good luck! :checked is also relevant for <select>/<option> tags. [0] https://www.w3.org/TR/WD-html40-970917/interact/forms.html#h-18.2.5 https://www.w3.org/TR/WD-html40-970917/interact/forms.html#h... [1] http://caniuse.com/usage-table http://caniuse.com/usage-table
    - EdSharkey 10y ago
      Yeah, it is a problem ... blind users on Windows XP or vista is not unheard of. Vista shipped with ie7, if you can believe it. Modern screen readers are really great and standards-friendly. There are even fully featured free/open source options. The problem really is disabled users stranded on old platforms. It is very common for users with disabilities to not want to disclose their disabilities to websites. Very common to see low vision users use an independent magnifier tool rather than the browser zoom, for instance. Screen reader software is not detectable on the user's browser. So hoping to get a good count of users with disabilities visiting your site is going to be fraught with difficulties. The kindest thing you can do from a web design standpoint for people with disabilities would be to read the WCAG, understand the issues and tradeoffs, and make tweaks to the way you form your markup and styles to conform, where you are able. I learned about all this stuff while working on a public utility's website that got sued by a disabled persons' legal rights group who (legitimately) argued and won a case where they claimed the site was inaccessible to screen reader users. The site was totally atrocious, legacy Struts cruft, and we got to do a full overhaul of the UX, markup, and CSS for accessibility. I expect more of these types of lawsuits in the future, so it could be useful career-wise to be aware of this stuff. WCAG infos: https://www.w3.org/TR/WCAG20/ https://www.w3.org/TR/WCAG20/

jessaustin 10y ago

ISTM 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 ago
It'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.
- jessaustin 10y ago
  Implicit label association was documented in 1997. [0] It is unlikely that screen reader software from that time is still in use; is anyone still using Windows 95? Web developers have at times been fairly ruthless in ending support for e.g. IE 8 based on empirical measures of browser use. [1] Blind users are already a relatively small percentage of all users, and the quality of available "opt-in" screen reader surveys seems a bit lacking, so it seems possible that the problems you describe are actually experienced by very few people. The other possibility would be that commercial reader distributors in "maintenance mode" spend more time lobbying accessibility organizations and discouraging the use of standards-compliant free software than they do maintaining their own software. Whatever the case, ISTM developers who care about blind users might better use their time helping to improve the screen reading capabilities of standards-compliant browsers rather than redefining standards to coincide with the capabilities of outmoded screen readers. Just my two cents; clearly I don't care as much about this stuff as you do. Good luck! :checked is also relevant for <select>/<option> tags. [0] https://www.w3.org/TR/WD-html40-970917/interact/forms.html#h-18.2.5 https://www.w3.org/TR/WD-html40-970917/interact/forms.html#h... [1] http://caniuse.com/usage-table http://caniuse.com/usage-table
  - EdSharkey 10y ago
    Yeah, it is a problem ... blind users on Windows XP or vista is not unheard of. Vista shipped with ie7, if you can believe it. Modern screen readers are really great and standards-friendly. There are even fully featured free/open source options. The problem really is disabled users stranded on old platforms. It is very common for users with disabilities to not want to disclose their disabilities to websites. Very common to see low vision users use an independent magnifier tool rather than the browser zoom, for instance. Screen reader software is not detectable on the user's browser. So hoping to get a good count of users with disabilities visiting your site is going to be fraught with difficulties. The kindest thing you can do from a web design standpoint for people with disabilities would be to read the WCAG, understand the issues and tradeoffs, and make tweaks to the way you form your markup and styles to conform, where you are able. I learned about all this stuff while working on a public utility's website that got sued by a disabled persons' legal rights group who (legitimately) argued and won a case where they claimed the site was inaccessible to screen reader users. The site was totally atrocious, legacy Struts cruft, and we got to do a full overhaul of the UX, markup, and CSS for accessibility. I expect more of these types of lawsuits in the future, so it could be useful career-wise to be aware of this stuff. WCAG infos: https://www.w3.org/TR/WCAG20/ https://www.w3.org/TR/WCAG20/