Accessibility in Government Digital Services: Beyond compliance

Accessibility is about people, not just standards

A government digital service can pass an accessibility audit and still be difficult for people to use. Its pages might meet technical standards, its forms might work with a screen reader, and its content might satisfy the organisation’s compliance requirements. Yet users could still struggle to understand what they need to do, find the information they need or complete the service without assistance.

This is the distinction between making a service accessible on paper and making it genuinely inclusive.

In public sector digital delivery, accessibility is sometimes treated as a technical requirement that teams must satisfy before launch. It appears in acceptance criteria, forms part of quality assurance and becomes a consideration during testing. These activities are important, but they do not necessarily address the wider barriers that prevent people from accessing and completing a service.

The consequences matter. Government services support people through important moments in their lives, from accessing financial support and healthcare to managing professional responsibilities and meeting legal obligations. When a service is difficult to use, the impact can extend beyond frustration. People may miss deadlines, submit incorrect information, abandon an application or rely on someone else to complete a task they should be able to manage independently.

Throughout my work in government digital delivery, I have seen the importance of understanding the relationship between users, business processes, technology and the wider service. Accessibility needs to be considered across all these areas. A well-designed interface cannot compensate for an inaccessible process, just as technically accessible software cannot overcome confusing content or unclear instructions.

Business analysts and service designers have an important role to play here. They can help teams understand the barriers users face, identify where those barriers originate and make sure accessibility informs decisions throughout delivery.

The objective should not simply be to demonstrate compliance. It should be to create services that people can understand, navigate and complete with as much independence as possible.

1. Understanding the difference between compliance and inclusion

Accessibility standards provide an essential foundation for digital services. They establish expectations for how services should be designed and built so that people with disabilities can use them. Without these standards, accessibility can become subjective, inconsistent and dependent on individual preferences or assumptions.

However, meeting a technical standard does not automatically mean a service meets every user’s needs.

Consider a government application form. Its fields have appropriate labels, the page can be navigated using a keyboard, and the colour contrast meets the required threshold. From a technical perspective, the team has addressed several important accessibility requirements.

Now consider someone who has limited digital confidence, struggles with complex written information or needs additional time to understand unfamiliar terminology. The form might technically be accessible but still present significant barriers.

Perhaps the instructions assume the user understands a government-specific term. Perhaps the form asks for information without explaining why it is needed. Perhaps an error message identifies a problem but does not explain how to resolve it. None of these issues necessarily results from a failure to implement an accessibility standard, yet each can prevent someone from completing the task.

“What stood out about the approach was the focus on understanding accessibility from the user’s perspective, rather than treating it purely as a compliance exercise. The work helped us look beyond the technical requirements and consider how people actually interact with our services, where they encounter difficulties, and what we could do to remove those barriers. It also gave us a clearer understanding of how accessibility connects to the wider service experience, from the language we use to the processes users must navigate. That shift in perspective has been valuable in helping us make more informed design decisions and build accessibility into our approach to digital delivery from the outset.”

Head of Digital Services

This is why I believe accessibility must be considered alongside usability, content design and the wider service experience.

The two concepts are closely connected, but they are not interchangeable. Accessibility addresses barriers that prevent people with disabilities from using a service. Inclusion requires teams to understand the wider range of circumstances, abilities and experiences that shape how people interact with it.

A service designed for someone using assistive technology should also be clear enough for someone who is unfamiliar with the process. A service that supports people with cognitive impairments should avoid unnecessary complexity for everyone. A form that works well on a mobile device can also help someone who has limited access to equipment or a stable internet connection.

These benefits should not be used to suggest that accessibility is only worthwhile when it improves the experience for everyone. People with disabilities have a right to access services, regardless of whether the improvements deliver wider organisational benefits.

Instead, the point is that inclusive design often reveals opportunities to improve the service as a whole.

For delivery teams, this starts with asking better questions. Rather than asking only whether a requirement has been met, ask whether users can complete the task, whether they understand what is expected of them and whether the service places unnecessary demands on their time, attention or memory.

That change in perspective moves accessibility away from a narrow compliance exercise and towards a more meaningful measure of service quality.

