Feed on
Posts
Comments

The World Health Organization estimates 278 million people worldwide have some form of hearing impairment.

A Nielsen study suggests that there has been over a 300 percent increase in online video watching since 2003. Further, most watching is done during work hours. Workplace computers are often muted or have no speakers.

Several billions of videos are watched monthly worldwide, with many of them in different
languages.

See 22frames.com for more about this.

I had my first foray into captioning this week for a short video that a colleague Daniel Davis (@ourmaninjapan) did on remote debugging with Opera Dragonfly and Opera Mobile 10 to mark the release of Opera Mobile 10 Beta (go try it, it’s free).

I’m slightly pink faced to say I’ve not done any captioning before having always opted to transcribe video and audio so I had to start from scratch sourcing the right tool and figuring out how to go about editing and setting up a process. Whilst I set out to caption a video my purpose was also to see how easy or difficult it was as captioning is the poor cousin of accessibility considered to be expensive, time-consuming and only relevant to hand-full of people.

Before I launch into my findings below is the final product captioned in English, Japanese and Russian using  Overstream and hosted on YouTube. Big thank you to Daniel for the translation and original video and Vadim for the Russian. You can also watch the video on Easy YouTube.

There’s also a hidden Easter Egg in there, see if you can spot it.

Captioning benefits

Accessibility – this is the obvious benefit as you’ll be opening up your content to deaf and hard of hearing users as well as people find it easier to read rather than listen (or do both together). If you don’t have translated captions some non-native speakers may also find content easier to consume when reading captions.

Localisation – adding translations to your captions widens your potential audience massively. There are plenty of tools out there such as dotSUB that enable you to crowdsource translations and many hosts such as YouTube which support multiple caption tracks.

Mobile – users with mobile phones who may not have earphones or are in a noisy place also benefit. I do wonder how much can be visible on some small screens but certainly some people will find it useful.

Search – site indexing may also get a boost. For example YouTube supports video searching of caption data which also filters through into Google search.

Getting the right tool

There are more captioning tools out there than I’ve had hot dinners so I thought I’d narrow it down scientifically and just ask over Twitter what people recommended. My only stipulations were that it had to be quick, easy and free (what else!).

CaptionTube

I gave Google’s web based tool CaptionTube a go first. It’s super easy to get started as you just use a Gmail login and from there you upload video from your YouTube collection. So far so simple.

What I didn’t find so intuitive was the captioning interface itself. When dropping text into the timeline I wasn’t able to clearly see when text started and ended as the end time was measured in how long the segment was rather than when it stopped in the overall timeline. This just didn’t work for me.

The CaptionTube interface fails to show captions overlaid the video

In addition to that I had to flick between the Timeline and Preview screens to see the captions I’d just created overlaid on the video. With pages taking a time to download, not to mention breaking the rhythm of what I was doing, this really held me back. Too much buffering for my liking.

Overstream

Being a newbie to all this I wasn’t sure if I was expecting too much or missing the point but after a chat with Antonia Hyde – who knows a thing or two about accessible multimedia – I decided to switch to Overstream which had originally been recommended by AbilityNet.

This was altogether a lot better plus Overstream support a number of video providers: YouTube, Google Video, MySpace Video, Dailymotion, Veoh Blip.tv and Archive.org. It was pretty easy to upload a YouTube video but equally easy to miss a crucial instruction that you need to have the video in question playing in YouTube when you hit the upload button.

Overstream shows the edit box and video with captiones overlaid on the same page.

Overstream shows the edit box and video with captions overlaid on the same page.

The interface gave me much more of an integrated toolbox and by now I had an idea of what I wanted which helped. One huge bonus was being able to add text to the timeline, complete with start and end times, adjust time lengths and see in real time the text overlaid on the video on the same page.

I had a few problems trying to play the video once done in a new window with a URL warning popping up but it was easy enough to download the .srt file (with all the captions and timeline in) and upload that in turn to YouTube.

MAGpie

