Look Listen Touch

If you’re proofreading the transcriptions of BrailleSC interviews, please follow these guidelines:

• Check that the transcription matches what’s being said.
• Check spelling and punctuation.
• Don’t worry about grammar if the transcription matches the audio.
• There only needs to be one space between the end of one sentence and the beginning of the next.
• Ignore any verbal filler like “Um” or “Uh” or “like” or “you know” or “I mean.” Such filler does not need to be included in the transcription. If it’s already there, you can delete it, or you can ignore it (in the interests of time) and count on me to catch it in the final phase of proofreading.
• Where someone laughs, please include “[Laughter]” in that part of the transcription. This will be helpful for deaf users who read the transcription or watch a captioned version of the video.
• Note that the word “braille” does not need to be capitalized unless it’s used as part of a proper name, like “Braille National Challenge” or “Louis Braille.”

Any questions? Just leave them in the comments below. Thank you!

The BrailleSC project currently has almost 30 oral histories on video, some of them already transcribed but most of them not. For transcription work, we’ve been using Amazon’s Mechanical Turk service, which is certainly reliable, affordable and efficient (as I wrote here), but it’s not exactly ethical (as I wrote here). Is there another solution? What about crowdsourcing? Could we, in other words, make the task of transcription available to an army of potential volunteers from across the Internet and get good results?

Plenty of online projects rely on crowdsourced work with (mostly) good results: see, for instance, LibriVox, Project Gutenberg, and Wikipedia. And recently, George Mason’s Center for History and New Media was awarded an NEH Digital Humanities Start-Up Grant “to support the design and development of a tool for crowdsourcing documentary transcription:”

The $49,215 award will enable CHNM’s dev team to to build an open source tool to enable researchers to contribute document transcriptions and research notes to digital archival projects, thus harnessing the power of the community of users to improve the discoverability and usefulness of the archive.

That’s a very exciting project, and I look forward to seeing the results. What about crowdsourcing audio transcription?

Consider this an invitation to participate in an informal experiment in volunteer transcription work. Here’s the question we’d like to answer:

Can a project involving audio or video recordings of spoken words rely on volunteers for transcription of interviews broken up across short clips?

Transcriptions will allow for various forms of textual analysis and re-use of the interviews, and transcriptions will also aid in creating captions to accompany the videos, which will make them accessible to users with hearing impairment.

What I’ve done is take one interview and break it up into 2-minute clips. I chose that length somewhat (but not completely) arbitrarily. Each clip is hosted on YouTube, where you may view it while transcribing. And while it’s true that YouTube has added automatic captioning of their videos, these captions don’t always work and when they do their accuracy leaves something to be desired.

Here are the details:

1. Unless you instruct us otherwise, we will credit you by name on the web site for your work.
2. All of the materials we produce at BrailleSC will be published with a Creative Commons license allowing others to make use of them under certain conditions (Attribution-Noncommercial-Share Alike), so your work could potentially benefit many projects (if any other projects take our materials and work with them, that is).
3. To volunteer, go to this page and follow the directions.

Any questions or comments about this process (or about the challenge of transcribing audio)? Please leave them below.

Thanks!

[Creative Commons-licensed flickr photo by Beverly & Pack]

We’re trying to figure out if it will be possible to use volunteers from across the Internet to transcribe spoken words recorded on digital audio or video. To participate in this informal experiment, please follow the instructions below.

(For a more detailed explanation of what this is all about, please read this.)

Thank you!

Instructions

1. Before you do anything else, first leave a comment below stating which part of which video you are going to transcribe. This will prevent two people accidentally transcribing the same video clip.
2. On your computer, open a simple word processor like Notepad (if you’re a Windows user) or TextEdit (if you’re a Mac user). Use this application for creating your transcription (and save often!).
3. While watching and listening to your chosen video on YouTube, transcribe what’s being said.
4. Ignore any instance of “um” or “uh.” Where there’s laughter, simply type “[Laughter].” If you can’t make out what’s being said, simply type “???” in that portion of your transcript.
5. When you are finished with your transcript, please cut and paste it into a comment below, identifying which video clip you’ve transcribed.
6. Finally, please go here to leave any observations you’d like to share about your experience. How long did it take you to transcribe 2 minutes of audio, for example? Do you have any ideas for how to improve this process?

Links to video clips

Video 01

Part 01 :: Part 02 :: Part 03 :: Part 04
Part 05 :: Part 06 :: Part 07 :: Part 08
Part 09 :: Part 10 :: Part 11 :: Part 12
Part 13 :: Part 14 :: Part 15 :: Part 16

Video 02

Part 01 :: Part 02 :: Part 03 :: Part 04
Part 05 :: Part 06 :: Part 07 :: Part 08
Part 09 :: Part 10 :: Part 11 :: Part 12
Part 13 :: Part 14 :: Part 15 :: Part 16
Part 17 :: Part 18

Questions or comments about this process?

If you have any questions or comments about this project or this process, please leave them in the comments section of this post: “An Experiment in Audio Transcription.”

Thanks!

[Creative Commons-licensed flickr photo by ghwpix]

You think you’re a fast reader?

You might change your mind after you listen to this recording (mp3, 4:12, 2.4MB) of a Civil War-era letter being read aloud by a "screen reading" computer application called JAWS.

