Navigated to episode Making a Podcast WCAG 2.1 Compliant.

Making a Podcast WCAG 2.1 Compliant

by Nicolas Steenhout

recorded on October 03, 2018

Transcript

>> MICHAEL: Welcome to technica11y, the webinar series dedicated to discussing the technical challenges of making the web accessible.

Our presenter this month is Nic Steenhout, host of the popular Accessibility Rules podcast.

And now, our host and moderator, Karl Groves.

>> KARL: Alright, everybody! This is Karl Groves from Tenon. This is our first technica11y webinar and I think it’s really interesting to note who we have with us. It’s Nicolas Steenhout and Nic and I have known each other for a while. The idea for technica11y came about from Job van Achtenberg, who can’t be with us. He’s actually at Frontiers today. He’s on the Frontiers committee. Job came up with this idea and I sort of ran with it. There’s a lot of conferences out there and there’s a lot of meetups and all that sort of thing, and a lot of the discussions are sort of introductory in nature. There’s lots of reasons why they’re introductory in nature and that’s because a lot of people need the introductory stuff; they need the introductions. But the idea that we had was that we wanted to dive into more discussions around the technologies and more discussions around making sure the information is directly actionable.

And, so, this is the first one of these. We’re going to have these every month, so if anybody has anything to share, that they’d like to talk about about accessibility and they want to get into the weeds a little bit, this is going to be a good format for you.

So without further ado, though, I’m going to introduce Nic and Nic is going to take over and drive the discussion here around podcast accessibility and a lot of the things you have to consider, including new WCAG success criteria and things like that. So, here we go, here’s Nic.

>> NICOLAS: Hello, everyone! I’m really happy to be the first guinea pig to give this series of webinars, but even more excited to talk about podcast accessibility. It's been a pet peeve of mine that there is so many great podcasts out there, but so few are out there are accessible or providing even basic accessibility. Let's get started. Before I share my screen, I should say a couple of things about housekeeping. First is that we're going to take questions but if you can send them through the Zoom interface and we will pile them up at the end rather than interrupt the flow because with this format, it’s a bit difficult. And the other thing is that for people with vision disabilities, the slides don't really have visuals. It's just mostly text to help you to help sighted people to go along. You are not going to miss anything from my slides that I'm describing because it’s just text. With that, I'm going to share my screen for a second. Let's see. Start broadcast.

So I'm sharing screen. Accessible podcast, so that’s what we’re talking about. If you are not here to listen to this, stay anyway, going to be super interesting. I think many of you know me. I'm easily found at Twitter @vavroom. I work for Nobility, based in Austin, Texas. We do accessibility, that’s what we do all the time. I have a personal blog site at http://incl.ca and, of course, I have my podcast website at http://a11yrules.com. I also a few months ago put together a site about podcast accessibility. There is a lot of resources and information there that follow with what I will be talking about today on podcast accessibility websites.

Quick overview. Few things to consider when we are talking about podcast accessibility. The first thing is that we have to provide transcripts. And website need to be accessible and big aspect of an accessible web site is the media player we are using. I will be talking about WCAG 2.1 contrasted with 2.0 which was part of my accessibility journey for with making the podcast accessible.

Do note, it’s not an in depth code review. This is not what this is about. There’s o many things to consider and talk about. I'm not going to go in depth about code and not going to review things that most people should be comfortable with in terms of accessibility when looking at WCAG 2.0 success critera. Accessibility: A11y. For those of you who don’t know, it means accessibility. There’s been a lot of debate about this shortcut, this hashtag is not really accessible. But it's taken ground and known more and more. How did it become A11y instead of accessibility. It's a because it’s a numeronym, a word that I am always tripping on. Basically, we’re looking at the first letter of the word and the last letter of the word and counting the number of letters in between. There’s eleven letters in between A and y. So we have A11y for accessibility. Something that a lot of people don't know where it comes from. There you go.

