Page structureInteractivityWritten contentProviding alternativesResources

AccessibilityLeader’s guide to accessibility

Table of Contents

Introduction

Accessibility as a team sport

Accessibility and your product

Accessible procurement

Glossary

Introduction

“The single best thing a leader can do is ask ‘Is it accessible?’ because everything flows from that, for both themselves and their team.”

James Buller, Senior Accessibility and Inclusion Consultant at Home Office Digital, Data and Technology

This guide is for anyone with responsibility for a digital team, product or service. It will help you work out what role each team member plays in making your service accessible, and what tools and training you and others may need, to help you build accessibility into your product from the start.

Maybe you’re not sure what we mean by accessibility. Maybe you understand the principles, but you don’t know how to embed them in your team and your product. Maybe you know the basics, but you want to know more.

This guide covers the basic information you need to know, and links to further resources if you want to increase your knowledge.

What accessibility means for you

So that everyone can access and use websites, web pages and online services provided or used by your department:

  1. Use clear, simple design and content to make it as easy as possible for users to do what they need to.
  2. Make sure the service works with assistive technology. For example, some users might increase the text size so they can read it more easily, use the keyboard instead of a mouse, or use software that reads a web page out loud.

How to use the guide

The guide covers the following areas:

  • Accessibility as a team sport: The roles and responsibilities within a typical delivery team, and how leaders can help everyone understand what they need to do and get the training they need (accessibility from the top down).
  • Accessibility and your product: Where accessibility sits in the product lifecycle, the risks related to accessibility, the business case for accessibility, and the role of the accessibility statement.
  • Accessible procurement: The responsibilities of third party suppliers, and how to make sure they’re getting it right.
  • Tips and resources: A glossary, links to further reading, courses and contacts, and some small changes you can implement right away to make a measurable difference!

Accessibility as a team sport

Accessibility is not something one person, team or specialism should deliver on their own. Delivering accessible services for staff and the public takes effort and a variety of skills.

Every person in the department has a role to play to ensure that everything we do is accessible whether it’s a policy document, public report, training session, digital service, caseworking system or anything else we deliver.

In this section, we’ll mainly focus on the roles within a delivery team and the role you as a leader have in making sure your teams are delivering in an accessible way.

We’ll also touch on some general principles that everyone can adopt to ensure the work they deliver is more accessible.

Roles and responsibilities: delivery teams

These role descriptions are based on the Government Digital and Data Profession Capability Framework. Use them as a guide to help you assign responsibilities. You may not have, or need, all these roles in your own team.

Product and delivery roles

Product manager

  • Overall responsibility for the accessibility of their product or service.
  • Makes sure everyone else on the team knows the role they play in accessibility.
  • Prioritises accessibility – sets a culture of accessibility being important.
  • Ensures stakeholders understand why accessibility is being prioritised.
  • Understands the risks relating to accessibility of their product or service.

Delivery manager

  • Allocates time and budget for iterative accessibility testing, research and fixes in delivery plans.
  • Includes accessibility standards in supplier contracts.
  • Makes sure:
    • accessibility is baked into the definition of done and acceptance criteria for features
    • the team understands that accessibility is part of the quality of a delivered service
    • any accessibility trade-offs are conscious, documented and reasonable.

Business analyst

  • Includes accessibility standard and regulations in delivery requirements.
  • Includes accessibility testing for all user interface features and content in the definition of done.

Software development roles

Developer / Engineer

  • Uses HTML and well documented, accessible components where possible.
  • Avoids using ARIA where possible and follows the key principles of ARIA if needed.
  • Understands that code libraries, design systems and frameworks are not automatically accessible. Follows accessibility guidance for using them.
  • Builds automated and manual accessibility into continuous testing.

Tester

  • Builds automated and manual accessibility into continuous testing at every stage of lifecycle.
  • Collaborates with the rest of the team to prioritise defects according to impact on users, not output from automated tools or predefined levels based on WCAG success criteria.
  • Completes automated, manual and assistive technology compatibility testing.
  • Carries out User Acceptance Testing (UAT) with individuals that use assistive technology
  • Makes recommendations for further levels of testing or assurance that may be required depending on the current levels of quality, confidence or product risk.

