Evaluate how accessible your website is and make a plan to fix any issues.

New regulations came into force on 23 September 2018 which say that all public sector websites or apps must:

  • meet accessibility standards
  • publish an accessibility statement

The best way of doing this is:

  1. Check your website or app for accessibility problems.
  2. Make a plan to fix any accessibility problems you find, within reason.
  3. Publish your accessibility statement.
  4. Make sure new features are accessible.

There’s guidance on who the regulations apply to if you’re not sure.

The full name of the new regulations is the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

Deadlines

If you create a new public sector website on or after 23 September 2018, you need to meet accessibility standards and publish an accessibility statement by 23 September 2019. You will then need to review and update your statement regularly.

For existing websites (published before 23 September 2018) the deadline is 23 September 2020. In some circumstances, you might need to do things earlier than 2020 for existing websites.

If you make substantial changes to the code, for example to create new features, or if you create a subdomain with its own distinct codebase, it’s likely that these will need to be fully accessible from 23 September 2019 (the same deadline as for new websites).

Mobile apps need to be accessible by 23 June 2021.

There are a lot of steps involved, so allow time to work through them. Check for accessibility problems as soon as you can, so there’s plenty of time to plan what you’ll do about the problems you find.

1. Decide how to check your website or app for accessibility problems

The first thing to do is to check your website or app for accessibility problems.

This doesn’t mean checking every single page. Instead you need to check a representative sample that captures the variation in content and functionality that your website or app has. By identifying problems in a sample, you should then be able to fix any issues you identify across the whole website or app.

There are a few different ways of checking your sample. Use a process of elimination to decide which method is appropriate for your organisation. In some situations you might use a combination of methods.

Every method involves checking your sample against the international WCAG 2.1 AA accessibility standard – in a different way depending on the resources that your organisation has.

Some types of content are exempt from meeting accessibility standards – you won’t need to include those in your sample.

Method 1. Do a detailed check yourself

If somebody within your team or organisation has the technical skills to do it, they should do a detailed check to see if your sample content and functionality is WCAG 2.1 AA compliant.

Method 2. Pay a third party to do a detailed check for you

If there’s nobody in your organisation with the skills to check your content and functionality is WCAG 2.1 AA compliant, you can pay a third party to do a detailed check (often known as an audit) instead.

They’ll tell you what needs fixing and – once you’ve made the fixes – can audit your website again to check it’s accessible. You can also ask them to prioritise and fix some or all of the issues.

You should expect to pay a third party up to £1,300 a day. The number of days an audit will take depends on the complexity of your website. A small website with static pages might only take 1 to 3 days to audit. This means it could cost roughly £1,300 to £4,000.

It’s more difficult to estimate how long an audit of a large website with complex code and functionality would take. You may need to budget for anything between 5 and 20 days. For example, an audit that takes 20 days could cost £26,000.

You’ll also need to budget for the cost of fixing problems and then retesting things. The time it takes to fix things can vary. A re-audit normally takes about half the time of the original audit.

There’s guidance on choosing a supplier and writing an audit brief in the UK government Service Manual.

Method 3. Do a basic check if a detailed WCAG 2.1 check is a disproportionate burden

If you can’t reasonably afford to pay an external supplier to do a detailed WCAG 2.1 evaluation for you, you can judge that it would be a ‘disproportionate burden’. This means a burden or cost that is too much for your organisation to reasonably bear.

For example, if an external supplier would charge £10,000 for a detailed check but your yearly budget after essential running costs is £2,000, you could argue it would be a disproportionate burden to pay for the detailed check.

In this case, you can do a basic check for accessibility without any technical knowledge.

If your organisation is very small, you might want to find a volunteer with a basic knowledge of websites to help you.

Using a combination of methods

If you’ve got a complex collection of websites but limited resources, you might use more than one method to check for accessibility problems. Allocate your resources so you’re making the biggest difference to your users.

For example, you might not have the budget to pay an auditor to check your entire collection of websites. But you could reasonably afford to pay a third party to check your most important, most used content. In this case you could:

  • use method 2 (pay an auditor) to do a detailed check on the most important content
  • assess that it’s a disproportionate burden to pay for a detailed check on the rest of your websites
  • use method 3 (do a basic check) for the rest of your content