Next on my list to try is the downloadable tool MAGpie, from the National Centre for Accessible Media. I didn’t try it this time as Overstream got the job done plus MAGpie supposedly doesn’t play nicely with Intel based Mac’s. I did have a quick look at it however and while very clunky and old looking it does give you an the option to style captions which looks pretty good. I’ll be looking at this in more depth when I next caption something.

Stanford Captioning Service

John Folliot pointed me to Stanford Captioning Service which looks like an excellent service. All you need to do is upload a video file which then is put in multiple formats – FLV, MP4, MP3. These are then transcribed by Stanford contractors for a small fee. When the transcription is done Stanford do automatic timestamp generation to turn transcript into various formats – this part is free.

For my short video I was happy to transcribe and caption the audio myself but if I had longer videos to get caption I’d almost certainly use these guys. Victor Tsaran, head of accessibility at Yahoo!, used the Stanford Captioning service to caption a video about himself recently.

dotSUB

Lastly I dug out my login to dotSUB, who’s main selling point is enabling subtitling of videos on the web into, and from, any language. It’s also a collaborative tool so you can crowdsource community input and/or work collaboratively with your team to get the captions done. Of the tools tested this was by far simplest and easiest to use. 

Captioning tips

As soon as I got started I realised that I needed to have a process as to how I approached doing the actual work. Here are a couple of things that worked for me – let me know if you have any more worth adding to the list:

  • Transcribe text before you start captioning – you can do this yourself, pay a professional to do it or use voice recognition. Even though the last two options are less labour intensive you will need to edit and double check text – especially with voice recognition.
  • Break it down – once you have your transcript you’ll have a clear idea of the volume of words and quality. You can then break text into short sentences that fit on screen without obscuring too much of the screen real estate. All I did was use a text file and hit return after short sentences or natural breaks in a sentence. Once I started adding text to the timeline this had to be reworked as I went along but having it already drafted was a big help.
  • Editing text - if you have a text that works verbatim then great, but this is unlikely and there’s nothing wrong with removing repetitions or false starts to sentences. The key is to keep it succinct while maintaining the original meaning and flavour of the language as well as the character of the speaker.
  • Punctuation – I found that less is more. Obviously you want full stop at the end of sentences but Andrew Kirkpatrick, head of accessibility at Adobe, recommends removing commas at the end of lines. We don’t ’see” punctuation when we hear people so visually breaking text down like this makes sense to me.
  • Timing – you can create a bit of drama, suspense and humour by remaining faithful to how people speak and using timing to replace tone. For example, someone getting excited may talk in short sentences so break the transcript down so that it is given in short segments rather than having longer segments.

Check out captioning tips from the WGHB Media Access Group, captioning tips and tools from NCDAE and W3C Multimedia FAQ for more.

How long did the whole process take?

Captioning the 4.27 minute video took be the best part of 10 hours BUT this included researching tools, false starts as well as a bit of reading around the subject. If it’s a long video you definitely want it to be transcribed for you but if a short one like this you could estimate 1 to 2 hours depending on your typing speed and how audible the sound is.

After that, once you have the hang of adding text to a timeline you should be ok. I added text and allocated times as I went along but you can add text then allocate time second if breaking the two tasks work better for you. This probably took me about 1.5 hours.

All in all I’d average out a 4 minute video at 3 hours – but this will no doubt get better as it becomes more familiar.

It’s a bit fiddly to start with but smooth running once you get the hang of it and seeing the end result is completely worthwhile. It’s satisfying to know that the captions will help not just deaf users but also non-native English speakers as well a people looking at video on their mobile phone.

Update 20 November 2009

Google have just announced automated captioning of YouTube video which will include automatic time stamping as well as transcripts. This should be available soon and will have a huge impact for many users as well as influence in promoting captioning overall.

WebAim released their 2009 Screen Reader Survey last week, a follow up from last years Screen Reader survey. Very good reading it makes too but of particular interest are results around screen reader choice on the desktop and increased screen reader access on mobile.

For years it’s felt like screen reader users have mainly used IE on the desktop in combination with the major screen readers Jaws by Freedom Scientific and WindowEyes by GW Micro. It’s not that other platforms don’t support screen readers (we have Orca on Linux, VoiceOver on Mac) it’s just that IE seems to have dominated.