User centred design roles

Service designer

  • Ensures group collaboration includes a diverse range of participants.
  • Designs services for the widest user need.
  • Considers accessibility and digital inclusion when planning end to end service design approaches.

User researcher

  • Includes a representative sample of disabled people in research (at least 1 in every 5 users).
  • Carries out full rounds of research with disabled people where appropriate, for example highly complex services and services likely to have a high number of disabled users.

Interaction designer

  • Designs for the widest user need.
  • Reviews designs for accessibility and resolves issues.
  • Understands the limitations of design systems.
  • Follows accessibility guidance on individual components and accessible design.
  • Documents accessibility design decisions so others understand why and how to implement them.

Content designer

  • Designs for the widest user need.
  • Writes in an accessible and inclusive way using plain language.
  • Reviews content for accessibility and resolves issues.
  • Makes sure all content meets accessibility requirements, including video, audio and non-HTML documents.
  • Avoids using PDFs if possible, and makes sure they are accessible if used.

Roles and responsibilities beyond your team

These people are often ‘enablers’ for accessible service delivery.

Design authority

  • Makes sure technology systems, services and websites submitted for approval are evaluated for accessibility.

Spend control and service assessment team

  • Considers accessibility requirements in making spend control decisions.
  • Include appropriate challenge relating to accessibility in service assessment.
  • Considers evidence of work relating to accessibility when making decisions about service assessments.

IT team

  • Makes sure staff have access to appropriate assistive technology.
  • Provides training and support for assistive technology.
  • Makes sure IT support agents understand assistive technology and that support routes are accessible.

DDaT Profession lead (for example Head of User Research)

  • Develops and embeds inclusive, high quality professional standards for accessibility within their specialism.
  • Develops accessibility skills, practices and capabilities of their communities.
  • Develops appropriate accessibility quality controls for their specialism.

Accessibility team

  • Sets, owns and maintains accessibility standards, guidance and governance.
  • Provides assurance of accessibility standards across portfolios, functions and professions.
  • Supports the adoption of accessibility standards, guidance, governance and toolset.
  • Works to ensure a coordinated approach to accessibility.
  • Defines accessibility training.
  • Supports other professions to develop resources for their communities.

Chief Technology Officer (CTO)

  • Makes sure technology systems, services and websites meet accessibility standards and legal requirements

Your role as a leader

Leaders have a key role in embedding accessibility in their team’s people, processes and technology. You set an example from the top and help to drive understanding of accessibility principles and why they’re important.

To achieve this, you’ll need to know:

  • what accessibility is
  • why products and services must be accessible, and
  • how to make sure that they are accessible and will continue to be

Your responsibilities as a leader are to:

  • champion accessibility, raise awareness and sell the importance of making outward facing and internal products and services accessible
  • ensure that accessibility is considered in the decision-making process
  • champion upwards, so accessibility is considered and included in broader discussions outside your department
  • actively participate in accessibility related meetings, sharing knowledge and experience
  • make sure appropriate accessibility roles are created, maintained and recruited
  • measure accessibility maturity within your organisation, and see that improvement plans are in place and delivered against
  • look outwards to partners across government, commercial partners and academia for best practice and sharing opportunities to improve accessibility across other areas of your department and broader government

Educating yourself and others

You do not need an in-depth knowledge of accessibility. You have experts in your organisation who can help with the technical work.

However, it is important that you have a basic understanding of accessibility principles, including the Public Sector Bodies Accessibility Regulations (PSBAR) and the Web Content Accessibility Guidelines (WCAG), and how they should be applied, so you can guide and support your team.

The following resources provide quick and simple guidance on the basics.

Short:

Longer:

In-depth:

Web Accessibility Introduction (edX) is a strong foundation in digital accessibility to make your website and apps work well for people with disabilities and meet international standards. (4 weeks, 4 to 5 hours a week, self-paced)

Accessibility and your product

Your product must be accessible to comply with point 5 ot the government Service Standard: Make sure everyone can use the service.

The business case for accessibility

Initial investment in making services, products and documents accessible can save time and money later in development and production.

The easier your products are for everyone to use, the less time you will spend answering enquiries and providing alternative formats. Using accessible formats and language can reduce the need for helplines and call centres.

