Accessibility should matter to you

Accessibility

What do you think when you read that word? Maybe nothing at all. Maybe you’re aware of it, but since you don’t have a disability, it doesn’t really matter that much. For about 57 million Americans it means a great deal. People who have some kind of disability are more common than you think. Did you know 1 in 12 men have some form of color blindness? For women it’s 1 in 200.

Here are a few more stats:

3.3% of the American population have blindness/vision loss
8.2% of Americans have some form of impaired mobility
3.1% of American adults report some form of hearing loss
8.1% of Americans experience cognitive impairment

In the software development community, Accessibility should matter a great deal. For far too long the digital experiences we have designed and developed have created barriers for a large group of people. But that’s starting to change. Awareness around Accessibility is gaining momentum, and companies are recognizing it’s important to create software that serves all users.

Regardless of your role – CIO/CTO, developer, designer, tester, program manager – you should be learning about Accessibility and influencing your teams and organizations to adopt Accessibility standards across your areas of ownership. Here are three reasons why Accessibility should matter to you.

It’s good business

Guess what? People with disabilities buy stuff. And people with disabilities are a consumer demographic whose business you should be competing to win. About 16 percent of the US population has some kind of disability, and they make purchasing decisions just like everyone else. Ensuring your site and digital content provides a great user experience for everyone is good business. If you’re not making your site accessible, you’re giving away business to your competition.

You might be saying, “Well… the services or products I sell can’t be used by people with disabilities, so I don’t need to be too concerned about it.” This is a narrow position to take. First, there is a lot of assistive technology (AT) on the market that may allow your product to be used by someone with a disability. And even more compelling, people with disabilities have spouses, kids, extended family, co-workers, and friends who do not have disabilities for whom they want to make purchases. By ignoring accessibility you’re choosing to miss out on a significant number of customers.

In some instances, there may even be legal requirements around accessibility compliance for your site. There are legal risk factors of which you should definitely be aware when choosing not to prioritize accessibility. You can learn more about some of the legal requirements and policies around accessibility and the web at https://www.w3.org/WAI/bcase/pol.

Making the decision to put off accessibility reduces your opportunity for revenue, excludes potential customers, and can decrease overall satisfaction towards your company.

It’s good design practice

What does accessibility have to do with design? Actually, quite a lot. Designing for accessibility is as much a part of user experience as visual or interactive design. It’s a common misconception that for a site to be accessible all design elements (i.e. brand, color, font treatments, imagery, etc) should be thrown out for the sake of accessibility. Rather, a truly accessible site maintains those design elements while also creating a great experience for anybody who visits your site.

In the book, Web Accessibility: Web Standards and Regulatory Compliance, the first chapter titled “Understanding Web Accessibility” Shawn Lawton Henry writes, “While access to people with disabilities is the primary focus of web accessibility, it also benefits people without disabilities. [Accessibility standards]… increases general usability and lets people without disabilities use websites according to their preferences.”

I have some indirect experience with this. I have two teenage boys, and they both play Fortnite. Fortnite has a great accessibility feature for users who are deaf or hard of hearing where an on-screen display visually depicts nearby gun fire/explosions and footsteps. Neither of my boys have an audio/visual disability, yet they really like this feature and use it all the time. Though not a web site scenario, I think this perfectly demonstrates the message Shawn is conveying when it comes to accessibility and design: creating content and features that can be used based on user preference.

It’s the right thing to do

I was in a meeting with a group of accessibility testers, and we were talking about test automation and how we could apply that to accessibility test cases. Through the course of that discussion, one of the test leads mentioned a fundamental difference between typical software testing and accessibility testing: empathy. Humans can have empathy; machines don’t (at least not yet).

For example, I can automate a test case to determine if a certain action produces a result and then automatically capture the results of that test case. There’s really no empathy involved. Either it passes or fails based on the test case requirements.

But, it can be different for testing accessibility scenarios. I can have automated test cases to determine if an image contains alt-text or other attributes, if a text color has the required contrast with a background color, or to identify the order of elements on a page. But each one of these scenarios requires empathy. Sure, alt-text may be applied to an image, but is that alt-text going to help the user or cause distraction or confusion? Elements on a page may be ordered so as not to bounce a screen reader back and forth all over the page, but does the actual order make efficient use of the user’s time, or is the order on the page causing frustration? This is the empathy that has to be a part of accessibility.

I remember when the needle on my empathy meter moved in a big way. I was in workshop session about accessibility, and a man who is legally blind was brought in to demo how he uses AT on web sites. The scenario for his demo included navigating to a site to look for and purchase a laptop. What would have taken me, a full-sighted person, just a few minutes to perform this activity took this gentleman upwards of half an hour. It wasn’t because he didn’t know what he was doing, and it wasn’t because the AT he was using was faulty. It was because the site wasn’t following some basic accessibility standards. After dealing with the screen reader speaking out elements on a page that were not ordered correctly, and then navigating through lists that weren’t set up correctly to work with a screen reader, he finally landed on the page with the laptop he wanted to purchase. And when he clicked to buy it he received a message saying that product was out of stock. If only the “out of stock” image several pages back had been tagged so that the screen reader could read it, this man could have saved a lot of time and headache.

This was my accessibility epiphany. Why should the task of buying something online be as labor intensive as what I just saw for this man? That was the moment when it really hit me – that accessibility is not a nice-to-have or a break-fix issue. Instead, we should be training dev and design resources to plan for accessibility at the very beginning of every project. Accessibility should never be an afterthought.

I hope you’re thinking about Accessibility. It should be our goal to delight our customers, but if we’re ignoring Accessibility we’re not delighting ALL of them.

If you’re new to Accessibility check out the Web Content Accessibility Guidelines at https://www.w3.org/WAI/standards-guidelines/wcag.

Microsoft is doing some cool things around Accessibility, and you can learn more about how they think about it at https://blogs.msdn.microsoft.com/accessibility.