Skip to content

Acknowledging the Elephant in the Room – Moving Toward Media Accessibility

Rahul Gonsalves
2 min read

Accessibility evangelists have long touted the ease with which inaccessible online content may be made accessible – merely convert your nasty, table-based website to spanking clean HTML and CSS, sprinkle on a few skip links and and you were home scot free. The argument was a compelling one – multiple groups of people with impairments (screen reader, keyboard and assistive technology device users) benefit from these technical fixes, it makes for an elegant and easily-digested business case and more over, can be carried out relatively cheaply.

However, the accessibility of online media – videos, audio and interactive presentations which combine the two – has been carefully ignored and cannot be solved via technical means alone. No amount of tinkering with source code is going to make them accessible to people who cannot see, hear or who are deaf-blind. The solution is obvious – captioning is needed for those who cannot hear while text descriptions which can be both accessed on a Braille device and converted to speech are required for the deaf-blind and the blind respectively.

Three problems exist: firstly, adding captions and writing text descriptions involves a significant amount of effort; secondly, it is often unclear – even in countries where accessibility legislation exists–whose responsibility it is to provide these alternatives; and lastly, even in the rare case where there are content authors who are willing to add captioning to media, there are further technical issues which harken back to the Dark Ages of web design – multiple, incompatible (proposed) standards, fragmented or non-existent application support and little or no adoption by content creators.

What is urgently needed is to standardise on a file format for captions, encourage application vendors to adopt it and to ensure that tools that produce these files exist and are used. The World Wide Web Consortium’s proposed standard, Synchronized Multimedia Integration Language (SMIL), an XML-based language that allows authors to “describe multimedia presentations”, is one possibility. It uses an XML-like syntax and is thus easy to repurpose existing editors to generate these files.

Secondly, there is a need to educate content authors on best practices for captioning. Captioning is a far more comprehensive exercise than subtitling (which merely involves translating dialogue for hearing viewers who do not understand the original language). Captioning describes sound effects, moves to indicate who is speaking (thus requiring the ability to add layout or positioning information, which SMIL provides) and may be displayed on an assistive technology device (text-to-speech convertor, refreshable braille device, etc).

Media accessibility is often carefully swept under the carpet; however, there is an urgent need to start addressing it’s absence. Large portions of the internet otherwise risk becoming unavailable including incredibly popular websites like Youtube (currently ranked the third-most popular website in the world) – to visitors with impairments.

Most people with impairments would benefit greatly from the greater social participation that access to these resources would give them. Furthermore, the United Nations Convention on the Rights of Persons with Disabilities has been signed and ratified by a large number of countries, India included. It is time for accessibility evangelists to move away from the low-hanging fruit of web standards towards advocating rich media accessibility and for content creators to embrace media accessibility best practices.

Accessibility

Related Posts

Let My People Go Surfing

Let My People Go Surfing

The only way to build digital products

A digital product starts with an idea. But it takes a lot more than that to get it to real users. You need to run experiments, speak to users at different stages, build a product and market it. The typical journey looks like this: Right in the middle of this

The Founder OS

Working at a startup is super stressful. Running a startup is 10x more stressful. How do I know? I run one. Some habits and practices have helped me deal with the stress and stay as sane as possible. I call it “The Founder OS” and it has four or five