4 ms·

> toggle state with `:checked ~ .foo` selectors I loved this when I first learned it but was convinced by some accessibility-minded people that it usually does

> toggle state with `:checked ~ .foo` selectors I loved this when I first learned it but was convinced by some accessibility-minded people that it usually doesn’t accurately convey the state to assistive technologies. Instead, use a <button> with an appropriate ARIA attribute conveying a state (pressed, expanded, etc.) that’s toggled by JavaScript. Or use <details> <summary> elements if it’s a disclosure widget.

inopinatus 5y ago
Yeah, they lied to you. The trouble with ARIA is that it relies, fundamentally, on the assumption that everything's a RIA (the hint is in the name). This assumption is bollocks. A typical failure scenario is toggles in forms, that appeared to have been set by button-press, but have only changed cosmetically. The silent errors that creep in this way are painful to unravel. Relying on input element state avoids not merely the tail wagging the dog, but the tail wagging only itself because TypeError: dog is not an object. When overused, or used in a cargo-cult fashion, ARIA is also notorious for making pages less accessible, and unfortunately this is frequently the case. If you want to build accessible pages, then write simple and semantic HTML. Out of the box this is likely to be fairly accessible from the go. Then annotate using the minimum of JS to set the minimum of ARIA attributes that clearly improve accessibility, and if someone's relying on ARIA then you can, by definition, assume that JS is available, since it is (I'll reiterate this) right there in the name, and what's more if it it's broken or unavailable, then your fallback plain-old-HTML retains some semblance of utility and accessibility for assisted and non-assisted visitors alike. The path through the swamp doesn't have to be smothering it in concrete.
- extra88 5y ago
  > annotate using the minimum of JS to set the minimum of ARIA attributes that clearly improve accessibility Yes, like aria-expanded="true" on a <button> that opens a custom disclosure widget instead of using the CSS-only :checked ~ .foo hack I was responding to. The actual hiding/revealing of the related content can still be done with CSS alone using [aria-expanded="true"]. Here's a bunch of checkbox hack examples [0]. The custom radio buttons and checkboxes and the push toggles are fine (the use-case is fine, I didn't closely examine everything about the implementations), the rest should be done some other way that probably involves buttons with JavaScript. [0] https://css-tricks.com/the-checkbox-hack/ https://css-tricks.com/the-checkbox-hack/
  - runarberg 5y ago
    Custom radio buttons and checkboxes are remarkably easy if you style the <input> it self using `appearance: none`. With multiple background images and masks there is really no need for a complicated sibling selectors and <label> setup: <label> <input type="checkbox"> <span class="label">Some label</span> </label> input[type="checkbox"] { appearance: none; /* ... */ } input[type="checkbox"]:checked { /* ... */ } input[type="checkbox"]:indeterminate { /* ... */ } input[type="checkbox"]:disabled { /* ... */ }
    - extra88 5y ago
      That's good to keep in mind. No IE support for `appearance` but it can be used in such a way that it's just a more ordinary input in that browser. There are still more things you can do within a label. This is a good article on improving methods of visually hiding the actual inputs. https://www.sarasoueidan.com/blog/inclusively-hiding-and-styling-checkboxes-and-radio-buttons/ https://www.sarasoueidan.com/blog/inclusively-hiding-and-sty...

inopinatus 5y ago

Yeah, they lied to you. The trouble with ARIA is that it relies, fundamentally, on the assumption that everything's a RIA (the hint is in the name). This assumption is bollocks. A typical failure scenario is toggles in forms, that appeared to have been set by button-press, but have only changed cosmetically. The silent errors that creep in this way are painful to unravel. Relying on input element state avoids not merely the tail wagging the dog, but the tail wagging only itself because TypeError: dog is not an object. When overused, or used in a cargo-cult fashion, ARIA is also notorious for making pages less accessible, and unfortunately this is frequently the case. If you want to build accessible pages, then write simple and semantic HTML. Out of the box this is likely to be fairly accessible from the go. Then annotate using the minimum of JS to set the minimum of ARIA attributes that clearly improve accessibility, and if someone's relying on ARIA then you can, by definition, assume that JS is available, since it is (I'll reiterate this) right there in the name, and what's more if it it's broken or unavailable, then your fallback plain-old-HTML retains some semblance of utility and accessibility for assisted and non-assisted visitors alike. The path through the swamp doesn't have to be smothering it in concrete.

extra88 5y ago
> annotate using the minimum of JS to set the minimum of ARIA attributes that clearly improve accessibility Yes, like aria-expanded="true" on a <button> that opens a custom disclosure widget instead of using the CSS-only :checked ~ .foo hack I was responding to. The actual hiding/revealing of the related content can still be done with CSS alone using [aria-expanded="true"]. Here's a bunch of checkbox hack examples [0]. The custom radio buttons and checkboxes and the push toggles are fine (the use-case is fine, I didn't closely examine everything about the implementations), the rest should be done some other way that probably involves buttons with JavaScript. [0] https://css-tricks.com/the-checkbox-hack/ https://css-tricks.com/the-checkbox-hack/
- runarberg 5y ago
  Custom radio buttons and checkboxes are remarkably easy if you style the <input> it self using `appearance: none`. With multiple background images and masks there is really no need for a complicated sibling selectors and <label> setup: <label> <input type="checkbox"> <span class="label">Some label</span> </label> input[type="checkbox"] { appearance: none; /* ... */ } input[type="checkbox"]:checked { /* ... */ } input[type="checkbox"]:indeterminate { /* ... */ } input[type="checkbox"]:disabled { /* ... */ }
  - extra88 5y ago
    That's good to keep in mind. No IE support for `appearance` but it can be used in such a way that it's just a more ordinary input in that browser. There are still more things you can do within a label. This is a good article on improving methods of visually hiding the actual inputs. https://www.sarasoueidan.com/blog/inclusively-hiding-and-styling-checkboxes-and-radio-buttons/ https://www.sarasoueidan.com/blog/inclusively-hiding-and-sty...