Tag: Accessibility

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.