The letter is one of the items in the rough draft of our "proof-of-concept" Omeka archive with an accessibility plugin (created by Cory Bohon with input from George H. Williams) designed to make navigation easier for the visually impaired.

We’ve developed a plugin for Omeka that allows a user with visual impairment to use “Access Keys” to navigate through the site by sound and memory, instead of viewing the menus and links visible on the screen. Our goal is to have a finished, working demonstration of this plugin installed on an Omeka archive of nineteenth-century documents by the end of Fall 2009. (We’ve chosen these documents simply because they were already digitized and available to us with metadata.)

In this mp3 recording, the enduser running JAWS is Marty McKenzie of the South Carolina School for the Deaf & Blind and the South Carolina Department of Education.

The other voices are Tina Herzberg, assistant professor of education at USC Upstate, and George H. Williams, assistant professor of English at USC Upstate.

The image, transcription, and metadata associated with the letter (and many other items) were generously shared by the archivists and librarians working with the Littlejohn Collection at Wofford College.

by Cory Bohon

Universal Access is an interesting topic and while many companies are trying to be innovative in this area, there still needs to be more work with regards to Universal Access and website design. Most web designers (myself included) don’t spend a lot of time thinking about how the end user will access the site. Many of us spend the time to make the site look pretty or achieve an important function without paying attention to things like screen readers, refreshable braille displays, or other asistive devices for the sighted user, tactile user, or auditory user.

Access Keys could be a potential use in designing accessible web pages. By adding a bit of HTML code to a link, we can give a new type of behavior to the web browser. Users can use modifier keys and the specified access key to jump to different links on a web page. While some developers use this type of technology, which has actually been around since 1999, it’s use isn’t as prevalent as it could be.

The UK has actually specified a standard of sorts for access key usage. It goes something like this:

• S – Skip navigation
• 1 – Home page
• 2 – What’s new
• 3 – Site map
• 4 – Search
• 5 – Frequently Asked Questions (FAQ)
• 6 – Help
• 7 – Complaints procedure
• 8 – Terms and conditions
• 9 – Feedback form
• 0 – Access key details

While these rules aren’t imposed on web designers, it is considered good use to develop pages using these access keys. I would love to see the US follow similarly for web design principals. If we could start using these access keys on more websites it would make them universally navigatable by different users.

One hitch to using access keys is that the web browser developers all use different modifier keys to make them work. Google Chrome uses “Alt,” Internet Explorer uses “Alt,” and Opera uses “Shift + Esc.” Apple’s Safari is the most confusing of them all, if you are using version 2.0, Mac users use “Control” while Windows users use “Alt”; if you are running version 3.0, Mac users use “Control + Option” while Windows users use “Alt.” How do you convey to your user which key they should use? If the user isn’t tech savvy, how will they know what they’re running, let alone which version? All of these differences pose problems in standardizing the usage of access keys. This is one of the things we’re trying to figure out.

You can read more about access keys on Wikipedia and WordPress.

As you might have seen on this blog, we’re starting a new section of Look Listen Touch called Look Listen Touch Media that will allow us to create screencasts, podcasts, and more interactive material to supplement and show off what we’re doing. We have already published our first screencast to demonstrate what an accessible website looks like. We also have more of these screencasts currently in the planning stages.

We have made the Look Listen Touch Media screencasts available via the iTunes Podcast Directory. This will allow you to subscribe and get all future episodes of our screencasts delivered directly to iTunes (or your other favorite podcast aggregation tool). To subscribe, just install iTunes (Win or Mac), Miro (Win, Mac, Linux), or  Juice (Win, Mac, Linux) and subscribe to this RSS feed: http://www.looklistentouch.org/casts/?feed=podcast

If you are using iTunes, you may go to the following URL to subscribe: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=333189645

Look Listen Touch Screencast 001 from LookListenTouch on Vimeo.

This video is a basic demonstration of a screen reader, software that reads aloud digital information. The voice you hear first is computer-generated.

More screencasts are planned.

Please send any feedback to gwilliams@uscupstate.edu.

Project Description

LookListenTouch is a University of South Carolina Upstate research project exploring best practices in applying universal design principles to digital humanities projects. Initial funding has been provided through the student research assistant program of the USC Upstate Office of Sponsored Awards and Research Support.

Since last week, I’ve been working on this research project with Professor George H. Williams at the University of South Carolina Upstate. We’re trying to find out the best practices for developing accessible web sites while keeping Digital Humanities in mind. We are attempting to turn Omeka, a CMS for digital cataloging, into the most accessible form of accessing scholastic information no matter a persons disability.

While I was thinking about the different techniques we could use to make these accessibility options available, and I pondered a cool idea. What if, in the same way we can use OpenID to log into multiple websites, we could use a standard accessibility options “plug-in” that anyone could install/code into their site to make it more accessible. Different preferences, like the ability to use a screen reader or use a braille display, could be carried from one website to another without the user having to setup these options again.

Perhaps this task could be completed easily with a Firefox extension that could communicate with the code on the website to load a specific CSS file that would allow for better interaction with a screen reader or braille display.

There is the possibility that someone has already come up with and implemented this idea of a tool for universal web accessibility, and if you know of a project that currently does this same thing or does it better, feel free to leave a comment and let us know!