LLMs are useful when you need a compromise between fast and good. You will never get a good outcome fast.
I’m afraid we are settling into a status of good enough when using “AI,” which is especially hurtful for accessibility.
I like the idea of adding this to personal websites:
Mastodon shows an “Alt” button in the bottom right of images that have associated alt text. This button, when clicked, shows the alt text the author has written for the image.
We shouldn’t rely on colour alone to indicate that something is interactive.
Take links, for example. Sure, you can give them a different colour to the surrounding text, but you shouldn’t stop there. Make sure there’s something else that distinguishes them. You could make them bold. Or you could stick with the well-understood convention of underlying links.
This is where some designers bristle. If there are a lot of links on a page, it could look awfully cluttered with underlines. That’s why some designers would rather remove the underline completely.
I’ve done a lot of audits in the first half of this year and at this point a believe that designing links without underlines is a kink. The idea that users don’t understand that links are clickable arouses some designers. I can’t explain it any other way.
But underlining links isn’t the binary decision it once was. You can use CSS to style those underlines just as you’d style any other part of your design language.
Here’s a regular underlined link.
For a start, you can adjust the distance of the underline from the text using text-underline-offset. If you’re using a generous line-height, use a generous distance here too.
Here’s a link with an offset underline.
If you’d rather have a thinner or thicker underline, use text-decoration-thickness.
Here’s a link with a thin underline.
The colour of the underline and the colour of the link don’t need to be the same. Use text-decoration-color to make them completely different colours or make the underline a lighter shade of the link colour.
Here’s a link with a translucent underline.
That’s quite a difference with just a few CSS declarations:
text-underline-offset: 0.2em;
text-decoration-thickness: 1px;
text-decoration-color: oklch(from currentColor l c h / 50%);
If that still isn’t subtle enough for you, you could even use text-decoration-style to make the underline dotted or dashed, but that might be a step too far.
Here’s a link with a dotted underline.
Whatever you decide, I hope you’ll see that underlines aren’t the enemy of good design. They’re an opportunity.
You should use underlines to keep your links accessible. But you should also use CSS to make those underlines beautiful.
I heard you like divs…
Today is Global Accessibility Awareness Day:
The purpose of GAAD is to get everyone talking, thinking and learning about digital access and inclusion, and the more than One Billion people with disabilities/impairments.
Awareness is good. It’s necessary. But it’s not sufficient.
Accessibility, like sustainability and equality, is the kind of thing that most businesses will put at the end of sentences that begin “We are committed to…”
It’s what happens next that matters. How does that declared commitment—that awareness—turn into action?
In the worst-case scenario, an organisation might reach for an accessibility overlay. Who can blame them? They care about accessibility. They want to do something. This is something.
Good intentions alone can result in an inaccessible website. That’s why I think there’s another level of awareness that’s equally important. Designers and developers need to be aware of what they can actually do in service of accessibility.
Fortunately that’s not an onerous expectation. It doesn’t take long to grasp the importance of having good colour contrast or using the right HTML elements.
An awareness of HTML is like a superpower when it comes to accessibility. Like I wrote in the foreword to the Web Accessibility Cookbook by O’Reilly:
It’s supposed to be an accessibility cookbook but it’s also one of the best HTML tutorials you’ll ever find. Come for the accessibility recipe; stay for the deep understanding of markup.
The challenge is that HTML is hidden. Like Cassie said in the accessibility episode of The Clearleft Podcast:
You get JavaScript errors if you do that wrong and you can see if your CSS is broken, but you don’t really have that with accessibility. It’s not as obvious when you’ve got something wrong.
We are biased towards what we can see—hierarchy, layout, imagery, widgets. Those are the outputs. When it comes to accessibility, what matters is how those outputs are generated. Is that button actually a button element or is it a div? Is that heading actually an h1 or is it another div?
This isn’t about the semantics of HTML. This is about the UX of HTML:
Instead of explaining the meaning of a certain element, I show them what it does.
That’s the kind of awareness I’m talking about.
One way of gaining this awareness is to get a feel for using a screen reader.
The name is a bit of a misnomer. Reading the text on screen is the least important thing that the software does. The really important thing that a screen reader does is convey the structure of what’s on screen.
Friend of Clearleft, Jamie Knight very generously spent an hour of his time this week showing everyone the basics of using VoiceOver on a Mac (there’s a great short video by Ethan that also covers this).
Using the rotor, everyone was able to explore what’s under the hood of a web page; all the headings, the text of all the links, the different regions of the page.
That’s not going to turn anyone into an accessibility expert overnight, but it gave everyone an awareness of how much the HTML matters.
Mind you, accessibility is a much bigger field than just screen readers.
Fred recently hosted a terrific panel called Is neurodiversity the next frontier of accessibility in UX design?—well worth a watch!
One of those panelists—Craig Abbott—is speaking on day two of UX London next month. His talk has the magnificent title, Accessibility is a design problem:
I spend a bit of time covering some misconceptions about accessibility, who is responsible for it, and why it’s important that we design for it up front. It also includes real-world examples where design has impacted accessibility, before moving onto lots of practical guidance on what to be aware of and how to design for many different accessibility issues.
Get yourself a ticket and get ready for some practical accessibility awareness.
The foreword to the O’Reilly book on creating inclusive experiences.
Are you looking for a book that explains why you should care about web accessibility?
This is not that book.
Manuel Matuzović has too much respect for your intelligence to waste time trying to convince you of something you already know. You already know that web accessibility is important.
What you really need is a guidebook, a handy companion to show you the way through a tangled landscape.
This is that book.
If you want, you can read it cover to cover. That’s what I did, and I enjoyed every moment of the journey.
But you might not have time for that. That’s okay. The way that this book is subdivided means you can deep into any chapter and it will make perfect sense by itself. It really is like a cookbook. Every chapter is like a standalone recipe.
Whether you read this book linearly or dip in and out of it is up to you. Either way, Manuel is going to massage your brain until something new takes shape in there. An understanding. Not just an understanding of web accessibility, but of the very building blocks of the web itself.
See, that’s the sneaky trick that Manuel has managed with this book. It’s supposed to be an accessibility cookbook but it’s also one of the best HTML tutorials you’ll ever find. Come for the accessibility recipe; stay for the deep understanding of markup.
Best of all, Manuel manages to do all this without wasting a word. Again, he has too much respect for you to waste your time. The only unnecessary words in your Accessibility Cookbook are the ones you’re reading now. So I’m going to follow Manuel’s example, respect your time, and let you explore this magnificent book for yourself.
Enjoy the journey!
So my observation is that 80% of the subject of accessibility consists of fairly simple basics that can probably be learnt in 20% of the time available. The remaining 20% are the difficult situations, edge cases, assistive technology support gaps and corners of specialised knowledge, but these are extrapolated to 100% of the subject, giving it a bad, anxiety-inducing and difficult reputation overall.
Web Content Accessibility Guidelines—or WCAG—looks very daunting. It’s a lot to take in. It’s kind of overwhelming. It’s hard to know where to start.
I recommend taking a deep breath and focusing on the four principles of accessibility. Together they spell out the cutesy acronym POUR:
A lot of work has gone into distilling WCAG down to these four guidelines. Here’s how I apply them in my work…
I interpret this as:
Content will be legible, regardless of how it is accessed.
For example:
I interpret this as:
Core functionality will be available, regardless of how it is accessed.
For example:
I interpret this as:
Content will make sense, regardless of how it is accessed.
For example:
This is where it starts to get quite collaboritive. Working at an agency, there will some parts of website creation and maintenance that will require ongoing accessibility knowledge even when our work is finished.
For example:
I interpret this as:
Content and core functionality will still work, regardless of how it is accessed.
For example:
If you’re applying a mindset of progressive enhancement, this part comes for you. If you take a different approach, you’re going to have a bad time.
Taken together, these four guidelines will get you very far without having to dive too deeply into the rest of WCAG.
Manu’s book is available to pre-order now. I’ve had a sneak peek and I highly recommend it!
You’ll learn how to build common patterns written accessibly in HTML, CSS, and JavaScript. You’ll also start to understand how good and bad practices affect people, especially those with disabilities.
Another handy accessibility testing tool that can be used as a bookmarklet.
This is good advice:
Write alternative text as if you’re describing the image to a friend.
I’m at day two of Indie Web Camp Brighton.
Day one was excellent. It was really hard to choose which sessions to go to because they all sounded interesting. That’s a good problem to have.
I ended up participating in:
In that testing session I shared some of the bookmarklets I use regularly.
Bookmarklets? They’re bookmarks that sit in the toolbar of your desktop browser. Just like any other bookmark, they’re links. The difference is that these links begin with javascript: rather than http. That means you can put programmatic instructions inside the link. Click the bookmark and the JavaScript gets executed.
In my mind, there are two different approaches to making a bookmarklet. One kind of bookmarklet contains lots of clever JavaScript—that’s where the smart stuff happens. The other kind of bookmarklet is deliberately dumb. All they do is take the URL of the current page and pass it to another service—that’s where the smart stuff happens.
I like that second kind of bookmarklet.
Here are some bookmarklets I’ve made. You can drag any of them up to the toolbar of your browser. Or you could create a folder called, say, “bookmarklets”, and drag these links up there.
Validation: This bookmarklet will validate the HTML of whatever page you’re on.
Carbon: This bookmarklet will run the domain through the website carbon calculator.
Accessibility: This bookmarklet will run the current page through the Website Accessibility Evaluation Tools.
Performance: This bookmarklet will take the current page and it run it through PageSpeed Insights, which includes a Lighthouse test.
HTTPS: This bookmarklet will run your site through the SSL checker from SSL Labs.
Headers: This bookmarklet will test the security headers on your website.
Drag any of those links to your browser’s toolbar to “install” them. If you don’t like one, you can delete it the same way you can delete any other bookmark.
Per Axbom quite rightly tears Jakob Nielsen a new one.
I particularly like his suggestion that you re-read Nielsen’s argument but replace the word “accessibility” with “usability”:
Assessed this way, the
accessibilityusabiity movement has been a miserable failure.
AccessibilityUsability is too expensive for most companies to be able to afford everything that’s needed with the current, clumsy implementation.
This is a really lovely little HTML web component from Jason. It does just one thing—wires up a trigger button to toggle-able content, taking care of all the ARIA for you behind the scenes.
I just attended this talk from Heydon at axe-con and it was great! Of course it was highly amusing, but he also makes a profound and fundamental point about how we should be going about working on the web.
Products of all kinds are required to ensure misuse is discouraged, at a minimum, if not difficult or impossible. I don’t see why LLMs should be any different.
Wouldn’t it be great if all web tools gave warnings like this?
As you generate and tweak your type scale, Utopia will now warn you if any steps fail WCAG SC 1.4.4, and tell you between which viewports the problem lies.
I agree with everything that Matt says here. Evangelising accessibility by extolling the business benefits might be a good strategy for dealing with psychopaths, but it’s a lousy way to convince most humans.
The moment you frame the case for any kind of inclusion or equity around the money an organization stands to gain (or save), you have already lost. What you have done is turn a moral case, one where you have the high ground, into an economic one, where, unless you have an MBA in your pocket, you are hopelessly out of your depth.
If you win a business-case argument, the users you wanted to benefit are no longer your north star. It’s money.
Vasilis gives the gist of his excellent talk at the border:none event that just wrapped up in Nuremberg. The rant at the end chimed very much with my feelings on this topic:
I showed a little interaction experiment that one of my students made, with incredible attention to detail. Absolutely brilliant in so many ways. You would expect that all design agencies would be fighting to get someone like that into their design team. But to my amazement she now works as a react native developer.
I have more of these very talented, very creative designers who know how to code, who really understand how the web works, who can actually design things for the web, with the web as a medium, who understand the invisible details, who know about the UX of HTML, who know what’s possible with modern HTML and CSS. Yet when they start working they have to choose: you either join our design team and are forced to use a tool that doesn’t get it, or you join the development team and are forced to use a ridiculous framework and make crap.
