It's common sense to ensure that your service is usable by as many people as possible, which is what accessibility is all about. We both know this from practical experience, as a short glance at our background will underline.

In web and digital services, we typically use the term to focus on making sure things work for people with disabilities and access needs. In government we also consider other areas where our users may be excluded, such as those who may not be skilled or able to use online services. These are typically classed under the term "assisted digital". 

Accessibility in context

Key data that informs our work comes from the Office for National Statistics (ONS). It estimates that the UK population stands at 67 million, of whom 20%, some 14.1 million people, are disabled. It breaks this down further as follows:

8% of children are disabled
19% of working age adults are disabled
46% of pension age adults are disabled

Yet even these figures don't represent the whole story. Those with situational, temporary, hidden or non-visible disabilities are unlikely to be counted, so in reality, accessibility will affect a lot more people than that original one in five estimate.

Some 85% of those with a visible disability also have a non-visible one. This indicates that there are many who only have non-visible disabilities (such as dyslexia, ADHD, autism, etc) and are far less likely to be noticed, diagnosed or captured in the statistics.

Digital services, an interaction such as applying for Universal Credit or renewing a passport which results in an outcome, are taken for granted by most of us. Yet failing to consider the needs of disabled users when it comes to using these same services can mean that they are unable to use them to achieve their goal. In much the same way that a lack of subtitles or captions acts as a barrier to a deaf or hard of hearing person's enjoyment of a film, or the absence of a ramp or lift might make a building inaccessible to someone with mobility issues, so might a hard-to-read form hamper their ability to interact with government.

So, might an inaccessible digital service hamper ability to interact with government? Keyboard functionality is essential for those with co-ordination, visual or motor impairments.

As civil servants working on government services, we are committed to making sure our services are accessible and usable to all. This isn't just because it's the right and moral thing to do, or that it's part of the service standard that all government services must meet. It also happens to be the law, as per the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations, the Public Sector Equality Duty and the Equality Act 2010 

But if Government does it because it's the right thing to do, while also being a legal requirement, there is a financial incentive for businesses to improve accessibility, digital and physical, too.

The Purple Pound refers to the spending power of disabled households, in which at least one member has a disability. It's estimated that businesses lose around £2bn a month by ignoring the needs of disabled people, with 73% of potential disabled customers experiencing barriers on more than a quarter of the websites they visit.


In Government, we recognised the scale of the problem and are using agile methods when designing services. This falls into four stages:

  • Discovery: understand the users' needs and what they are trying to do
  • Alpha: builds on the identified needs and tests hypotheses
  • Beta: build the service, release it to users and iteratively improve it
  • Live: run the service and continue to iteratively improve it

User research is a cornerstone of how we work during all these phases, from discovery onwards. We try to ensure we include users with disabilities and access needs throughout the stages so that what we design and develop is accessible and usable to all.

Personally, I don't like to badge research "accessibility research" or "accessibility testing". If I'm interviewing an individual with a disability I just also learn about any additional or differing needs that they have because of how they may use a service or a computer. Their disability doesn't define them. 

Design and development

If you're doing true "User Centred Design", accessibility needs to be part of that process. It's often viewed as a requirement or a checkbox exercise to say a website meets a standard, but at its core, accessibility is just a user need, and linking it up with user research is the only way to know that your product is truly accessible.

The standard we need to meet legally, currently the recognised international standard, is the Web Content Accessibility Guidelines (WCAG) 2.1. It's often viewed as the end-goal, but actually it's just the bare minimum. Many organisations stop there, pat themselves on the back, without understanding that their website might still not work for some people.

For example, many considerations around the use of simple language and readability are not mandated, so most organisations ignore them. You can be WCAG compliant despite having a website full of complex language, acronyms and technical jargon that nobody can understand. This makes it particularly challenging for neurodivergent people, screen reader users and those who don't have English as their first language. But, looking at it objectively, if people cannot understand it, then it's not accessible. 

So, WCAG 2.1 is a starting point and a legal requirement for Public Sector Bodies. You can test your website against the criteria and be confident that most of the big barriers have been removed, but without doing proper user research you will never be able to understand how accessible your website truly is.