Mike examines the real power of CSS custom properties compared to Sass variables—they can change at runtime.
I’m convinced that in almost all cases, responsive design logic should now be contained in variables. There is a strong argument too, that when changing any value, whether in a media query or an element scope, it belongs in a variable. If it changes, it is by definition a variable and this logic should be separated from design.
There are some great hands-on accessibility patterns in this talk transcript from Scott.
Comparing different ways to hide content accessibly:
There are three reasons behind hiding content in an interface, and it’s important to identify what those reasons are, as they will correlate with the appropriate technique needed to hide such content.
- Temporarily Hidden Content
- Purposefully Visually Hidden Content
- Purposefully Visual-Only Content
A great step-by-step walkthrough by Heydon of making an accessible to-do list, the “Hello World” of JavaScript frameworks.
There’s a lot of great knowledge in here that can be applied to plenty of other interface elements too.
Following on from Ire’s post about linting HTML with CSS, here’s an older post from Ebay about how being specific with your CSS selectors can help avoid inaccessible markup getting into production.
Rich has posted a sneak peek of one part of his book on Ev’s blog.
Here’s one of them new-fangled variable fonts that’re all the rage. And this one’s designed by David Berlow. And it’s free!
The aria-current attribute is very handy and easy to implement. Léonie explains it really well here.
Harry demonstrates a really good use for CSS custom properties—allowing users to theme an interface.
This is what Nick Sherman has been banging on about for years, and now the time has come for variable fonts …as long as typographers, browser makers, and standards bodies get behind it.
More details on Ev’s blog.
I wrote a while back about how I switched from using a button to using a link for progressive disclosure patterns. That looks like it was a good move—if I use a button, I’d need to use aria-controls and, as Heydon outlines here, the screen reader support is pants.
In the same vein as Hugo’s script, Ire walks through the steps involved in making an accessible modal window. Seeing all the thinking and code required for this really highlights the need for a way of making the document in the background inert.
I think it’s a safe bet that this new book by Heydon will be absolutely brilliant.
It’s a handbook with valuable, time-saving techniques that will help you avoid hacky workarounds and solve common issues effectively.
On the need for a way to mark parts of a document as “inert” while the user is interacting with modal content.
A typically superb article by Aaron. Here, he breaks down a resilient approach to building for the web by examining the multiple ways you could add a button to a page. There’s a larger lesson here too:
We don’t control where our web-based products go or how our users access them. All we can do is imagine as many less-than-perfect scenarios as possible and do our best to ensure our creations will continue to do what they’re supposed to do. One of the easiest ways to do that is to be aware of and limit our dependencies.
Here’s a bit of convergent evolution: Hugo’s script is similar to what I wrote about recently.
He also raises a point that Kevin mentioned:
I would like to investigate on the
detailsandsummaryelements as they are basically a native implementation for content toggles.
For some reason details never got much browser love, even though it’s clearly paving a well-trodden cowpath.
A very lightweight script for toggling the appearance of elements in an accessible way.
Three very easy to implement additions to scrollable areas of your web pages: tabindex="0", role="region", and an aria-label attribute.
A great description of a solid architectural approach to building on the web (and not just for accessibility either).
It really isn’t hard to get the basics of accessibility right on the web …and yet those basics are often neglected.
Here’s a handy shortlist to run through, HIKE:
- H stands for headings and semantic markup.
- I stands for images and labels.
- K stands for keyboard navigation.
- E asks for you to ACT with a little extra love for custom components and more.
(ACT = ARIA, Colour Contrast, Text Size)