How to Run a Website Accessibility Audit (UK Guide)

Website accessibility should be one of the key considerations when building any best practice, modern website. And yet, we still regularly see sites go live with clear accessibility issues like poor colour contrast and iffy keyboard navigability. 

The good news is that if you’re reading this, there’s a good chance you already understand the value of website accessibility. Perhaps your existing website needs an accessibility audit (and you know it), or you’re currently in the midst of a new website project and want to make sure it’s fully accessible for all. 

In this guide, we’ll take you through what a website accessibility audit involves, how much of it you can do yourself (quite a lot!), when you might want to consider an external expert, and what you should do with the findings that come back. 

If you want to roll back a step, our guide to building an accessible website will give you a broader context on why accessibility matters. And if you’re in the charity sector specifically, we have an accessibility guide for charities that’s just for you. 

What is a Website Accessibility Audit? 

A website accessibility audit is a systematic examination and evaluation of how well a website performs against the leading international standards for accessibility. The gold standard for website accessibility in 2026 is the Web Content Accessibility Guidelines (WCAG) 2.2. 

The goal of a website accessibility audit is to identify and document the barriers that prevent those living with a disability from using your website, and produce a roadmap for fixing them. 

Website accessibility isn’t just an ethical consideration; it’s also a commercial one. 1.3 billion people live with a disability worldwide. Besides, having a clear, easy-to-navigate website is good for everyone. Accessibility isn’t just good for those with a disability. 

Most importantly, an accessibility audit isn’t a one-off exercise in compliance that you can just tick off. Regulations and best practices frequently change, so running a free online checker one time won’t cut it. A comprehensive audit combines automated tooling, manual testing, and - ideally - testing with people who actually use assistive technology day-to-day. 

Depending on the nature of your business and the complexity of your website, it may not be necessary to go the whole nine yards. But you should at least be cognisant of what’s possible and where the limits are. 

Why Run an Accessibility Audit? 

There are 4 reasons why you might want to run an accessibility audit. And the reason you conduct your own will likely be a mixture of each of them. 

Any organisation with a public-facing website should consider running an accessibility audit. The pressure is rightly heaviest on public sector bodies, charities, healthcare, education, and ecommerce, but the underlying obligation is increasingly broad. 

Legal Exposure 

According to the Equality Act 2010, service providers must make reasonable adjustments to avoid discriminating against disabled people. That includes digital services. 

Public sector bodies have stricter obligations under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, which require WCAG-aligned standards and a published accessibility statement. 

The European Accessibility Act, in force since June 2025, has tightened expectations across the EU and is influencing UK practice even where it doesn't directly apply. 

Commercial Reach 

Included in the 1.3 billion worldwide figure above, 16 million people in the UK are disabled, which is roughly one in four. 

The Click-Away Pound Survey has consistently shown that disabled users abandon inaccessible sites and spend their money elsewhere. If your site is hard to use, you’re probably leaving money on the table, and you just don’t know about it. 

Search Visibility 

The same things that make a site accessible - semantic markup, descriptive link text, alt attributes, good structure and headings - also make it easier for search engines and large language models to parse. 

In short, accessibility is an SEO consideration. See our piece on schema markup for SEO and AI search for more on the structural overlap. 

Doing the Right Thing 

And, of course, website accessibility is an important ethical consideration. Most teams we work with consider accessibility because excluding people from their service is wrong. The legal and commercial arguments are rarely the root motivation. 

Before You Start: Scoping the Audit 

Don’t skip ahead. Running tools in isolation won’t give you the fullest picture. 

As with any audit or evaluation of this nature, it’s worth setting out what you want to achieve first, and defining what success looks like. Ask yourself: 

Which standard are you measuring against? For most UK organisations, the answer is WCAG 2.2 at Level AA. Level AAA is going above and beyond; even W3C doesn’t recommend it as a general policy. 

What's the scope? Auditing every page of a huge and complex website isn’t realistic (or affordable). Instead, identify and list out the representative templates of each page type: homepage, article page, product page, checkout flow, contact form, search results, etc… Thinking logically about the scope of your audit should mean that the bulk of your website is represented in fewer examples. 

Live, staging, or both? If you’re working on a new site, don’t wait until launch to audit. Doing it in staging is an opportunity to go live in the best possible position. That said, looking at the live site as users see it gives you the best possible representation of what real users are actually experiencing. To a greater or lesser degree - and where relevant - the best audits cover both. 

