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.
Thursday, June 25th, 2020
Wednesday, June 10th, 2020
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.
Tuesday, May 5th, 2020
Ever wanted to set some text in 70% Times New Roman and 30% Arial? Me neither. But now, thanks to variable fonts, you can!
Saturday, April 25th, 2020
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.
Friday, April 17th, 2020
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.
Monday, March 23rd, 2020
This is a great walkthough of making a common form pattern accessible. No complex code here: some HTML is all that’s needed.
Friday, March 13th, 2020
A history of typesetting from movable type to variable fonts.
Friday, March 6th, 2020
Everything you ever wanted to know about variable fonts, gathered together into one excellent website.
Tuesday, March 3rd, 2020
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.”
Friday, February 14th, 2020
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.
Wednesday, November 27th, 2019
Accessibility on The Session revisited
Earlier this year, I wrote about an accessibility issue I was having on The Session. Specifically, it was an issue with Ajax and pagination. But I managed to sort it out, and the lesson was very clear:
As is so often the case, the issue was with me trying to be too clever with ARIA, and the solution was to ease up on adding so many ARIA attributes.
Wherever the pagination pattern appears, there are “previous” and “next” links, marked up with the appropriate
rel="next" attributes. Well, apparently past me thought it would be clever to add some ARIA attributes in there too. My thinking must’ve been something like this:
- Those links control the area of the page with the search results.
- That area of the page has an ID of “results”.
- I should add
aria-controls="results"to those links.
That was the problem …which is kind of weird, because VoiceOver isn’t supposed to have any support for
aria-controls. Anyway, once I removed that attribute from the links, everything worked just fine.
Just as the solution last time was to remove the
aria-atomic attribute on the updated area, the solution this time was to remove the
aria-controls attribute on the links that trigger the update. Maybe this time I’ll learn my lesson: don’t mess with ARIA attributes you don’t understand.
Thursday, November 7th, 2019
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.
Friday, September 6th, 2019
Play around with this variable font available soon from Google Fonts in monospaced and sans-serif versions.
Saturday, August 31st, 2019
This is why we need an
nth-letter selector in CSS .
Friday, August 9th, 2019
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.
Tuesday, July 30th, 2019
Tough, but fair.
Thursday, July 25th, 2019
You can spot the less useful design principles after a while. They tend to be wishy-washy; more like empty aspirational exhortations than genuinely useful guidelines for alignment. I’ve written about what makes for good design principles before. Matthew Ström also asked—and answered—What makes a good design principle?
- Good design principles are memorable.
- Good design principles help you say no.
- Good design principles aren’t truisms.
- Good design principles are applicable.
I like those. They’re like design principles for design principles.
One set of design principles that I’ve included in my collection is from gov.uk: government design principles . I think they’re very well thought-through (although I’m always suspicious when I see a nice even number like 10 for the amount of items in the list). There’s a great line in design principle number two—Do less:
Government should only do what only government can do.
This wasn’t a theoretical issue. The multiple departmental websites that preceded gov.uk were notorious for having too much irrelevant content—content that was readily available elsewhere. It was downright wasteful to duplicate that content on a government site. It wasn’t appropriate.
I think that the design principle from GDS could be abstracted into a general technology principle:
Any particular technology should only do what only that particular technology can do.
Choose the least powerful language suitable for a given purpose.
Or, as Derek put it:
In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.
ARIA should only do what only ARIA can do.
CSS should only do what only CSS can do.
HTML should only do what only HTML can do.
Monday, July 1st, 2019
Sunday, June 9th, 2019
fopenwhen you can write
throwVE. Call that name
fct. That’s German naming convention. Do this and your readers will appreciate it.