8 ms·

I’m not surprised but a little disappointed that most of the older techniques aren’t mentioned: - checkbox/radio inputs can be used to toggle state with `:chec

I’m not surprised but a little disappointed that most of the older techniques aren’t mentioned: - checkbox/radio inputs can be used to toggle state with `:checked ~ .foo` selectors - `:focus` (and now `:focus-within`, and `:active` though it’s less useful) can be used similarly, but also allow child selection [Edit to add: `tabindex="-1"` makes anything focusable with a pointer input, but doesn’t capture keyboard tab or iteration with assistive tools] - `:target` can be used similarly, paired with fragment links [Edit to add: but beware history entries, this can be a poor UX] - `<label>` can be used to not only set those states but also trigger scrolls (including within `scroll-snap` parents) without creating navigation history entries - the `attr()` function can be used to reference server-dynamic HTML data for display with `content` in pseudo-elements - I have to assume CSS animations are adopted widely enough that people aren’t using JS for that where it isn’t needed; but you can also use declarative, even interactive, animations in SVG - speaking of which, inline SVG (even `<use>` references) are part of the CSS cascade, and you can change any CSS-addressable property with `currentColor` - and you can nest HTML in SVG with `<foreignObject>` if you want to use SVG techniques in HTML - probably not worth mentioning but in case you don’t know... if you miss table layouts, you can use them with `display` on basically anything; if you want table semantics without tabular rendering you can override `display` as well Alllllll of that being said, if you use these techniques check your stuff with assistive technologies!

eyelidlessness 5y ago
Also: almost all of these are actively in use on my personal site, they’re not just stuff I mention academically. They’re great for places you might progressively enhance with JS but want to provide reasonable no-JS fallbacks.
decremental 5y ago
I'm new to getting my designs working well with assistive tools. What do you use for testing and what are the prominent tools that should be targeted?
- eyelidlessness 5y ago
  Admittedly I have a better track record saying than doing. So I’ll double down on that and repeat what all of the a11y advocates I follow say: - you want to at least test with JAWS, NVDA and VoiceOver - automated tooling isn’t great and you probably need to manually verify things - axe does help spot problems just don’t rely on it completely
  - decremental 5y ago
    Thanks for the tips. I'll check those out.
  - runarberg 5y ago
    As a linux user I do most of my assistive technology testing with Orcas. Do you have any insight into that? Do many assistive technology users use Orcas? Is Orcas behavior significantly different from the more popular once?
    - eyelidlessness 5y ago
      No, I wish I had insight here but I don't. I'm sorry I can't be any more help.
    - extra88 5y ago
      In the last WebAIM Screen Reader survey [0], if anyone answered they primarily use Orca, they got lumped into "Other"; out of over 1,000 respondents, 7 primarily use Chromevox so the Orca number must be lower than that. If some use Orca sometimes, they must have been less than 1% of the respondents and got lumped into Other for that question as well. That doesn't mean that Orca doesn't do a good job or that it works very differently than other screen readers. The A11ySupport site [1] does have some data on Orca's support for specific code. For instance, it fully supports the aria-expanded attribute but has no support for description list elements. If you have an iOS or Android device, using their built-in screen readers might be more instructive. [0] https://webaim.org/projects/screenreadersurvey8/ https://webaim.org/projects/screenreadersurvey8/ [1] https://a11ysupport.io/ https://a11ysupport.io/
asddubs 5y ago
>if you miss table layouts, you can use them with `display` on basically anything except not really because there's no CSS equivalent for rowspan/colspan. wish they would add this, it'd also be useful for making tables responsive. Thanks for the attr tip though, somehow that one had completely slipped by me!
- xkyf 5y ago
  Sure there is, the grid-row and grid-column CSS properties https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_La...
  - asddubs 5y ago
    sure, but if I have an actual table with tabular data, it would be nice to be able to just hide a row and adjust colspan in css as well as necessary. it's much less of a problem than it used to be these days, since grid is very well supported now, but still kind of annoying to rebuild the entire table into a grid.
    - onion2k 5y ago
      If you have an actual table with tabular data then your should be using an HTML table. That's what it's for.
      - asddubs 5y ago
        yes and if i want to make it responsive i can't change the colspan/rowspan via css. that was my point.
        xkyf 5y ago
        You can! CSS Grid works just fine with <table> and its related elements. In fact Grid is overkill here, you can span multiple rows or columns using flexbox alone. You don't need to "rebuild" anything, use the same markup. You couldn't control colspan/rowspan with CSS before, only HTML, which isn't responsive. (Ignoring the `column-span` property which isn't very flexible.)
SimeVidas 5y ago
> checkbox/radio inputs can be used to toggle state with `:checked ~ .foo` selectors What kind of state do you mean? Could you give an example?
- joeframbach 5y ago
  An accordion widget is simply a series of radio button followed by div. You can see this in action at amazon.com in a product page with multiple purchase options, the buy button will have a radio with multiple options, it's just a radio button. An accordion that allows multiple open panes is a series of checkbox followed by div. More advanced, you can create a flashcard app by allotting two checkboxes per card. I used this technique around 3 years ago when I was studying kanji: http://sokogakuen.framba.ch http://sokogakuen.framba.ch
- charrondev 5y ago
  The pattern is: <label> <input class”real-check” type=checkbox /> <span class”fake-check”/> <strong>this is the text label</strong> </label> - visually hide the checkbox - use a selector like “.real-check:checked + .fake-check and draw whatever you want in the fake check. - the fake check and the text label are both inside the label element. Interacting with them will toggle the check box.
- inopinatus 5y ago
  Here's a simple example, toggles for checkbox inputs. https://play.tailwindcss.com/BvQpg9QWEe https://play.tailwindcss.com/BvQpg9QWEe
  - meagher 5y ago
    Coming soon to Tailwind https://twitter.com/adamwathan/status/1400516100329295875?s=20 https://twitter.com/adamwathan/status/1400516100329295875?s=...
extra88 5y ago
> 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/
chrismorgan 5y ago
One popular case for :checked JavaScriptless visual state is popups of various kinds; these days, many of those can be done with <details>, which is normally semantically better out of the box and generally equally capable (even down to things like “click anywhere outside and it closes” via some full-viewport ::before, on the summary rather than label in this instance).
inopinatus 5y ago
:focus-within is a favourite of mine since it is one of the few CSS selectors where child element state is significant. Thus it is very nice for drop-downs. It also works with CSS transitions, so my pure CSS drop-downs have a 150ms easing in & out (tip: transition the visibility property, since display:none can't be delayed). There is another, however. An element whose state depends on that of other elements, and it's even more general. A form element moves between :valid and :invalid based on its inputs, allowing us to use form:{in}valid with any of the descendant, child, sibling or adjacent combinators. A hidden required checkbox is sufficient. Radio inputs work too (tip: you can clear radios back to :invalid with an input type="reset"). The really, truly monstrous part of this, however, is that the associated input doesn't even have to be a child of the form. Using the form attribute (i.e., <input form="whatever">) means they can be anywhere on the page, and they can themselves be hidden and targeted from somewhere else on the page again, with a <label> element. I once documented the horrifying potential of this in a company wiki, along with a lovely modal slideover that was wrapped in a <form> element and transitioned to visible based on form:valid via a hidden required radio button, and whose backdrop was a reset button, and this was rightly labelled NSFW and banned by popular acclaim from ever appearing in our HTML.
- pickpuck 5y ago
  The form/valid one is very interesting but I'm not sure I completely follow, especially the last example. Would you be able to post a Codepen?
  - inopinatus 5y ago
    Done. I've posted a sample usage, it's in a reply to a comment a bit further down.
  - e12e 5y ago
    I'm assuming the input is toggled via js (or server rendered html) - and the selector is used for cascading "state" into the html?
  - eyelidlessness 5y ago
metters 5y ago
Is there a good blog post about all those techniques you listed, or some collection? I would like to read more about it.
dgb23 5y ago
I‘ve found that SVG animations seem to be kind of slow, especially compared to CSS animations. My suspicion is that specific browsers don’t optimize them in the same way.
- SynnVoid 5y ago
  CSS animation are usually done with the use of the transform propertie. The transform propertie does not trigger painting, and then can be done with the help of the GPU. https://csstriggers.com/transform https://csstriggers.com/transform
kypro 5y ago
Something to keep in mind about using checkboxs and radios to toggle state changes, CSS tricks in general is that depending on what you're doing they're often not fully accessible. To fully support keyboard input and aria attributes like `aria-expanded` you often need to use JavaScript.
- nitrogen 5y ago
  To fully support keyboard input...you often need to use JavaScript. This seems 100% backward. What happened to tabindex? My experience has been that HTML+CSS (I wouldn't even call most of these "hacks", they are normal intended features of CSS) is much more likely to be navigable by keyboard than anything using JS.
RunawayGalaxy 5y ago
Does anyone know if changing the display type of table elements (table, tr, td, etc.) to `block` or `flex` affect accessibility in any way? I would hope that the semantic structure of the tags would override changes on the styling level, but never been able to find a solid answer.

eyelidlessness 5y ago

Also: almost all of these are actively in use on my personal site, they’re not just stuff I mention academically. They’re great for places you might progressively enhance with JS but want to provide reasonable no-JS fallbacks.

decremental 5y ago

I'm new to getting my designs working well with assistive tools. What do you use for testing and what are the prominent tools that should be targeted?

eyelidlessness 5y ago
Admittedly I have a better track record saying than doing. So I’ll double down on that and repeat what all of the a11y advocates I follow say: - you want to at least test with JAWS, NVDA and VoiceOver - automated tooling isn’t great and you probably need to manually verify things - axe does help spot problems just don’t rely on it completely
- decremental 5y ago
  Thanks for the tips. I'll check those out.
- runarberg 5y ago
  As a linux user I do most of my assistive technology testing with Orcas. Do you have any insight into that? Do many assistive technology users use Orcas? Is Orcas behavior significantly different from the more popular once?
  - eyelidlessness 5y ago
    No, I wish I had insight here but I don't. I'm sorry I can't be any more help.
  - extra88 5y ago
    In the last WebAIM Screen Reader survey [0], if anyone answered they primarily use Orca, they got lumped into "Other"; out of over 1,000 respondents, 7 primarily use Chromevox so the Orca number must be lower than that. If some use Orca sometimes, they must have been less than 1% of the respondents and got lumped into Other for that question as well. That doesn't mean that Orca doesn't do a good job or that it works very differently than other screen readers. The A11ySupport site [1] does have some data on Orca's support for specific code. For instance, it fully supports the aria-expanded attribute but has no support for description list elements. If you have an iOS or Android device, using their built-in screen readers might be more instructive. [0] https://webaim.org/projects/screenreadersurvey8/ https://webaim.org/projects/screenreadersurvey8/ [1] https://a11ysupport.io/ https://a11ysupport.io/

asddubs 5y ago

>if you miss table layouts, you can use them with `display` on basically anything except not really because there's no CSS equivalent for rowspan/colspan. wish they would add this, it'd also be useful for making tables responsive. Thanks for the attr tip though, somehow that one had completely slipped by me!

xkyf 5y ago
Sure there is, the grid-row and grid-column CSS properties https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_La...
- asddubs 5y ago
  sure, but if I have an actual table with tabular data, it would be nice to be able to just hide a row and adjust colspan in css as well as necessary. it's much less of a problem than it used to be these days, since grid is very well supported now, but still kind of annoying to rebuild the entire table into a grid.
  - onion2k 5y ago
    If you have an actual table with tabular data then your should be using an HTML table. That's what it's for.
    - asddubs 5y ago
      yes and if i want to make it responsive i can't change the colspan/rowspan via css. that was my point.
      - xkyf 5y ago
        You can! CSS Grid works just fine with <table> and its related elements. In fact Grid is overkill here, you can span multiple rows or columns using flexbox alone. You don't need to "rebuild" anything, use the same markup. You couldn't control colspan/rowspan with CSS before, only HTML, which isn't responsive. (Ignoring the `column-span` property which isn't very flexible.)

SimeVidas 5y ago

> checkbox/radio inputs can be used to toggle state with `:checked ~ .foo` selectors What kind of state do you mean? Could you give an example?

joeframbach 5y ago
An accordion widget is simply a series of radio button followed by div. You can see this in action at amazon.com in a product page with multiple purchase options, the buy button will have a radio with multiple options, it's just a radio button. An accordion that allows multiple open panes is a series of checkbox followed by div. More advanced, you can create a flashcard app by allotting two checkboxes per card. I used this technique around 3 years ago when I was studying kanji: http://sokogakuen.framba.ch http://sokogakuen.framba.ch
charrondev 5y ago
The pattern is: <label> <input class”real-check” type=checkbox /> <span class”fake-check”/> <strong>this is the text label</strong> </label> - visually hide the checkbox - use a selector like “.real-check:checked + .fake-check and draw whatever you want in the fake check. - the fake check and the text label are both inside the label element. Interacting with them will toggle the check box.
inopinatus 5y ago
Here's a simple example, toggles for checkbox inputs. https://play.tailwindcss.com/BvQpg9QWEe https://play.tailwindcss.com/BvQpg9QWEe
- meagher 5y ago
  Coming soon to Tailwind https://twitter.com/adamwathan/status/1400516100329295875?s=20 https://twitter.com/adamwathan/status/1400516100329295875?s=...

extra88 5y ago

> 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/

chrismorgan 5y ago

One popular case for :checked JavaScriptless visual state is popups of various kinds; these days, many of those can be done with <details>, which is normally semantically better out of the box and generally equally capable (even down to things like “click anywhere outside and it closes” via some full-viewport ::before, on the summary rather than label in this instance).

inopinatus 5y ago

:focus-within is a favourite of mine since it is one of the few CSS selectors where child element state is significant. Thus it is very nice for drop-downs. It also works with CSS transitions, so my pure CSS drop-downs have a 150ms easing in & out (tip: transition the visibility property, since display:none can't be delayed). There is another, however. An element whose state depends on that of other elements, and it's even more general. A form element moves between :valid and :invalid based on its inputs, allowing us to use form:{in}valid with any of the descendant, child, sibling or adjacent combinators. A hidden required checkbox is sufficient. Radio inputs work too (tip: you can clear radios back to :invalid with an input type="reset"). The really, truly monstrous part of this, however, is that the associated input doesn't even have to be a child of the form. Using the form attribute (i.e., <input form="whatever">) means they can be anywhere on the page, and they can themselves be hidden and targeted from somewhere else on the page again, with a <label> element. I once documented the horrifying potential of this in a company wiki, along with a lovely modal slideover that was wrapped in a <form> element and transitioned to visible based on form:valid via a hidden required radio button, and whose backdrop was a reset button, and this was rightly labelled NSFW and banned by popular acclaim from ever appearing in our HTML.

pickpuck 5y ago
The form/valid one is very interesting but I'm not sure I completely follow, especially the last example. Would you be able to post a Codepen?
- inopinatus 5y ago
  Done. I've posted a sample usage, it's in a reply to a comment a bit further down.
- e12e 5y ago
  I'm assuming the input is toggled via js (or server rendered html) - and the selector is used for cascading "state" into the html?
- eyelidlessness 5y ago

metters 5y ago

Is there a good blog post about all those techniques you listed, or some collection? I would like to read more about it.

dgb23 5y ago

I‘ve found that SVG animations seem to be kind of slow, especially compared to CSS animations. My suspicion is that specific browsers don’t optimize them in the same way.

SynnVoid 5y ago
CSS animation are usually done with the use of the transform propertie. The transform propertie does not trigger painting, and then can be done with the help of the GPU. https://csstriggers.com/transform https://csstriggers.com/transform

kypro 5y ago

Something to keep in mind about using checkboxs and radios to toggle state changes, CSS tricks in general is that depending on what you're doing they're often not fully accessible. To fully support keyboard input and aria attributes like `aria-expanded` you often need to use JavaScript.

nitrogen 5y ago
To fully support keyboard input...you often need to use JavaScript. This seems 100% backward. What happened to tabindex? My experience has been that HTML+CSS (I wouldn't even call most of these "hacks", they are normal intended features of CSS) is much more likely to be navigable by keyboard than anything using JS.

RunawayGalaxy 5y ago

Does anyone know if changing the display type of table elements (table, tr, td, etc.) to `block` or `flex` affect accessibility in any way? I would hope that the semantic structure of the tags would override changes on the styling level, but never been able to find a solid answer.