Tag: Accessibility

The relevant parts of an image aren’t limited to the cold hard facts. Images can make you feel a particular way, and that’s something that should be made available to a screen reader user.

Quite the collection of accessibility tools here from Nic Chan. A bunch of these were new to me and look super interesting.

Also gave me some ideas for a few things we could start baking into WebPageTest.

Creating a modal that could do all of this required thoughtful consideration and hard work. Under the hood, the modal component is composed of more than 10 sub-components. But that complexity is not passed on to our client.

A good reminder that I really, really need to get with it and spend a bit more time with web components.

Adding a ‘show password’ option to GOV.UK Accounts seemed like a straightforward task, but the more we looked into it the more complicated and interesting it became. This is how we did it and some of the challenges we faced.

More fodder for my firm belief that the closer you look at anything, the more interesting it becomes.

I love it when someone takes a specific problem (in this case, adding text labels to buttons in an accessible way, and then digs deep into solving it.

This is a terrific post by Sara, where she dives into making “Add to Cart” (and other generic text labels) more accessible to both screen readers and dictation services.

I’ve been super keen on getting some sort of way to measure when the accessibility tree is ready ever since first chatting about it with Marcy Sutton 5 years ago or so. Scott has a great post here about why it’s important. He’s also filed issues on WebPageTest and Lighthouse to get something added. Hopefully we’ll see something soon!

We recognize, of course, that “Always accessible” is not a novel approach. Here in California accessibility is a guiding principle in the state’s digital strategy. And our work is just one part of the state’s larger commitment to ensuring that information and services are accessible.

What is novel is how our team is broadening the definition of accessibility for state government to include performance as a core component. Performance as accessibility.

Our goal is to make COVID19.CA.gov fast and easy to use on any kind of hardware or with any level of bandwidth. 

Ethan, eloquent as always, on the inaccessibly of AMP Stories:

Conjecture aside, here’s what I do know: the AMP team decided that each of these Story demos was worth showcasing on the official page for AMP Stories. And that sends a powerful signal about where the priorities for AMP Story sit. The content in each AMP Story is wonderful, the visual designs are effective—but if you use a screen reader, each Story is an assault on your senses. And by showcasing these demos, the AMP team is signaling that’s entirely acceptable.

It reminds me of Surma’s comments about JS frameworks and performance:

Unless a globally launched framework labels itself as exclusively targeting the users of the Wealthy Western Web, it has a responsibility to help developers target every phone on The Widening Performance Gap™️ spectrum.

It’s a big responsibility, but if you’re shipping something that will be this widely used, you’ve got a responsibility to make the default state as secure, accessible and performant as possible.

That’s particularly true for something that makes as bold a claim, as aggressively, as AMP has always done.

I always associated prefers-reduced-motion with CSS, but of course the picture element accepts media queries!

A quick post from Brad showing how you can use the picture element to serve up a static image instead of an animated gif when the “reduce motion” preference is enabled.

Examples like this are why I love how the whole suite of responsive images standards (srcset, sizes and picture) turned out. I know some weren’t as pleased with the final product, but there’s so much darn flexibility (ahem) here to enable us to account for scenarios, like this, that only really emerged after those standards were created.

Fantastic post from Marcy about the consequences of the way we build, and how we can improve.

Brucey-kins on how semantic markup like <strong> and <em> is interpreted by screenreaders.

A good alt text can conjure up wonderfully stimulating mental images. A friendly smile is the same in print, photo or wax crayon. Whether you listen to an image or see it, the emotional response is the key factor, so why should we recommend that these emotion rich images should be given a null alt text and hidden from screen reader users?

VoiceOver has a bug that causes it to misbehave when content is broken up, such as by a <br> or <span> inside a link or header. This is a quick explanation of the issue and how to use role="text" to fix it.

When we rethink our approach to development, we go beyond just the base level of access to information. Inclusive development means making something valuable, not just accessible, to as many people as we can.

I really enjoyed this post from Dropbox about what they do to help cultivate an internal culture of accessibility.

Unsurprisingly, a lot of the advice here mirrors the same sort of good advice an organization might here about cultivating cultures of performance, security or any other critical yet overlooked component of design and development: share knowledge, experience the issues first-hand, celebrate improvements, and build it directly into your workflow.