Web Accessibility Audit: A Step-by-Step Guide for UK Businesses

Most website owners assume that if a site looks good and loads quickly, it works for everyone. It doesn’t. Around 16 million people in the UK live with a disability, and a significant proportion rely on assistive technologies, such as screen readers, keyboard navigation, and voice control, to access the web. A web accessibility audit identifies exactly where your site fails users with disabilities, what needs to change, and how urgently. It also tells you where you stand against WCAG 2.2, the current international standard, and what UK law actually requires of you.

This guide walks you through conducting a website accessibility audit from start to finish: defining your scope, selecting testing methods, interpreting your findings, and turning your report into a remediation plan. We cover the UK legal framework, the difference between automated and manual testing, the five-step audit framework used by accessibility specialists, and what a complete audit report should contain.

What Is a Web Accessibility Audit?

A web accessibility audit is a structured evaluation of how well a website supports users with disabilities. It measures your site against the Web Content Accessibility Guidelines (WCAG), the internationally recognised technical standard published by the W3C’s Web Accessibility Initiative, and identifies barriers that prevent users from perceiving, operating, understanding or interacting with your content.

WCAG is organised around four principles, referred to by the acronym POUR: content must be Perceivable, interfaces must be Operable, information must be Understandable, and content must be Robust enough to work reliably with assistive technologies. Every WCAG success criterion maps back to one of these four principles.

The Three Levels of WCAG Conformance

WCAG uses three conformance levels. Level A covers minimum requirements. Level AA addresses the barriers affecting the broadest range of users and is the target most organisations aim for to meet legal obligations. Level AAA is the most stringent level and is rarely achievable across an entire site. For most UK businesses, WCAG 2.2 Level AA is the relevant target.

What Changed in WCAG 2.2

WCAG 2.2 was published in October 2023 and added nine new success criteria, most focused on mobile usability and cognitive accessibility. The changes most likely to affect SME websites include minimum target sizes for interactive elements (buttons and links must now be at least 24×24 CSS pixels), a requirement that keyboard focus indicators are clearly visible, and new rules ensuring that authentication processes do not rely on cognitive function tests such as character transcription or image puzzles.

Many older audit reports and online guides still reference WCAG 2.1. If you are commissioning an audit or reviewing existing documentation, confirm explicitly that it covers WCAG 2.2, as the additional criteria are now the benchmark for compliance in UK government procurement and are expected to become the standard for private sector guidance as well.

Automated vs Manual Testing: The Core Distinction

Automated accessibility testing tools Axe, WAVE, and Google Lighthouse scan your HTML and CSS and flag issues against known WCAG success criteria. They are fast and useful for an initial baseline. The limitation is that automated tools reliably catch only around 30–40% of WCAG failures. The majority of real-world accessibility barriers require human judgement to identify: whether alt text is actually meaningful, whether a keyboard navigation sequence makes logical sense, or whether content announced by a screen reader communicates the same information as what a sighted user sees.

A credible web accessibility audit always combines both approaches. Running only an automated scan and declaring a site compliant is not a defensible position under UK law and will miss the majority of practical barriers your users face.

The UK Legal Framework for Web Accessibility

Understanding which legal obligations apply to your organisation is the first step in scoping an audit. The UK has two distinct frameworks that affect different types of organisations differently.

The Equality Act 2010 and Private Sector Obligations

The Equality Act 2010 applies to all organisations in England, Scotland and Wales that provide goods, services or facilities to the public. Under the Act, service providers have a duty to make “reasonable adjustments” to remove barriers that put disabled people at a substantial disadvantage. Websites fall within scope. The Act does not specify a technical standard, but courts and tribunals have consistently looked to WCAG as the appropriate benchmark for what constitutes a reasonable adjustment in a digital context. For most private-sector businesses, including SMEs across Northern Ireland, Ireland and the rest of the UK, WCAG 2.1 AA has been the de facto minimum standard. With WCAG 2.2 now published, that bar is shifting.

Public Sector Bodies Accessibility Regulations 2018

The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 (PSBAR) impose stricter requirements on public sector organisations. Covered bodies must meet WCAG 2.1 AA, publish an accessibility statement, and monitor compliance on an ongoing basis. Enforcement in the UK is the responsibility of the Central Digital and Data Office (CDDO). Non-compliance can result in formal enforcement action. Organisations working with public sector clients should be aware that their digital products, websites, applications, and intranets may fall within the scope of these regulations or their clients’ compliance obligations.

