Three Brief Points About Accessibility

On Friday, the entire Covenant Eyes User Experience team, two programmers, and I went to the Resource Center for Persons with Disabilities to talk through accessibility issues on our website, a growing concern for our team. Over the last few weeks, four of us in particular have been thrashing our way through the WCAG 2.0 guidelines; but of course, there’s a vast difference between reading up on what technically meets accessibility standards and what it, er, looks like when a blind person interacts with your site.

The meeting lasted for two hours, and pretty much all of it was very revealing. But here were three main takeaways with pretty broad applications.

1. Don’t make a mess.

Blind people use assistive technology known as screen readers. These look at the code and read the important bits, broken up by key words like “header,” “navigation,” and “link,” back to the blind person at a super-fast speed (like 150 WPM). Mostly, this means that if your code isn’t clean, you’re hosing blind people from being able to use your site. However, there were two interesting associated problems.

First came the ability to succeed. The blind guys listened to the code and said we were actually doing really well; headings seemed to be labeled well, and they could jump around with ease. However, it became clear to us that we, as sighted users, had different definitions of success. Namely, they didn’t seem to be going anywhere or finding any relevant information about who we are or what we do. And they, of course, couldn’t know that. It was a bit like a movie, where the protagonist doesn’t see the enemy but the viewer does; only a blind user can’t know that they’re missing the vital information. There’s simply no indication that there’s something more.

The other problem came with language use. At one point one of them ran into a request to run Flash in order to “view” our video. At least four or five times, they had to sit through the screen reader reading the permissions request: “This site requires Adobe Flash to be enabled. Would you like to proceed?” or something equally wordy. For sighted users, there are enough visual cues to tell quickly what it is and either take action or ignore it. For our blind users, though, they have to sit through a tediously wordy message at least once just to understand the action. That’s, say, 3 seconds. A sighted user will have not only gotten through the message, they will likely have already taken action by that point.

So: Brevity through code and language is crucial. Otherwise, it’s like you’re taking a blind man into a room strewn with paper and books. Will they be able to navigate without tripping? Probably. But it won’t be pleasant.

2. Be humane.

So, Captcha. You know, those stupid crossed out and fuzzed up letters and numbers that you have to type in to prove you’re not a spammer. Turns out they’re just as bad or possibly worse for blind people. When we first launched our site, I specifically excluded Captcha from all our forms. Recently we started getting spam from one of them, so our web developer threw a Captcha up at the last second as a temporary measure.

This is what we see. It’s actually not that bad.

This is what a blind person hears.

So, yeah. That’s less “Anti-spam device” and more “Spawn of Satan.”

One of the blind gentlemen told us of a time when he attempted to register on a site and encountered an unusable Captcha. He went to leave a comment and encountered an equally evil Captcha. Unable to use the site and unable to even complain about it, he never went back.

“But at least we have the e-mail address…” I started.

“Nope. You’re not giving me access here. I’d get mad and just leave.”

I don’t think we realize how many of our systems are set up like this. Sure, blind people are a minority, but they’re not an insignificant one. So are we testing for spambots, or are we testing for humanity? It’s a surprisingly important distinction.

3. Differentiate yourself.

At the beginning of the meeting, they had us go around and introduce ourselves, not just by name, but with some distinguishing feature (like how we wound up in our field) so they’d have a way of telling us apart.

So often designers rely on images or color or cool fonts or whatever as a way of standing out. But when you’re blind, all you have are words. Surely, though, there’s a better way.

I’m reminded of an old illustration. Sloped curbs were originally designed for those in wheelchairs to have easy access from parking lot to sidewalk, but other users quickly started taking advantage of the feature – people like mothers with baby strollers, or shoppers with grocery-laden carts.

Don’t get me wrong; design is important. But what if we focused on differentiating through other means? Cleaner code, clearer text. Humane interactions. And a beautiful simplicity. Surely more than the blind would benefit.