Accessibility is not an optional feature

Recently, I had one of those moments where someone asks you a question that exposes a lack of knowledge you didn’t know you had. The question concerned accessibility and best practice in this area. It’s possible that I once knew the answer, but if I did it’s since been pushed out of my head by something shiny and new. It’s more likely that I’ve just been guilty in the past of not giving it the proper consideration it deserves. Either way, I needed answers, so cue a whole heap of Googling.

Obviously after such a short period of time I don’t consider myself an authority on this subject. I do however, feel that by sharing my experience in learning the basics and putting them into practice, it might just encourage someone else to do the same. The barriers to entry are low, and the rewards are well worth it, as I’ll explain.

What did I learn?

The first thing I began to comprehend is that accessibility is not the niche area I thought it was, where only a small minority of individuals are catered for. Perhaps I was guilty of not giving proper consideration to the scope of subject with regards to who it affects, which I think is a common misconception that can lead to under-investment in this area.

If we take a broader look at the population, you’ll soon realise that we’re not just talking about people with the most extreme of disabilities when discussing web accessibility. Yes, these individuals are part of this demographic, but we also need to consider the visually impaired, elderly, physically restricted, or any number of others affected by conditions that might make interacting with a website difficult.

My second realisation was that an accessible site does not equate to compromise in the application in any way – be it in design or function. In fact, I think the opposite is true; adhering to accessibility principles actually encourages good coding and design practices. Simple customs, like the use of semantic HTML result in a cleaner, easier to read codebase, and can make a huge difference to people using assistive technology such as screen readers.

As I dug deeper into the subject, I started to turn my focus to the Red Badger website, running a whole host of open source tools against our site to see what they came back with. The results, on the whole, were encouraging, due in large part to an advocacy of the concept within the company and a history of promoting accessible design. We’re the first to admit that we can improve though – we have a small backlog of bugs that we’re churning through, and yes there are some accessibility issues that we have prioritised. This is not an area that you can become complacent in, as we need to maintain compatibility with the tools designed to assist people when using our site.

A common practice that continued to pop up in my research was the use of Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA). By the way, if you’re going to read up on some of this, be prepared for an acronym onslaught.

WAI-ARIA is basically a way of inserting tags in your HTML which are functionally ignored, but picked up by a screen reader. It sounded encouraging, and I would urge you to read up on this initiative for a way to enhance your coding practice for all users. This is actually where I stumbled across one of my biggest frustrations though – the inconsistencies in how these are supported. Take the tag “aria-selected” as an example. This is supposed to act as a way of informing a screen reader that an item is in a selected state. The problem is, only some types of screen reader support this, and so by implementing it, there’s no guarantee that it will work for everyone. It’s frustrating that those trying their best to adhere to these standards run into problems like this, and this need to be resolved.

We can only strive to do our best with the tools available to us, and until the disparity that exists across assistive technologies is reduced there will be an element of trial and error involved in achieving an accessible site. This is no different to challenges we have faced in the past though. The prospect of making websites mobile friendly across a range of devices and operating systems is an example that come to mind. What was once a daunting prospect is now a day to day aspect of web development, and I believe that is a learning we would do well to remember when trying to adopt accessibility practices.

I could go on about my findings, but I encourage you to do some research for yourselves, partly because there’s not enough room in this article, but also because it’s enjoyable to learn new skills than can enact positive change for so many.

How do I get started?

Earlier on, I mentioned the use of open source tools, so I thought it would be a good idea for me to share a few that I’ve found most useful. This is by no means an exhaustive list, but a good starting point.

• Web Developer – Chrome or Firefox extension that enables you to disable images and styling easily to provide a visual representation of how a screen reader interprets your site. Web Developer also allows you to run a WAVE web accessibility report on your site which includes an assessment of page tags, colour contrasting amongst other features
• NoCoffee Vision Simulator – Chrome extension that allows you to view your site from the perspective of someone inflicted with any number of visual conditions, from 8 different types of colour blindness, to other visual impairments. See the screenshot below.
• http://www.accessible-email.org/ – To verify the accessibility of email campaigns before they go out
• Tenon – Produce a quick and easy to read accessibility report on a web page against industry standards
• And plenty more on the Chrome Store if you want to go further

I recommend that you try out at least one of these on a site you’ve worked on. Not only will you see it from a new perspective, but I believe you will be surprised at how easy it can be to improve the site for so many people one step at a time.

Aside from the technological considerations already covered, I think as an industry, we have focused our efforts on a non-existent cardboard cut-out user for too long.

“As a <nondescript user>, I want…”

To anyone who has worked in an Agile environment, this format will look very familiar. For those who haven’t, It’s a representation of an umbrella statement that introduces most, if not all, user stories. This format serves a purpose, but does little to expose who our end user’s really are. In jumping straight into solution definition off the back of this limited information, we may not be fully understanding who we are targeting. Next time you come across one of these stories, I urge you to try recasting the narrative to cater for different perspectives. By doing this you will find that accessibility is brought to the forefront at an early stage, and from this, an inclusive design and solution can organically grow.

There are a multitude of ways to self-improve in this area, but a mindset shift is always a good place to start. Accessibility should never be an afterthought, or a secondary concern. Small improvements can make huge differences to so many, and all with the added bonus of extending your potential customer reach. A financially prudent and ethical practice? It really is win-win.