The Business Case Beyond Legal Compliance

Disabled consumers in the UK represent significant purchasing power. Scope’s research puts the combined spending power of disabled people and their households at over £274 billion annually. Inaccessible websites exclude these users and represent a direct commercial loss. There is also a consistent overlap between accessibility improvements and general usability gains: better heading structure, clearer navigation and descriptive link text benefit all users, not only those using assistive technologies.

The Five-Step Web Accessibility Audit Framework

A professional website accessibility audit follows a structured sequence. Skipping steps, particularly moving directly to automated scans without defining an audit sample, produces incomplete findings that are difficult to act on.

Step 1: Define the Audit Sample

For most websites, auditing every page individually is not practical. Instead, a representative sample is selected to reflect the full range of page types, templates and user journeys on the site. A typical sample for an SME website would include the homepage, the primary navigation structure, at least one service or product page, a contact or enquiry form, a search results page, where present, and any transactional pages such as checkout or booking flows.

If a template-level issue is identified on one page built from a shared component, it is likely to affect all pages using that template. Identifying and fixing it at the template level resolves the issue site-wide. Document your sample selection before you start, so the scope of the findings is clear in the report.

Step 2: Automated Baseline Scanning

Run automated scanning tools across your selected sample. Axe DevTools, WAVE and Google Lighthouse are the most widely used options. Axe produces detailed issue descriptions with direct references to WCAG success criteria. WAVE provides a visual overlay that makes spatial issues easier to interpret. Lighthouse integrates with Chrome DevTools and gives an overview score alongside performance and SEO data.

Export and document all findings before moving on. Automated results typically surface issues, including missing image alt text, insufficient colour contrast ratios, absent form labels, missing landmark regions, and incorrect heading hierarchy. These are the most straightforward fixes and should be addressed as a baseline before manual testing begins.

Step 3: Manual Code and Keyboard Review

Work through your audit sample using keyboard-only navigation: tab through interactive elements, use enter and space to activate controls, and verify that the visual focus indicator is always visible and never lost. Check that the tab order follows a logical sequence that matches the page’s visual layout.

In the HTML, verify that semantic markup is used correctly. Headings should follow a proper hierarchy — one H1 per page, H2 for major sections, H3 for subsections. Landmark regions (header, nav, main, footer) should be present and used consistently. Links should have descriptive text that makes sense out of context; “click here” and “read more” fail WCAG regardless of the surrounding context. Forms should have labels explicitly associated with their inputs, not just visually adjacent text.

Step 4: Assistive Technology Testing

Testing with real screen readers is the step that separates a surface-level scan from a substantive audit. The most commonly used screen readers are NVDA (free, Windows), JAWS (commercial, Windows) and VoiceOver (built into macOS and iOS). Testing with NVDA on Chrome on Windows and VoiceOver on Safari on iOS covers the majority of real-world assistive technology use for SME website audits.

Navigate the audit sample using each screen reader. Check that images convey meaningful information through their alt text, that dynamic content changes (such as form validation messages) are announced to the user, that ARIA attributes are used correctly, and that the reading order announced by the screen reader matches the page’s logical structure.

Step 5: Prioritised Remediation Reporting

The output of a web accessibility audit is a structured report, not a raw export from a scanning tool. Each identified issue should include the WCAG success criterion it fails, a severity rating (critical, serious, moderate or minor), the specific location on the site, a description of the barrier it creates for users with disabilities, and a clear remediation instruction for the development team.

Organise issues by severity. Critical failures, those that make core functionality completely unusable for assistive technology users, require immediate attention. Serious issues should be addressed in the next development sprint. Moderate and minor issues can be scheduled into a longer-term roadmap. This prioritisation makes the report actionable and allows organisations to make meaningful progress even when a full site overhaul is not immediately feasible.

Running a Website Accessibility Audit: Tools and Techniques

The right combination of tools varies depending on the depth of the audit required, but a small number of reliable options cover most SME website audits.

Automated Tools: What to Use and When