Transcripts. Obviously, podcasts are an audio format. For a lot of people that can't hear the audio or access the audio for whatever reason, we should provide transcripts. I'm going to focus on transcripts here. There was a study that was done for the show, This American Life for NPR. They transcribed about 500 of their episodes and after they did that, they realized that they had a lot of inbound traffic coming through whether unique visitors or search traffic coming through. They realized that 7% of unique visitors viewed at least one script when looking at site. Seven percent of traffic is considerable. Over 4% of new traffic coming through. And over 6.6% of increased search traffic coming through. That's also quite interesting.

They had nearly 4% of inbound links that started appearing after this transcript. In this day and age of trying to get information and more traffic and more visitors, I think just in and on itself, these numbers for me are really and a good argument to provide transcripts. But there is more. More than that. Beyond making the content accessible for people with disabilities, you end up with audio content indexed searchable. So if you have to refer to episode, you have it right there easy to find. It's more easily translated. If you have your podcast in English and people coming to your site from France or Japan or anywhere else, they can run your content through Google translator or other translating machines and that will be easier for them to access. More people can access your content. There is people that love to listen to your podcast, maybe they are in an open plan on a bus or any number of reasons that it's difficult for them to access the audio. We still have people that have slow connections. We are not all blessed with gigabyte internet connections and we don't have all we can eat data either. So, there’s a whole lot of reasons people will benefit from your transcripts including you.

So, hat is a transcript? It's basically taking anything that is spoken and translating that into the written word. And there is a few things you need to keep in mind when looking at doing transcripts. Typically, when you purchase transcription services, you are going to be asked, “Do you want time stamps?”. Time stamps typically are more expensive to get, but if you implement synchronized transcripts, that's mission critical. I will talk a little bit more about synchronized transcripts later on.

You can get the speaker's name included in the transcript and if you have more than one speaker, it's really crucial to actually know who is saying what. Depending on transcription services, you might have that done for free if there is no more than four speakers or something like that. You will also be asked if you want your transcript to be verbatim. And that means it includes all the “ums” or “you know” or all of these vocal ticks that might be present in the speakers, and typically that makes it harder to read. I think verbatim transcripts are more important when looking at legal or medical transcription, which is obviously not the realm we are moving in when talking about podcasts. Do yourself a favor and order the clean or clean verbatim that includes only the words that are important. Not all the text. It makes it so much easier to read.

There is three main types of transcription you can look at. Two of them are human transcription and the other one is machine transcription. Human transcription, you do the transcript and that can be consuming. It’s cheap if you don't value your time. Can take a while when not used to it. On the other hand, you know the content better. You are going to be more accurate into what is being said.

I'm using human transcription service. It’s costing me a dollar U.S. per minute of audio. So, it’s not cheap but it’s not super expensive. You have to shuffle around. I’m not going to recommend certain transcription services. They are out there and some of them are doing a good job. Between 97 and 99% but if you are doing a technical show, the accuracy goes down. It’s good to build a glossary of words that you are using in podcast. That's going to help the transcription service to actually be more accurate.

A lot of people want to use machine or automated transcription. It’s not a bad thing. Some people say it’s better to have a machine transcript that’s 80% accurate than no transcription at all. In some way, I find that argument difficult to argue against. At the same time, I'm not entirely convinced at the same time. The benefit of the machine transcription, it's going to cost you 10 cents per minute on audio. That can be good approach to starting your transcription. You get the transcribed cheaply with machine transcription and go back and fill in the blank where it's not quite as accurate as you would want.

If we are looking at machine transcription, we may be thinking, “Better poor transcript than no transcript for your podcast.” This sentence has ten words. We are looking at 80% accuracy. What happens if you're missing the first word and a word in the middle and the sentence reads, “[a] poor transcript than no for your podcast.” Suddenly, it doesn’t make a whole lot of sense. Or you can miss other words in the sentence. So, “Better a transcript than transcript for your podcast.” So we dropped poor and no. This gives you a feel when you have only 80% accuracy. You can get a gist, maybe, but you will be missing the crucial points of the whole thing.

If you do rely on machine transcription, I strongly urge you to go back and run through the transcript while listening to your show and fill in the blank and correct the text as it goes.

