This is a thoughtful proposal for a browser feature from Bram. Very convincing!
Monday, May 30th, 2022
Tuesday, September 14th, 2021
I was doing some accessibility work with a client a little while back. It was mostly giving their site the once-over, highlighting any issues that we could then discuss. It was an audit of sorts.
While I was doing this I started to realise that not all accessibility issues are created equal. I don’t just mean in their severity. I mean that some issues can—and should—be caught early on, while other issues can only be found later.
Take colour contrast. This is something that should be checked before a line of code is written. When designs are being sketched out and then refined in a graphical editor like Figma, that’s the time to check the ratio between background and foreground colours to make sure there’s enough contrast between them. You can catch this kind of thing later on, but by then it’s likely to come with a higher cost—you might have to literally go back to the drawing board. It’s better to find the issue when you’re at the drawing board the first time.
Then there’s the HTML. Most accessibility issues here can be caught before the site goes live. Usually they’re issues of ommission: form fields that don’t have an explicitly associated
label element (using the
id attributes); images that don’t have
alt text; pages that don’t have sensible heading levels or landmark regions like
nav. None of these are particularly onerous to fix and they come with the biggest bang for your buck. If you’ve got sensible forms, sensible headings,
alt text on images, and a solid document structure, you’ve already covered the vast majority of accessibility issues with very little overhead. Some of these checks can also be automated:
alt text for images;
labels for inputs.
So if you commission an accessibility audit, you should hope to get feedback that’s mostly in that third category—interactive widgets.
If you get feedback on document structure and other semantic issues with the HTML, you should fix those issues, sure, but you should also see what you can do to stop those issues going live again in the future. Perhaps you can add some steps in the build process. Or maybe it’s more about making sure the devs are aware of these low-hanging fruit. Or perhaps there’s a framework or content management system that’s stopping you from improving your HTML. Then you need to execute a plan for ditching that software.
If you get feedback about colour contrast issues, just fixing the immediate problem isn’t going to address the underlying issue. There’s a process problem, or perhaps a communication issue. In that case, don’t look for a technical solution. A design system, for example, will not magically fix a workflow issue or route around the problem of designers and developers not talking to each other.
When you commission an accessibility audit, you want to make sure you’re getting the most out of it. Don’t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.
Thursday, October 8th, 2020
Considering how much accessibility work happens “under the hood”, it’s interesting that all five of these considerations are visibly testable.
- Think about accessible copy
- Don’t forget about the focus indicator
- Check your colour contrast
- Don’t just use colour to convey meaning
- Design in anticipation of text resizing
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.
Sunday, July 21st, 2019
Some excellent explanations for these five pieces of sensible typography advice:
- Set your base font size in relative units
- Check the colour of your type and only then its contrast
- Use highly legible fonts
- Shape your paragraphs well
- Correctly use the heading levels
Monday, May 20th, 2019
This looks like a really useful tool for generating accessibile colour combinations from a starting colour.
Saturday, November 10th, 2018
Some advice from Andy on creating a dark theme for your website. It’s not just about the colours—there are typography implications too.
Tuesday, August 7th, 2018
Inclusive design is also future-proofing technology for everyone. Swan noted that many more developers and designers are considering accessibility issues as they age and encounter poor eyesight or other impairments.
Wednesday, June 20th, 2018
A lot of the issues here are with abuses of the
placeholder attribute—using it as a label, using it for additional information, etc.—whereas using it quite literally as a placeholder can be thought of as an enhancement (I almost always preface mine with “e.g.”).
Still, there’s no getting around that terrible colour contrast issue: if the contrast were greater, it would look too much like an actual pre-filled value, and that’s potentially worse.
Saturday, March 10th, 2018
Sunday, March 4th, 2018
A primer on accessible colour contrast with links to some handy tools for testing.
Wednesday, January 10th, 2018
Suggestions for small interface tweaks.
Thursday, December 7th, 2017
Great advice on keeping your hyperlinks accessible.
Thursday, November 9th, 2017
A clever performance trick for images:
- Reduce image contrast using a linear transform function (Photoshop can do this)
- Apply a contrast filter in CSS to the image to make up for the contrast removal
Thursday, May 11th, 2017
This is a really intriguing book that combines design theory and programming—learn about contrast, colour, and shapes, with each lesson supported by code examples.
It’s still a work in progress but the whole thing is online for free. Yay for web books!
Wednesday, April 26th, 2017
A plug-in for Sketch that allows you to simulate colour blindnesses and check colour contrasts.
Friday, March 24th, 2017
If we describe patterns also in terms of content, context, and contrast, we are able to define more precisely what a specific pattern is all about, what its role within a design system is, and how it is defined and shaped by its environment.
Friday, October 21st, 2016
Kevin writes a plea on Ev’s blog for better contrast in web typography:
When you build a site and ignore what happens afterwards — when the values entered in code are translated into brightness and contrast depending on the settings of a physical screen — you’re avoiding the experience that you create. And when you design in perfect settings, with big, contrast-rich monitors, you blind yourself to users. To arbitrarily throw away contrast based on a fashion that “looks good on my perfect screen in my perfectly lit office” is abdicating designers’ responsibilities to the very people for whom they are designing.
Friday, April 22nd, 2016
A nice tool for choosing colour palettes that look good and are also accessible.
Wednesday, December 31st, 2014