Accessibility audit checklist

This process is for service owners and technical teams who want to conduct an accessibility audit on their service, in line with the WCAG 2.1 guidelines. The audit process is compatible with the approach taken in the WCAG Website Accessibility Conformance Evaluation Methodology (WCAG-EM).

It's maintained for NHS Digital, but is applicable to all public sector bodies.

Full compliance with this checklist does not guarantee full compliance with the WCAG 2.1 standards, and you should seek expert input where necessary.

You should follow a structured audit approach, starting with a defined scope. You then explore this scope, define your test sample, and conduct a structured test.

Finally, you document your findings in a report.

The first step is to define the scope of the audit. This means which site or product you are testing, and what that involves.

Examples could be:

• the NHS Digital website
• the Organisation Data Service portal

Where a user journey crosses more than one site, then the complete journey should be tested, but the test sample may be constrained in order to align with organisational responsibility – see Step 3 for more detail. 

We are testing against the AA standard of WCAG 2.1. This requires meeting both the A and AA standard, as the standards are cumulative.  

We are testing for: 

• supported versions of main browsers, in a variety of screen widths 

• text-only browsers as a proxy for accessibility tools such as braille readers 

• screen readers, using supported browsers 

We will test against the NHS Digital Standard for web products, and against the GDS service manual for accessibility.

We will also check if the site meets the legislative requirements of the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 as regards to accessibility statements. 

In this step, you need to identify how the site works, and what journeys are being completed. This will be in conjunction with a subject matter expert from the team responsible for the site. 

You will find: 

• all the different elements and patterns used on the website such as different navigation elements, content elements, or content types  

• the journeys which are expected to be completed through the site 

• the varying technologies in use 

Use this information to create a list of essential functionality. This is the list of what the website must do in order to be considered functional and useful.  

You should also identify any pages particularly relevant to users with accessibility needs, such as the accessibility page, contact details, and any 'how to use this website or tool' information. This could also include pages specifically targeted at users with disabilities.

Lastly, you can run automated crawler scans over the site, where possible (it may not be possible on sites behind a login, or on HSCN) to identify areas with known problems. 

This step involves defining what pages and journeys will be tested. 

By using a structured approach, you can help ensure that all parts of your site are compliant.

The size of the sample will be dictated by the size and complexity of your site. A single-page application may have the entire site/journey tested, but a large site with thousands of pages will have a sample tested.

Structured sample

In the structured sample, you should include pages which include representative content identified in Step 2 exploration.  

This means that there should be at least one page which contains every type of: 

• element available within the essential functionality 

• technology being used 

• navigation being used 

You should also include each of the critical journeys identified, or a sample of these if there are too many.  

This means you will test the end-to-end journey that a user is expected to complete (such as submitting a return, or applying for a service).  

Each test in this instance may be scope limited in order to align with your internal areas of responsibility, but this will be made clear, as will external failure dependencies (such as the site in scope test complies, but users must use a non-compliant site in order to complete their task, making it an end-to-end failure) 

Random sample

Where the structured sample doesn't cover the entire site, you should add a randomised sample of pages to be tested.  

You should test random pages equal to 10% of the number of structured pages checked, or at least 10, whichever is higher. 

On some very small sites, or sites where the structured tests represent a very high proportion, it may not be appropriate to add a random sample. 

You are now ready to conduct an audit on the pages identified. 

This will consist of: 

• a technical conformance check, following our detailed checklist 

• the use of automated tools appropriate to the site 

Where possible, you should also seek to test the service for real with some users of assistive technology. We recommend that you complete and fix the technical elements before you do user testing, as otherwise you may be incurring significant cost to find out about failures you could have identified yourself in the technical checks.

Each page or process step will be checked, including adding real data to forms. Both success and failure states will be tested. 

Each finding should be documented, to include whether the tested item Passed or Failed. 

Where a Fail is recorded, the reason or reasons for failure will be recorded. 

For some tests, there are 'Warning' statuses, which indicates that the page may have some problems, but that compliance is not a two-state pass/fail. This includes areas such as ease of understanding, and simplicity of written language, which have a subjective element. 

You should compare the results from the structured and random samples. Where the random sample shows failures not present in the structured sample, you should consider returning to Step 3 to widen the sample. 

Your report should detail:

• the number of pages tested which passed the agreed standard 

• the number of pages tested which failed the agreed standard along with a summary of the main reasons causing failure

• any priority findings and recommendations in order to meet the standard 

• the form of words which will be required on the accessibility statement going forward (whether the site complies, partially complies, or does not comply)

We recommend that this audit is completed by a technically-aware member of staff, who is likely to require the following items.

Hardware

You will need:

• a computer with multi-screen setup (ideally 3, minimum 2)
• screens large enough to use developer sidebars
• an Apple iPhone
• a modern Android phone

Software

You will need:

• multiple standard browsers installed, including Chrome, Edge, and Firefox
• Lynx browser (a text-only browser, good as a proxy for many accessibility technologies)
• Safari browser configured on the iPhone

Chrome browser needs to be configured with:

• developer mode
• ARC toolkit toolbar
• Google Lighthouse toolbar
• Quick Javascript switcher extension
• alt text testing extension
• Microdata.reveal
• high contrast extension
• NVDA screen reader