By henny
Podcasts are getting ever more popular on the web and for good reason. They're a portable easy way for many of us to keep up with what's going on whilst on the move as well as a welcome alternative to wasting trees by printing things off to read on the train. Listening to podcasts from South by Southwest 2007 (SXSW), Web Axe and Equal Access to Software and information have provided a welcome distraction for me whilst wedged in between disgruntled commuters on the way home (and also a lot easier than reading a paper). For many people it's also their preferred format when sourcing information.
When meeting with Hidden Differences last week, an organisation that represents people with cognitive and reading problems, they talked about how when canvassing a large organisation's employees recently on their preferred format for internal communications around a third opted for audio. Interesting. However for some of us listening to podcasts it is not an option. If you're deaf, hard of hearing, deaf-blind, do not have a soundcard or speakers you'll be locked out of content if it is only provided in audio format. Not only that so too will search engines. The guidance therefore, according to the Web Content Accessibility Guidelines, is to provide a transcript of what's being said. But here's where the problem starts. Some of you may have noticed I have been promising for some time now a transcript of Shawn Henry's presentation on WCAG 2.0 that RNIB hosted in June. This has proven a trickier promise to meet than I first anticipated and through conversations with other people it's clear that I'm not the only one finding it difficult to get a quality transcript from an audio file. So here are some tips to help you on the way when you're looking at getting a transcript for a podcast:
1. Get speakers to explain what is happening
I'd say that of the majority of presentations I listen to the speaker will kick off with a round of questions such as "How many of you are web designers?", "How many of you are from the US" and so on. This is a great technique for not only the speaker to gauge who they are talking to and who's awake, but also for the audience to know who else is interested in what they are. The problem is that 9 times out of 10 the speaker will fail to repeat the number of hands that go up. This can be very frustrating for the listener and reader who are not there and it leaves you with a sense of "if your name's not down then you can't come in". Equally problematic is the use of images in presentations used to illustrate a point which is then not described. Often you'll see a speaker use a cartoon or some funny photo in a presentation and not describe it. This is an issue not just for people listening to the podcast and reading the transcript after the event, but also for users who can't see the presentation slides when they are there. The final one here is not repeating comments or questions made by the audience which are out of range of the mic. I'd always advise repeating a comment or question anyway not just for the benefit of people who can't here it during the live presentation but also to give both the speaker and audience time to take stock of the question. So the advice is, when presenting take care to describe what is happening.
2. Ensure a good quality of audio
This is obvious I know but when it comes to transcribing you really need to ensure that what you're asking to be transcribed can be heard. It goes back to that old adage of "garbage in garbage out". Try and minimise background noise, noisy clothing, tapping the podium or shuffling about. It can be a long an laborious process for the sound engineer to have to go back and clean up the audio. If you have good equipment this should go a long way to managing this but we don't all have that luxury and even the best of equipment can't block everything out.
3. Provide a list of key words and phrases
When it comes to actually transcribing the audio think about providing the person who is doing it with a list of key words, technical words, acronyms, abbreviations, people and place names, or anything else that is mentioned in the podcast that maybe difficult to transcribe. It is better to assume that the person doing the transcription doesn't have an in depth knowledge of your topic area. Their skill is in transcribing after all, not web accessibility, quantum physics, rhythmic gymnastics techniques from Uzbekistan or what ever your topic is.
4. Get the best person for the job
If you're not a touch typist or trained in transcription it is very hard to transcribe audio and probably counter productive time wise. If the amount of time it takes you to transcribe a podcast takes you away from other areas of your job then think about outsourcing. A quick Google search on podcast transcription services lists a multitude of companies who can do the work for you, it's then just a matter of finding one that can work to your timescales, budget and deliver to a high standard. If you're concerned about cost then think about it in a different way i.e as a cost saving exercise. Think about how much you earn per year and from that work out how much you earn per hour. If what you earn per hour is more than the cost of having somebody do the transcription then there you have your answer (as well as your business case for your boss): outsource. This useful little nugget came from a SXSW podcast called The 4-hour work week: secrets of doing more with less in the digital world by Tim Ferriss (come on, who isn't going to listen to a podcast with that title!).
5. Make sure your transcript can be found
Another common mistake, especially for audio or video delivered in Flash, is to make the link to the transcript difficult or impossible to find. It may be buried in a pop-up window reliant on JavaScript or a link at the foot of a Flash movie. Ideally a link to both the podcast and transcript should be placed side beside within the HTML clearly stating in the link text what they are.
Resources