Skip to main content

Amphora.

I recently found myself on the official page for AMP Stories, the latest offshoot of Google’s Accelerated Mobile Pages (AMP) project. If you’re not familiar, an AMP Story presents content in a carousel-like format, similar to what you’d see on Snapchat, or in Instagram Stories. (As an aside, Kottke did an excellent write-up on this editorial trend.) About halfway down the page, you can find nine featured demo Stories produced by editorial teams at Wired, the BBC, The Atlantic, and others.

I opened up this AMP Story demo promoting a CNN article on the environmental collapse of Antarctica, turned on Apple’s VoiceOver screen reader, and made this audio recording:

In that recording, a computerized voice can be heard reciting a seemingly nonsensical string of words, numbers, and letters. Phrases like “protecting the Antarctic” and “a journey to a continent in distress” can be heard here and there, but those are rare bits of coherence. Instead, the voice tends to sound more like this: “Button. Button. Button. Leaving web content. Null, group. Null, group. Button.” It’s a stream of gibberish.

If you’re curious, the audio came from this video recording I made:

In the recordings above, I’m trying to navigate through the AMP Story. And as I do, VoiceOver describes a page that’s impossible to understand: the arrows to go back or forward are simply announced as “button”; most images are missing text equivalents, which is why the screen reader spells out each and every character of their filenames; and when a story’s content is visible on screen, it’s almost impossible to access. I’d like to say that this one AMP Story was an outlier, but each of the nine demos listed on the AMP Stories website sound just as incomprehensible in VoiceOver.

Now, the usual caveats: VoiceOver is just one screen reader, and AMP Stories might be more usable in other browser / screen reader combinations, as Marco Zehe reminds us; screen readers are just one form of assistive technology; I’m not a VoiceOver expert; and maybe most importantly, the way I use a screen reader is dramatically different from someone who relies on that technology to browse the web.

With all that said: as these AMP Stories are currently designed, they seem completely unusable—that is, unless you can see the screen like I do.

I have some thoughts about this.

First, it’s tempting to criticize the individual publishers for the usability of these demos. However, I can’t help but notice that each demo is inaccessible in very, very similar ways: unlabeled buttons and groups, images missing alternative text, and so on. Given that, I’m inclined to think one (or both) of these things happened:

  1. That the AMP Story format is riddled with accessibility issues. (Given that AMP itself has significant accessibility issues, this wouldn’t surprise me.)
  2. That the Google AMP team provided guidance to each editorial team prior to the launch of AMP Stories, and that guidance shaped the inaccessible demos.

Now, I’m not suggesting these editorial teams shouldn’t have to care about accessibility—we all have to care about the web we broke, and urgently. But since all of these demos are unusable, and in eerily similar ways, I have to imagine there are broader, cross-team issues at work here.

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.

Since the beginning, Google has insisted AMP is the best solution for the web’s performance problem. And Google’s used its market dominance to force publishers to adopt the framework, going so far as to suggest that AMP’s the only format you need to publish pages on the web. But we’ve reached a point where AMP may “solve” the web’s performance issues by supercharging the web’s accessibility problem, excluding even more people from accessing the content they deserve.


Update: Paul Baukaus, one of the leads on the Google AMP team, mentioned on Twitter that this wasn’t intentional, and that AMP’s aiming to “follow the WCAG closely.” Paul also noted that AMP has an accessibility working group.

I replied with a few questions, asking whether these rather serious issues were discussed prior to the launch of AMP Stories. I also asked whether that accessibility working group will be reviewing and approving new features before they’re launched. Paul replied to say that there is an accessibility review process, but that something happened with the launch of Stories; there’s an ongoing internal discussion to identify what happened, and how to move forward. I was intensely curious to know if any part of that discussion will be happening in public, and Paul created a public issue on GitHub to track the discussion.

There’ll be more to come, I’m sure.


Current page