Who's doing it? An audit run by someone familiar with WCAG will likely be better and more instructive than one run by a developer learning as they go. Be honest about your team's expertise before deciding what to handle in-house. But also consider website complexity and the specific implications of your own audit, legally, commercially, and ethically. 

Step 1: Automated Accessibility Testing 

Though automated testing does have its limitations, it’s where your accessibility audit should start. But it isn’t perfect and won’t solve everything. 

According to Deque Systems - a global digital accessibility leader advancing digital equality - research, “automated testing identifies 57 per cent of digital accessibility issues.” And while that is a respectable result - and is better than many assume - it shows that automated testing isn’t a silver bullet and manual checks are still often worth the time and effort required. 

Still, at the very least, automated testing will do a fantastic job of flagging those easily detectable, machine-checkable issues like missing alt attributes, empty links, contrast issues, etc. 

Our favourite accessibility tools are: 

• axe DevTools is the industry standard browser extension, free for individual use 
• WAVE by WebAIM, is easy to pick up and good for non-developers 
• Lighthouse is built into Chrome DevTools and gives an accessibility score alongside performance and SEO 
• Pa11y is a command-line tool, good for automating checks in CI/CD pipelines 
• Silktide is a paid platform, suitable for ongoing monitoring across larger sites 

There’s overlap between all of these tools, but try running several against the sample pages you identified in scoping. Should they identify no major issues, still move on to step 2 as many accessibility issues (43% in fact) are less easily picked up through automation. 

Step 2: Manual Accessibility Testing 

By now, you’ve likely identified most of the glaring accessibility issues. But the audit doesn’t end there; many of WCAG’s guidelines can only truly be evaluated with human experience and judgement. 

Keyboard navigation. Go ahead and unplug that pesky mouse. Commit to using only Tab, Shift+Tab, Enter, Space, and arrow keys to navigate your website. Set yourself some key customer journeys to go through using only your keyboard. Can you reach every interactive element? Is the tab order logical? Are focus states visible (a clear outline or highlight on the focused element)? Can you escape your own dropdowns? Are there any keyboard traps (places you get stuck)? 

Heading and landmark structure. Browse the page with a tool like the HeadingsMap browser extension. Does the heading order make sense (H1 > H2 > H3)? Are landmarks (<header>, <nav>, <main>, <footer>) used correctly? A screen reader user relies on these structures to navigate your website. 

Forms. Every input needs a properly associated label (not just placeholder text). Error messages need to be linked to the field they refer to, and announced when they appear. Required fields should be marked in a way that doesn't rely solely on colour. 

Reflow and zoom. Set your browser zoom to 200% and 400%. Does the content reflow into a single column without horizontal scrolling? Is anything cut off or unreachable? WCAG 2.2 requires content to be usable at 400% zoom on a 1280px-wide viewport. 

Colour and contrast. Most of these issues will be caught by the automated tools, but it never hurts to cast your eye over everything. Besides, there’s a chance they will miss text on images, gradient backgrounds, and interactive elements like hover states. Spot-check these manually with a tool like the WebAIM Contrast Checker. It’s also a good idea to check whether any information is being conveyed only by colour - red error states, for instance, should ideally be accompanied by a label or icon. 

Motion and animation. In our experience, this one is frequently missed. Any auto-playing animation longer than five seconds should be pausable. Carousels, video backgrounds, and decorative animations should ideally respect the prefers-reduced-motion system-level accessibility setting. 

Step 3: Assistive Technology Testing 

It should be relatively clear by now, but what you’re trying to do in all of this is to, as much as possible, put yourself in the shoes of those navigating your website through other means. Manual testing with a keyboard complete, you’ll want to move on to a screen reader, which should reveal many of the remaining issues. 

The most popular screen readers globally are: 

• NVDA is a free, globally popular screen reader program for Windows 
• VoiceOver is the screen reader built into macOS and iOS 
• TalkBack is the screen reader built into Android devices 
• JAWS is a commercial and feature-rich screen reader for Windows

If you’ve never used a screen reader before, don’t go straight for JAWS. Instead, pick up your phone and start with either VoiceOver or TalkBack. What to listen for: 