One of the things I have seen happen a lot is when the show has a transcript, suddenly they put it on different page and the link to the transcript is often hard to find. I’m going to suggest to you that to get the search engine friendliness and all these people being able to benefit from the transcript, the transcript needs to be easy to find. Ideally, it's part of the podcast episode page. If you look at my website for the podcast, all the episodes have the player on the top of the page and right below that, the transcript is available and easy to find and text of the transcript is then associated with the show and it's much better on several respects.

Now, please don't provide the transcript as a downloadable document-- not a PDF or a Word document or a text file. Just put it into your page. It's not going to harm anything. That's what web is for -- to present documents. Avoid putting it on separate page. I think you will have a lot more people enjoying the transcript if it's on the same page.

Now, one thing that a lot of people don't say, is they don't say on the show they have a transcript. That’s something that pays to do. At the start, you can say, there is transcript available and where to find it. If someone is looking for that and accessing the podcast through maybe their podcast player of choice, they will know there is a transcript available and it’s easy to find. You might want to state it that way and when you talk about show notes or anything else, ideally at start of the show so people actually know it's right there when show begins and they don't actually you make it front and center, not as an afterthought. That's a good idea.

So, that was transcripts, a fairly quick overview. We could probably talk more about it. But, let's look a little bit about website. Because, of course, once you have a transcript, you have to have a website of show. There is a lot of different flavors of podcast hosting and solutions.

I was looking for Accessibility Rules podcast to have something that I could make accessible easily and have control over. I chose the WordPress platform, which I’ve known for a while, so, it wasn’t too difficult to make that work for me. Then, I went in search for right plug in. There is a lot of plug ins for podcasting. Some of them you have less control over rather than more. I chose the Seriously Simple podcast plug-in because the code is open and I was able to go in and do the modifications I needed. Again, mostly from an accessibility point of view.

Now, we know that for a website to be accessible, we have to think about the usual suspects. We have to make sure it works for keyboard users whether sighted or not. Being able to tab forward and say backwards and activate all the interactive elements with the enter key or with the space bar. We want to make sure the site works for screen reader users and users with low vision and that includes contrast issues. There is a list of things and I think that majority of people that are attending this webinar actually know about basic accessibility. I'm not going to go in-depth about that. In fact, I'm going to leave it out there that if you want to make an accessible website, look at WCAG 2.0 to get you started if you don't know how to do that.

One of the things I did when I did my website was from early January, I went live with the website and I looked at WCAG 2.0 AA compliance. I was asked on someone on the WCAG 2.1 committee that they really wanted to have my site as implementation site before making the guidelines be accepted. So, I foolishly, maybe, agreed to that and delved into the guidelines to see what would apply to my site, what I needed to worry about, and what did not apply. That was quite an interesting learning experience for me because obviously I've been doing accessibility for a long time, but I was not at that time familiar with 2.1.

I will get back to 2.1 in a little bit with specific criteria I was looking at. If you're looking at building a website like I did on WordPress, you have to start with right theme. Make sure it’s accessibility ready, whatever that means. You have a lot of themes on the marketplace that say they are accessibility ready but are not exactly ready. But, it's a good start. And then you may want to look at Joe Dolson’s most excellent WP Accessibility plug-in which implements a lot of accessibility for things that may not be fully accessible.

Then you may need to do additional custom work. That included for me making 2.1 work. A lot of things in 2.1 did not apply to me. The other aspect is that I was not aiming for a AAA level accessibility, so that let go of a few aspects. Some things were unclear. One of the new success criteria identify input purpose, that's 1.3.5, basically is now understood as make sure that you form input fields have auto complete in it. It wasn’t clear that that was it. I sought guidance with the people that were actually writing the standard and there were some discrepancies in what they were saying. That can actually cause issues for you if you are not really familiar with accessibility. Hopefully, the new technical documents to help you along are going to help. And I should plug in the fact that Nobility has been putting one new blog post about 2.1 success criteria every week. We do cover in depth about what each means and how that's going to impact on you if you look at 2.1

