Accessibility

The World Health Organization estimates that 15% of the world population is disabled. After the initial shock about that statistic sets in (that is a lot more than I expected), you may ask why I’m writing about it.

People with disabilities are on the web every day, trying to use your product, just like their non-disabled peers. However, I’m willing to bet that accessibility is an afterthought as you design and build. That does not make you a bad person. Far from it. It just makes you unaware. Unaware that you are ignoring a significant number of users who may find your site, who may want to signup for your site or even pay you money. Your particular user base may over or under index, but even if a conservative estimate is just 5%, you should address this issue. Imagine if your dev team told you they would no longer support a browser that accounted for 5-10% of your traffic? Seems crazy, I know. That is effectively what you are doing when you ignore accessibility on your site.

We have come under more scrutiny on accessibility since pivoting to an institutional sales model with Boundless. Schools are vigilant (as they should be) about keeping their courses available to everyone on campus. We agree with that goal. Our engineering team provided a great explanation of the process on the Boundless blog. Go there to read the details and the process. It’s worth it – I promise.

Based on that experience, there are a few lessons that I’ve learned through the process.

1. Start small. Don’t buy expensive screen readers out of the gate. You can use the VoiceOver technology that is integrated into Mac and iOS devices. Take a run through your site and see if it makes any sense at all. If you don’t have an Apple device or your site is not mobile friendly, you have bigger problems – address those first.

2. Don’t get caught up in the jargon. It’s confusing and hard to understand without any context. Lots of people have deep expertise in this domain, but don’t feel like you need to rival their knowledge. Originally, we paid to have the Carroll Center for the Blind do an audit. They did a comprehensive review and gave us a detailed report. They did amazing work, but frankly, it was too overwhelming to even figure out where to start. The jargon was too unfamiliar, and the list of issues too many. We were paralyzed by how much work we seemed to have to do. Instead…

3. Do what you should always do – test with real users. Define your most critical user paths and walk through the most important ones with a live user. Have the whole engineering team watch. Make it mandatory. We did not do this purposefully, but the results were great. You could watch the team’s empathy for our user grow, as they saw how frustrated she became. There was even a hint of embarrassment when the user was unable to complete even the most basic task. After the session, they were ready to knock out every major roadblock we saw. They now understood why this was important, instead of it being an abstract concept that required a lot of code to address.

Accessibility is not a certification you achieve, despite it seeming that way. It is more of a mindset you need to instill in your organization. It is a hygiene and best practice you need to always address. If you build the right habits around it, you will be better off for it in the long run. And you will have much happier users because of it!


Other good resources on this topic can be found here

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s