Assessing if a detailed check is a disproportionate burden

If you want to establish whether a detailed check is a disproportionate burden, you’re legally required to carry out an assessment.

You need to weigh up, roughly speaking:

  • the burden that paying for a detailed check would put on your organisation
  • the benefits of making your website or app accessible

In your assessment, you need to think about:

  • your organisation’s size and resources
  • the nature of your organisation (for example, do you have services aimed at people who are likely to have a disability?)
  • how much a detailed check would cost and the impact that would have on your organisation
  • how much users with a disability would benefit from you making things accessible

You might judge that the benefits of making things accessible wouldn’t justify the impact on your organisation. In that case, you can claim it wouldn’t be reasonable for you to do a detailed check because it’s a disproportionate burden.

You shouldn’t take things like lack of time or knowledge into account in your assessment – or argue that a detailed check is a disproportionate burden because you haven’t given it priority.

2. Make a plan to fix any accessibility problems you find

Once you’ve done an accessibility check and identified any problems in your sample, you need to make a plan to fix those problems across the whole of your website or app.

This involves talking to people who know about the different elements of your website so you can:

  • estimate how long things will take to fix
  • work out how difficult each fix might be

Try to at least talk to:

  • your suppliers, about the technology behind your website
  • developers who know about the code for your website
  • content editors, publishers or people who edit the text and documents on your website

Start by focusing on barriers that are easy to fix. Think about the impact of each thing you’re fixing to help you decide on a priority order. For example, it’s probably of more benefit to your users that your essential services meet accessibility standards than blog posts about out-of-date campaigns.

If you’ve used a third party to check your website or app, they can help you to prioritise how to fix the problems they find, and fix the more complex things for you. But you’ll probably be able to fix some of the simpler problems yourself, like making sure there is a transcript for any audio content.

Build accessibility improvements into your processes. If you’re making frequent code deployments, consider building accessibility improvements into your longer term planning – for example, your quarterly roadmap – rather than for every deployment.

Decide if anything is a ‘disproportionate burden’ to fix right now

You might decide that some problems would be a ‘disproportionate burden’ for your organisation to fix at the moment. Like when you were deciding how to check your website for accessibility problems, this means a burden or cost that is too much for your organisation to reasonably bear when weighed up against the benefit it would bring to people with a disability.

As before, if you want to establish whether something’s a disproportionate burden for your organisation, you’re legally required to carry out an assessment.

You need to weigh up, roughly speaking:

  • the burden that paying for a detailed check would put on your organisation
  • the benefits of making your website or app accessible

In your assessment, you need to think about:

  • your organisation’s size and resources
  • the nature of your organisation (for example, do you have services aimed at people who are likely to have a disability?)
  • how much making things accessible would cost and the impact that would have on your organisation
  • how much users with a disability would benefit from you making things accessible

You might judge that the benefits of making things accessible wouldn’t justify the impact on your organisation. In that case, you can claim it wouldn’t be reasonable for you to do a detailed check because it’s a disproportionate burden.

You shouldn’t take things like lack of time or knowledge into account in your assessment – or argue that a detailed check is a disproportionate burden because you haven’t given it priority.

Talk to your legal adviser if you’re not sure what to do.

If you judge that some things would be a disproportionate burden to fix, you need to say what these things are in your accessibility statement.

Remember that even if you judge some fixes are a disproportionate burden, you’re still legally required to make reasonable adjustments for people with disabilities when they’re needed – for example, by providing the information they need in alternative, more accessible formats.

Also bear in mind that just because something’s a disproportionate burden now, doesn’t mean it will be forever. You should review your assessment whenever there’s a change in any of the factors that you took into account.

Examples of when you might claim disproportionate burden

You’re less likely to be able to claim disproportionate burden for services that are specifically aimed at people with a disability, like ‘apply for a Blue Badge’.

This would also likely apply to services like ‘register to vote’ or ‘find a job’. The benefits of making things like these accessible clearly outweigh the cost – because they allow everyone to participate in society and help ensure people with a disability are not at a disadvantage when using those services.

It’s more likely you’d be able to argue that making content like marketing material or out of date campaigns accessible would be a disproportionate burden. Not being able to access content like this doesn’t prevent you from doing important tasks in your life.

