In the UK, at least 1 in 5 people in the UK have a long term illness, impairment or disability, ranging from visual, hearing and motor (affecting fine movement) to cognitive, which affects memory and thinking. Globally, it is estimated one in six people experience significant disability, according to the World Health Organisation.
Despite this, there is a significant digital divide when accessing the internet with a majority of websites having accessibility errors – WebAIM’s 2025 accessibility evaluation detected basic accessibility failures on 94.8% of the home pages for the top 1,000,000 web sites. This limits people’s ability to access and engage with a wide range of products, services and information.
But the concept of accessibility does not just apply to disabled people; according to the UK Government, it is about making sure services can be used by as many people as possible, considering different needs at different times and in different circumstances. Failing to do so may mean you are breaking the law.
Photo: Nathan AndersonThe Government Digital Service’s head of accessibility, Alastair Duggin, says it is a lack of awareness that most commonly results in things being inaccessible, and that our understanding of accessibility may be too narrow.
“When I talk about accessibility, I’m using it to mean that people are not excluded from using something on the basis of experiencing a disability. Accessibility means that people can do what they need to do in a similar amount of time and effort as someone that does not have a disability. It means that people are empowered, can be independent, and will not be frustrated by something that is poorly designed or implemented.”
The Arts Council England’s new access scheme for creativity and culture in the UK, All In, is a shining example of Alastair’s definition of accessibility. The initiative seeks to increase access to culture for deaf, disabled and neurodivergent people via a digital membership scheme, which has been designed to make all aspects of the booking process more accessible.
At Calvium, we design with accessibility front of mind, and as a standard process every project undertaken has an accessibility audit to ensure we are meeting essential accessibility requirements – and that we are continually improving. With that in mind, this blog will discuss how we approach digital accessibility and highlight key considerations for good practice.
These interface design examples show a range of accessibility features, from dark modes to alternative filtering options.
Common digital accessibility issues
The broad spectrum of disability means there are multiple factors to consider when approaching disability and producing websites and apps. For example, fonts and colour contrast can cause issues for people with visual impairments. So can unstructured headings, a lack of image alt text and inaccessible documents, as assistive technologies like screen readers rely on them.
Video content is often uploaded without transcripts or subtitles, which renders it inaccessible to people with hearing impairments and screen readers. While people with motor disabilities can find it difficult to use a mouse or keyboard in the same way, websites may be too busy or complex for people with neurological conditions such as autism. Flickering images and animated backgrounds can trigger seizures for people with photosensitive epilepsy.
Websites do have accessibility guidelines (WCAG 2), but there is not much specifically for apps. In lieu of established guidelines, Calvium uses an adapted version of WCAG 2.2 and aims to be at least AA compliant, which is the minimum needed to meet accessibility requirements.
Our process includes web and mobile accessibility audit templates with around 100 checks, which we use to test new app features and whole products at various stages of development. It has proved to be successful, indeed, the Government Digital Services (GDS) accessibility auditors recently took our recommendations for the Met Office app on board for future GDS mobile app audits.
What, then, is involved in the digital accessibility process?
Photo: Robin Worrall
Design system best practice
Local government and government entities, such as police and educational institutions, all require high accessibility standards – as set out in the Government’s Design System guidance. It is why we also choose to match work to the GDS guidance, which involves eight key considerations.
Think about accessibility from the start
This means thinking about all user needs at different times and in different circumstances, for example their location, health and what device they are using. Factors for design will depend on functionality, budget, target users and assessment criteria, so it is important to consider the purpose of the app upfront and build as appropriate.
For instance, remember not all apps can be fully accessible due to their purpose, resources or client restrictions, and some aspects may be of greater priority than others.
For an app like Place Experience Platform which has a broad church of users, inclusive design elements like text contrast functionality are built into the code. Additionally, as it is available through the GCloud procurement portal, it must meet high public sector accessibility standards. Developers are constantly adding new accessibility features as technology evolves and to ensure it is meeting those standards.
Accessibility is the whole team’s job
It is really important that every person in the team understands accessibility, so that everyone is working together to avoid accidentally making something inaccessible.
The Calvium team are all involved in increasing accessibility across product development and making sure our apps work for as much of the population as possible. As mentioned, we have web and mobile audit templates and design documentation, which we refer to throughout the design and development process. But equally importantly, we listen to team members with personal experience of disability, who can provide valuable insights and positively impact the way we approach tasks.
We use tools such as Wave and Lighthouse to support checks, and we share accessibility tasks and improvements through Gitlab for everyone to review. We also have an accessibility Slack channel and peer learning talks to share best practice and new developments in the team.
There are many useful guidelines and tools to support best accessibility practice, e.g. from UK government, WebAIM and Material.io.
Researching with disabled users
Online tools and automated checks are an efficient method for testing accessibility, but they cannot cover all aspects and nothing compares to working with real-life users. Alongside our own team members, working with people with diverse lived experiences is essential to ensure accessibility is baked in at all stages and covers all bases.
The voices of disabled people should be at the front and centre of accessible product development and inclusive design, shaping projects as they go. For example, the success of our two major wayfinding apps, NavSta and UCAN GO, was completely dependent on not only testing with the target audience but co-designing with them.
This user-led approach allowed us to prioritise solutions that were most meaningful for people with varying impairments – for example, making it easy to personalise the app design and features – and earned NavSta ‘highly commended’ at the 2020 Celebrating Neurodiversity Awards.
What to do about accessibility in the ‘discovery’ stage
This phase is all about understanding how disabled users might use a service, as well as considering what problems they may experience.
Projects like the Sidekick mobile app we developed for Open Bionics highlights why the discovery phase is so integral. Given every bionic Hero Arm is 3D printed specifically for each individual, we had to make sure the app catered for a wide variety of needs and could provide a personalised experience. This involved a great deal of discovery work with users over the three-year project.
If you discover full accessibility is compromised at this stage, it is important to ensure the client is aware and agrees to limitations, which should be noted in the accessibility statement (see below).
What to do about accessibility in ‘alpha’
Alpha testing is done to make sure a product is ready to send to potential users for beta testing. So this is when it is crucial to consider whether the design meets the WCAG 2.2 design principles and to start those initial checks. If you haven’t already done so, now is a good time to begin preparing your full accessibility audit as these can take time to arrange and usually need to be carried out before moving into public beta.
There are a range of tools that can help with those checks before moving to the next phase. For example, we use Apple Store guidance to inspect the accessibility of screens in the app, while Google Play Store allows you to generate a pre-launch report to identify issues.
What to do about accessibility in ‘beta’
Beta is a time to keep testing and making amends. Advice and technology often changes during this stage, so you must be open to adapting. As mentioned above, it is essential to get an accessibility audit here, ensuring apps work with assistive technologies such as screen readers and meet criteria of standards such as WCAG 2.2. It is particularly important if working with the public sector, given the existing accessibility responsibilities of public bodies.
Publish an accessibility statement
The accessibility statement is a fundamental part of the process, providing detail of what has been tested, what is or isn’t compliant, and what steps are being taken to improve the process and address any issues.
If there is something that can’t be addressed immediately, or if the client deems certain factors irrelevant to their project, we document it in the statement. For instance, Open Bionics’ Sidekick app was audience-specific, and this dictated its features.
The statement should be reviewed at least once a year and updated if necessary.
What to do about accessibility in ‘live’
Even once the product is publicly available, it is essential to keep testing and improving. Accessibility features and compliance guidance are changing all the time, so products that were once compliant might not be as those rules and regulations change.
It is also important to carry out regular skill audits and ensure team knowledge is up-to-date. At Calvium, we have weekly tech training sessions to share new advances and best practice, which allows us to involve the whole team in improving product accessibility and ensure we are moving in the same direction.
And, of course, it’s best practice to continue to listen to user feedback to inform ongoing improvements.
Final thoughts
Accessibility is a business imperative, a key component for success, and a legislative requirement for public sector digital services.
Breaking the process down into bite-sized chunks and stages, as outlined in this blog, will help to establish good processes and highlight where new skills and knowledge are needed.
As a Disability Confident Committed (Level 1) employer and co-chair of the Disability Confident Network, we are committed to sharing knowledge and best practice to increase accessibility of digital tools and tech more broadly. And we are open to continual learning from others, always looking to improve where we can. Accessibility and digital inclusion is, after all, an ongoing journey that we should all be taking together.
