Archive for the ‘accessibility’ Category

h1

YouTube’s Added Value

13 May 2009

I’ve been using YouTube quite a bit lately to host shareable videos. It’s so easy, a child can use it (and clearly they do, for better or worse). But it’s also maturing into what could become an enterprise-level tool that is a lot more meaningful than videos of kittens falling asleep.

It’s important to me to ensure that as much video as possible is captioned. We’ve captioned many of our YouTube videos already, and we’re hard at work captioning more. The goal is that all of the videos we publish will be closed captioned. Why is this important? Well, certainly for accessibility. Someone who can’t hear the audio track of a video needs to know what’s being said. But also, people in offices who don’t turn up their volume, people in noisy places who can’t quite make out what’s being said through their speakers — they too can use closed captions to ‘hear’ what’s going on.

That’s enough reason for me. But it wasn’t enough for Google. They’ve added the killer-app feature that makes it critical for all thinking people to add captions to their videos — SUBTITLES. That’s right, if you caption your video, the user viewing it has the option to translate those captions into any of approximately 40 different languages. (The thumbnails below will link you to screen shots of just how it works on the user end.)

First there was YouTube EDU, and now captioned *and* subtitled videos — a suite of remarkable tools rising from a pool of skateboarding dogs and angsty teens.

Advertisements
h1

Must try this out…

25 April 2008

Overstream allows you to add captions/subtitles to your YouTube or other videos. Awesome. (UPDATE: Now YouTube allows you to add captions directly to YouTube videos — see the May 2009 blog post here on the topic.)

h1

Accessibility article

25 April 2008

Opera developer James Edwards makes a point about AJAX and accessibility. I definitely see, and mostly agree with, his point. But one must consider the subtleties. If a particular user interaction makes a function significantly more simple for most users to understand or interact with, but it’s not accessible, the developer has to do a lot of soul searching. Is the solution as good? His Flickr remake example works, but it’s nowhere near as appealing as Flickr’s current interface. You have to edit all the fields at once. You have to take extra steps, as a sighted user, to work with the page. But most importantly, it looks nothing like your final product when you’re interacting with it. That’s the appeal of Flickr’s current interface…there’s no difference in the admin interface and the end-user interface. It just works.

So while the point is very well taken, there has to be some happy medium, for the sake of usability. We can’t throw away, or significantly dumb down, some ideal usability for mainstream users simply to make something ideally accessible. We should make it BOTH accessible AND usable at the same time. It can be done, but it’s hard.

h1

Who are your users?

19 October 2007

No half-decent web developer would tell you that accessibility is not important. But few developers have been fortunate enough to work hands-on with users who have disabilities, and/or the software that they use. I’ve been very fortunate to have experience with lots of assistive technology — in fact, just yesterday, I had a routine eye checkup, and I was explaining to my eye doctor what a refreshable Braille display was, and how it worked. He was floored!

Well, here’s an opportunity to see a few different users of assistive technology, and see the processes the use to bend computers to their wills. I found the videos uplifting and enlightening — honestly, I had no idea just how good AssistiveWare’s Mac software really was — even controlling Windows through Parallels! It’s good stuff.

h1

It’s all about the user, dear.

25 September 2007

I find it interesting how web publishing so clearly mirrors print publishing. Perhaps not the advertising model — that’s still in flux in both camps — but the user model. Newspaper editors are concerned with two types of stories: the ones that the readers want to read, and the ones that the readers need to read.

Then I think about my local newspaper. There’s the police log, the fire log, the public notices, the school lunch menus — all the stuff I want, available when I want to find it. I already know it’s there. It’s referenced in the page index of the paper, so I know right where to flip. It’s always in the same font, the same size, easily recognizable. It’s easy for the user, who anticipates its existence, to locate it when she wants to.

But then there’s the stuff we need to know, but don’t know to look for. That’s the stuff on the front page, the news well, the feature well — the stuff we don’t even know to ask about, because we don’t know what we don’t know. The editors have a handle on the content. They know what they’ve got, and we readers entrust them to judge the important items, and stick them where we can’t help but see them. We need to know, even if we didn’t ask (because we didn’t know to ask, so didn’t come awanting).

As web publishers, we show our users what we think they need to read — someone has to do the information architecture, make decisions about what goes where, and frame the user’s first impression. We also need to provide users with what they want to read; we are rightly inclined to include search functionality, site maps, and other navigational aids to expose content at the user’s behest.

What drives the need? For a local paper, perhaps good citizenship. For a trade pub, something important to our careers or our businesses. For a web project…whatever you, as the content wrangler, decide to be the most important. (If you make a glaringly wrong decision — well, either you didn’t have enough information, or you’re in the wrong line of work.)

Experience in conventional publishing is a boon for anyone who’s a web developer, because although the media is somewhat different, the users are the same, and they’re looking for the same stuff. As a consumer, I don’t care if I’m reading the school committee meeting minutes on a screen or on a page. I’m the same person, looking for the same information.

As web developers, it’s our job to make sure our users can get what they need as easily and intuitively as possible. User interfaces should be developed by people who know how to develop user interfaces (e.g. editors and art directors), not database developers who have no such experience. But too often, the UI follows the backend. (Here’s a fun real-world example. Well, fun, as in, horrifying.) A clock asymptotically approaches useless if you can’t figure out how to set it — I can more easily look at my watch than dig the manual out of the glove box and profess some mysterious incantation over the trip odometer — something that I’ll not remember six months later when I need to reset the clock. Make it easy, or I’m not going to be able to get what I want or what I need.

People forget. We’re busy. And I feel rather disrespected when something that could have been made so obvious is not. As a web developer, I’m in the service of my users. It’s my job to give them what they need, to give them what they want, and facilitate their getting it. I feel pretty maternal towards my users. I wish more content owners did.

h1

“When Available”: Closed Captioning in iTunes

6 September 2007

“With iTunes 7.4…[y]ou can now also play purchased videos with closed captioning (when available)…”

So! This is cool. Sort of. Of course, none of the videos in the iTunes store up until now has been captioned, so nothing you’ve bought in the past would apply. I’d love to see a press release about the plans for captioned video, though.

Also, it only applies to ‘purchased videos’…so, hmmm. Gonna have to find out some more information about this. I already rip my DVDs with captions open (in Handbrake), so that’s not a problem. But come on. If the HDTV over-the-air signal can handle the scant extra bandwidth captions require, surely broadband can.

h1

Flash Accessibility

7 August 2007

Issues, bugs, workarounds… Of course, the worst bug is that it doesn’t work on the Mac at all…