ExampleWhen you first evaluated your website’s accessibility, you did a disproportionate burden assessment and decided that fixing some of the issues was a disproportionate burden. You’re replacing the technology behind your website, which creates an opportunity to make it more accessible. You might no longer be able to argue that this is a disproportionate burden.

ExampleEvery academic year, some of your content is updated as course requirements change. If it’s not due for an update, you might be able to say that making it accessible is a disproportionate burden because you can only afford to update it once a year. When it’s time to update the content anyway, you’re less likely to be able to argue that it’s a disproportionate burden.

Things you might not need to fix

You don’t need to fix the following types of content because they’re exempt from the accessibility regulations:

  • audio and video – although you’ll need to make any new pre-recorded audio and video accessible from September 2020 onwards
  • heritage collections like scanned manuscripts
  • PDFs or other documents published before 23 September 2018 – unless users need them to in order to use a service, for example a form that lets you outline school meal preferences
  • maps – but you’ll need to provide an accessible alternative where appropriate
  • third party content that’s under someone else’s control if you didn’t pay for it or develop it yourself – for example, a third party payment system or social media ‘like’ buttons
  • content on intranets or extranets published before September 2019 (unless you make a major revision after that date)
  • archived websites if they’re not needed for services your organisation provides

You’ll need to explain in your accessibility statement that you haven’t made things like this accessible because they are exempt.

Create a roadmap

Once you’ve worked out your priorities, it’s helpful to make a high level plan or roadmap to show how you’ll meet accessibility standards.

This should be a living document that you update regularly. Base your plans around any opportunities you’ll have to improve the accessibility of your website or app. For example, if you’re appointing a new supplier or making particular changes to a section of your website.

3. Publish your accessibility statement

Once you’ve made your plan, you need to to publish an accessibility statement to explain how accessible your website or app is.

A lot of the people looking at your statement won’t be accessibility experts, so make sure it’s written in plain English that everyone can understand. This will also make it easier for users with a disability (who might have a cognitive impairment or learning disability) to understand how they can best use your website or app.

Your statement needs to cover:

  • whether your website or app is ‘fully’, ‘partially’ or ‘not’ compliant with accessibility standards
  • if it’s not fully compliant, which parts of your website or app aren’t currently meeting accessibility standards and why (for example, because they are exempt or it would be a disproportionate burden to fix things)
  • how people can get alternatives to content that’s not accessible to them
  • how to contact you to report accessibility problems – and a link to the government website that they can use if they’re not happy with your response.

You should describe your website or app as fully compliant if it meets accessibility standards in full, partially compliant if it meets most requirements, and not compliant if it doesn’t meet most of the requirements.

You could also include information like how you evaluated your website or app’s accessibility and your plan to fix any accessibility problems.

You must publish an accessibility statement by:

  • 23 September 2019 for new websites created from 23 September 2018
  • 23 September 2020 for existing websites
  • 23 June 2021 for mobile apps

For websites, publish the statement as a normal HTML page. Make sure it’s linked to from every other page on the website, in a prominent place like the website footer. For mobile apps, make the statement available in the app store, on your website or both. Make sure it’s in an accessible format that everyone can use.

We’ve produced a sample accessibility statement to help you write yours. Some of the wording is legally required, so make sure you include that in your statement. You can adapt the rest of the wording to suit your organisation.

The sample statement is based on the model statement published by the EU, which sets out what information you have to put in an accessibility statement – and our own research into what’s useful to disabled website users.

You need to review and update your statement regularly (at least once a year).

4. Make sure new features are accessible

Make sure any new content or features that you publish meet accessibility standards (unless it’s something that’s exempt). If they don’t, you’ll have to go back and fix things.

The people who edit your website or app have a responsibility to make content and features accessible. This means:

Make sure you have the processes and software to enable people to do these kinds of things easily. It’s much easier to make things accessible from the start than it is to go back and fix them.

Get support or advice

Depending on where you work, you may be able to get support from:

The Government Digital Service is researching what guidance and support public sector organisations need in order to meet accessibility requirements. If you’re interested in taking part in this research, contact [email protected].

Published 17 May 2019
Last updated 23 August 2019 + show all updates

  1. Added link to evaluation methodology for organisations who don’t have access to an accessibility expert and can’t pay a third party to do an evaluation.
  2. First published.

Contents