For a first-pass audit or a quick internal review, Google Lighthouse is the most accessible starting point: it is built into Chrome DevTools, requires no setup, and produces results across accessibility, performance and SEO simultaneously. For more detailed output, Axe DevTools provides richer WCAG-referenced findings and is available free as a browser extension. WAVE is useful when you want to visualise issues overlaid on the page itself, making it easier to present findings to non-technical stakeholders.

For organisations auditing at scale, commercial tools such as Siteimprove, Silktide and Monsido provide crawl-based scanning with reporting dashboards. These are generally more relevant to larger organisations than to SMEs conducting an initial compliance review.

Manual Testing: Key Elements to Check

A manual accessibility check for an SME website should cover the following areas at a minimum.

Images: All non-decorative images have meaningful alt text. Decorative images use empty alt attributes (alt=””) to instruct screen readers to ignore them.

Colour contrast: Body text meets a 4.5:1 contrast ratio against its background. Large text (18pt or 14pt bold and above) meets 3:1. This applies to text in images as well as HTML text.

Keyboard navigation: All functionality is accessible via keyboard alone. No keyboard traps exist that prevent focus from leaving a component.

Form labels: Every form input has a programmatically associated label. Error messages are specific, visible, and not conveyed solely by colour.

Heading structure: The page has exactly one H1. Headings follow a logical hierarchy without skipping levels.

Link text: Links are descriptive and make sense when read in isolation, without relying on surrounding context.

Videos and audio: Video content has synchronised captions. Audio-only content has a transcript. Captions include descriptions of relevant non-verbal sounds.

Interactive elements: Buttons, modals, dropdowns and custom UI components are keyboard operable and use ARIA attributes correctly where native HTML is insufficient.

Target size: Clickable elements meet the WCAG 2.2 minimum of 24×24 CSS pixels, with 44×44 pixels as the recommended comfortable target for mobile.

Authentication: Login and verification processes do not require users to solve cognitive puzzles or transcribe characters unless an accessible alternative is provided.

Accessibility and SEO: The Technical Overlap

One reason a website accessibility audit often produces immediate SEO improvements is that the two disciplines share significant technical ground. Descriptive alt text improves image search indexing. A logical heading hierarchy makes it easier for search engines to understand a page’s structure. Descriptive link text improves internal link equity. Accessible forms with properly labelled fields are less likely to produce rendering errors that affect crawl coverage. When ProfileTree conducts technical SEO reviews for clients, accessibility failures frequently appear in the audit findings because they are treated as usability problems that affect both human users and search engine crawlers.

Addressing Accessibility Across Different Disabilities

A website accessibility audit covers a broad range of user needs. Understanding how different disabilities interact with common website structures helps both interpret audit findings and brief developers on remediation.

Visual Impairments: Screen Readers and Low Vision

Users who are blind typically navigate the web using screen readers, which convert on-screen text and semantic HTML to audio output. For these users, the quality of alt text for images is not a cosmetic consideration; it is the image’s entire content. Whether a button is marked up as a native button element or a styled div determines whether a screen reader identifies it as interactive. Users with low vision may use screen magnification software, which can break layouts that rely on fixed pixel widths or that do not reflow correctly at high zoom levels.

Motor and Cognitive Impairments

Users with limited fine motor control may rely on keyboard navigation, switch access devices, or voice control software such as Dragon NaturallySpeaking. For these users, the keyboard operability of every interactive element is critical, as is sufficient spacing between click targets to prevent accidental activation. Cognitive accessibility, clear language, consistent navigation, predictable page behaviour and simple authentication are addressed by WCAG 2.2’s newer criteria and are the areas most frequently overlooked in basic automated audits.

Deaf and Hard-of-Hearing Users

The primary requirement for deaf users is that all audio and video content is accessible in text form. Captions must be synchronised with dialogue and include descriptions of relevant non-verbal sounds. Transcripts must be available for audio-only content. For organisations that use video as a content marketing channel, which covers a significant proportion of SME websites, ProfileTree designs and develops captioning, which is often the single most impactful accessibility improvement. Video production workflows that build captions as a standard deliverable rather than an afterthought are considerably more cost-effective than retrofitting them afterwards.

From Audit Findings to an Accessibility Remediation Plan