2. Find the barriers before they become requirements

One of the most effective ways to improve accessibility is to identify barriers before they become embedded in the design, requirements or technical implementation.

This sounds straightforward, but it requires teams to challenge their assumptions about users.

Government services are often shaped by legislation, established business processes, legacy systems and organisational responsibilities. These are legitimate constraints, but they can encourage teams to focus on what the organisation needs to collect or process rather than what the user needs to understand and do.

A business analyst can help bridge this gap by examining the relationship between the business objective and the user’s task.

For example, imagine a service that requires an applicant to provide supporting evidence. The existing process might require users to download a document, complete it using separate software, save it in a particular format and upload it through an online form.

The process may work for confident users with suitable equipment and software. For someone using assistive technology, working on a mobile device or managing a cognitive impairment, however, it could introduce several unnecessary obstacles.

The immediate temptation might be to improve the instructions or add accessibility requirements to the development backlog. These changes may help, but they do not address the more fundamental question: does the process need to work this way at all?

This is where business analysis and service design can make a practical difference.

By mapping the end-to-end process, teams can identify every step users must complete, the information they need at each stage and the systems or people they depend on. They can then examine where the process creates friction and distinguish between genuine business requirements and inherited ways of working.

User research adds the evidence needed to make these decisions. Instead of assuming that users understand the process or can complete each step, researchers can observe how people interact with the service, identify where they struggle and explore what would help them succeed.

Importantly, research should involve people with different access needs, including disabled users who rely on assistive technologies. Their experiences should inform design decisions from the beginning rather than being sought only when the service is ready for testing.

Teams should also consider the circumstances in which people access the service. Someone completing an application at home with a large monitor may have a very different experience from someone using a mobile phone in a noisy environment or trying to complete a task while under significant stress.

These circumstances do not replace the need to understand disability-specific barriers. They provide additional context for designing a service that works in the real world.

The resulting insight should influence requirements, priorities and design decisions.

Rather than simply recording that a form must support keyboard navigation, a team might establish that a user must be able to complete the entire application without using a mouse. Rather than stating that error messages must be accessible, it might define the need for users to identify errors, understand how to correct them and retain the information they have already entered.

The distinction matters because the first approach describes a feature or technical condition. The second focuses on what the user needs to achieve.

Good requirements should do both: establish the necessary accessibility conditions and explain the outcome those conditions are intended to support.

“One of the challenges we face in government digital transformation is balancing delivery commitments with the need to get services right for the people who use them. Accessibility can easily become something that teams focus on towards the end of a project, when making changes is more difficult and expensive. The work helped us take a more proactive approach by bringing accessibility considerations into requirements, design and testing much earlier. What I particularly valued was the ability to connect user needs with our operational and technical constraints, giving the team practical ways to improve the service without losing sight of its wider objectives. It reinforced the importance of treating accessibility as a shared responsibility across the programme, rather than leaving it to specialists to resolve at the final stage.”

Programme Director

3. Make accessibility part of the entire delivery lifecycle

A common mistake is to treat accessibility as a final stage of quality assurance.

A team designs a service, develops the interface, completes functional testing and then arranges an accessibility assessment before launch. If the assessment identifies problems, the team must decide whether to fix them immediately, delay the release or accept the risk.

By this point, some problems may be expensive to resolve. The design has been agreed, technical decisions have been made and delivery plans have been built around an existing solution.

Accessibility findings can then become competing priorities rather than essential evidence about whether the service is ready.

A more effective approach is to build accessibility into the delivery lifecycle from discovery onwards.

During discovery, teams should investigate the existing service, understand user needs and identify barriers in the current experience. This includes considering the accessibility of existing processes, content, documents and supporting systems, rather than focusing exclusively on the proposed digital interface.

During alpha, teams should test design assumptions and explore different ways to meet user needs. Prototypes provide an opportunity to investigate navigation, content structure, form behaviour and interaction patterns before committing to a full implementation.

During beta, the focus shifts towards validating the working service. Automated tools can help identify some technical issues, while manual testing and testing with disabled users provide additional evidence about how the service performs in practice.

