Website Accessibility: Clicking ‘Click Here’

May 4th, 2016

A little while ago I attended a Dragon NaturallySpeaking and NVDA assistive software demo session; I have to admit this really was an eye-opening experience that completely changed my perspective on the concept of website accessibility. This area of web design and development appears to be full of mystery from both client and web professional’s perspective, and it seems to me that somehow in one way or another we managed to morph our understanding of web accessibility into a myth-riddled nightmare process for all parties involved.

In a nutshell, the term ‘website accessibility’ refers to removing barriers for using websites for people with disabilities. And that’s where the very first myth about accessibility comes into play: very often people think of accessibility compliance as ‘making websites work for screen readers’. In reality, there are lots of different types of disabilities, and screen readers are not the solution to all of them: they will assist with low vision, but will be of little use when it comes to hearing, cognitive or motor disabilities. Importantly though, it’s not just people with disabilities who benefit from accessible websites. For instance, imagine a person with a broken wrist who has no other option but use keyboard for navigating a site; their broken wrist is likely to heal over time, but they will probably keep a grudge against a site that was difficult for them to use.

A lot of people tend to approach accessibility as an ‘added bonus’ to web design and development projects, arguing that the majority of their site users don’t have disabilities and as such they won’t need to consider it. As much as that assumption may be correct in a few instances, the reality is that 16% of working age adults in the UK has a disability. That’s a huge chunk of the population you could unknowingly be preventing from using your site.

In fact, this attitude to accessibility as an added optional extra is one of the reasons I deeply despise one-size-fits-all ‘website builders’. For instance Wix seem to simply state that their sites aren’t accessible at all, and if enough people ‘vote’ for that ‘feature’ they may or may not consider it in the future.

I have also come across a notion that accessibility guidelines only apply to public sector—but that to me seems to be backwards thinking. If user experience is at the heart of any web project, then why do we often forget that what may slow down an average user by a couple of seconds could become a real barrier for a user of assistive technologies?

Another myth is that accessible websites are not pleasant-looking. Truth be told, if you’re hoping to achieve a AAA certification you will likely need to make a difficult design decision somewhere along the way. But even with that, if your web design and development process is structured well, and user experience is a basis for that development, then those difficult design decisions will simply become challenges you’ll enjoy solving, that will allow you come up and road-test brilliant innovative ideas. Throw a little collaboration into your project mix, and you’re onto an all-round winner!

One of my pet hates is the fact a lot of people treat accessibility as an after-thought: they first build a site which then fails testing, and only then site components that failed the compliance test get re-programmed or re-designed. In reality it’s much more efficient to start off with an approach inclusive of diverse audiences, and build on that.

It seems to me, the key is not to think of accessibility as something that is purely up to a developer to achieve at the end of a project. The process really does need to be supported and embraced by your whole team at every step. From copywriting that will make sense to your audiences and will keep assistive technologies in mind (unfortunately the era of ‘click here’ calls to action is still not over!), through to effective and beautiful design that doesn’t lead the user to a dead end in their site journey. Only then can design be translated into accessible code. After all, it’s not just about passing the accreditation test. If your approach really is about ticking boxes you will probably end up with a ‘concrete lifejacket’ scenario , where your product might be certified but completely and utterly pointless and unusable, in which case it simply becomes a waste of everyone’s time.

I might be far too overly-optimistic here, but let’s try to put all those accessibility myths to rest once and for all, and make web a nice place to be!

This blog is brought to you by the collective genius of the Front Page team.