Some of specific things I implemented when I was looking at making my podcast site, 1.3.4 orientation. Basically, it needed to work in both sides of landscape and portrait. That is important for people that will have their devices often be mounted on, for example, wheelchairs. So, they use their phone or iPad premanently mounted in one orientation. If your website requires you to be in one direction rather than the other, it can cause issues. So, for me, orientation worked a little bit with the reflow aspect, 1.4.10, basically, being able to change font size and element being placed where they need to be placed. So, that was work I had to do in the theme in making sure that worked. 1.3.5, as I said, identify input purpose, that was to do around making sure the forms, in that case particularly contact form, had the auto complete field associated to that when the right field were used.

So the name, e mail, address, phone number, all that can be used with auto complete. I ended up removing the contact form for a technical reason. I would not make my contact form system error messaging actually work. I could not associate the error message with the erroneous field and that's something I work on when I had spare time which I haven't had much lately. Something for you to consider that sometimes you might be able to make a form work with some of the new success criteria. But if they are not working across the board with even the old success criteria, there is no real point working on the new ones.

Other elements that were tripping me were 1.4.11 which is non text contrast. That's contrast on elements that are not necessarily text. Logos are good example of that and some images that are critical to understanding on the page. I was loading third party content, namely Patreon, which is a platform that is not accessible. That's a discussion for another day. I had to adjust things to make it work. 1.4.12, text spacing. So, the theme I had selected needed a little bit more spice around line heights and kerning and that kind of stuff, so, I had to move around that. And finally, 2.4.12, which is label in name. I was using a Paypal donate button that I had to implement the label a little bit differently than the code that they were giving me when you are exporting code out of Paypal. I had to play a little bit with that. Nothing major. And I think it's within the reach of pretty much everyone who understands coding a little bit. But, you have to do a little bit of thinking and you might have to play around a little bit before you're reaching a point where you are at. And I would like to point out something that I always tell people that is better to implement a little accessibility and keep implementing as you go, rather than hold back until you are done. Just like any website, you are never really done. There’s always going to be things to improve and implement. Don't wait until you're, quote, unquote, done to make it happen. So, the last aspect I want to cover about podcast accessibility is the player that you provide on your site. I had an issue with the default player that was coming with Seriously Simple pod casting. It was a similar issue found with a lot of podcasting plug-ins, using players that are somewhat accessible, maybe not completely. Seriously Simple podcasting using the JW player that worked with keyboard, but, there was no way to create visible focus on the element. At least not within the implementation when it was on WordPress with the different layers of CSS, so it was difficult in making it work. You could navigate the player with keyboard, you could not see which element was active and that makes it basically not unusable, but, very difficult to use for sighted keyboard users.

Under the hood, they were using some weird ARIA attributes and values which, in my test with voice over and VDA, meant that there were some things that were unexpected. While it wasn't major blockers, you could work around that, it also did not create a friendly experience. And accessibility for me really is about being friendly and making it easy for people. So, I did some research. I tried a few players and I ended up going with Able Player. Incidentally, that's player used on W3C websites, so it’s pretty good in many respects.

Some of the things I like about Able Player, it allows you to add timed transcripts. Earlier, I was talking about when you purchase transcriptions, you can get timed transcripts and they put time stamps through. When you have these timed transcripts and you use Able Player, you can actually get an area on your site that will be timed. So, as the podcast is playing, the transcript is moving along with the right cadence; it's associated that way. I did not implement that because I thought it might create some other issues and it also doesn't allow people to scan the transcript quickly if they want to get feel for the show or get to a specific part of transcript. But, it is a popular option.

The other aspect is that if you are doing video podcast, vlogs more than podcast, you can also provide an audio description file with Able Player. So, that associates the audio description to video file and you are going to be able to have that associated. With a lot of players out there, you would have to jump through massive hoops to make happen.

Able Player is a really solid thing, bu it's also not designed necessarily for WordPress. I thought, “Okay, am I going to spend time making it work more in WordPress or is there a plug in?” And lo and behold, there is a plug-in! It's older, but it’s worked and it’s secure. I'm keeping an eye on security and updates. I was able to find a plug in that allows me to fairly straightforward use Able Player in the site. I had to go in and use short codes in the podcast plug in to remove the default player and be able to use the Able Player. There’s a few hoops to jump through and that's probably something you want to plan for when you start building your site instead of building it and seeing as you go which was a mistake I made, maybe. While I bit of a mistake on the front end, I learned so much and actually having fun doing it! People tell me, “Nic, accessibility is such a chore.” And I say, “You are a coder, right? You like a coding challenge, right?”

