The only person who wants a carousel on your site is you. That’s it. It’s a self-serving vanity project so that you can showcase all of your babies at the same time without telling the world which one is your favorite.
Wednesday, March 30th, 2022
Wednesday, October 20th, 2021
Do you need a button for your next project but you’re not sure about the right markup? Don’t worry, The Button Cheat Sheet™️ has got you covered.
Spoiler alert: it’s the
Monday, September 20th, 2021
On the surface this is about the pros and cons of minting a new HTML
search element to replace
div role="search" but there’s a deeper point which is that, while ARIA exists to the plug the gaps in HTML, the long-term goal is to have no gaps.
ARIA is not meant to replace HTML. If anything, the need to use ARIA as ‘polyfill’ for HTML semantics could be considered as a sign and a constant reminder of the fact that HTML falls short on some semantics that benefit users of assistive technologies.
Thursday, September 16th, 2021
This is a fascinating deep dive by Léonie on the inner workings of speech synthesis. She has quite a conundrum: she wants fast playback, but she also wants a voice that doesn’t sound robotic. Unfortunately it’s the robotic-sounding voices that work best at speed.
If you’re interested in this topic, I highly recommend listening to (or reading) the accessibility episode of the Clearleft podcast which featured Léonie as a guest giving demos and explanations.
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.
Monday, September 6th, 2021
The annual day-long online accessibility event is back on September 23rd.
No sign-up. No registration. All sessions are streamed live and publicly on the Inclusive Design 24 YouTube channel.
Thursday, August 19th, 2021
Tuesday, August 17th, 2021
I was moaning about Safari recently. Specifically I was moaning about the ridiculous way that browser updates are tied to operating system updates.
But I felt bad bashing Safari. It felt like a pile-on. That’s because a lot of people have been venting their frustrations with Safari recently:
- Jorge Arango wrote Back to the Bad Old Days of the Web,
- Dave Rupert wrote One-offs and low-expectations with Safari,
- Perry Sun wrote For developers, Apple’s Safari is crap and outdated, and
- Tim Perry wrote Safari isn’t protecting the web, it’s killing it.
I think it’s good that people share their frustrations with browsers openly, although I agree with Baldur Bjarnason that’s good to avoid Kremlinology and the motivational fallacy when blogging about Apple.
It’s also not helpful to make claims like “Safari is the new Internet Explorer!” Unless, that is, you can back up the claim.
On a recent episode of the HTTP 203 podcast, Jake and Surma set out to test the claim that Safari is the new IE. They did it by examining Safari according to a number of different measurements and comparing it to the olden days of Internet Explorer. The result is a really fascinating trip down memory lane along with a very nuanced and even-handed critique of Safari.
And the verdict? Well, you’ll just to have to listen to the podcast episode.
If you’d rather read the transcript, tough luck. That’s a real shame because, like I said, it’s an excellent and measured assessment. I’d love to add it to the links section of my site, but I can’t do that in good conscience while it’s inaccessible to the Deaf community.
When I started the Clearleft podcast, it was a no-brainer to have transcripts of every episode. Not only does it make the content more widely available, but it also makes it easier for people to copy and paste choice quotes.
Still, I get it. A small plucky little operation like Google isn’t going to have the deep pockets of a massive corporation like Clearleft. But if Jake and Surma were to open up a tip jar, I’d throw some money in to get HTTP 203 transcribed (I recommend getting Tina Pham to do it—she’s great!).
I apologise for my note of sarcasm there. But I share because I care. It really is an excellent discussion; one that everyone should be able to access.
Some folks called us out for lacking transcripts for our podcasts. Fair point! So, here we go (and all future episodes will have transcripts)https://t.co/HmfwBvAicA— Jake Archibald (@jaffathecake) August 18, 2021
Sunday, June 6th, 2021
A great introduction to structuring your content well:
Wednesday, May 12th, 2021
Google Workspace Updates: Google Docs will now use canvas based rendering: this may impact some Chrome extensions
We’re updating the way Google Docs renders documents. Over the course of the next several months, we’ll be migrating the underlying technical implementation of Docs from the current HTML-based rendering approach to a canvas-based approach to improve performance and improve consistency in how content appears across different platforms.
I’ll be very interested to see how they handle the accessibility of this move.
Friday, May 7th, 2021
This is a great deep dive into a single component, a password toggle in this case. It shows how assumptions are challenged and different circumstances are considered in order to make it truly resilient.
Thursday, April 1st, 2021
A very comprehensive directory of accessibility resources.
Wednesday, March 24th, 2021
Given the widespread browser support for
prefers-reduced-motion now, this approach makes a lot of sense.
A good tutorial on making password fields accessible when you’ve got the option to show and hide the input.
Monday, March 22nd, 2021
Vitaly has rounded up a whole load of accessibility posts. I think I’ve linked to most of them at some point, but it’s great to have them all gathered together in one place.
Wednesday, March 17th, 2021
I really like the approach that Carie takes here. Instead of pointing to specific patterns to use, she provides a framework for evaluating technology. Solutions come and go but this kind of critical thinking is a long-lasting skill.
Monday, March 15th, 2021
Based on the problems with accessiBe and its ilk, I have signed my name to this:
- We will never advocate, recommend, or integrate an overlay which deceptively markets itself as providing automated compliance with laws or standards.
- We will always advocate for the remediation of accessibility issues at the source of the original error.
- We will refuse to stay silent when overlay vendors use deception to market their products.
- More specifically, we hereby advocate for the removal of accessiBe, AudioEye, UserWay, User1st, MK-Sense, and all similar products and encourage the site owners who’ve implemented these products to use more robust, independent, and permanent strategies to making their sites more accessible.
Monday, March 8th, 2021
This is a really interesting take on the intersection between accessibility and progressive enhancement (which I always felt was there, but this expresses it well):
Accessibility aims to optimize an experience across a spectrum of user capabilities. Progressive enhancement aims to optimize an experience across a spectrum of user agent capabilities.
Indeed, if you broaden the definition of “user agent” to include a user’s physiology, I think the concepts become nearly identical.
Vasilis offers some research that counters this proposal.
It makes much more sense to start each page with the content people expect on that page. Right? And if you really need navigation (which is terribly overrated if you ask me) you can add it in the footer. Which is the correct place for metadata anyway.
That’s what I’ve done on The Session.
Sunday, March 7th, 2021
I like this proposal, and I like that it’s polyfillable (which is a perfectly cromulent word).