|Notes on Accessibility|
The concept of accessibility as applied to this project was in connection with the ability of hearing impaired learners to access learning events that were primarily presented in audio. It is ironic that this giant leap forward for the vision impaired was a step backwards for the hearing impaired. Prior to the interest in presenting audio materials on the web, this medium was a great boon for the deaf community.
George Buys, a blind software developer who developed the Talking Communities virtual classroom (otherwise known as iVocalize or Alado), says that making audio input accessible for the hearing impaired is one of the more challenging issues facing web developers.
At this point in time, there are a couple of courses of action, neither of them totally satisfactory.
1) Voice Recognition Software
This kind of technology is reasonably well known and quite common. Voice recognition software is that kind of software that can be trained to recognise an individual users voice and transcribe the spoken utterances of that voice into written (typed) text. In a mattter of hours users report a 90% accuracy rate for this remarkable software.
This may be useful when composing an audio file for a voice email or voice board (asynchronous media), but won't work in a live synchronous setting as voice recognition software is trained to transcribe one voice, and one voice only, and the mix of different vocal inputs present in a typical synchronous interaction would render the output of voice recognition software unintelligible. Even if each user in a synchronous environment was using their own specially trained software to transcribe their own voice, it is not practical to set up a dialogue where you can hear the voices of the other participants in say, an online chat, but the software is shielded from those other voices.
Another disadvantage of voice recognition software is that its final output is a written text only. Spoken text is not retained, and ideally what is needed is software that produces an oral and written output in tandem.
2) Closed Captioning
When I first saw this approach in action I was very impressed. As the speaker at the conference worked through their presentation the entire text of their speech was appearing on a separate screen in real time with stunning speed and accuracy. I thought that it was being magically transcribed by some superb state of the art machine somewhere. It was, but that machine was human. What was happening was that a highly paid speed typist was writing every word virtually as soon as it was uttered.
There are closed captioning services (Caption IT, Caption Colorado, Caption First) that will offer to be present in a live voice chat or conference presentation to provide such synchronous typing, but they don't come cheap. A$200 is the cheapest I have been able to find. And no such services exist in Australia at present. This A$200/hr rate is the same whether you ask the captioning service to be present in real time or, as more typically is the case, the transcribing of the spoken dialogue takes place after the fact.
Some companies, notably Horizon Wimba with their Live Classroom, have arrangements with specific closed captioning services at reduced rates. Tools like Live Classroom archive all the content from live sessions, and if an archive has been targeted for close captioning (it does not happen automatically), the third party closed captioning service provides a written transcript of the spoken dialogue for inclusion in the archive. The hearing impaired viewer, when listening to the archive, simply types /cc to call up the close captioning provided for the archive and they can read every spoken word.
Live Classroom provides another service to aid the hearing impaired participant in live sessions and archives. If presenters are using Powerpoint to design content for their sessions they can use the notes tool (that facility where the presenter writes a note of explanation for each slide) to ensure that some written text appears in the text chat area as s/he speaks. This requires that what is written in the notes view for each slide becomes in effect a script that closely corresponds to what you actually say. The listener, either in live or delayed, asynchronous mode simply types /sd to be able to view the spoken comments of the presenter as written text.
from the Elluminate website:
Accessibility at a
* Multiple streams of closed captioning
From the White Paper:
So - who organises the cc provider? The user or the organisation hosting the event? And who pays?
More From the White Paper:
So I figure then
the screen reader cannot read the text chat?
Other Kinds of Accessibility
Voice as a Solo Pursuit
There is another aspect of accessibility that needs to be considered when approaching the use of web based voice tools. In my observations of students using voice tools throughout this project it has been apparent that most of them do not have access to a private space where they can contribute to voice based events in private. Most computers in institutions (where many students typically work on computers) are in public spaces. Contributing in writing is a silent activity and can be done without fuss in a public space. This is not the case with voice tools. Contributing with your voice means you can be heard by others sharing that public space and may disrupt them. It also has the effect of hampering free communications by the participant, as those randomly gathered around are not your intended audience, and it can be embarrassing to be sitting at a computer, albeit with a headset, seemingly talking to oneself. This has quite drastic consequences for the take up and effective use of voice tools in educational environments. Students may need access to computers in relatively private or sound-proofed areas to feel totally comfortable contributing to voice based online events.
(also access to headsets, mics, expertise)