Vincent Gable’s Blog

March 13, 2009

Reasons to WANT to Design For Accessibility

Accessibility is too often seen as a chore. But there are many reasons to be excited about making things usable for everyone.

It Just Feels Good

I know it’s cliché, but helping people does feel good. Making your website work with screen-readers is not the same as volunteering your time to read for the blind and dyslexic. But it still helps…

More cynically, accessibility means your work reaches more people. Even if it’s just an extra 0.6%, it still feels good to know you are having a bigger impact.

We Are All Impaired

As Keith Lang points out, “we are all impaired to some amount (or sometimes)”. Everyone is “deaf” in a library, because they can’t use speakers there. Similarly, if you try showing a video on your phone to a dozen people, many of them will be “blind”, because they can’t see the tiny screen.

Consequently, accessibility means designing for everyone, not just a disabled super-minority.

Accessible Design is Better Design

Usability improves when accessibility is improved. For example, a bus announcing stops with speakers and signs means you can keep listening to your iPod, or looking at your book, and still catch your stop. It makes buses easier to ride.

Maximally accessible design engages multiple senses. Done well that means a more powerful experience.

Early Warning

The flip-side of accessibility improving usability is that bad design is hard to make accessible. How easy it is to make something comply with accessibility guidelines is a test of the soundness of the design.

I don’t care about accessibility. Because when Web design is practiced as a craft, and not a consolation, accessibility comes for free.

Jeffrey Veen

Accessibility compliance should be like running a spellcheck — something quick and easy that catches mistakes. When it’s not, it’s a warning that something is fundamentally wrong. That’s never fun, but the sooner a mistake is caught, the cheaper it is to correct it.

Challenge the Establishment

Accessibility might be the best “excuse” you’ll ever get to do fundamental UX research.

I think for people who are interested in user interface disability research is another area that gets you out of the Mcluhan fishbowl(??) and into a context where you have to go back to first principles and re-examine things. So I think the future there is very bright but we need more people working on it.

–Alan Kay, Doing With Images Makes Symbols

If anybody knows what he meant by what I heard as “Mcluhan fishbowl” please let me know!

Technology is Cool

Accessible design makes content easier for machines and programmers to deal with. This makes the future possible. For example, embedding a transcript in a video means that the video’s contents can be indexed by google, or automatically translated, etc.

BUt the really exciting stuff hasn’t happened yet.

Accessibility research is going to be a huge part of what advances the state of the art in Augmented Reality and cybernetics/transhumanism. The common theme is mapping data from one sense to another, or into a form that computers (eg. screen readers today) can process.

Why do You Like it?

I’d love to know what makes you passionate about accessibility. For me it’s that it feels right, and as a programmer, I am very excited about what it enables.

November 4, 2008

The Perils of Localization

Filed under: Uncategorized | , , , , , ,
― Vincent Gable on November 4, 2008

The sign below is supposed to say ‘No entry for heavy goods vehicles. Residential site only’ in English and Welsh.

localization

Unfortunately the Welsh version says ‘I am not in the office at the moment. Send any work to be translated’.

Story from the BBC

(Via Successful Software.)

August 20, 2008

Hardwired Strings

With every programming language/development environment I know of, you have to do extra work to make a string localizable. For example,
errorMessage = NSLocalizedString(@"This is hard!",@"");
not simply,
errorMessage = @"This is hard!";

And it’s not just extra work, it’s a ridiculous amount of work. E.g. to create an Objective-C string, you just put an @ in front of a standard C string. But to create a localized string, you have to surround your string in ()‘s, and prefix it with a seventeen character mixed-case function-name, and finally add an empty “note” for the translator. (Rarely, you may want to add a note for the translator, and it’s good that you can, but you should not be forced to write something when it is not necessary.)

There isn’t really an excuse for this; it’s just how languages have lazily evolved.

Non-localizable (“hardcoded”) strings are a huge issue, even though they are trivially simple for programmers to fix. The problem is that translators do not work with source code, they work with resource files. So when they find a “hardwired” string that must be changed in code, they tell a programmer to fix it. And that communication is slow and costly. Especially when you consider that good localizers are probably native to the place they are localizing for — meaning that having a real-time conversation involves at least one party staying up past 3AM.

I dream of a day where "this would be localized by default"; "and"("syntactic sugar for adding optional translator notes would be there too"); and creating C"literal C-strings" would be easy.

“Unicode support libraries” are doomed to institutionalized-failure, because they will never make it easier to do the right thing. It must be so easy to create a localizable program that you wouldn’t dream of doing anything else.

Powered by WordPress