Going Beyond the Listener: Accessible Audio for Podcasting [TRANSCRIPT]
REBECCA KLEIN: We’re so excited to have you here today for Going Beyond the Listener– Accessible Audio for Podcasting. This webinar is being live captioned. My name is Rebecca, and I’m from 3Play Media.
And I’ll be moderating today. I’m joined by accessibility consultant Nic Steenhout, who hosts the Accessibility Rules Podcast. In this presentation, he’ll share his tips for hosting an inclusive podcast, and explain why accessibility matters for a better listening experience. And with that, I’ll hand it off to Nic, who has a wonderful presentation prepared for you all.
NIC STEENHOUT: Thank you, Rebecca. Good morning, everyone. [SPEAKING FOREIGN LANGUAGE] We’ll talk about accessible podcasts today, which is obviously a really important topic.
There is so much to talk about around this topic that the limited time we have is not enough to cover everything. But hopefully, we’ll give you the tools to start asking the right questions, and start thinking about where you can find more information. Obviously, I’m always available for answering questions later, particularly on Twitter. I’m good on Twitter.
A few links of interest– my personal website, which is at incl.ca. Don’t freak out about having to write these down. I’ll make the slides available to 3Play Media for later access.
I do host the Accessibility Rules Podcast. It’s a series of conversation around accessibility. I have two series. One is a long-form interview, and my most recent series is the Accessibility Rules Soundbite, where we have discussions with disabled people about the barriers they experience on the web, and these are 5 to 10 minutes each, really easy to find time to watch, to listen, to read.
I have a general site about podcast accessibility, which is podcast-accessibility.com. And I just started a new series called Accessibility Minute, which is primarily TikTok based, where I talk about accessibility one minute at a time or less. So that might be interesting for you as well.
But let’s dive into our topic. There’s three main areas I’m going to talk about today– transcripts and the website to host your podcasts, whether it’s a hosting platform, Podbean, or whichever ones, or you make your own website. And then around that, we also want to talk a little bit about the player. It’s not an in-depth code review. I can talk about that if you’re interested, but I think for now, we’ll keep it more of an overview.
Now, you’ll see that my logo for my podcast is actually A11y Rules, which is Accessibility Rules. And I want to talk a little bit about that because when you’re looking at resources on the web or social media, being able to search on that a11y hashtag is quite useful. A11y stands for accessibility.
It’s called a numeronym. And that’s a complicated word, really, to say that we’re taking words and transforming them into a series of letters and numbers to represent something. So in this case, we’re looking at the first letter, which is A, and then the last letter, which is Y.
And we’re counting the number of letters in between. We have 11, so we have a11y, which gives us accessibility. You may have come across things like internationalization, which is a18y. It’s something that happens quite a bit in the tech world. But for those of us who aren’t really techie, the a11y or ally tag is useful to know about when you’re doing some searching.
Let’s dive in to the benefits of transcripts. I’m really amused that 3Play Media asked me to do this presentation because one of the things I’ve been using a lot when talking about accessibility of podcasts and the benefit of transcripts is a case study they did a few years ago with the NPR show, This American Life. Basically, if you have a transcript, you will have a lot more new traffic– 4.36% of new inbound traffic.
Now, for some people that doesn’t seem like a lot, but 4%, more than 4% of new people coming to your site all the time– it actually builds up quite an audience. There were over 7% of visitors that actually relied on the transcript. So it’s not insignificant to have 7 people out of 100 that when there is a transcript, they actually use it. That’s fantastic.
We’re also talking about search result increase. I often say Google was the largest screen reader on the internet because it spiders the web. It searches the web as if it was a screen reader. It only looks at text content. So if you have a transcript, you will have more opportunity to be indexed by search engines.
So from that perspective, you will get more people coming to you. You will appear in search results more often. And that’s really good.
But that’s not the primary benefit of having a transcript when you’re looking at an accessibility perspective, of course. The primary benefit is to make sure that people who need access will be able to use your show to get the information. So some of the benefits of the transcript– indexed and searchable.
So I have about 200 shows. And all my transcripts are all in one place. And if I don’t remember who was it that I spoke about this topic about, or what was it that Joe actually said to find the right text to use somewhere else– maybe in a blog post or marketing material– because everything is indexed and searchable, I can actually go through that very easily.
Your content will be more easily translated if you have it in a transcript format, rather than just audio. You have more people that can access your content. And it’s also a benefit for folks that have limited bandwidth or slow connections.
And for a lot of us, we live in urban areas. We have really high, fast broadband connections. But the reality is that we have over 80% of people that access the internet access podcasts through their mobile device.
And again, we’re in town. We have 5G connections. We have really good amount of data. But for the majority of people, that’s not the case.
So if you’ve traveled throughout the US at all or traveled in rural anywhere, really, you’ll realize that data is limited. And the speeds are also limited. So sometimes, accessing the content through a transcript is better than actually interacting with a media player.
There’s also that people that don’t speak the language of your podcast may have an easier time to follow the conversation along and reading it. I know I have several French speakers that come to my podcast. And they say, without the transcript, I would not be able to really follow the conversation.
But this is an accessibility that is not disability related. But it’s an accessibility feature where we’re providing this ability to interact with the content in more than one way. So that’s the general benefit above and beyond people that have hearing impairments will benefit from transcripts– all that.
I talk a lot about transcripts because it’s important. We’ll get to other things later. But let’s focus on that for a little bit.
The features of transcripts that are really important– time transcript– you have to have a timestamp in your transcript. Why do you want that? Well, you may or may not choose it, but if you decide to implement a feature for synchronizing the transcript with the audio band, which helps people follow along what’s being written as it’s being spoken, having time transcript will allow that to happen.
You want to make sure that if you’re not having only one person speaking, you actually include the names of the speakers every time someone changes. So if I’m speaking, I’m going to start the line by Nic, and then whatever I’m saying. And if Sofia is speaking, I’m going to say “Sofia,” and follow up with whatever name is there. So it’s important to have names in the transcript to make more sense as to who is saying what.
Often, you have the options of creating verbatim transcripts. It’s harder to read. You want to avoid pauses, hesitation, language sticks, whether someone is saying “so” or “yeah” or pauses and goes, “hmm.”
All these things will in a way pollute the transcript and make it harder to understand. So you want to try and avoid verbatim transcripts unless you really need it by law. For example, if it’s a court transcript, that needs to be verbatim. But in the context of podcasting, generally speaking, we don’t need that.
And you want the transcript to be clean. Include only the words. You may want to say things like– if there’s music that’s coming in, you may want to add that for context. But you try to avoid including all the noises and all that. The transcript is not a series of captions, so the rules for transcripting in the content is somewhat different from captions.
Before I move on to the next, I see that there’s a question in the Q&A. I can’t see that. But Rebecca, please feel free to flag me, interrupt me. And I’ll be happy to answer questions on the fly, not just necessarily at the end.
REBECCA KLEIN: Sure, if you’d like to answer it now, we can. The question is, how many timestamps make sense? After how much time goes by in the transcript should you add another timestamp?
NIC STEENHOUT: That’s actually a fantastic question. Generally speaking, when you’re getting transcript done by services, they will add timestamp at speaker change. If you’re only the one, every probably 30 seconds, 20 seconds, something like that, would be a good rule, generally, to allow for the synchronization of a transcript to the audio.
But that varies. And I would say that you really should do a test, and get one time transcript, and see how it plays with your implementation to see. Because depending on the player you’re using, that might actually have an impact.
So there’s two primary ways to get transcripts created. One is human transcription, and that’s generally more accurate. 97% to 99% is my average success rate when I give transcripts out, whether it’s a big commercial entity or an individual that specializes in doing transcripts.
So it’s fairly high accuracy, but it can be more expensive. Prices right now for the big outfits, you can find as low as $1, $1.25. If you’re looking at non-English transcripting services, then you can pay $5, $6, $7 per minute of audio, depending on the language and the experience of the transcribers.
So it can get expensive quickly if you’re doing a lot of podcasts. I had a client once that decided that they were going to actually hire somebody full-time to do transcription because they were producing so many, having an external transcriber was not an option cost-wise.
You have also machine translation, sometimes called “automatic translation.” It is a lot cheaper, $0.05, $0.10, $0.15 per minute of audio. But it’s also a lot less accurate, about 80% if you’re lucky, although the artificial intelligence gets better all the time.
But it also gets really, really good if you have a fairly standard, Midwestern, North American accent. The moment you have a more tricky accent, even my French Canadian accent– I’ve been speaking English for 30 years, but it triggers some interesting interpretation from automatic transcription tools. For example, one that really cracks me up all the time is every time I say the word “deaf” referring to someone who has no hearing, automated translation will typically write “death,” D-E-A-T-H. And that’s a little bit embarrassing when you’re trying to provide information and you refer to one topic as something completely opposite to that. So you want to be careful around that.
There’s been this thing that you may have seen people say, “Better a bad transcript than no transcript.” And I think there should be a lot more of a pushback against that. Because if you’re looking at 80% accuracy, you’re looking at missing two words in 10.
That can be skipping the word “better.” That can be skipping the word “transcript.” So “a poor transcript than no for your podcast”– that starts making no sense.
Or “better a transcript than transcript for your podcast.” That’s 80% accurate, but it actually means nothing. In fact, a lot of people in the deaf and hard of hearing community refer to bad automated transcript and captions as “craptions.” It makes me laugh every time I hear that, but that’s really, really important to realize that transcripts must be accurate.
Now, how do you produce transcripts? There’s really two big ways to go about that. You can hire a transcription service.
It’s easy. Cost can be a concern. And it will require review. Every time I have someone create a transcript for me, particularly around the fact that my podcast is tech, so there’s a lot of jargon that is used, but I want to make sure I correct that.
Or you can create your own. And that’s always time consuming. Obviously, it costs less because it’s your own time. But your time is worth money.
You get better at it. But it can take a while to do. And it still requires review because when you’re working so closely with stuff, you will always be in a position where you’re likely to make mistakes. So having somebody review your work is also a good way to do this.
Now, my own transcript workflow is actually fairly straightforward. I get an automated transcript done. And then I manually edit. For my context, I have realized this is really the most cost-efficient way, time-efficient way, to get to 100% accurate transcripts.
There’s different platforms you can use. I’m not going to name any specific one. I don’t want to advertise one service or another because the quality changes all the time.
You’ll have to do a little bit of testing. Most of the automated transcript services will offer a free test to try it and figure it out. But if you’re looking at trying to get a feel for how you’re going to implement transcripts and create transcripts, this might be a good way to get started– do automated transcript, and then fix it up yourself.
So you have this transcript. Where do you put it? That’s always the question. It’s got to be easy to find. If the transcript is not easy to find, it might as well not exist.
My personal preference, and usability testing over the years, tells me that the best place for your transcript is as part of the episode page. This may or may not be possible, depending on the platform you’ve used. And we’ll talk about that a little bit.
But if you’re doing your own website or if you’re picking a new platform that allows displaying the transcript on the page, that’s really the best place. Don’t do it as a downloadable document unless that’s in addition to being displayed on the page. And try to avoid having the podcast on a separate page.
Sometimes, you may not have a choice because maybe your platform only allows you to put some show notes or limited links. So you have to look at that. But if at all possible, display the transcript front and center on the main page of your episode.
And title it “Transcript.” Don’t put the text there without a title. Because we’re going to look for transcripts, and the best way to look for that is actually look for the word “transcript.” If it’s not there, it’s going to be hard to find, and you’re making the user think, and maybe you’re going to lose the audience before they find the product you worked so hard to create.
One thing you may want to get into the habit of doing is during your show, announce that you have a transcript available, maybe up at the first, after the intro, you may say, “Hey, we have transcripts.” It’s a good habit to get into because people will become aware it’s available. They may not be able to see it.
Maybe they’re getting to your podcast through their application. But when they realize you have a transcript, they might actually swap and go where the transcript is. You’ll never know.
So that’s a quick overview of transcripts. Let’s take a few questions around that while it’s fresh. What is up there?
REBECCA KLEIN: Sure. So we had one question just to clarify. The person was confused about the verbatim versus clean. And are you saying that the transcript should or should not be verbatim?
NIC STEENHOUT: Transcripts in general, unless you have a legal requirement for having it verbatim, should not have all the hesitation, the hums, the ah, the pauses. That will make it harder to read and follow.
REBECCA KLEIN: Got it. And I think that’s it for now.
NIC STEENHOUT: OK. All right. So let’s talk about where is your podcast going to live? There’s generally two big solutions. One is you buy a service, a podcast hosting platform that specializes in that. Or you’re going to roll your own.
Now, there are literally dozens of different hosting platforms. And I have not seen very many that had all the features that I wanted to have in a fully accessible podcast. That’s why I ended up building my own. Excuse me for a second. Sorry about that.
So the offerings changes often. So I can’t say Podbean is more accessible than Buzzsprout or whatnot, because they keep improving. And you’re going to have to do a bit of legwork to decide which one is going to work for you at the moment.
But hopefully, by the end of this session, you’ll actually know what to look for when you’re looking for a host. I would say the most important feature when you’re looking for a host is, do they allow you to display a transcript on the page. Some of them offer that as a premium feature.
I think it’s appalling to force people to pay to make the features more accessible, so I would not personally do that. But again, you may find features of that particular platform appealing and useful to use. So that might be an option.
One of the reasons why I say the ability to display a transcript on your podcast platform– why that’s the most important– is because if people have other accessibility needs, often, they may use or rely on their own podcast application playing. So they may get to it through different ways, not directly through your host or your website. So we have to keep that in mind.
Finding a platform is incredibly difficult, and probably one of the most important decisions you can make before starting a podcast. Because it’s not necessarily a good idea to change after six months or a year. It can fragment your audience and make things more complicated.
There’s a difference, also, between hosting and the platform. Because some services will allow you to host your files, have your actual MP3’s hosted somewhere that you can link to from different places. I host all my files on DigitalOcean because I have a space, and it’s cheap to do that.
But you have also podcast providers that allow you to have hosting only, or hosting and the platform. So you can decouple these two features as you need. So that is something else– eventually, maybe you want to change the platform that displays your podcast, but you want to remain with your host, so you can do that. You need to ask these questions of the platform, the provider, before getting established with them.
So I ended up building my own website for my podcast, rather than using a specialized podcast provider, because I wanted everything to be accessible. Some of the things you want to look at is, can somebody using only a keyboard interact with the website? Whether it’s the website of the platform you’re using or your own, you want to make sure that someone can actually get through all the buttons, and tab from one to the next, and be able to trigger each button, interact with them as you go.
You also want to make sure that screen reader users are able to interact with all the buttons, including, and perhaps especially, around the player, the media player, to show your podcasts– whether it’s a video podcast or an audio-only podcast. Screen reader users, folks who have no vision or maybe folks who have low vision, will need to interact only with the keyboard. So you also have this double layers of people who are sighted that can’t use a mouse, so they need to be able to see where to focus that, but blind screen reader users will also need to interact only with the keyboard.
You also have folks that have low vision that need to come to the site. So your color contrasts need to be spot on. You don’t want to have gray text on gray background. That’s going to make it incredibly hard to read.
It’ll even make it hard to read for you, if you’re accessing your site on a mobile phone and you’re outside waiting for a bus or whatever. So you want to make sure your contrast is quite good. In technical speak, we want a contrast of 4.5 to 1 of the foreground of the text against the background. So that’s really a minimum.
So these are the primary things you want to look at. Can you interact with every element on your page using only keyboard? And are all the buttons labeled properly?
If you decide to build your own– which can be a bit of a daunting proposition, but it’s actually worth it, I think– you need to find the right CMS, the right Content Management System. A lot of people are using WordPress because there’s a lot of themes for WordPress that are already accessible. So that’s a good start. And there’s a lot of plugins that are available for creating the podcast aspect of your website.
So once you build that you want to ensure accessibility– again, looking at keyboard, contrast, interactions for screen readers. And then you may need additional custom work. On my site, I use the plug-in from Seriously Simple.
They are a podcast host and platform providers, but they’re also providing a plug-in, and I was able to modify that to my own needs. One of the problems I had with this plug-in was that the player they were providing was not fully accessible. I could not make it do what I needed it to do. So I did additional custom work. When you’re looking at starting a podcast or maybe revamping your podcast, these are all items that you need to investigate and scope before you start to work.
And looking around the player, some of the things we want to look at– are all the buttons keyboard friendly? That is, can you get to all the buttons by using the Tab key? And once you’ve moved forward through it, can you move backwards? Using Shift and Tab on your keyboard will allow you to progress backwards on the page.
Do you have visible focus style? So a sighted keyboard-only user should be able to know where their tab is at, where the keyboard has moved, onto which element. Because maybe if you don’t see that, maybe you’ll trigger the Rewind button or go to the End button, instead of the Pause button.
And all the buttons need to be programmatically labeled, so someone who can’t see the interface using their assistive technology should be able to know that when they reach the Play button, it’s the Play button. And when they reach the Timeline, they should be able to know it’s Timeline. And they should be able to know that they’re at 5 minutes into the timeline out of 59 minutes. And they should be able to interact with the scrubber to move forward or backwards.
There are more and more accessible media players. Unfortunately, very few of them are actually used by the big podcast providers. The two top ones are called Able Player, which is a free, open source media player you can get on the web. You also have OZ Player, which is really good. And those will require a little bit of technical know-how to implement, but they’re really good, powerful options.
And there’s other options out there. You can do a search for “accessible menu player.” And I did one this morning, and there were half a dozen pages, including one that was itemizing all the top players, and giving pros and cons. So the information is fairly straightforward to find, if you know how to look for it.
Talking about Able Player– it’s the one I went to because it allows implementing time transcripts. For videos, it also allows audio description, which is a separate audio file that allows you to insert a description of what’s on the screen. So if you have specific actions that are providing information, and someone can’t see that on the screen, with an audio description band, we can give that information.
The problem with Able Player is it’s complex. A friend of mine said it’s like using a 10-pound sledgehammer to put in a finishing nail sometimes, because there’s so many features. But we are where we are. Sometimes, we need to have this complex piece of software to be able to get basic accessibility because some of the out-of-the-box players are not so accessible.
So that’s a bit of a turnaround. I see Sheri is saying, don’t forget speech interfaces. Thank you. I was actually forgetting about that.
The labeling of the buttons and the interface needs to be clear so someone who interacts with the site using only speech voice commands can say, “Click Play” or “Click Pause” or “Click Fast Forward.” So you need to have that interactions not only being able to give the command, but know which command to give. If the buttons are not labeled really well, then that’s going to be more difficult.
So to recap, you want to find a platform that’s good for your podcast, but make sure it’s accessible. Either you find a host and a platform that is already accessible, or you roll your own. You want to make sure that the media player that is being used is accessible to folks of all disabilities.
You want to provide a transcript. Again, transcript is probably one of the biggest aspects of accessible podcasting. And you want to make them easy to find.
So that’s the nutshell of accessibility for podcasts. And I would love to open up to questions and answer, and maybe have a bit of a discussion around that.
REBECCA KLEIN: OK, thank you, Nic. We’ve had a lot of great questions come in. But I encourage everyone to continue asking, and we’ll try to get to as many as possible.
So the first question I have here is, if not a downloadable document, how are transcripts presented on most sites? Are they just HTML text underneath or some other format?
NIC STEENHOUT: Yeah, HTML text underneath is the best way. It’s good because it’s accessible for anyone, whether it’s displayed visually or it’s accessed programmatically via assistive technologies. It’s going to be responsive, ideally, so you can view it on a big 32-inch screen or you can view it on small mobile devices.
So that’s really the best way is HTML. A good example, if you go to my website, a11yrules.com, you will see all the transcripts there, how it’s presented. I’ve gotten feedback from a lot of people saying it’s really useful.
REBECCA KLEIN: OK, and then up next– does laughter fall under what you said about clean transcripts? Or should it be added in? And if so, what’s the best practice for denoting an important sound?
NIC STEENHOUT: Yeah, this is a question of a judgment call. You have to look at it. I would tend to insert that kind of information if it’s really important to the context. One of the best ways to do that is to put the sound within brackets, so a square bracket. And you would say either “music” or “laughter.”
Or sometimes, two guests will speak one on top of the other. So you may want to actually specify there’s cross-talking happening. And it really comes down to a judgment call as to how important it is to really make sense of the conversation. What you want to avoid is loading so much of that extra information that you end up increasing the cognitive load as you’re reading the transcript.
REBECCA KLEIN: OK. And then here’s a question about TikTok captions. So it says that a lot of content creators will transform words that will flag the TikTok censors, such as curse words or words that will bring up hate speech. And so creators will use sound-alike spellings or emojis. And the question is, what experience does this create for people actually using the captions to understand the content?
NIC STEENHOUT: That’s a touchy topic. First, I have to say that TikTok captions are far from the best. They’re often difficult to read. They often appear right under the hashtag, so there’s conflicts between the foreground and background, and it can be a bit hard to follow.
In terms of trying to avoid censors and automated detectors, sometimes you don’t have a choice. The best way is to actually avoid words that will trigger that. Sometimes you don’t have a choice.
It has an impact on the experience, obviously. I would personally not censor sensitive words, swear words in particular. Because as my good friend Meryl Evans has said repeatedly, we’re deaf. We’re not fragile, little things that can’t actually view these things.
But if you don’t have a choice, you don’t have a choice. I personally would avoid emojis because that, again, increases cognitive loads. Emojis have a very highly cultural context, so the same emoji can be perceived very differently, whether it’s looked at by someone in North America or someone in Europe or someone in Asia.
Probably replacing some of the crucial letters with asterisks is one way to avoid censorship while providing enough context to someone reading it to be able to figure out what’s going on. But there’s no easy answer here.
REBECCA KLEIN: Yeah, it’s a tough question. Can you discuss the podcaster using a script versus speaking off the cuff, and the advantages and disadvantages as they pertain to accessibility?
NIC STEENHOUT: There’s a couple of things. Using a script is actually really good, but it takes practice to be able to follow the script when you’re actually podcasting. Having a script there will– if you don’t deviate from it and ad lib, like I do a lot.
I start reading my script, and then suddenly I say, oh, I wanted to say this, and I go off script. So that’s a problem. But if you have a script and you follow it, that will be really helpful to create your transcript.
Where it’s a little bit more difficult is if you have an interview podcast where you can’t really script the conversation. So that’s going to become more difficult. So you can have parts of things that are scripted– your intro or sponsor announcement or whatever else. But depending on the kind of podcast you’re running, you may not be able to use and rely on the script to get to a point where you have a transcript.
REBECCA KLEIN: OK. And the next question is, is there a recommended font color and background for accessibility?
NIC STEENHOUT: No. That’s the short answer. The longer answer is, you want to avoid colors that might trigger issues for folks that have color blindness. Typical is green and red. Blue and orange will be problematic. So these combinations you want to avoid.
What you really have to look at, though, is contrast levels. So you want to make sure that your text has enough contrast, pops enough against the background. And there are a lot of tools online to check that.
If you do a search for “color contrast checker,” you should get two or three different options right at the top of your search list. And you would put the color value in hexadecimal. So you may have seen codes like FFFFFF for white or 000000 for black.
So you put that in the contrast checker. And it will tell you the contrast ratio. If you’re above 4.5 to 1, you’re doing good. If you’re below that, you have to adjust your colors to make sure that you have that sufficient contrast.
In terms of fonts, you may have come across people touting dyslexic fonts or use Comic Sans because it’s easier for people with reading disabilities. The fact of the matter is there actually hasn’t been any studies peer-reviewed that are statistically solid enough, that have a large enough number of participants, to say yes, absolutely, this particular font is easier to read in that particular font. In general the suggestion is around using a sans serif typeface.
I think the best thing you can do is give users a choice. So allow a user to implement their own style sheets. So if they have a specific need for a specific font, they can actually do that in the browser.
If that’s not possible, you want larger text. You want sans serif for on-screen reading. And you want to avoid the number of characters being more than 80 characters per line. Because of that, it becomes too wide, too hard to read.
REBECCA KLEIN: OK. Does having a transcript allow you to meet WCAG 2.0?
NIC STEENHOUT: Yes. Actually, transcripts are one of the top success criteria. It’s 1.2.1 off the top of my head, so that’s meeting level A of WCAG 2.0 and 2.1 and 2.2. And you actually need that to meet that success criteria.
REBECCA KLEIN: Great. Do you have any advice for making podcast art or related imagery accessible?
NIC STEENHOUT: I don’t. It’s not something I’ve really looked at. I know it’s out there. I personally find a lot of the podcast art distracting, so I try to avoid it because I think it can trigger a lot of people with ADHD.
And some of them are actually too flashy. And it can trigger people migraine or seizures. So you really want to stay away from things that flash a lot.
Other than that, for visual aspects, you want to make sure that if it’s really informative, you want to make that available to folks that have no vision. And apart from using a player that allows you to add audio description, the only way you would have to do that would be to add that information within the page or the transcript, but that can really make things a lot harder to follow. So I think visual art for a podcast is something that needs a lot more investigation as to is it really accessible or not. And my gut feel, based on doing accessibility so long, is that it’s not the best approach.
REBECCA KLEIN: Got it. How exactly do you ensure that the player on your site is accessible?
NIC STEENHOUT: There are a lot of things to do. Your first thing that you want to do is anyone can do it that uses a keyboard, load a page with that player, a demo page or whatever. And use the Tab key. And try to see if you can go through all the elements on the player.
Associated with that, try to see if you can see where your keyboard is at. Because sometimes, you can get to each of the elements, but you actually can’t see the focus. So those are the two primary things. If you can do that, chances are your podcast is really much better than other players.
The other test that you can do is using a screen reader to interact with it, and see if you can actually know what each interactive element is about or what the purpose of these elements are. Testing with screen readers is tricky if you’re not used to it. There’s information out there as how to do that. The other thing is, if you have a specific question around a specific player, reach out to me on Twitter, vavroom, V-A-V-R-O-O-M, and I’m likely to be able to tell you about your player that you’re looking at or do a quick test, five minutes, to get an idea as to how accessible it is.
REBECCA KLEIN: OK. The next question says that Able Player has a Show Transcript button. Would you still want to display the transcript on the page if your player has this feature?
NIC STEENHOUT: My preference is yes. If you want to limit the amount of information immediately visible, you can use Expand and Collapse Section. But I like to have the transcript front and center, and make it there for two main reasons.
One, I find it easier to find. But also, it’s a little bit of education on the fly, because people coming to your show see, oh, there’s a transcript. And they may be a podcaster, and they may realize, I don’t have a transcript on my show, but this was so useful. And then you start giving back to the community by showing that, yes, you can do it, and it’s easier.
Now, can you rely only on a Show Transcript button in the player? Sure, you can. It’s a question of how do you want to have your page styled, what’s the feel you want to give. And whatever your decision, just make sure that it’s easy to find, easy to interact with, before you make a final decision on how you’re going to display the transcript.
REBECCA KLEIN: Next question says that some of the biggest podcast platforms, such as Spotify and Apple Podcasts, don’t appear to have a way to access the transcripts that we upload on our hosting platforms. So how do these listening apps use the transcripts? And do you know if they plan to make them available at some point?
NIC STEENHOUT: I have no idea what’s going on in the minds of those big platforms, especially Apple. Apple has been really a big advocate for accessibility on so many fronts. I do not understand why they’re not making it easy to reach transcripts.
A lot of the big, commercial organizations seem– and I’m not talking Apple here, I’m talking about the specific podcasting hosting platforms– seem to think that accessibility is a nice to have, bonus feature. They don’t understand that accessibility is a civil right. And there is a lot of advocacy that needs to happen, probably a couple of lawsuits.
There were a couple, three, I think, recently. We need to see more of that because that’s probably the only way that we’re going to progress the ability of doing that. This is why I was saying earlier, in the show itself, say it– “Transcripts are available.”
And then provide a link and show notes to where the transcripts are available, if your platform does not allow you to show them. And then, depending on how people are reaching your show, different modalities, chances are someone who relies on transcript or someone who is deaf, hard of hearing, is not likely to be relying on podcast applications that don’t allow transcripts displayed– chances are.
REBECCA KLEIN: But if you have a website with a video on each page, would it be better to have each transcript under each video or all of the transcripts together on one page?
NIC STEENHOUT: I would have each individual transcript on the same page that the video or the audio is on. Don’t bundle them all together because it’s going to be harder to access.
REBECCA KLEIN: Has there been any push for ASL interpretation for podcasts? And should podcasters strive to do this or is it unnecessary?
NIC STEENHOUT: ASL is particularly useful when you are using video podcastings, or vlogs. If you have an audio-only band, implementing ASL becomes difficult because ASL will need to have a video aspect to it. So you’re taking an audio-only media and making it into an audio and video aspect, so that can be a little bit difficult.
Another thing is that not all people who are deaf or hard of hearing are fluent in sign language, much less American Sign Language. The world we live in is global. And we have audience coming from all over the world.
People in England don’t speak– people who sign in England don’t speak American Sign Language. They use British Sign Language. People in New Zealand will use New Zealand Sign Language. People in France use another type of language.
And while there’s similarities between some of them, they’re not the same. So by all means, provide a sign alternative because it will make things more accessible to a lot of people. But you cannot think, oh, I’m providing ASL, therefore I don’t have to provide captions or transcripts.
REBECCA KLEIN: Great. So I think that’s just about all of the questions that we have time for. I want to thank everyone for joining us. And thank you, Nic, for a wonderful presentation.
NIC STEENHOUT: Well, thank you for having me. And thanks to everyone who sat through the presentation. Just final reminder– feel free to ping me on Twitter if you have any follow-up questions. I’ll be happy to answer there.