• Does the page title get announced clearly on load? 
• Do image descriptions make sense? 
• Do interactive elements announce their role (button, link, checkbox) and state (expanded, selected, disabled)? 
• Are headings used to navigate, and do they make sense? 
• When something changes on the page - an error appearing or a cart updating - is it announced? 

It goes without saying that you can’t live in the shoes of someone with a disability if you don’t have it yourself. We try to get as close as possible, but you may decide it’s worth the time and investment to test with disabled users who rely on assistive technology every day. 

Organisations like AbilityNet and Digital Accessibility Centre offer this as a service. 

Step 4: Creating an Audit Report 

Don’t just create a Word document of screenshots and exports from the tools above. If your business has any complexity at all, the best course of action is to create an audit report that a developer can easily act on and that a non-technical stakeholder can understand. 

As much as anything, we find that adopting a structured approach to audit creation and communication makes buy-in far more likely. And it’s usually a good opportunity to recap the legal and commercial benefits of undertaking further accessibility work and remediation. 

Document each issue with: 

• Description - describe the problem clearly 
• Location - capture the URL alongside a screenshot 
• WCAG criterion - document the failed criterion 
• Severity - critical/high/medium/low 
• Recommended fix - propose a solution 

Assuming you’re auditing a number of page templates, you’ll probably want to group the identified issues to aid communication. Don’t individually log the same issue 40 times just because it appears on 40 pages if they all use the same template. 

Then, use a prioritisation matrix to clear the path forward: 

• Critical-High / Low Effort | Immediate fix (e.g. missing alt text) 
• Critical-High / High Effort | Planned fix (e.g. navigational issues) 
• Medium-Low / Low Effort | Weekly maintenance (e.g. form default text) 
• Medium-Low / High Effort | Next release or major update (e.g. CMS fixes) 

Step 5: Remediation and Re-Testing 

Assuming you have buy-in and the green light - not always given, in our experience! - it’s now time to start fixing some of those issues you’ve identified. 

Per the matrix above, start with the high-impact, low-effort issues. 

These are typically easy to deal with, and are often some of the most obvious issues. Things like colour contrast on links or images. Then, start working your way down your priority list. 

Be realistic; not every issue will be immediately solvable. Some may even require significant dev work and will need to be scheduled in with either your internal resource or external website support team. 

Re-test as you go. Fixed components need to be rechecked with the same tools and methods used in the original audit. Your fix may not be as effective as you think, or the fix you introduce could break something else, somewhere else. 

If applicable, when you’ve completed your remediation work, update your accessibility statement. If you don’t have one, consider putting one in place. The GOV.UK guidance on accessibility statements is a good template. 

Ongoing Accessibility Auditing 

Websites require maintenance. And that’s as true of accessibility testing as it is of the CMS and plugin updates that keep your site secure and performing well. 

Treat your audit as a snapshot. Your site is likely always changing with new content and features. Not to mention, global accessibility regulations and standards are always being tweaked and updated. 

Our recommendation is: 

1. To adopt an automated testing schedule against key pages
2. Accessibility checks in CI/CD that flag issues before code merges 
3. Review editorial guidelines for content teams: alt attributes, heading hierarchy, link text conventions, video caption requirements 
4. Introduce periodic, deeper audits, typically annually or after major changes/releases 

Assuming any initial audit you carried out was good and thorough, additional maintenance should be a much easier commitment to make going forward. 

Can I Do an Accessibility Audit Myself? 

This is something of a frequently asked question. And our recommendation typically depends on a number of factors. 

DIY accessibility audits work especially well when you have someone on your team with familiarity with the tools and requirements accessibility auditing demands. 

Also consider the risks involved; if there’s not too much to worry about legally, commercially, and reputationally, then DIY could be the way to go. 

A motivated developer or content lead with time to learn the tools and methods can produce a useful audit, particularly for small to mid-sized sites that aren’t overly complex. 

Bringing in specialists makes most sense when your site is large or complex, the legal exposure is high (public sector, healthcare, financial services), or you need a third-party report for compliance or procurement reasons. 

External auditors aren’t inexpensive, but they will likely catch things internal teams miss, partly through expertise and partly because they're not blind to the patterns the in-house team has lived with for years. 

You could even consider a hybrid approach. Take it as far as possible internally, especially through the use of automated tools and more routine manual testing. Then, work with an external supplier to run a deeper audit and user testing programme.