It’s becoming increasingly clear that online retailers are losing out on billions of dollars in revenue because their websites don’t meet the needs of disabled shoppers. Unsurprisingly, more than two-thirds of disabled online customers click away from sites they find difficult to use, despite the total spending power of this market in the UK hitting £17.1bn [$23.3 billion USD].

This isn’t something that will just automatically improve as technology advances. In fact, the problem has become worse in recent years, as businesses shift to digital it exacerbates the difficulties that many people have.

In Canada, there are steps being taken to address this, but while the Web Content Accessibility Guidelines (WCAG) provide a strong baseline standard, private organizations elsewhere in the world are lagging far behind. Even with 61 million registered disabled residents in the US and 14 million in the UK, there is no legal requirement in either country for private companies to conform.

This isn’t unique to a few countries. All developed and emergent nations now face this issue. Large numbers of people who want the choice to buy products online and at their convenience are slipping through the cracks due to poor digital accessibility.

One way to solve the problem of inaccessible websites and services would be to hire more designers, developers and content authors with disabilities. However, many business tools, developer platforms, and content management systems are an accessibility nightmare. How can we expect people to work with software that excludes them by design?

We’re doing our bit to change the authoring process, so that everyone has online freedom.

It’s not just severe disabilities

Although poor accessibility affects permanently disabled people the most, there are many developers and authors that endure temporary or situational disabilities. Anybody can be involved in a car crash, an accident or have a stroke. While it’s not a pleasant thought, it’s one that must be understood nevertheless.

If a developer you work with suddenly lost the use of a hand, even temporarily, should they be forced to change careers? Because, in practical terms, that’s what they might have to do now in many workplaces.

Contensis is a platform for all users. While we work tirelessly to improve the experience for disabled – whether severe or permanent – users, the end results of that work ultimately benefits an even broader audience.

One of the core principles of Microsoft Inclusive Design states, “Designing for people with permanent disabilities actually results in designs that benefit people universally. Constraints are a beautiful thing”.

This principle rings true with us and has been highlighted in our work with the Digital Accessibility Centre (DAC) here in the UK. Even when you might think your software will be reasonably usable for someone with a particular impairment, you’re quickly given a stark eye-opener.

We’ve been sitting down with authors, users of the system with varying abilities, and developers, some also with varying degrees of disabilities, along with a DAC representative. We then ask the user to complete a series of tasks, or user journeys, and observe how they get on. The points at which they aren’t able to use the software in the way they need to often come shockingly early, and with alarming regularity.

Bear in mind that these are knowledgeable people — they understand what they’re doing. In reality, it’s the way the technology that has been implemented that hampers the user. Whether they’re using a screen reader, dictation software, a keyboard to navigate, or they need to magnify their screen, it’s often the same tale.

And that’s not to say software developers mean to build inaccessible software, or that they are somehow lazy. A developer’s job usually involves building small, well-specified pieces of functionality in the most logical and efficient way. If that specification doesn’t include meeting accessibility standards as a default, the responsibility relies with the developer.

Retrospective cost implications

Accessibility tends to be taken more seriously in the public sector rather than the private sector. Those institutions receive government funding and are more regulated as a result. Whereas, in the private sector, there is a financial implication to the extra work involved in making websites or software accessible. However, that mentality can prove narrow minded when you consider the huge number of people who can’t access your product or service, and who may be a valuable asset to the business.

Wondering how accessible your website or software is? A good place to start is to simply unplug or disable your computer’s mouse or trackpad, and navigate around using the tab key. It’s normally obvious very quickly that you aren’t able to do much at all.

The issue of how much it might cost to retrospectively make a piece of software, an app or a website more accessible really is one of those ‘how long is a piece of string?’ questions, although there are certain factors that influence the work involved.

The complexity of the product, for example, will often be one of the most significant factors. A large number of unique pages and different features may mean that fixes have to be multiplied many times over.

Similarly, the number of interactive elements, such as extra forms and confirmations, as well as the use of images and videos, all complicate the process further.

As a software vendor, it’s tempting to layer in new behavior or improve the product without necessarily thinking about the broader impact of your product offering. But doing so usually comes at the expense of addressing accessibility concerns – potentially making your product more difficult to use or, in some cases, rendering it unusable for an entire audience.

Instead, sometimes we need to reduce our features, simplify the experience and ensure that not only is a feature easy-to-use but it’s also accessible.

Consider everything from the start

Not only is it much less time consuming and expensive to consider the accessibility of a design right from the earliest stage, it’s essential for the system to be as accessible as possible.

So what should a product feature to make it as usable as possible for disabled users?

A good rule is following the POUR principles outlined by the W3C; Perceivable, Operable, Understandable and Robust. In doing this, a user should be able to access everything and do what they need to do, using the technology or input device of their choosing. This includes providing:

Perceivable

• captions for users who are hard of hearing
• sufficient color contrast for users with visual impairments
• video transcripts for users who are hard of hearing

Operable

• compatibility with screen readers
• speech controls
• the ability to navigate  with the keyboard
• focus indicators for keyboard users
• form field labels

Understandable

• hierarchical heading structures
• accessible error messages
• alt-text on images to help people using screen readers

Robust

• compatibility with current and future user tools

Every input method should work. If not, you need to fix any underlying issues.

Thorough testing is key to building an accessible product. It's best to test in three distinct rounds.

The first involves running automated tests. While automated testing won't catch all accessibility issues, it's quick, cheap, and easy. There are a plethora of accessibility testing tools available – some even run in your browser – and almost anyone can use them to run tests and hand a report to a developer.

While automatic testing will only examine so much, it will catch a lot of issues. That's good, because now you're going to have to roll your sleeves up and test manually – using your product in the same way as someone with a disability. This will involve things like using a screen reader, navigating using just the keyboard, and checking everything works properly for users of Windows High Contrast Mode. If you've already caught the most basic issues with your automated tests and fixed them, your manual testing will be a lot quicker.

The third phase, and the most important in developing a truly accessible product, is to have disabled users test it — the same users you’re trying to accommodate. You need to make it fit their methods, rather than the other way around.

Like our testing with the DAC, it will be amazing how they can show you that you have made incorrect assumptions about something, and how often barriers can crop up.

Then, when the fix has been implemented, you need to repeat the process again — fully. It’s easy to make a tweak and not realize that you’ve caused an issue for someone reliant upon accessible technology, so you need to check with people who will be affected.

Remember that finding and making the changes when you’re at the design and development stage is ideal, and avoids costly retrospective changes. Accessibility testing is just usability testing, but with a subset for disabled users.

The future

It’s important to be mindful that a CMS or other software products will never realistically be 100% accessible. Although Contensis improves the interface for all its users, it’s something we’ll constantly be working on. It’ll never be ‘done’, although that’s true of software in general.

It’s likely that, at some point in the near future, more laws will be introduced to ensure private sector companies are compliant for accessibility. And, the buck stops with the businesses’ decision makers, who should be actively working closely with their developers to ensure compliance across the board.

For now, though, the process of accessibility testing and improvement must continue. We’re constantly working towards a CMS platform that is inclusive for all users, pushing forward in the education and training of our staff and customers so we’re better informed to step out of our own perspective.

We’re encouraging our team to think about designs that will benefit everyone, not just ‘people like me’. Because accessible products benefit everyone. Disability, whether it’s temporary or permanent, can happen to any person and that person could be any one of us.

About the Author: Richard Saunders, product owner of SaaS product Contensis