I spent the weekend discovering just how poorly thought out and poorly supported closed captioning is in online video. Some highlights (based on the SRT format because that was the only one I could find any information about syntax for):

• Definitive guides to the format either don’t exist or are so poorly used that they don’t appear in the first 3-4 pages of a Google search.
• Timestamps use a non-standard format. The inventor was apparently French so instead of the usual hh:mm:ss.ttt the period is replaced with a comma. I sympathise with everything being US-centric, but the number of people who were making this mistake on forums etc and the number of players who support period but not comma (and visa-versa) is scary.
• Only DOS line endings are supported. \r\n is fine as part of the standard, but why can’t players be a little liberal in what they accept? It’s not like \n or \r by itself within the caption is going to work anyway…
• No standard font, so no way to know if the caption will fit or not.
• Absolutely zero feedback from any player I found about why it was ignoring the captions.
• Really, really poor tooling support for creating captions.

So, coming around to the real point of this post, I wound up writing my own tool to help take a script, synchronize it to the spoken voice and output the right format. Worked a treat, and now I have working captions on my video. I suspect it would be useful to others and there’s certainly plenty to do to improve it that would be great if others jumped in and helped with.

The trouble is, to make playing the video easier, I used Cocoa and Objective-C. Great decision, got me up and running in no time – with really, really, really, lousy code. See, I haven’t done anything more than vaguely dabble in Objective-C and I’ve only used XCode back when it was Project Builder and I suspect OS X was in beta. Needless to say, the resulting code is terrible. I didn’t want to learn all the ins and outs of the Cocoa document system and where I’d have to change the names of things so the main document class is still called “MyDocument”. I think I turned on the Objective-C garbage collection, but if not it will leak like a sieve (it might anyway, not sure).

If you look at it one way, it’s pretty impressive to pick up a completely new tool set and get a useful application out in a morning, but more likely you’d look at the code and decide I was incompetent. So the great dilemma, should I push this rubbish code up to GitHub and hope someone comes along to refactor it, or will it just sit there waiting to appear in a Google search when I next wind up applying for a job, thus killing all my hopes and dreams?

The Australian brings news of the growing battle for mobile banking leadership among Australian banks:

Brisbane-based Suncorp launched the first mobile browser-based banking service and last week made it compatible with iPhone and Google Android handsets.

The Commonwealth Bank has similarly updated its mobile service, which will work on any internet-enabled mobile phone, and has additional functionality for the iPhone.

People have been talking about the coming mobile revolution for a long time. In fact, as the article mentions, the Commonwealth Bank had previously tried to jump on the mobile banking wagon as early as 1999 via a WAP interface. So what’s changed and what does this have to do with accessibility?

1. The capabilities and affordability of mobile phones with Internet access has dramatically improved. Firstly with the iPhone and now a top-notch browser is a must have feature in a smart phone.
2. WAP is out, users want the real web. It’s not ok to provide a text only WAP interface that works on phones, users want the full functionality and they want it to look pretty too. Modern phones support HTML, CSS and JavaScript and most of the time you should be writing just one site that works everywhere rather than a separate mobile site.

It’s that second point that really brings accessibility in. If you design your site so that it can be used with a range of disabilities, there’s a much better chance that it will also work on devices with a range of capabilities. In other words, someone using an iPhone to view the site is just a user with a particular type of disability.

• They have a small screen so the site needs to scale properly (use relative units, not absolute). If your site can handle users changing the size of the font, it can probably scale pretty well to fit on an iPhone.
• If the networks slow, they may not be able to see images. If you have good alt tags, they won’t need to.
• They can’t see flash. While you can design accessible flash, most people don’t so surfing without flash is often very similar to what a screen reader would see (at least for the flash side of things).
• They can’t use a keyboard very fast and can’t drag and drop anything.

There’s also plenty of unique things about various disabilities and the iPhone as well as different limitations on different handsets, but there’s also a lot of overlap.

Accessibility isn’t a cost centre – it’s a competitive advantage.