As such what types of content and web technologies users can and can’t access has very much been driven by what the three software vendors Microsoft, Freedom Scientific and GW Micro have supported. This has made access to the open web a bit lopsided cutting down on choice for the end user, competition and by extension innovation. SVG is an example of a web technology that has possibly suffered by not being supported by IE and in turn by Jaws and WindowEyes.

What’s interesting to see in this year’s survey is that Jaws and WindowEyes – while still the most used – have some stiff competition at snapping at their heels from open source, free screen readers (NVDA and  SAToGo ) and VoiceOver which is available with Mac:

  • JAWS 75.2%
  • Window Eyes 23.5%
  • VoiceOver 14.6%
  • System Access or System Access To Go 22.3%
  • NVDA 25.6%

While this year’s stats show little shift for Jaws and WindowEyes usage overall there is a significant leap forward for NVDA (NonVisual Desktop Access) and VoiceOver:

Of the 1121 respondents, 74% use JAWS, 23% use Window-Eyes, 8% use NVDA, and 6% use VoiceOver. While several other screen readers were reported, these were the most prominently reported.

The upsurge in VoiceOver could be explained in part by iPhone now providing VoiceOver support; all of a sudden there is a very real reason to switch to Mac if you can use a screen reader you are familiar with on both your desktop and mobile.

This could also explain the increase of screen reader users on mobile reported this year with 53% of survey respondents with disabilities confirming they use a screen reader on a mobile device. This is up from 12% last year (although last year’s survey doesn’t distinguish disabled from non-disabled users).

I wonder how much this is to do with the ‘iPhone Factor’ but also can’t help thinking that social networking has done for the mobile web what Kylie Minogue did for Agent Provocateur – everybody wants some. And for me at least 2009 feels like the year that we all sat up and paid attention to the potential of mobile for people with disabilities.

We’re still faced with one massive problem with mobile access however and that’s the lack of an open, cross platform accessibility API that mobile screen readers can hook into. On desktop we have IAccessible2, MSAA and UI Automation (amongst others) but on mobile users are tied into one platform often only supporting one browser (such as iPhone, Blackberry RIM and others) so while desktop has opened up we find ourselves in a 1990’s type impasse with users left with little room to choose on mobile. Opera works well with VoiceOver but we have no way of telling if it works on the iPhone as it’s not supported. My hope is that with more users there’ll be more momentum behind breaking this stand off and opening up the market and ultimately giving users not only choice but portability between platforms.

It’s good to also see the free, open source NVDA on the up. They’ve worked hard to include WAI-ARIA support and are becoming a key tool for web developers when testing. The Jaws demo version used to be popular among developers but with the license becoming less developer friendly NVDA is becoming a safer option.

It’s early days but the rise of VoiceOver and NVDA combined with alternative browsers such as Opera, Safari and Firefox may break the hold that screen reader giants Jaws and WindowEyes have over the market, helping to open up competition and with it how fast screen readers innovate in supporting new technologies such as HTML5, SVG and so on. This will be a win all round for both users and developers.

Update 12 November, 2009

Jared’s presentation The Legend of the Typical Screen Reader User summarises many of the points above. He also includes quotes from screen reader users at the end in response to the question “What suggestions do you have for developers/manufacturers of screen readers?” which he mentions in his comments below.

Mobile accessibility resources:

Some good stuff flying around Twitter and the web at large this week:

I presented at Techshare earlier this month focusing on universal access on mobile drawing on comparisons and lessons from desktop and looking ahead at existing and emerging technologies that help developers ensure content is accessible across devices.

I tried to answer the question “Is the mobile web enabled or disabled by design?”, in other words can one web work for mobile users with disabilities? After much talk with people and feedback from my presentation my thoughts on this have evolved to the following:

  • Mobile development is at a cross roads just as desktop development was in the late 90s with a danger of separate versions, building for single platforms/browsers, reliance on proprietary technologies and ignoring web standards biting at our heels
  • We should focus on one content source, multiple delivery mechanisms (CSS Media Queries, personalisation, geolocation etc)
  • We can learn from our mistakes of the late 90s on desktop and skip to progressive enhancement, one web, cross browser compatibility and web standards
  • We are all disabled to some extent on mobile – this may influence better usability and accessibility overall
  • Mobile development may, in time, inform better web development on desktop
  • We need common accessibility APIs on mobile to support text-to-speech / screen reader output (pretty please)
  • Widgets are the way forward (more of that later)