“Yeah.”

“Well, think about accessibility as a coding challenge.”

That, for me, was the case. It was a strategy and implementation challenge.

So, as I said, even with the plug-in, I needed to make it work with Seriously Simple podcast. And I did so. Recap quickly and then I will be taking questions. We will have about 20 minutes for discussion and questions. So, find a platform for your podcast. That might take you some time because you have to test the different platforms. There’s a lot of platforms out there, but most of them are not really accessibility friendly or not really easily modifiable. Make sure your platform accessible. Ensure your media player is fully accessible. Provide transcripts and make them easy to find. That is really the end of the slides and hopefully we open up discussions and questions for this.

>> KARL: For those of you who do have questions, type them up in here in the chat. The way that Zoom webinars work is that they don't allow anybody to talk except for presenters which I guess is by design and okay as opposed to having 55 people talking at once. But, it definitely does hinder some interaction. If you have questions, put them through here.

Nic, do you have any favorites in terms of people to do the transcript over others. I know you mentioned that a bit? There’s a couple of services out there. We are using for our live webinar here right now, we are using ACS Captions. I know you have done research on that.

>> NICOLAS: Yeah, I did do quite a bit of research on best transcription services out there. For a while, I was using Rev.com. And they are good. They are quick. They are relatively accurate. But, I have found that a lot of the time, I did not get all that accurate things even when I was providing glossaries. Sometimes they were making mistake even on my name. However, when you have high volume, they provided an API, so, that's good.

Currently, I'm using an independent transcriber that is quick and much more accurate. Because she is independent, she is actually able to tell me, “Ni,c, something wrong with your audio in this particular episode,” or that kind of feedback for me is really important. And so anyone who wants the details, I'm happy to provide contact details after the show.

if you are looking at cheaper machine translation, there is Temi. They are pretty much the best out there. And they are coming up with an API. So you can hook up your system if you have machine if you have high volume as well. There is yeah.

>> KARL: API thing is interesting because we had a client who, you know, doing a high volume of videos and stuff like that on their website, and the ability to sort of shoot off that file for for transcription and getting it right back was neat. That's a pretty competitive space, right?

>> NICOLAS: Yeah.

>> KARL: A lot of services out there. That's why you get it so cheap. It's competitive space. A lot of people use Mechanical Turk, they send them out to Turk workers. That's an increase charge to get the accuracy. It's worth it to spend the extra money to get the increased accuracy.

>> NICOLAS: Yeah.

>> KARL: Anybody else having any questions?

>> NICOLAS: So, I see a lot of questions coming through about my contact details. I think that's been given out by Michael. I see question of use of sign language for deaf people who cannot read or write?

Yeah, you know, this is something that I struggled with. Do I provide that or not? And I think it's fantastic if you are in a position to be able to provide it. From podcast accessibility in general, I think you are going to find issues with making that happen.

So, I struggle a lot with podcasts to tell them, “Hey, you need to be accessible. You need to provide a transcript.” I'm getting a lot of push back on that. I can't really see myself going back to them and saying, “Hey, you know, great, you provided a transcript, fantastic, please provide a video in sign languages with equivalent of your transcript so people who are deaf and cannot read will be able to understand that.” I think that would really be pushing the envelope a lot to the point where people would actually wash their hands of it and not want to touch accessibility. That said, if you are able to provide that, by all means, do it. More accessibility is better than less. Absolutely. Some of the pitfalls I would look at is make sure that sign language you are using is actually relevant to the language of your podcast. If you are using more – your guests are more American, use ASL. If they are more in Canada or Australia or U.K., you have to pick up the right flavor of sign language. You have to see how you integrate the sign language with the podcast audio episode. I think would get quite tricky technically, but, it’s worth doing.

>> KARL: Are you aware of any services that do that? I know, you know, with so with the accessibility boot camps that I do, I have one coming up in November in San Francisco. I've gotten some contacts out there that I have dealt with through online directories for sign language interpreters to do it in person.