Internal services should be accessible, as well as those used by the public. Many of our colleagues and employees have access needs, including visual and hearing impairments, mobility issues and learning difficulties.

It is a leader’s responsibility to make sure everyone can use the systems they need to do their job and communicate with colleagues. Accessibility should be an important part of our inclusive working culture.

If you think you don’t currently have any employees with accessibility needs:

  • Are you sure you don’t? Not all disabilities are visible.
  • Why don’t you? Are the systems you use a barrier because they have accessibility issues?
  • What if you do in the future?

The risks of non-compliance

There are a number of reasons to include accessibility issues in your risk register.

Legal consequences

Most people are aware that there are legal requirements around accessibility, though not necessarily what they are. This is sometimes used as the ultimate threat to force compliance.

The relevant laws are:

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018

The Government Digital Service (GDS) is responsible for monitoring public sector website compliance. It has the power to request information and demand access to any public sector organisation’s web content – both intranet and public-facing materials. If a public sector body fails to publish an accessibility statement on their website – or one that is not accurate – the Central Digital and Data Office (CDDO) will publish the organisation’s name. Enforcement falls under the Equality and Human Rights Commission (except in Northern Ireland).

Equality Act 2010

Legally protects people from discrimination in the workplace and in wider society.

You might find it useful to refer to the GOV.UK guidance Understanding accessibility requirements for public sector bodies:

Your website or mobile app will meet legal requirements if you:

Financial, time and resource costs

Bolting on rather than baking in accessibility can mean extra development work is needed to make the service accessible and compliant, costing more money and occupying more developer time. This can mean your project misses deadlines and goes over budget.

If a service is not accessible to all users, there will be more need for call centre staff, and more time spent assisting users by phone or online.

Reputational damage

Complaints from users who cannot use the product or find it difficult to use, especially if voiced online or picked up by the media, can damage team morale as well as the reputation of your team, your department and the government.

Loss of your users’ trust can be hard to fix and may take a long time.

User research

User research is an important part of developing your product. At least 1 in 5 user research participants should be someone with an access need across a representative range of disabilities.

Testing with users will give you and your team more insight into how accessible the product is than an audit alone. An accessibility audit checks that the product meets a set standard, but it might not reflect the real world user experience.

If your team includes user centred design specialists, they will carry out user research. If not, consider contacting a third party agency for assistance.

Read more about users with access needs.

Accessibility testing

Testing for accessibility at each stage of development makes it easier to solve problems than if you leave it till last.

Remember, accessibility is a team sport and different roles will perform different tests. Developers check their code is accessible. Content designers check that wording is clear and concise.

Your department’s accessibility and inclusion team, if you have one, can help you with testing, or recommend external companies to test your product, depending on your requirements.

It is important to understand the difference between a WCAG audit and an accessibility test. Accessibility testing primarily involves manual assessments by real users. It highlights issues that might not be obvious by automated tools alone.

On the other hand, an accessibility audit systemically examines whether a site or application adheres to the WCAG standard. Audits are normally a combination of automated tools and expert evaluations. They often provide a structured detailed assessment so to meet the legal requirements an audit is required.

Accessibility audit and accessibility statement

Before a service is made publicly available, you’ll need:

  • An accessibility audit
  • An accessibility statement

An internal or external tester carries out the audit. They will check that the service meets accessibility standards, and list areas where it fails. They may also make recommendations for fixes and improvements.

High priority issues make a service unusable for some people. The product cannot go live until these are fixed.

Medium and low priority issues make a service difficult to use for some people. Fix before launch if possible, or as soon as possible afterwards.

Allow time after the audit and before the product launches to work on accessibility issues and write the accessibility statement.

The accessibility statement should list:

  • any issues that have not been fixed
  • how users can work around them
  • how you plan to fix them
  • when they will be fixed

Read more about accessibility audits, including how to book one.

Read more about accessibility statements. This includes a sample statement to use as a template.

Product lifecycle

It’s important to build in accessibility from the start of a project, rather than add it in at the end. This approach will save time and money in the longer term.

If you are working with a legacy system, it may not be possible to make it accessible from the start of the project. Run an accessibility audit, list any issues in order of priority and include fixes in the improvements you are making.