I’ve gone into more depth on this in thoughts on making the mobile web accessible.

What next?

My research has showed me that there really isn’t a lot of information out there on how to make mobile browsing accessible. What’s key however is to remember that while there is a cross over between difficulties all users experience on a mobile and difficulties experiences by disabled users on the desktop  we can’t lump them together – we need to work to understand issues specific to disabled users and how to address them.

There are a number of great people out there already working in this area and starting to talk about findings and research. Ones to watch are:

If you know of any other people, initiatives or pieces of research flying around let me know and I’ll update this list.

There was an interesting mix of design, development and mobile covered at Accessibility 2.0 yesterday but for me I was most interested to hear people’s comments on mobile browsing for disabled users. Below are some quick thoughts of the day. Big thanks to AbilityNet and the other speakers and the Opera Developer Network who sponsored the podcasts and transcriptions which will be online soon.

Slides from my Techshare presentation is the mobile web enabled or disabled by design also provide background to this.

Panel on accessibility beyond the desktop and ‘one web’

  • Lucy Dodd – BBC (Chair)
  • Julian Hartly – Google
  • Damon Rose – BBC Ouch!
  • Veronika Jermolina – AbilityNet
  • Greg Fields – Blackberry
  • Me – Opera

Is one web possible with diverse users?

I enjoyed our panel which challenged the idea of ‘one web’ across devices whilst accommodating diverse users. Damon had some valid inputs saying that in the real world ‘one web’ doesn’t work for many disabled users who prefer .mobi sites not only on mobile but also on desktop due to their ease of use. This is an argument I hear often with m.facebook.com cited as a prime example as it’s less cluttered and more usable and accessible than it’s desktop counterpart.

My take is that because some disabled users prefer the mobile version of Facebook you can’t assume this is an argument against ‘one web’ as it could just as easily highlight the poor usability and accessibility of Facebook or <insert your site of choice here>. Instead we should be looking at better adaptation of content specific to delivery context using techniques such as progressive enhancement with media queries and adapting content with CSS.

I think Damon’s are important concerns and raise the real question which is how can we replicate what people like about mobile versions without resorting to versioning websites?

Step in personalisation. With the web everywhere we want to tailor content to suit context. Makes sense. This does not mean cutting or trimming actual content so that’s it not available but allowing users to choose what content they get on their device of choice. This can be done via the website itself and to an extent Facebook allows this by giving you options of what updates and notifications you receive in your timeline. If you allowed people to choose content order that would also help enormously on mobile.

The browser can also support personalisation by allowing you to set up different profiles when accessing content using the same browser of different devices. Opera Link allows users to sync bookmarks, speed dial, searches and notes touching on a respectable representation of what we can do to facilitate fast effective browsing. Imagine saving your fonts, colour combinations and other accessibility preferences that you could port across from desktop to mobile.

For this to truly work you’d need to be able to save different profiles to suit context. What I want in my Speed Dials on desktop, for example, may not be the same on mobile.

Will mobile innovate desktop browsing?

I’m beginning to see how innovations in mobile browsing to support universal access may just start influencing better desktop browsing and web design. On mobile you have to be more precise and targeted with content than on desktop as there is less accommodation for usability and accessibility error. The mobile context trumps assumptions of desktop such as a user is sitting down in a well lit place with no background noise and time on their hands to ‘browse’.

Maybe the convergence of mobile with desktop web design will have a positive influence on web design overall. Just as print informed web design when websites first appeared and desktop influenced mobile web design perhaps we’ll see mobile now inform desktop. Who knows.

Some very basic introductory slides and a transcript are available on slideshare.

Graded mobile browser support