When I wrote my post on accessibility the other day, what I really meant to say is what basically what Rob Foster wrote. Very roughly summarized, accessibility is about real people, not checklists.

The issues of accessibility are a daily reality for my family. For us, it’s not a political issue at all. Our oldest daughter, Ramona, has cerebral palsy and uses a wheelchair to get around.

…

Here’s my point–if your brother or sister had a disability, you would give a crap. But you don’t have to have a sibling in a wheelchair to genuinely care, even if it’s only in your work.

And:

And from my perspective, accessibility is about giving a crap.

Accessibility is NOT a checklist.

Accessibility is about usability.

Accessibility is a paradigm shift.

Accessibility is a personal issue.

Checklists and accessibility reports are just tools to help you make things accessible – they can be really powerful if they’re used with the right intent, but they’re not the answer.

That’s why I’m so glad to see Ephox adding not just more and better accessibility checking and reporting into their products, but also tools to make it easier for authors to get accessibility right. We need to do more though, so much more, but at least it’s a start and we can start taking this message out to all the web content administrators that we talk to and try and get them to care.

Mark Pilgrim and Sam Ruby have been going back and forth and back again about accessibility and in particular the SVG images on Sam’s blog. In Mark’s latest post he explains the somewhat crazy world of access enablement:

Long answer: As far as I know, none of the commercially available screenreaders support svg in any way, much less reading the title of an svg image included inline in an xhtml page (as opposed to, say, linked from the src attribute of an <img> element, or embedded in an <object> element). Nonetheless, you have provided a text alternative for the image, and theoretically, that could be presented to a user in place of (or in addition to) the image. You have therefore fulfilled your moral duty, even though no one actually benefits from it. Welcome to the wacky world of access enablement.

Mark’s right – in many companies and other organizations you have to tick the boxes for accessibility rules and they are quite often just plain stupid. Mark calls that access enablement, I call it beurocracy or perhaps more kindly, the only effective way to get a large organization to meet difficult to understand objectives.

However, in the case of Sam’s blog, there really isn’t any loss of information if you can’t see the image. They act as a kind of category logo, and when you can see them, provide a quick way to scan the page for a particular topic. It would not be quick to scan the page if the images were displayed as a text alternative.

In fact, it could well be argued that adding the text alternative makes the page less accessible, not more. Compare:

Accessible

accessible

Mark Pilgrim: Deep thought: every post on @samruby 's blog since June 2006 contains an image without a text alternative.

With:

Accessible

Mark Pilgrim: Deep thought: every post on @samruby 's blog since June 2006 contains an image without a text alternative.

If you were a blind user accessing the page with a screen reader (the mythical one that supports titles in SVG), your screen reader would say the word “accessible” twice – once as a header and once as the alternate text for the image. You might get “Heading: Accessible, Image: Accessible” read to you but it’s still not useful. The single most useful thing that could be done with that image when encountered by screen readers is to simply ignore it.

One of the biggest challenges about accessibility is convincing people that it’s not just about adding alt tags to images, it’s about allowing people with disabilities to access the page. Following the rules to the letter is neither the absolute right answer nor a silver bullet. What you need to do is actually test with real world tools. That’s why the actual rules, particularly in WCAG 2.0, are so incredibly vague. The techniques are more detailed and more descriptive but the rules themselves are very high level.

The same thing applies in the real world. You have to provide ramps or elevators so that people in wheelchairs can get everywhere they need to go, but you don’t have to provide ramps everywhere. There are plenty of shopping malls and other public places that provide a normal set of stairs in the most convenient place and an elevator off to one side. Sam’s blog is a perfect example of that concept applied to software. I read Sam’s blog without seeing those SVG images all the time because they don’t come through to my feed reader, yet I can still tell what the post is about because it has a descriptive title.

If you’re asking yourself “does my site meet WCAG 2.0?” you’re doing it all wrong. You should be asking “is my site accessible?” Just meeting WCAG won’t necessarily make your site accessible – do it if that’s what is required to get paid, but don’t fool yourself into thinking that it’s the real aim.