Standard point 5

Make sure everyone can use the service

This guidance will help you apply standard point 5.

Everyone is responsible for meeting the Service Standard. This standard point is most relevant to:

Designers User researchers Accessibility specialist

---

Summary

Make sure your service can be used by people with different physical, mental, social, cultural or learning needs, whether it's for the public, for staff working in DfE or across the education sector.

Champion the needs of all users and include them as part of the design and iterative process. Consider where these users are on the digital inclusion scale.

Depending on the size and complexity of your service, this standard could be assessed by an accessibility specialist at assessment.

Why it's important

Everyone who works on DfE digital services has a role to play in making them accessible and inclusive.

If your service isn't accessible to everyone who needs it, you may be breaking the 2010 Equality Act.

Accessibility regulations say that public sector websites must meet accessibility standards and publish an accessibility statement. You can find out more about the regulations on GOV.UK.

How to meet this standard in every phase

You'll be assessed on what you've done to meet this standard at service assessments. However, even if the service you're working on is not being assessed, it's good practice to consider how you'll meet this standard point.

Discovery

Things to consider:

• time and money allocated for accessibility testing and audits at future phases

• what your approach to recruiting users with access needs will be

• evidence of talking to people who use assistive technology

• user research with people with access needs

• the context of your users' environment

• non-digital parts of the service, for example, letters and phone calls

• a content strategy based on user needs and policy intent

• a plan for things you might test at alpha

Things to avoid in discovery

• overlooking a potentially key user group

• research findings about user preference, not user behaviour

• no user research or limited research has taken place

• no hypotheses for alpha

Alpha

Things to consider:

• testing the user journey with users

• what your approach to recruiting users with access needs will be

• exploring the support model, for example, consider the offline user journey and whether there is a phone number or email address for service support

• starting accessibility testing

• inclusive design, considering how age, gender, and culture might impact the service

• a plan for accessibility testing at beta

• designing and testing content with users of the service

• the context of your users' environment when they might be using the service, for example, a noisy classroom, slow internet connection, and what devices they're using

• how the service fits into wider DfE services

• testing how assistive digital support will work

• research with users across the digital inclusion scale

• content written in plain English

Things to avoid in alpha

• not enough testing of hypotheses about how people will use the service

• not testing different ways of delivering content

Beta and live

Things to consider:

• continual testing with users with access needs

• what your approach to recruiting users with access needs will be

• the context of your users' environment when they might be using the service, for example, a noisy classroom, slow internet connection, and what devices they're using

• how you've tested—and continue to test—with users who need assistive digital support

• an accessibility audit and any issues fixed, this is a mandatory requirement

• how the service meets the latest accessibility standards

• an accessibility statement that explains how accessible the service is. This needs to be published when the service moves into public beta

• the service continues to be iterated based on insights from user research

• any changes are tested to make sure they meet accessibility requirements

• non-digital or offline processes and their impact or relationship to the service

Things to avoid in beta and live

• not enough people with access needs invited to use the private beta

• not having or testing an assisted digital route

• not enough research to understand how users with access needs might interact with the service

• accessibility testing being an afterthought

Profession specific guidance

Each DDaT profession in DfE has their own community and guidance.

• User Research Manual
• Design Manual
• Architecture
• Technical Guidance