A very handy community project that documents support for ARIA and native HTML accessibility features in screen readers and browsers.
Van11y (for Vanilla-Accessibility) is a collection of accessible scripts for rich interfaces elements, built using progressive enhancement and customisable.
A handy reminder from Léonie (though remember that the best solution is to avoid the problem in the first place—if you avoid using ARIA, do that).
A score of 100 in Lighthouse or 0 errors in axe doesn’t mean that you’re done, it means that you’re ready to start manual testing and testing with real users, if possible.
Smart thinking from Sara to improve usability for keyboard users by using
aria-hidden="true" tabindex="-1" to skip duplicate links:
A good rule of thumb for similar cases is that if you have multiple consecutive links to the same page, there is probably a chance to improve keyboard navigation by skipping some of those links to reduce the number of tab stops to one. The less tab stops, the better, as long as it does not worsen or compromise on other aspects of usability.
I’ve cautiously implemented this pattern now over on The Session where snippets of comments had both a title link and a “more” link going to the same destination.
Ever wanted to set some text in 70% Times New Roman and 30% Arial? Me neither. But now, thanks to variable fonts, you can!
This is such a clever use of variable fonts!
We can use a lighter font weight to make the text easier to read whenever dark mode is active.
This is a terrific explanation of the concept of accessible names in HTML, written with verve and style!
Contrary to what you may think, naming an element involves neither a birth certificate nor the HTML
nameattribute is never directly exposed to the user, and is used only when submitting forms. Birth certificates have thus far been ignored by spec authors as a potential method for naming controls, but perhaps when web UI becomes sentient and self-propagating, we’ll need to revisit that.
This is a great walkthough of making a common form pattern accessible. No complex code here: some HTML is all that’s needed.
A history of typesetting from movable type to variable fonts.
Everything you ever wanted to know about variable fonts, gathered together into one excellent website.
Well, this is a grim collection from Dave:
There are some cases where even using plain ol’ HTML causes accessibility problems. I get frustrated and want to quit web development whenever I read about these types of issues. Because if browsers can’t get this right, what hope is there for the rest of us.
It’s worth clicking through each link he lists—the situation is often much more nuanced than simply “Don’t use X.”
A great explanation of
In this interview, Biance Berning says:
Cassie Evans from Clearleft is an interesting person to follow as she combines web animation with variable font technology, essentially exploring the technology’s practicality and expression.
We’re only just scratching the surface of what variable fonts can do within more interactive and immersive spaces. I think we’ll see a lot more progress and experimentation with that as time goes on.
Nolan writes up what he learned making accessibiity improvements to a single page app. The two big takeways involve letting the browser do the work for you:
Here’s the best piece of accessibility advice for newbies: if something is a button, make it a
<button>. If something is an input, make it an
<input>. Don’t try to reinvent everything from scratch using
And then there are all the issues that crop up when you take over the task of handling navigations:
- You need to manage focus yourself.
- You need to manage scroll position yourself.
For classic server-rendered pages, most browser engines give you this functionality for free. You don’t have to code anything. But in an SPA, since you’re overriding the normal navigation behavior, you have to handle the focus yourself.
Play around with this variable font available soon from Google Fonts in monospaced and sans-serif versions.
This is why we need an
nth-letter selector in CSS .
Hidde gives an in-depth explanation of the Accessibility Object Model, coming soon to browsers near you:
In a way, that’s a bit like what Service Workers do for the network and Houdini for style: give developers control over something that was previously done only by the browser.
Tough, but fair.