While commercial businesses aren’t subject to the digital accessibility regulations that apply to public sector organisations, they must still make accessibility provisions under the Equality Act 2010. And in addition to these legal requirements, there are the moral imperatives and economic drivers to make your digital product or service as inclusive as possible.
Making your product accessible to more people broadens your potential customer base, for example. By enabling more people to achieve their goals through self-service digital channels, you also reduce cost-per-transaction. And by ensuring people with additional accessibility requirements are able to use your product, you typically make it easier to use for everyone.
What is accessibility?
Accessibility is a measure of whether groups of people can use a system for its intended purpose. This may be with the help of assistive technology, such as a screen reader or a braille output device.
Because different groups have different needs, accessibility is an incredibly broad area, with a near-infinite number of requirements you could aim to address. Ultimately, it’s impossible to create a digital product that caters for every accessibility need in the world. Instead, it’s helpful to explicitly specify which needs you’re going to consider, and focus on meeting those really well. This could include partial-sightedness, limited motor function or dyslexia.
Whose responsibility is accessibility?
Meeting the accessibility needs you’ve decided to focus on requires everyone involved in the creation and operation of your digital product to play their part. Expertise can’t live in a silo, or be fully outsourced to an external specialist. Instead, all parties should understand the accessibility best practices relevant to their role.
Visual designers, for example, need to know how to apply brand colours in accessible ways when designing components or screens. Content designers must understand how to structure information accessibly, including appropriate use of headings. Developers need to understand the importance of using tags for those headings, rather than simply bolding the text or making it larger.
External accessibility specialists can (and indeed should) be drawn on to support your teams, by helping build up and maintain their knowledge. But since they can’t sense-check every accessibility-related decision each team member makes in the course of their job, they can never be a substitute for solid team understanding.
When should you be thinking about accessibility?
A not-uncommon pattern in organisations is to see accessibility as a self-contained wrapper that can be retro-fitted to an existing product, typically at the very end of the development cycle, or even post-launch.
While on the one hand, there’s a degree of ‘better late than never’, this approach almost invariably leads to the need for significant rework. A digital product that has been built without any consideration for accessibility will likely require changes to its user experience, some of them potentially complex. Like with any piece of engineering, making major alterations once the product has been built is far more expensive and time-consuming than it would have been at the design stage.
This is why it’s best to make accessibility a fundamental part of any project from the moment you begin creating it. This may require a change in mindset, away from a conventional approach where the team first builds all the functionality, then works on making it usable, and then addresses accessibility. Instead, focus on one feature at a time, factoring in functionality, usability and accessibility from the start. Once all three are delivered, repeat the process for the next feature.
Taking this approach will mean by the time you reach your planned launch date, your product or service should be functional, usable and accessible. And while it might mean your launch-ready minimum viable product (MVP) takes slightly longer to deliver, you’re minimising the likelihood of costly rework that could delay launch – not to mention the impact on your organisation if you release something that excludes particular groups.
How should you test your product’s accessibility?
There’s value in your own team testing the accessibility of your product, including via checklists, or one of the many publicly available auditing tools. However, there’s no substitute for testing with people who have the accessibility requirements you’re designing for.
Even if one of your team has had the best accessibility training in the world, if they don’t have that accessibility requirement, they’ll never truly recreate the experience of someone who does. This type of testing also frequently brings to light people using accessibility tooling in ways you may never have considered, thereby broadening and deepening your team’s understanding of how to meet particular needs.
Why you should be looking beyond just ‘accessible’
Accessibility is ultimately a binary measure of whether someone can use your product. What it doesn’t consider is how easy it is for them to use. Usability covers factors such as the number of steps required to complete a task, how long this takes, and how much someone needs to remember to do so.
Imagine a system that’s entirely accessible using a keyboard, but requires people to use a series of non-obvious keyboard shortcuts to achieve a common goal. Even if instructions are provided, there’s still a burden on the user to read them and learn how to achieve their objective. This would tick the ‘accessible by keyboard’ box, but score low on usability.
Your user research will help uncover what you can put in place to elevate the usability of your product for different people.
Configurability and customisation helps with accessibility and usability
Lastly, offering a degree of customisation is a powerful way to meet accessibility requirements and improve usability. This could include options to change the colour scheme, or alter text and image sizes without adversely impacting the layout of a screen.
Your next steps
Whether you’re a project sponsor, product owner or responsible for the delivery of a new digital offering, we hope this piece has given you an overview of what to be thinking about as you plan the build and/or operation of your product or service.
There’s lots of information about digital accessibility online, particularly the Web Content Accessibility Guidelines (WCAG) – the de facto standard for web accessibility. Other useful material includes the UK government’s guidance and tools for digital accessibility, and The Big Hack.
If you’re considering using external accessibility expertise, either to upskill your team, or assist with development, asking the right questions will help you pick a partner that genuinely understands how to create accessible digital products. Things to find out include what criteria they’ll design for and test against (this should ideally be WCAG to at least AA), and whether they have access to testers with the accessibility needs you want to accommodate. It may be valuable to test their understanding of common accessibility criteria, such as what makes a meaningful link name and why having good links is important.
