Why so many fail despite good intentions

“You are so good at criticising without being accusatory” A quote by a costumer after a meeting where I audited the accessibility of their e-service. Good praise, I was thinking. But was it, really?

The e-service I audited is used by around one million individuals every year and it turned out to be impossible to use for many users with disabilities. This, unfortunately, is not uncommon.

I have been working with auditing accessibility of different websites, apps, machines and other technology for the last three years of my professional life. We are talking hundreds of audits. I do tests using different assistive technology, tests using international accessibility guidelines (WCAG 2.0) and tests with actual users. No matter the method, the results are bad almost every time.

It is often fundamental deficiencies excluding a significant number of users with disabilities. An example is bad colour contrasts which means it is not possible for everybody to see the content. Or, keyboard navigation is not working, something that is of great importance for many people with motor impairments.

So I have become very good at criticising without being accusatory towards the web site owner. I do it a lot. And practise makes perfect.

But no one builds websites that exclude visitors on purpose. Accessible solutions are often a requirement. But the end result still turns out far from accessible.

So why do so many fail despite such good intentions?

I’ve been thinking a lot about this during my years at Funka. This is my top three list of what I believe are the reasons so many fail their accessibility work.

1. Difficult demands

The most common requirements are the Web Content Accessibility Guidelines (WCAG) level AA (level 2 out of 3). Now click the link and scroll the page. Come on, just do it!

Web Content Accessibility Guidelines (WCAG) (opens in new window)

As you can probably see, WCAG is long and complicated. It might not be surprising. It is a standard that covers all web content. In addition to HTML and CSS it also covers Flash, Silverlight, PDF and more. It is hard to cover everything and to still be straight forward and concrete. And this is a very very very long document. I copied the text, pasted it into a Word document and zoomed out. You can see the result below. 98 pages. Of course not many people have the time to read 98 pages of accessibility demands.

Everyone developing technical solutions should create their own demands that are easier to understand. You can do it yourselves. Or you can buy Funka’s: Funka's accessibility requirements.

Funka's consultancy

2. The lack of follow-up

It is horrifying how many requirements on accessibility are never checked in the delivery phase. I’ve lost track of how many surprised customers I have met who, when presented with the results of an accessibility audit, say something like: “This is very unexpected, we did have accessibility as part of the requirements.”

Why do so few people check that the accessibility requirements are actually met in the solution they get? That would have been unacceptable with so many other requirements. But with accessibility, it happens almost every time. Maybe this is related to the first item of this list, that the requirements are too long and complex for the customer to even understand and follow up on?

3. Too few user tests or none at all

It doesn’t matter how good you are at following accessibility guidelines if you never test your solution with actual users. In user testing you will discover comprehensibility issues not covered in requirements and checklists. Issues affect all users, but are guaranteed to hit even harder on many persons with disabilities.

The testing doesn’t have to be expensive and time consuming. One afternoon, 3-5 users, every second month. That is more than enough for most.

Many people are sceptical of the benefits of user testing before seeing it in action. Resulting in it being removed from priority. But anyone who has ever watched a user test immediately gets what I’m talking about. So give it a chance. And invite decision makers and colleagues to watch. The more people realizing the benefits, the better.

Accessibility is no rocket science

My recipe for a more inclusive digital world are the following

  • Clearer requirements
  • Follow up on requirements
  • Conduct user testing

If more people follow this recipe, I might not need to do so much criticising in the future. It does have only three ingredients. Very easy to cook.

Hampus Sethfors