Jeremey reacting to Sara’s tweet, about using [aria-*] selectors instead of classes when the styling you are applying is directly related to the ARIA state.
… this is my preferred way of hooking up CSS and JavaScript interactions. Here’s [an] old CodePen where you can see it in action
Which is this classic matchup:
[aria-hidden='true'] {
display: none;
}There are plenty of more opportunities. Take a tab design component:
Since these tabs (using Reach UI) are already applying proper ARIA states for things like which tab is active, they don’t even bother with class name manipulation. To style the active state, you select the <button> with a data attribute and ARIA state like:
[data-reach-tab][aria-selected="true"] {
background: white;
}The panels with the content? Those have an ARIA role, so are styled that way:
[role="tabpanel"] {
background: white;
}ARIA is also matches up with variations sometimes, like…
[aria-orientation="vertical"] {
flex-direction: column;
}If you’re like, wait, what’s ARIA? Heydon’s new show Webbed Briefs has a funny introduction to ARIA as the pilot episode.
Hi, this is great.
One question, regarding this suggestion:
Might that be a bit too much – e.g. if you want some content visible for screen users, but not for assistive technology?
One example comes to mind is the Font Awesome 4 icons, often using syntax such as
<i class="fa fa-something" aria-hidden="true"></i>though I appreciate with the newer versions with SVG etc, that is less an issue now?Admittedly, most of the examples I am suddenly thinking are decorative, so you’d ideally prefer CSS for that anyway! (And scanning a couple of large projects, where we are currently on the older version of font awesome, that was the only example we have used aria-hidden anyway!)