remwork with the user’s font size;
pxcompletely overrides it.
remwork with the user’s font size;
pxcompletely overrides it.
Here’s a short fifteen minute video (and transcript) of an interview I did about accessibility and inclusive design. I quite like how it turned out!
It’s been almost two years since I added audio playback on The Session. The interface is quite straightforward. For any tune setting, there’s a button that says “play audio”. When you press that button, audio plays and the button’s text changes to “pause audio.”
By updating the button’s text like this, I’m updating the button’s accessible name. In other situations, where the button text doesn’t change, you can indicate whether a button is active or not by toggling the
aria-pressed attribute. I’ve been doing that on the “share” buttons that act as the interface for a progressive disclosure. The label on the button—“share”—doesn’t change when the button is pressed. For that kind of progressive disclosure pattern, the button also has an
From all the advice I’ve read about button states, you should either update the accessible name or change the
aria-pressed attribute, but not both. That would lead to the confusing situation of having a button labelled “pause audio” as having a state of “pressed” when in fact the audio is playing.
That was all fine until I recently added some more functionality to The Session. As well as being able to play back audio, you can now adjust the tempo of the playback speed. The interface element for this is a slider,
But this means that the “play audio” button now does two things. It plays the audio, but it also acts as a progressive disclosure control, revealing the tempo slider. The button is simultaneously a push button for playing and pausing music, and a toggle button for showing and hiding another interface element.
So should I be toggling the
aria-pressed attribute now, even though the accessible name is changing? Or is it enough to have the relationship defined by
aria-controls and the state defined by
Based on past experience, my gut feeling is that I’m probably using too much ARIA. Maybe it’s an anti-pattern to use both
aria-pressed on a progressive disclosure control.
I’m kind of rubber-ducking here, and now that I’ve written down what I’m thinking, I’m pretty sure I’m going to remove the toggling of
aria-pressed in any situation where I’m already toggling
What I really need to do is enlist the help of actual screen reader users. There are a number of members of The Session who use screen readers. I should get in touch and see if the new functionality makes sense to them.
A demonstration of how even reinventing a relatively simple wheel takes way more effort than it’s worth when you could just use what the brower gives you for free.
I’ve done this quite a bit: using ARIA attributes as “hooks” for styling and behaviour. It’s a way of thinking of accessibility as the baseline to build upon rather than something that can sprinkled on top later.
I like this approach to offering a design system. It seems less prescriptive than many:
Designed not as a rule set, but rather a toolbox, the Data Design Language includes a chart library, design guidelines, colour and typographic style specifications with usability guidance for internationalization (i18n) and accessibility (a11y), all reflecting our data design principles.
Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than a group of fantastic programmers working in a system designed with other goals.
I think he’s on to something. I also think this applies to design just as much as development. Maybe more so. In design, there’s maybe too much emphasis placed on the talent and skill of individual designers and not enough emphasis placed on creating and nurturing a healthy environment where anyone can contribute to the design process.
Jacob also ties this into hiring:
Instead of spending tons of time and effort on hiring because you believe that you can “only hire the best”, direct some of that effort towards building a system that produces great results out of a wider spectrum of individual performance.
I couldn’t agree more! It just one of the reasons why the smart long-term strategy can be to concentrate on nurturing junior designers and developers rather than head-hunting rockstars.
As an aside, if you think that the process of nurturing junior designers and developers is trickier now that we’re working remotely, I highly recommend reading Mandy’s post, Official myths:
Supporting junior staff is work. It’s work whether you’re in an office some or all of the time, and it’s work if Slack is the only office you know. Hauling staff back to the office doesn’t make supporting junior staff easier or even more likely.
Hiring highly experienced designers and developers makes total sense, at least in the short term. But I think the better long-term solution—as outlined by Jacob—is to create (and care for) a system where even inexperienced practitioners will be able to do good work by having the support and access to knowledge that they need.
She answered a question that had been at the front of my mind: what’s the difference between inclusive design and accessibility?
The way Irina put it, accessibility is focused on implementation. To make a website accessible, you need people with the necessary skills, knowledge and experience.
But inclusive design is about the process and the system that leads to that implementation.
To use that cliché of the double diamond, maybe inclusive design is about “building the right thing” and accessibility is about “building the thing right.”
Or to put it another way, maybe accessibility is about outputs, whereas inclusive design is about inputs. You need both, but maybe we put too much emphasis on the outputs and not enough emphasis on the inputs.
This is what made me think of Jacob’s assertion that quality is systemic.
Imagine someone who’s an expert at accessibility: they know all the details of WCAG and ARIA. Now put that person into an organisation that doesn’t prioritise accessibility. They’re going to have a hard time and they probably won’t be able to be very effective despite all their skills.
Now imagine an organisation that priorities inclusivity. Even if their staff don’t (yet) have the skills and knowledge of an accessibility expert, just having the processes and priorities in place from the start will make it easier for everyone to contribute to a more accessible experience.
It’s possible to make something accessible in the absence of a system that prioritises inclusive design but it will be hard work. Whereas making sure inclusive design is prioritised at an organisational level makes it much more likely that the outputs will be accessible.
The obvious answer to why you should build a website that doesn’t need
jsis… because some people don’t use
js. But how many?!
A handy little script from Aaron to improve the form validation experience.
New from Mr. Vanilla JS himself, Chris Ferdinandi:
A learning space for people who hate the complexity of modern web development.
It’ll be $29 a month or $299 a year (giving you two months worth for free).
Though I didn’t make the connection until much later, the philosophy of progressive enhancement in web design, which I’ve been advocating for nearly two decades now, is very much the embodiment of equity. It’s concerned with building interfaces that adapt to a wide range of circumstances, both tied to an individual user’s capabilities as well as those of the devices, networks, and environment in which they are accessing our creations.
I really, really enjoyed this deep dive into practical HTML semantics. Sit back and enjoy!
I really enjoyed Laurie’s talk in Berlin a few weeks back. I must blog my thoughts on it.
But I must admit that something didn’t sit quite right about the mocking tone he took on the matter of “the fundamentals” (whatever that may mean). Chris shares my misgivings:
Those websites that don’t load on slow connections, or break completely when a JS file fails to load, or don’t work for people with visual or physical impairments?
That’s not an issue of time. It’s an issue of fundamentals.
I think I agree with Laurie that there’s basically no such thing as fundamental technologies (and if there is such a thing, the goalposts are constantly moving). But I agree with Chris with that there is such a thing as fundamental concepts. On the web, for example, accessibility is a core principle of its design that should, in my opinion, be fundamental.
Do I wanna see teenagers building frivolous websites? Absolutely. But when people are getting paid well to build our digital world, they have a responsibility to ensure the right to engage with that world for everyone.
A fascinating account of the history of JAWS and NVDA.
This is why
This is a terrific resource! A pattern library of interactive components: tabs, switches, dialogs, carousels …all the usual suspects.
Each component has an example implementation along with advice and a checklist for ensuring its accessible.
It’s so great to have these all gathered together in one place!
Prompted by my recent post on
alt text, Geoff shares some resources on the right length for
I made the website for this year’s UX London by hand.
So it’s minium viable static site generation rather than actual static files. It’s still very hands-on though and I enjoy that a lot; editing HTML and CSS directly without intermediary tools.
When I update the site, it’s usually to add a new speaker to the line-up (well, not any more now that the line up is complete). That involves marking up their bio and talk description. I also create a couple of different sized versions of their headshot to use with
srcset. And of course I write an
alt attribute to accompany that image.
By the way, Jake has an excellent article on writing
alt text that uses the specific example of a conference site. It raises some very thought-provoking questions.
I enjoy writing
alt text. I recently described how I updated my posting interface here on my own site to put a
alt text front and centre for my notes with photos. Since then I’ve been enjoying the creative challenge of writing useful—but also evocative—
Some recent examples:
A close-up of a microphone in a practice room. In the background, a guitar player tunes up and a bass player waits to start.
People sitting around in the dappled sunshine on the green grass in a park with the distinctive Indian-inspired architecture of the Brighton Pavilion in the background, all under a clear blue sky.
Looking down on the crispy browned duck leg contrasting with the white beans, all with pieces of green fried herbs scattered throughout.
But when I was writing the
alt text for the headshots on the UX London site, I started to feel a little disheartened. The more speakers were added to the line-up, the more I felt like I was repeating myself with the
alt text. After a while they all seemed to be some variation on “This person looking at the camera, smiling” with maybe some detail on their hair or clothing.
The beaming bearded face of Videha standing in front of the beautiful landscape of a riverbank.
Candi working on her laptop, looking at the camera with a smile.
Emma smiling against a yellow background. She’s wearing glasses and has long straight hair.
A monochrome portrait of John with a wry smile on his face, wearing a black turtleneck in the clichéd design tradition.
Laura smiling, wearing a chartreuse coloured top.
A profile shot of Adekunle wearing a jacket and baseball cap standing outside.
The more speakers were added to the line-up, the harder I found it not to repeat myself. I wondered if this was all going to sound very same-y to anyone hearing them read aloud.
But then I realised, “Wait …these are kind of same-y images.”
By the very nature of the images—headshots of speakers—there wasn’t ever going to be that much visual variation. The experience of a sighted person looking at a page full of speakers is that after a while the images kind of blend together. So if the
alt text also starts to sound a bit repetitive after a while, maybe that’s not such a bad thing. A screen reader user would be getting an equivalent experience.
That doesn’t mean it’s okay to have the same
alt text for each image—they are all still different. But after I had that realisation I stopped being too hard on myself if I couldn’t come up with a completely new and original way to write the
And, I remind myself, writing
alt text is like any other kind of writing. The more you do it, the better you get.
I added a “notes” section to this website eight years ago. I set it up so that notes could be syndicated to Twitter. Ever since then, that’s the only way I post to Twitter.
A few months later I added photos to my notes. Again, this would get syndicated to Twitter.
Something’s bothered me for a long time though. I initially thought that if I posted a photo, then the accompanying text would serve as a decription of the image. It could effectively act as the
alt text for the image, I thought. But in practice it didn’t work out that way. The text was often a commentary on the image, which isn’t the same as a description of the contents.
I needed a way to store
alt text for images. To make it more complicated, it was possible for one note to have multiple images. So even though a note was one line in my database, I somehow needed a separate string of text with the description of each image in a single note.
I eventually settled on using the file system instead of the database. The images themselves are stored in separate folders, so I figured I could have an accompanying
alt.txt file in each folder.
Take this note from yesterday as an example. Different sizes of the image are stored in the folder
/images/uploaded/19077. Here’s a small version of the image and here’s the original. In that same folder is the
This means I’m reading a file every time I need the
alt text instead of reading from a database, which probably isn’t the most performant way of doing it, but it seems to be working okay.
Here’s another example:
In order to add the
alt text to the image, I needed to update my posting interface. By default it’s a little
textarea, followed by a file upload
input, followed by a toggle (a checkbox under the hood) to choose whether or not to syndicate the note to Twitter.
The interface now updates automatically as soon as I use that
input type="file" to choose any images for the note. Using the
FileReader API, I show a preview of the selected images right after the file input.
Here’s the code if you ever need to do something similar. I’ve abstracted it somewhat in that gist—you should be able to drop it into any page that includes
input type="file" accept="image/*" and it will automatically generate the previews.
I was pleasantly surprised at how easy this was. The
FileReader API worked just as expected without any gotchas. I think I always assumed that this would be quite complex to do because once upon a time, it was quite complex (or impossible) to do. But now it’s wonderfully straightforward. Story of the web.
My own version of the script does a little bit more; it also generates another little
textarea right after each image preview, which is where I write the accompanying
I’ve also updated my server-side script that handles the syndication to Twitter. I’m using the
/media/metadata/create method to provide the
alt text. But for some reason it’s not working. I can’t figure out why. I’ll keep working on it.
In the meantime, if you’re looking at an image I’ve posted on Twitter and you’re judging me for its lack of
alt text, my apologies. But each tweet of mine includes a link back to the original note on this site and you will most definitely find the
alt text for the image there.