I wonder is there a service that would do that let's say here on this Zoom or something like that, is it possible to have a sign language interpreter do it live the way we have ACS doing the captioning?

>> NICOLAS: There is a couple of aspects to that. First thing is I think finding an interpreter would be willing to do it would be relatively mundane. Just question of finding the right person and having budget for it. Last time I looked for interpreters in the United States, it was about $40 per hour on interpreting and I think it's gone up since. In the context of doing a podcast, I think interpreters would be happy to probably go on even Skype and do a Skype video and then you can record screen and then use that to edit your video file. That's relatively simple. For live podcast or live webinar like we are doing now, I think the barrier to use here becomes the platform that you use. How do you ensure that you are able to display the sign language live in the little vignette in the corner of the screen. I don't know that Zoom does that or any other platform that does that. If someone does, I would love to hear about it. >> KARL: You are saying the per hour rate for someone has to come on site and travel to your site and travel to your location like an event, that gets pricey. You know, $40 an hour not a big deal when it's one hour. When they are there all day, it’s pricey. I imagine there has to be a market opportunity for somebody who can do it virtually like this. But I don't know of any. That would be great to hear about though. Anybody else have any questions?

While we are waiting for any more questions to come up, I'm going to mention that next one of these is in November as well. Michael, do you have exact date in front of you or I can log on to Zoom or take a look at that. When everyone registered for Zoom, for whatever Zoom reason registers you for every webinar that you have that you have on the schedule. For us, you are registered for all the rest. That doesn't mean you have to attend, you can unregister if you would like.

>> MICHAEL: Going to be on November 7th.

>> KARL: November 7th. Awesome.

>> MICHAEL: And Gerard Cohen will be our presenter.

>> KARL: Gerard Cohen, another I guy I know rather well. He's a developer at wells Fargo. Going to be talking about custom form elements and specifically I think he's talking specific about the select element. Now, again, keeping in mind that technica11y is about deeply technical things. What I like about this and I'm not going to give spoilers for Gerard's talk, one of my personal pet peeves is the fact that a lot of developers will create custom form elements specifically so they can style them. Graphic designers come up with visual treatment that they want to have forms adhere to. Next thing you know, browser doesn't support styling accordingly. As a consequence, of course, as a consequence, developers will come up with custom form elements. Who God only knows what they were going to look like. It’s usually radio buttons and check buttons and select elements that they do it with because styling regular plain text inputs is kind of easy.

Select elements, everyone has select elements on their forms. And the mechanisms of interacting with select element via the keyboard and getting the necessary feedback to the user is nontrivial. And I give an example of this in a talk that I give that is called, “What is this thing and what does it do?” We have to have some level of predictability to the user interface so user understands how to use it. What is great about this is Gerard is going to give us a deep dive in that stuff. I think he's going to give us an awesome idea for how to make sure the select elements are accessible. That's cool. We are going to button this up here. One other question.

>> NICOLAS: Yep, just saw a question about which websites do I know that use accessible podcasts? There is a few of them, they are difficult to find. I started a list on podcast-accessibility.com. I'm sending that to chat. Oops, I sent that only to transcriber.

Yeah, that's difficult to know because there is no centralized lists anywhere. Every time I come across a podcast accessible, I put it on the list and that's on Github. I invite you to add yours to the list. It's interesting. TEDx videos have captions and transcript. It’s not a bad site at all from an accessibility standard but could be better. Pretty good.

>> KARL: Cool. Now, just for I never as we anyone else as we are buttoning up, if you would like to give a talk here on technically webinars, propose something. Give us a shout on any idea that you have that you would like to share a good technical deep dive on. PJ mentioned a topic she would like to hear about on upcoming topic and that is best practices for making error messages accessible. If anyone wants to do a talk on that, give us a shout. Until then, thank all of you for coming and I want to thank Nick for giving us our first talk for giving us our first talk and my colleague, Michael, for setting this up. God knows I'm too disorganized to get this started. And I want to thank ACS Captions for captions. We will see you in November. Bye.

>> NICOLAS: Thanks, everyone.

Back to the main page