James Cridland

Kahlimah Jones vs Gimlet — the fight for podcast accessibility

Spotify’s Gimlet is the subject of a class action lawsuit in the New York courts. In the complaint, the plaintiff, Kahlimah Jones, argues that Gimlet violates the Americans with Disabilities Act (ADA) by failing to provide closed captioning on various podcasts. Here’s the complaint in full:

The central point of the complaint is:

§5 [Gimlet] has chosen to post podcasts without closed-captioning, or with limited closed-captioning, that are inaccessible to deaf and hard-of-hearing individuals.

Podcast transcripts

A podcast transcript — here’s one — is the contents of a podcast, written out, so people can read it. The word comes from court transcripts, which are “a written record of spoken language”.

Transcriptions are important and desirable things to have. In part because of how it’s made, Podnews’s podcast has a full transcription in the show notes of most podcast apps: and a clear link from the minority of podcast apps that don’t support full HTML (which includes Spotify, by the way).

Automated transcripts are also available and relatively easily produced, though not always desired by podcasters.

Transcriptions are supported in some form, if not explicitly, by every podcast app out there. Of course, you should be doing transcriptions for every show: it’s helpful for people who are deaf or hard-of-hearing, but also helpful for humans searching your podcast or for search engines. Indeed — some people prefer reading than listening.

While podcasters can link to our transcripts somehow from our episode notes, that’s not ideal: since we all link in different ways. It would be excellent if we were able to link directly to an episode’s transcript with a consistent ‘transcripts’ button. That would require RSS to be extended with a distinct transcript link; and for podcast apps to add something parsing this, and displaying the ‘transcript’ button.

Transcripts for podcasts are normally text-based, but they don’t need to be. Transcripts can include links to other places, photographs, graphics, and more detail, to enhance the experience. You can’t include a map on a podcast: but you can include one in a transcript. Indeed, the BBC’s R&D department produced a “data-rich listening experience” for More or Less, a radio show that examines statistics and data, which contained both a full transcript and additional information like graphs and tables.

Closed-captioning

But, the Jones vs Gimlet suit isn’t asking for transcripts. Instead, it’s requiring Gimlet to produce closed-captions.

Closed-captions, colloquially known as “subtitles” in many countries, are produced from a transcript of a show, timed to display alongside the video.

Closed-captions can be automatically made in a very similar way to transcripts; but because they need timing information as well as text information, they’re harder to do manually.

Closed-captions are also a simple text format: which is great for the purpose of a black box with white text, but not so great for additional information.

While almost any podcast app will offer a link to a transcript, with the drawbacks that I outlined above, there isn’t a single podcast app that I’m aware of that natively supports closed-captions for podcasts. Neither are closed-captions written into the RSS specification.

Closed-captions are also timing-specific. Google did get a prototype of closed-captions working on the Google Podcasts app last year, but didn’t launch it. One of the main issues, one of the team told me over a coffee, was that pre-prepared closed-captions didn’t work with dynamically-inserted ads. If you’d been served a 40-second ad about mattresses while the closed-caption generator had been served a 25-second ad about a VPN, then all the closed-captions after that point would be misaligned with the audio.

Closed-captions are very helpful to help families and groups enjoy TV: and I regularly watch TV with them. However, 92% of podcast listening is done alone: and the experience here would be staring at timed, raw text on a screen. I wonder whether timed closed-captioning, for an almost entirely solitary medium, is the right solution for this medium.

None of this means that closed-captions are a bad thing for podcasts. They’re a good thing. But, they’re very different to a transcript.

Is this lawsuit the right thing to do?

The intention of this lawsuit is absolutely the right thing to do. Accessibility is important. Nobody would deny access to podcasts for deaf and hard-of-hearing people. The answer to “should these things be accessible?” is, of course, a loud “yes, yes they should be”. The Americans with Disabilities Act would seem to make this a requirement.

After fifteen years, podcasting is growing up: and accessibility should be part of podcasting’s future for us to be truly mainstream. However, as with all things, the devil is in the detail of this lawsuit. Questions in my mind include:

a) should closed-captions be legally mandated for all podcasts, as this lawsuit could mandate? Or, should transcripts be legally mandated?

b) what should be legally mandated? In this linked story, an audio transcript is a good thing, but is it better when rewritten for print, with additional material and photographs? Does the rewrite count as a transcript in this case, and help doh people understand the story better? And if so: where is the legal line drawn?

c) is automated transcription, which is typically about 90% correct though often doesn’t distinguish between voices, acceptable?

d) is a requirement for 100% of podcasts to be transcribed the right approach? The FCC has a bunch of rules around closed-captioning, including some program types and whether providing the captions is ‘economically burdensome’.

If it were up to me, I’d look at mandating transcripts, rather than closed-captions. I’d suggest they could include rewrites for different media that substantially contain the same material. I’d mandate 100% of all podcasts to be transcribed, with commercial podcasters (however we define that) legally required to produce transcripts that are humanly-edited and error free. And I’d mandate a transcript button in podcast apps (and thus an RSS extension).

But it’s easy for me to say this: I don’t have to rely on transcripts to enjoy a podcast. I’d be really interested to hear from the deaf and hard-of-hearing community.

One thing’s for certain: podcasting’s accessibility is not currently good enough: and we should do all we can to ensure that they are, truly, mainstream. Let’s make sure we get this right.