An audit report with no clear remediation path is of limited value. Converting findings into a structured plan requires matching each issue to the right team, estimating effort, and setting realistic timelines.

Categorising Issues by Severity and Owner

Critical and serious issues should be addressed before new development work begins if they affect core user journeys such as contact forms, checkout flows or login processes. Assign each issue to a clear owner, typically a developer for code-level fixes, a content editor for alt text and heading corrections, or a designer for colour contrast and layout revisions. Issues identified in shared templates or component libraries represent the highest-value fixes: a single change resolves the problem across every page that uses that component.

Building Accessibility Into Ongoing Web Development

The most effective way to manage accessibility long-term is to integrate it into development and content workflows rather than treating it as a periodic audit exercise. This means including accessibility acceptance criteria in user stories, running automated checks as part of continuous integration pipelines, and ensuring that anyone producing content, writing copy, uploading images, and embedding video, understands the basic accessibility requirements for their role. Digital training that covers accessible content creation is one of the practical ways ProfileTree supports SME teams in building these habits into day-to-day work, rather than relying solely on external audits to catch problems after they are published.

Writing an Accessibility Statement

Public sector bodies covered by PSBAR are legally required to publish an accessibility statement that documents known issues, their impact and the timeline for remediation. Private sector organisations are not currently required to publish one, but doing so is good practice: it demonstrates transparency, provides a clear point of contact for users with disabilities, and signals to regulators and customers that accessibility is actively managed. An accessibility statement is not a declaration of perfection — it is an honest account of your current position and your plan to improve it.

How Much Does a Website Accessibility Audit Cost?

Costs vary considerably depending on the type of audit, the size of the site, and who performs it. The following ranges reflect typical UK market pricing for SME websites, though these will vary by agency and scope.

An automated-only scan delivered as a report with no manual testing component typically costs between £200 and £800 for a small-to-medium site. This is a starting point only and should not be used as compliance assurance. A combined automated and manual audit covering a representative page sample, including keyboard testing and screen reader evaluation, typically costs between £1,500 and £5,000 for an SME website, depending on site complexity and the depth of assistive technology testing. Full audits of large or complex sites, e-commerce platforms, web applications, and sites with extensive dynamic content can cost considerably more.

For organisations building a new website rather than auditing an existing one, working with a development team that builds to WCAG 2.2 AA by default is significantly more cost-effective than retrofitting accessibility after launch. The economics of building it in from the start are straightforwardly better than auditing your way back to compliance after the fact.

Maintaining Accessibility Over Time

A web accessibility audit is not a one-off exercise. Sites change, new content is added, templates are updated, third-party scripts are integrated, new features are built, and each change introduces the potential for new accessibility barriers. Maintaining compliance requires an ongoing process.

Routine Audits and Monitoring

For most SME websites, an annual accessibility audit provides a reasonable monitoring cadence. Audits should also be triggered by any major redesign, template change or significant new feature release. Between formal audits, automated monitoring tools can run scheduled scans and alert teams to regressions—for example, if a CMS update changes site-wide heading markup or if a new image upload workflow bypasses alt text requirements.

Accessible Content as Standard Practice

The strongest long-term accessibility posture comes from building accessible practices into content creation workflows from the start. This means anyone uploading images adds alt text as a matter of routine, anyone embedding video checks for captions, and anyone writing copy uses heading tags semantically rather than for visual styling. These habits are straightforward once established, but they require initial training and clear editorial standards.

Feedback Channels and Continuous Improvement

Publishing accessible contact information and inviting direct feedback from users with disabilities is both a legal best practice recommendation and a practical source of real-world insight. Automated tools and expert manual audits can miss issues that a real user encounters in their specific assistive technology setup. A clearly signposted route for users to report accessibility barriers — and a process for acting on that feedback promptly — is a straightforward addition to any site’s accessibility programme.

Conclusion

A web accessibility audit is how you determine whether your website genuinely works for all your users or only for those who don’t rely on assistive technology. Starting with a representative page sample, combining automated scanning with manual keyboard and screen reader testing, and converting findings into a prioritised remediation plan gives you a defensible position under UK law and a more usable website for everyone. If you’re building a new site or planning a significant redesign, talk to the team at ProfileTree about building WCAG 2.2 compliance into the project from the start rather than auditing your way back to it.

FAQs