Since looking into universal access on mobile what’s struck me is what little information there is out there for developers about deciding baseline technologies that are supported and what mobile platforms and browser support can be assumed. Unlike desktop where there is a finite amount of browsers to test for (although it may not seem like it at times) mobile is multiplied tenfold.

Yahoo’s! graded browser support helps developers framework what browsers and versions they should target on desktop. This got me wondering if we need something similar for mobile. Seeing as Chris Heilmann from Yahoo! was sat in the audience I thought I might direct the question at him during the panel (also mentioned over Twitter) and being the thoroughly top bloke he is he listened. I know many larger orgnisations will have this sot of information fed into the test plans but for the large majority of us we have to figure it out as we go along. Not only that it’s such a fast changing target that it’s impossible to keep up with on your own.

PPK seemed interested which gives me hope that I haven’t taken leave of my senses and I’d love to know what you think.

Check out Chris’s keynote Finite Incatatem – Accessibility is not black magic. Aside from being one of the funniest and most informative keynotes ever he flags some pretty cool innovations in the mobile and devices space from Wiihab, Nokia braille reader and iPhone accessibility.

Building universally accessible web apps – Greg Fields, Blackberry

I didn’t managed to take notes of the whole day but did capture some of Greg Fields presentation on making mobile web apps accessible. While not directly related to mobile browsing or the mobile browser I found a lot of what he had to say crossed over neatly with recommendations for making mobile content accessible and how we should look to the mobile browser to support access.

Below are a few bullet points of what he captured with a few comments from me – most of it is good common sense but never a bad thing to repeat.

  1. Native UI library
  2. Colour and contrast
    • Use of colour WCAG 2.0 1.4.1 – Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)
    • Colour contrast 1.4.3 WCAG 2.0 – 1.4.3 The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)
    • Avoid red green combinations
    • Don’t rely on colour alone for meaning
    • Use semantic colours

    I think use of colour coding can be hugely helpful in the same was grouping and layout can help sighted users.

  3. Inherit global settings from the OS
    • Especially important on map applications
    • Don’t conflict with user defined settings
  4. This reminded me of the work Brothercake presented and Standards.Next on HTML5 where he showed HTML5 forms could be stylable if browsers inherited the user’s settings from the OS. Styleable forms for HTML5 is something that we are asked about a lot at Opera and seems to have sparked a lot of opinion. If you have any ideas or suggestions then head over to Bruce Lawson’s blog and let him know what you think.

  5. Error messages
    • Include description of the error and how to resolve it
    • Goal to prevent user making the same mistake again
    • Use active voice
    • Prompt a call to action
    • No surprises here but always worth noting. Even WCAG have brought in provisions to version 2 outlining accessible and usable error messages and making sure they are accessible.

  6. Focus placement
    • Use a visible focus outline
    • Align with the user’s mental model
    • Important for all users across devices. I would add to this to not be tempted to suppress outline within the browser and where a:hover is used also use a:active (to keep IE and mobiles happy) as well as a:focus.

  7. Contextual menus
    • Most used application of frequently used option is in focus
    • Builds trust and decreases time to access content
    • Good user perception “It just works”
    • Again no surprises here as it is a core principle of good web design on desktop but something to consider when allowing users to personalise content perhaps.

  8. Consistency
    • Navigation, presentation, interaction methods must be consitant
    • Make the mobile app familiar to the desktop experience
    • Most sites are pretty good with consistent navigation but can slip when it comes to consistent user interaction I find. Making the experience familiar to the desktop also builds trust in the user and confidence in what they are doing on the mobile.

  9. Progressive disclosure
    • Inform the user of the number of steps in a task
    • Something as basic as this can help users calculate how long a task will take – essential when on expensive mobile payment plans as well as multi-task where needed.

  10. Grouping and chunking
    • Organise info based on type, meaning and so on
    • Limit option to 3-5
    • This should help users pre-process information and enable them to complete tasks without having to think.

  11. Keyboard access
  12. Greg skipped this slide due to time and went onto list resources which I thought was a bit of a shame (you can always reference resources after). Keyboard navigation is key and I do cover this in my Techshare presentation ‘Is the mobile web enabled or disabled by design’ (post following soon).

« Newer Posts - Older Posts »