Bake in, not bolt on.

Here are the accessibility actions you need at each stage of design and development. If you work in an agile team, you’ll recognise these project phases, but anyone can use this guide.

See: Agile delivery - Service Manual for more information about project phases.

Discovery

Understanding the problem you’re trying to solve, and the people who will use your product.

  • Include users with accessibility needs in your user research.
  • Include the time and resources to make the service accessible in development plans.

Alpha

Testing and prototyping solutions to the problem.

  • Show that you understand accessibility principles.
  • Explore ways of meeting access needs
  • Include access needs in personas
  • Design accessibility into policies, process and interfaces
  • Find out what works and what doesn't
  • Continue user research, including participants with a range of access needs

Beta

Building your product and releasing it while you continue to make improvements. A private beta is only open to a limited number of users. A public beta is open to anyone who needs to use the service.

  • Design according to accessibility principles.
  • Test for accessibility regularly.
  • Act on any user feedback about accessibility.
  • Prepare an accessibility statement to go live at launch.
  • Carry out an accessibility audit, and resolve any issues, before you move from private to public beta. If there are significant changes, you may need to audit again.
  • Continue user research, including participants with a range of access needs.
  • Make sure there is additional support and an alternative route available for users who are unable to use the main service.

Live

Releasing your product to everyone and continuing to support and improve it.

  • Invite and act on any user feedback about accessibility.
  • Mature provision of adjustments and alternatives for people who cannot access the main service
  • Test for accessibility whenever there is a new release or change, and at least once a year.
  • Update the accessibility statement when you fix an outstanding issue or discover a new one, and at least once a year.

Retirement

Closing your product down because it is no longer needed.

  • Make sure all users are aware the service is closing, including people who access it by other routes.
  • If a new service is replacing yours, make sure it is accessible and all users will be supported to use it.

Accessible procurement

Your accessibility responsibilities apply to products sourced from external suppliers too. You are responsible for making sure that suppliers, third parties and subcontractors comply with equality legislation when delivering contracts.

The exception is content that is not

  • funded
  • developed
  • controlled

by your organisation, for example an external website that you link to.

Ask the right questions

Make sure your product meets your accessibility obligations by asking:

Do we have a statutory requirement or other mandatory requirement to use this product?

If you have to use that product for reasons outside of your control and there are no alternatives, it may not be your responsibility to resolve, or resolving it may be considered a disproportionate burden.

Are there alternatives?

Can you justify choosing a less accessible product if there are more accessible alternatives?

Are we using this on our own website or linking to it on another site?

Have you decided to place the content on a platform you control, or are you directing to another platform you do not control?

Is this a bespoke product?

If you are ordering a custom or non standard product, include accessibility in your requirements.

How do you procure accessible services?

Get your procurement team on board from the beginning.

Make accessibility a mandatory requirement.

Make sure your tender and contract documents include meeting the accessibility standard as a requirement.

Engage with accessibility specialists in your department to get contract requirements correct and ask them to sit in on tender panels before entering into new contracts.

Create an accessibility policy. Ask suppliers to sign up to the policy to confirm that they can meet the requirements on the legislation. Do not accept exemptions or limitations.

Your accessibility policy

  1. Make sure your policy asks:
    • Does the product meet the accessibility requirements?
    • Do they have a process for monitoring the level of accessibility of their product during the development lifecycle and post-development?
    • Do those working on the product know how to make accessible systems?
    • Can they provide evidence of how accessibility compliance and testing has been embedded?
  2. Ask for evidence of accessibility, for example:
    • Accessibility Conformance Report, also known as VPAT (Voluntary Product Accessibility Template), showing:
      • workarounds
      • how non-compliant elements will be made compliant
      • how any customisation of the system might impact on accessibility - for example, if the product includes a Content Management System (CMS) does this allow for accessible content authoring
    • An accessibility statement aligned to the requirements of the Public Sector Bodies Accessibility Regulations that includes information about non-compliant elements, workaround and plans for the future.
    • Testing documentation (sometimes called an audit) from an internal or external accessibility specialist aligned to an international standard EN 301 549, or ideally the Web Content Accessibility Guidelines 2.2.
    • Demonstrated operability with the gov.uk list of assistive technologies.
    • Results of testing and/or research with people who have access needs.
    • Do not rely on a VPAT without other evidence to back it up.
  3. Plan out how you will manage accessibility throughout the lifetime of the contract or systems lifecycle. Make sure future versions will be more, not less, accessible.

