Sarah E Bourne

I received a request for some advice from a newly named Accessibility Lead for a government agency.  He said, "I am being asked to provide accessibility guidance on products / software I have never used before; and, in my opinion, this is a rather dangerous venture."  I knew exactly what he meant.  You feel like you are being asked to wave the magic accessibility wand over any old tech that happens to come along, while knowing that there is no magic.

This is what I told him.  If you are in the same position, I hope this helps you, too.

There is no way anybody can be an expert in every aspect of how to implement something accessibly in every technology.  I’m sure not!  So here are some survival tips.

• Never claim to “know it all” or let others burden you with that.

• Admitting that you don’t know everything gives you a lot more credibility.
• It also leaves room to work cooperatively – let the devs, authors, etc. (“creators”) in on the discovery process and they will be more committed and learn more.  This is much preferable to a “dump it over the wall to the accessibility guy” approach, where it makes it look like you are the problem when issues are found.

• The general principals are the same: Perceivable, Operable, Understandable, and Robust.  And the guidelines under them in WCAG2 track nicely to just about any technology area.  The actual implementation and authoring techniques are where things vary.

• Always look to the technology provider (software vendor, for instance) for implementation guidance.  Look for their white papers or developer guides that address accessible implementation/configuration. If it’s not on their website, the creators need to contact the provider to get it (or to let them know that it’s important.)
• Your creators should have found and been using these before they come to you.  If they didn’t, send them back to find it, compare the guidance with what they have done, and make needed changes before they return.

• There may not be tools like we have for web-based technologies (accessibility checkers, code inspection tools) so you may end up having to do testing just with AT: screen readers, magnifiers, and speech recognition.  It takes longer and you’re more likely (as a human) to miss things.
• QA discipline is your friend here.  Identify a matrix of AT, platforms, and browsers (when applicable) that you need to test on to find source errors (versus AT bugs) and write formal test scripts.
• Involve the creators in testing so they can learn how to do at least some of it themselves, and so they understand the actual problem.
• Get Actual Users to do testing, too, as a reality check and to prioritize the severity of any issues found.

YouTube recently introduced automatic captioning for its videos. "O frabjous day! Callooh! Callay!" said people* I work with who are faced with the time-consuming and tricky task of creating transcripts for videos. Having seen some very … odd … output from high-end, state-of-the-art, speech recognition software, I suggested they wait to see for themselves before getting too excited.

I could easily make this a "bloopers" post, but it's almost too easy. Did you see the one where Massachusetts Secretary of Education Paul Reville says, "what the application does" but the automatic captioning is, "for the prostitutes"? That particular video is transcribed so poorly that it's not clear that it would save any time to edit their transcript file over doing it yourself.

But I think a better measurement of accuracy is looking at how a particular word or phrase is transcribed in the same video. Let's take a look at Mark Roth giving a TEDTalk, Suspended animation is within our grasp where he uses the phrase "hydrogen sulfide" fifteen times. It's correctly transcribed five times, including the first time he says it. The rest are pretty far off, and give you no idea what he's talking about. This is a problem - it's a key fact in his presentation.

1. hydrogen sulfide (8:42)
2. I didn't sell five (8:44)
3. hydrogen sulfide (9:04)
4. some hydrant sell fighting (10:17)
5. hundreds cell five (10:48)
6. hydrogen sulfide (11:14)
7. him I didn't sell fight (11:36)
8. I didn't sell five (13:43)
9. hydrogen sulfide (14:04)
10. hydrogen sulfide (14.17)
11. hide himself I (14:46)
12. apply to sell five (14:55)
13. the party itself by (16:18)
14. I didn't sell side (16:28)
15. high turn still fighters (17:07)

The take-away is clear. If you care about accuracy, if you want people to be able to understand what is actually being said, do not rely solely on automatic captioning.

* No, they didn't really say that. That's from Lewis Carroll's poem, The Jaberwocky. I wonder what YouTube would make of that?

This is a great video showcasing some of the things Yahoo is doing to educate their developers about accessibility.

Testing to make sure software the Commonwealth buys or creates can be used by people is a big part of my job these days, and a big part of that is just making people aware that people with disabilities can and do use computers and the Internet.

Yes, blind people can use the web ... unless the website was made in such a way that they can't. And what a shame it is when that happens, because the Internet has made it more possible for people with disabilities to live independent, productive lives.