After launch, teams should continue monitoring performance, responding to feedback and testing changes. Accessibility is not a permanent property that a service acquires when it passes an assessment. Content changes, new features, software updates and changes to connected systems can all introduce new barriers.

This approach also changes how teams should think about acceptance criteria.

Accessibility should not be represented by a single backlog item stating that the service must be accessible. That requirement is too broad to guide implementation or provide meaningful evidence of completion.

Instead, accessibility should inform the relevant user stories, design decisions, technical requirements and testing activities throughout delivery.

For example, a story about completing an application form might include the need to navigate fields using a keyboard, identify required information, receive understandable validation messages and recover from errors without losing previously entered data.

These conditions can be tested. They also give developers, designers and testers a shared understanding of what a successful outcome looks like.

The business analyst can help make these expectations explicit, while the service designer ensures they remain connected to the wider user journey. Developers and testers then contribute the technical expertise needed to implement and verify the solution.

This is a shared responsibility, not a task that can be delegated entirely to an accessibility specialist.

Specialist expertise remains essential, particularly when teams encounter complex technical barriers or need to assess assistive technology compatibility. However, specialists cannot compensate for a delivery approach that excludes accessibility from everyday decisions.

The goal is to make accessible design part of how the team works, rather than an additional activity that competes with delivery.

4. Test the service people actually use

Accessibility testing is most valuable when it examines how people complete real tasks, rather than simply whether individual components behave as expected.

Automated accessibility tools have an important role. They can detect certain issues consistently and quickly, including some missing form labels, insufficient colour contrast and problems with page structure. They are useful during development because they help teams identify defects before those defects spread across a service.

However, automated testing cannot determine whether every instruction makes sense, whether a user understands an unfamiliar process or whether an interaction creates unnecessary cognitive demands.

Manual testing is therefore essential. Depending on the service, this may include keyboard-only navigation, testing with screen readers, browser zoom, text resizing and other relevant assistive technologies.

Testing with disabled users adds another important perspective. It helps teams understand how accessibility issues affect real tasks and whether their assumptions about the user experience hold up in practice.

Consider an application that allows users to save their progress and return later. A team might test that the save function works correctly, that the confirmation message appears and that the user can reopen the application.

But what happens when someone returns to the service using a screen reader? Can they understand which information has been saved? Is the current status clear? Can they identify the next action without having to repeat information or navigate through unnecessary content?

These questions require the team to look beyond the individual function and examine the complete interaction.

The same principle applies to error handling. A form may correctly prevent submission when required information is missing, but that alone does not make the experience accessible. The user needs to understand what went wrong, locate the relevant field and correct the problem. If the form contains many fields, the service should help them identify errors without requiring them to search through the entire page.

The important measure is not whether an error can be generated. It is whether the user can recover from it.

I would also encourage teams to examine the service from beginning to end, including the points where users move between digital and non-digital channels. A user might begin an application online, contact a call centre for clarification and then return to complete the process. If the advice provided by the call centre does not match the online instructions, the user faces another barrier.

This is where service design becomes particularly valuable. Journey maps and service blueprints can help teams understand how different interactions, teams and systems combine to shape the experience.

They can reveal accessibility issues that would be missed by testing a single webpage or application in isolation.

The findings should feed directly into delivery decisions. Teams need a clear way to record accessibility defects, assess their impact, assign responsibility and verify that fixes have worked. Where an issue prevents people from completing an essential task, it should receive appropriate priority rather than being treated as a minor interface defect.

Testing should also continue after changes are introduced. A fix that improves one interaction can affect another, particularly in services with shared components or complex technical dependencies.

Ultimately, the question is straightforward: can people use the service to achieve what they came to do?

“The real value was in helping us understand the difference between a service that meets accessibility standards and one that genuinely works for a diverse range of users. By looking at the end-to-end journey, rather than individual screens or technical components in isolation, we were able to consider the wider barriers that can prevent people from completing a task successfully. The combination of structured analysis, user-centred thinking and practical recommendations gave us a much clearer basis for making improvements. It also helped bring different disciplines together around a common understanding of what a good service should achieve. For us, accessibility is not simply about avoiding problems; it is about giving people the best possible opportunity to use government services independently and with confidence.”