Tips and resources

Simple things you can do to improve accessibility in your product and awareness in your team. Pick three, one to do today, one for later in the week, and one for later in the month.

  • Discuss accessibility at your next team meeting. What do they think accessibility means? What is each person’s accessibility responsibility?
  • Run emails, documents, templates and presentations you’ve written through the inbuilt Microsoft Outlook accessibility checker and encourage your team to do the same.
  • Test websites you’re procuring and overseeing with an automated accessibility checker such as WAVE, Axe and/or inspect the HTML code to get a rough idea how accessible they are.
  • Ask for an update on accessibility in team meetings.
  • Read the sample accessibility statement and start to think about how yours might look.
  • Sit in on a user research session with a participant who has access needs. If your team doesn’t have a user researcher, ask around—observers and note takers are usually welcome.
  • If you have online forums such as Teams, Slack, Viva Engage or Yammer, join an accessibility channel (for example #accessibility in the UK Government Digital Slack workspace). They’ll answer questions and post useful links. There’s also the Cross-government accessibility community.
  • Find out if your organisation has an Accessibility Champions’ Network (or something similar), and attend their meetings whenever possible. If not, consider starting one.
  • Make increasing accessibility knowledge a learning objective for yourself or someone you manage (with their agreement!).
  • Allocate time and budget for team members to have accessibility training.
  • Visit an Accessibility Lab/Hub to familiarise yourself with assistive technology and better understand user needs. Ask cross-government colleagues if you can access their facilities if you do not have an in-house lab.
  • Review any outstanding accessibility defects on your service and assess whether they can be fixed now.
  • Create a pattern library of reusable elements, for example drop down boxes, that are coded for compliance (and keep it up to date).
  • Log inaccessibility as a risk on your department register.
  • Appoint a person to lead on accessibility, as dedicated and senior as possible, then grow a team around them.

Glossary

A, AA, AAA

Levels of accessibility conformance with WCAG. A is the lowest, AAA is the highest. The minimum for public sector bodies is AA.

Access need

What a user needs to access a product or service. For someone with a visual impairment, this could mean being able to enlarge or change the colour of text so they can read it.

Accessibility maturity

The level of accessibility in an organisation and its products. An accessibility maturity assessment documents areas in which an organisation is doing well and where accessibility can be improved. Read more about the Accessibility Maturity Model (W3C).

ARIA

Accessible Rich Internet Applications: specifications for creating accessible website components.

Assisted digital

Helping users who, for example, do not have access to the internet, or lack confidence in their internet skills, to use an online service. Read more about assisted digital.

Assistive technology

A product that makes it easier, or possible, for users with disabilities to do what they need or want to. Assistive technology for computer and internet users could be screen reader software or a trackball.

CSS

Cascading Style Sheets: the code that tells the web browser how it should display different HTML elements, for example the font size and colour of a header.

Disproportionate burden

Where the time and resources needed to fix an accessibility issue are greater than the benefit of fixing it.

ECNI

The Equality Commission for Northern Ireland (ECNI): enforces the requirement to make public sector websites and mobile apps accessible (making them perceivable, operable, understandable and robust) in Northern Ireland.

EHRC

The Equality and Human Rights Commission (EHRC): enforces the requirement to make public sector websites and mobile apps accessible (making them perceivable, operable, understandable and robust) in England, Wales and Scotland.

HTML

HyperText Markup Language: the code used to define elements of a web page, for example headers, paragraphs and images.

PSBAR

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 regulations that set standards for web accessibility.

W3C

The World Wide Web Consortium: develops standards and guidelines for the web, including accessibility standards.

WCAG

Web Content Accessibility Guidelines: a set of standards published by the W3C.

Widest user need

Designing services so as many people as possible, including those with access needs, can use them.

Contribute

Get involved with GitHub discussions about our styles, components and patterns.