Add transcript support for Level A Accessibility

[adamsilverstein]

As @timwright12 mentioned in his talk today, podcasts require a transcript to meet accessibility level A requirements.

• Add a meta box to enter a transcript.
• Add a link to view the transcript in the podcast feed.
• Add an endpoint for displaying the transcript.

[oscarssanchez]

I have some work done for this one, @jeffpaul can you assign to me please ?

[jeffpaul]

@oscarssanchez it's all yours, thanks!

[oscarssanchez]

Hey @jeffpaul ,

Re taking the work for this. The first and third bullet points should be ready for review, however, it is not 100% clear to me what are the requirements for Add a link to view the transcript in the podcast feed

Does this literally mean a link to the endpoint displaying the transcript, or actually displaying the transcription in the RSS feed?

[adamsilverstein]

Does this literally mean a link to the endpoint displaying the transcript, or actually displaying the transcription in the RSS feed?

@oscarssanchez thanks for working on this... Ask @timwright12 to make sure. I think the idea is to have a way to link directly to the transcript itself (a unique url for each transcript) and the link goes in the podcast description.

[timwright12]

@oscarssanchez a link to a transcript would be fine

[oscarssanchez]

Thanks @timwright12 ,

@jeffpaul it looks like you cannot have more than one <link> sub element on each <item> per https://validator.w3.org/feed/docs/rss2.html#hrelementsOfLtitemgt

Does inserting a string like "Transcription: transcript here" at the start of the <description> sub item be ok to account for it? (<description> shows the post content as of now).

For example:

<item>
		<title>testing title</title>
		<link>https://testing.test/test/</link>
					<comments>https://testing.test/test/#respond</comments>
		
		<dc:creator><![CDATA[admin]]></dc:creator>
		<pubDate>Thu, 11 Jun 2020 00:16:09 +0000</pubDate>
				<category><![CDATA[Uncategorized]]></category>
		<guid isPermaLink="false">https://testing.test/?p=2011</guid>

					<description><![CDATA[Transcription: https://testing.test/test/transcription  TESTING SOME TEXT HERE]]></description>
										<content:encoded><![CDATA[
<p>TESTING SOME TEXT HERE</p>



<figure class="wp-block-podcasting-podcast"><audio controls></audio></figure>


]]></content:encoded>
					
					<wfw:commentRss>https://testing.test/test/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
		<itunes:author>admin</itunes:author>
<itunes:explicit>no</itunes:explicit>
<itunes:summary></itunes:summary>
<itunes:subtitle></itunes:subtitle>
	</item>

[jeffpaul]

@oscarssanchez digging into this a bit, Apple Podcasts accepts RSS 2.0 tags and RSS 2.0 does not appear to have an obvious element where we could include a full transcript or a link to one. RSS 2.0 can be extended to include an element for the transcript, but I'm not certain Apple Podcasts would recognize that (and some quick searching doesn't seem to show any good examples of anyone doing this with success either). So after going back to the Apple Podcasts list of required and recommended tags as well as their RSS feed samples, I concur with your analysis that adding the transcription link within the <description> element seems to be our best option. I'd recommend that we include it at the end of any episode description that has been entered so the <description> element would be something like this:

<description><![CDATA[User submitted episode summary. <a href="https://www.example.com/podcast/episode/transcript.filetype">Full transcript available</a>.]]></content:encoded></description>

I know that @helen spent some time reviewing the RSS spec and Apple Podcasts feed spec as well, so I'd like her to chime in on approach before you dive into implementing this.

[oscarssanchez]

Thanks for the insightful info @jeffpaul ! I will hold on this for the moment when we have a consensus for how to move forward :)

[nateconley]

I dug into this a little bit, and 2.5 years later there is no real standard and a significant number of podcast publishers handle this by having a link to the transcript in the podcast's post page (not in the <description>, but within the post hosted at <link>).

WAI's guidance on Where to Put Transcripts is that it is best to include it on the same page, but when media is hosted elsewhere (which seems relevant here), the transcript might be placed on a separate page. WAI also provides an example of a transcript on a separate page.

In my opinion, it seems that having a direct link to the transcript in the <description> is more in the spirit of the guidelines than having a link on the post in the <link>. Having the transcript link in the <description> prevents users from having to follow an extra link to find the transcript.

I did find an organization called Podcastindex.org that has been working on formalizing podcast-specific elements, and has formalized a <podcast:transcript> element. This spec does not have wide adoption, but it may serve as a resource for HTML formatting.

[jeffpaul]

@nateconley that's SUPER helpful, thank you! I wonder then if a decent course of action here is the link in the <description> to ensure things are available now as well as including the <podcast:transcript> element as well (even if that won't immediately appear, for example, in Apple Podcasts) but puts this plugin on the path of being in-line with the future path of Podcast spec?

[nateconley]

@jeffpaul I think that is a reasonable path forward. It is also very possible that this spec will never be widely adopted, but at least this provides some guidance and consensus.

If we are following the Podcastindex.org spec for an HTML endpoint, the transcript should be a plain HTML endpoint (not using something like the_content) that supports <p>, optional <cite>, and optional <time> elements. The example provided does not include additional elements required for the HTML to validate. I do not know if this is an oversight or the expected result, but I assume we would not want to introduce an invalid HTML endpoint. We could do something like this with a basic HTML document (we could omit <head> and <body> and still validate):

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Title</title>
  </head>
  <body>
    <cite>Name:</cite>
    <time>00:00</time>
    <p>Hello world</p>
  </body>
</html>

The XML element could look like the guidance here:

<podcast:transcript url="https://example.com/podcasts/podcast-name/episode-slug/transcript.html" type="text/html" language="en" />

A couple of questions on implementation:

• What should this meta field look like? Should it be a TinyMCE editor, a textarea, or a block?
• Should the field and endpoint support elements other than those specifically mentioned in the spec (<p>, <cite>, and <time>)? Should it support attributes like class or id for those elements?

[jeffpaul]

I'm not wildly opinionated on what the data capture method should be for the transcript, though perhaps we limit element support to what the current state of the recommended spec, as well as ensure there's a relevant block that is included in the plugin to render that transcript after the podcast audio player block perhaps?

[nateconley]

I think a transcript block would be a useful addition. For the field, there is a scenario where someone pastes a transcript that they created elsewhere that uses different elements and they have to re-format everything.

[nateconley]

I have limited availability and need to step away from this issue. Draft PR with TODO: #221