Head of Service Design

5. Give accessibility the attention it needs

Even when teams understand the importance of accessibility, competing delivery pressures can make it difficult to give the subject sufficient attention.

Programmes operate within budgets, delivery deadlines and political expectations. Senior stakeholders need to demonstrate progress, while delivery teams are expected to manage scope and maintain momentum.

Under these conditions, accessibility can become something that teams intend to improve later.

The problem is that accessibility debt accumulates in much the same way as other forms of technical and design debt. An inaccessible component may be reused across several services. A confusing process may become embedded in operational guidance. A decision made early in delivery may create barriers that become increasingly expensive to resolve.

The longer these issues remain, the more difficult it can be to address them without affecting delivery plans.

For senior leaders, this means accessibility needs visible ownership and appropriate investment. It should form part of delivery governance, service performance discussions and decisions about whether a service is ready to launch.

This does not mean every accessibility issue carries the same level of risk or that all improvements must be delivered simultaneously. Teams still need to assess issues proportionately, taking account of their impact on users, legal obligations, available evidence and the consequences of leaving a barrier unresolved.

However, prioritisation must not become a way to normalise exclusion. Where a service prevents disabled users from completing an essential task, the team needs a clear plan to address the problem and appropriate scrutiny of any decision to proceed without a fix.

Leaders should also ensure that teams have access to the right skills. Designers, developers, testers, business analysts and content designers need sufficient knowledge to recognise common accessibility issues and understand when specialist support is required.

This is particularly important when organisations rely on multiple suppliers or delivery teams. If accessibility expectations are unclear, responsibility can become fragmented. Each team may deliver its own component successfully while the overall service remains difficult to use.

Clear requirements, shared design standards, consistent testing approaches and defined responsibilities can reduce this risk.

Teams should also measure outcomes rather than relying exclusively on compliance activity.

The number of accessibility tests completed, defects recorded or audits passed can provide useful management information. However, these measures do not necessarily show whether users can complete their tasks independently.

Depending on the service, teams could also examine task completion rates, abandonment, errors, requests for assistance and feedback from users with different access needs. These measures should be interpreted carefully because an apparent improvement in overall completion rates may conceal persistent barriers for a particular group.

Qualitative research remains important for understanding why people struggle and what needs to change.

No single metric can establish whether a service is inclusive. A stronger assessment combines technical evidence, observed user behaviour, feedback and an understanding of the service’s wider operational context.

This gives leaders a more credible basis for deciding where to invest and whether improvements are making a meaningful difference.

Final thoughts: design for the people who need the service

Accessibility in government digital services is not simply a technical consideration or a requirement to satisfy before launch. It is a fundamental part of delivering a service that people can use to meet their needs.

Legal standards provide an essential baseline. Automated checks, manual testing and specialist assessments help teams identify technical barriers. But genuinely inclusive services require more than these activities alone.

They require teams to understand how people experience a service, challenge assumptions about existing processes and test whether their solutions work in practice. They require accessibility to inform decisions from discovery through to live service improvement. And they require leaders to give the subject the ownership, resources and attention it deserves.

Business analysts and service designers can help make this happen by connecting user needs to business processes, requirements, design decisions and measurable outcomes. Their contribution is not simply to document accessibility requirements or map user journeys. It is to help the whole delivery team understand what a successful service must enable people to do.

There is also a wider lesson for public sector transformation. A service is not successful simply because the technology works, the project has met its milestones or the organisation has demonstrated compliance. Success depends on whether the service achieves its intended purpose for the people who rely on it.

That is particularly important in government, where users often have limited choice about whether they need to interact with a service.

If someone cannot access a government service independently, we should not automatically assume that the problem lies with the user. We should examine the service, the process and the decisions that shaped it.

The question for public sector leaders is this: are we measuring accessibility by our ability to demonstrate compliance, or by whether people with different needs can successfully use the services we provide?

The answer should shape how we design, deliver and improve government digital services.