What is a website accessibility audit, and what do you get?
A website accessibility audit is a structured test of your site against a recognised standard, usually WCAG 2.2 Level AA, to find the barriers that stop disabled people using it. The useful output is not a score. It is a list of specific problems, where they occur, who they affect and how to fix them.
Think of who uses your site. Someone navigating by keyboard because of a tremor. A blind customer using a screen reader. Someone with low vision browsing at 300% zoom. A person with dyslexia or ADHD who needs clear structure and no surprise time-outs. A website accessibility audit walks your key journeys the way each of them would.
From us you receive three things. An issue log, one row per problem, with the page, the WCAG success criterion, a screenshot or recording, the impact on users and the code-level fix. A summary ranking issues by harm, so blockers in checkout come before a decorative image missing its alt attribute. And, if you want it, the fix sprint itself, where we change the code and re-test.
What an audit is not: a certificate. There is no official UK certification for private websites, and nobody can promise a site is “fully compliant” forever, because every new page or plugin can introduce a barrier. An audit is a snapshot plus a plan.
Do UK private businesses legally need an accessible website?
There is no UK law that names WCAG for private businesses, but the Equality Act 2010 requires service providers to make reasonable adjustments for disabled people, and that duty applies to services you provide online. In Northern Ireland the equivalent duties sit in the Disability Discrimination Act 1995.
GOV.UK's guidance on public sector accessibility describes the public sector rules as building on these existing Equality Act obligations, which apply to all UK service providers. The practical reading for a shop, clinic, law firm or letting agent is that if disabled customers cannot use your website to do what others can, you may be failing that duty.
How far the duty goes in a given case, what is “reasonable” for your size and resources, and what a claim might look like are legal questions for your solicitor. We do not give legal advice. What we can do is give you evidence: a clear record of what was tested, what was found and what was fixed, which is exactly what a solicitor will ask for if a complaint arrives.
Many businesses commission a website accessibility audit for reasons beyond the law: a large customer's supplier questionnaire, a tender that asks about WCAG, or plain commercial sense. Barriers that block disabled visitors also frustrate older customers, people on small phones and anyone in a hurry.
Equality Act duties vs the public sector accessibility regulations
The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 set specific, testable rules for public bodies; the Equality Act sets a broader duty for everyone else. If you are a private business, the 2018 regulations usually do not apply to you directly, but they show what “good” looks like.
According to GOV.UK, public sector bodies must meet WCAG 2.2 AA, publish an accessibility statement explaining how accessible their website or app is and review it regularly, and the Government Digital Service monitors a sample of sites each year. Some organisations are exempt or partly exempt, such as non-government organisations that are not mostly publicly funded.
Private businesses that supply the public sector sometimes inherit these expectations through contracts. If you build or run a portal for a council, NHS body or university, check whether your contract requires WCAG 2.2 AA and an accessibility statement. Charities that are mostly publicly funded should check whether the regulations apply to them; our charity website design page touches on this.
Accessibility statements for private firms
Not required by the 2018 regulations, but a short, honest statement of what you tested, known issues and how to ask for help in another format is good practice. We draft it from the audit for you to approve.
What we would never write
Claims such as “fully WCAG compliant” or “certified accessible”. A statement should describe the testing and its date, and give a contact route for people who hit a barrier.
Does the European Accessibility Act apply to UK businesses?
It can, if you provide in-scope services to consumers in the EU. The European Accessibility Act (Directive 2019/882) applies to services provided to consumers after 28 June 2025, and e-commerce services are explicitly in its scope, so a UK online shop selling into EU member states should check its position.
The Directive includes an exemption: microenterprises providing services are exempt from its accessibility requirements. It defines a microenterprise as one employing fewer than 10 persons with annual turnover or balance sheet total not exceeding EUR 2 million. A small UK shop may fall under that; a growing brand with EU distribution may not.
The EAA is implemented through each member state's national law, and enforcement happens in the EU countries where you sell. Whether and how it catches your business is a question for a lawyer familiar with the relevant markets. Our role is technical: the requirements for web services map closely to WCAG, so a WCAG 2.2 AA website accessibility audit is the natural first step either way.
If you sell to Ireland from Northern Ireland or Great Britain, or run a European storefront on the same platform, include those storefronts in the audit scope. Shared templates mean one fix usually covers every market.
What does WCAG 2.2 AA mean in plain English?
WCAG, the Web Content Accessibility Guidelines published by the W3C, is a set of testable success criteria grouped under four principles: content must be perceivable, operable and understandable, and its code must hold up reliably across browsers and assistive technology. Level AA means meeting all Level A and AA criteria, which is the benchmark UK public bodies and most contracts use.
Perceivable covers text alternatives for images, captions for video, sufficient colour contrast and content that reflows when zoomed. Operable covers keyboard access, visible focus, enough time, no flashing that could trigger seizures, and clear navigation. Understandable covers readable language, predictable behaviour and helpful error messages on forms. The final principle covers valid names, roles and states so screen readers announce controls correctly.
Level AAA exists too, but it is rarely a sensible target for a whole commercial site; some AAA criteria are impossible for certain content. We test A and AA, and mention AAA improvements only where they are cheap and help your users.
The criteria are precise, which is useful. “Text contrast of at least 4.5:1 for normal text” can be measured. “Focus indicator visible” can be checked. That precision is what lets a website accessibility audit produce fixes a developer can act on, rather than vague advice to “be more inclusive”.
What changed in WCAG 2.2, and what does it mean for your site?
The W3C published WCAG 2.2 as a Recommendation on 5 October 2023. According to the W3C's summary, it adds nine success criteria and removes one, 4.1.1 Parsing, which is now obsolete. Everything else from WCAG 2.1 carries over.
Six of the new criteria are at Level A or AA, so they are part of any AA website accessibility audit. Focus Not Obscured (Minimum) means sticky headers, chat buttons and cookie banners must not hide the element that has keyboard focus. Dragging Movements means anything done by dragging, such as a slider or a map, needs a single-pointer alternative. Target Size (Minimum) sets a minimum size or spacing for tap targets.
Consistent Help asks that help mechanisms, like a contact link or chat, appear in the same place across pages. Redundant Entry says users should not have to retype information they already gave in the same process, which matters in multi-step checkouts and applications. Accessible Authentication (Minimum) means logins must not rely on cognitive tests such as remembering or transcribing a code without allowing paste or a password manager.
On UK business sites, the ones we expect to fail most often are Focus Not Obscured, because of sticky headers and cookie consent banners, and Target Size on mobile menus and footers. Both are usually quick CSS fixes once found.
How is a website accessibility audit carried out?
We agree a scope, run automated scans to clear the obvious, then test every in-scope page and journey manually. The manual part is where the real findings come from.
- Scope: agree templates and journeys, such as home, category, product, basket, checkout, contact, account and a typical article
- Automated pass: scanners and browser tools to catch missing labels, contrast failures and markup errors
- Keyboard pass: every journey completed with Tab, Shift+Tab, Enter, Space and arrow keys, watching focus order and visibility
- Screen reader pass: NVDA with a Windows browser and VoiceOver on macOS and iOS, checking headings, landmarks, labels and announcements
- Zoom and reflow: 200% text resize and 400% zoom at desktop width, checking nothing is cut off or needs sideways scrolling
- Visual checks: contrast of text, icons and focus indicators, meaning not conveyed by colour alone, motion and animation
- Forms and errors: labels, instructions, error identification and suggestions, time-outs
- Media: captions, transcripts, audio description needs, autoplay
- Reporting: issue log with criterion, impact, evidence and fix
We record short screen-reader and keyboard clips for serious issues. Seeing a screen reader announce “button, button, button” with no labels explains the problem faster than any report paragraph.
Are automated checkers and overlay widgets enough for accessibility?
No. Automated tools catch a useful share of issues but cannot judge most of what matters, and overlay widgets add a toolbar on top of the site without fixing the underlying code. Neither replaces a manual website accessibility audit.
A scanner can tell you an image has no alt attribute. It cannot tell you that the alt text on your product photo says “IMG_4471”, or that a link reading “click here” makes no sense out of context, or that the focus jumps from the header to the footer and skips the form. It cannot complete your checkout with a screen reader and notice that the payment step announces nothing.
Overlay widgets promise to make sites accessible with a line of script. Many disabled users already have their own assistive technology set up exactly as they need it; an overlay can conflict with that rather than help. And because the templates are unchanged, the underlying barriers remain for anyone who does not use the widget.
Automated checks do earn a place after the audit: run on every deploy, they catch regressions like a new image without alt text or a contrast failure introduced by a brand refresh. We can set that up in your build pipeline so problems are flagged before they reach visitors.
Which pages should a UK website accessibility audit cover?
Cover every distinct template and every journey that leads to money or a request for help. You do not need to test all 800 product pages; you need to test the product template thoroughly and a few pages with unusual content.
For a typical UK small business site we would include the home page, a service or product page, a category or listing page, the contact or enquiry form, the booking or quote journey, a blog post, the search results page, and any login area. For shops, add basket, delivery options, payment, order confirmation and account pages. For a firm of solicitors or accountants, add document download pages and client portals.
Third-party components count from the user's point of view even if you did not build them. A booking widget, a payment page, a chat tool or a map embed can block the journey. We test them in context and tell you which issues you can fix and which need raising with the supplier. The payment gateway integration page explains how hosted payment pages and embedded card fields differ, which affects who controls accessibility at that step.
PDFs are often forgotten. If customers must read a price list, a policy or a form in PDF, include a sample. Often the best fix is an HTML version of the key content.
Common accessibility failures on UK business websites
The same handful of problems appear on most sites, and most are fixable in the templates. Here is what a website accessibility audit most often turns up, roughly in order of how badly each blocks people.
- Forms with placeholder text instead of labels, so screen readers announce nothing useful and the hint disappears on typing
- Error messages shown only in red or only at the top, with no link to the field that failed
- Custom dropdowns, date pickers and menus built from divs that a keyboard cannot open
- Focus outlines removed in CSS, leaving keyboard users with no idea where they are
- Sticky headers, chat buttons and consent banners covering the focused element
- Low-contrast grey text on white, and white text over busy hero images
- Buttons and icon links with no accessible name, announced only as “button” or “link”
- Modal pop-ups that do not trap focus or cannot be closed with Escape
- Carousels that auto-rotate with no pause control
- Headings chosen for size rather than structure, breaking screen reader navigation
- Videos without captions; images of text used for offers and prices
Most of these live in shared components, so one fix repairs hundreds of pages at once. That is why we fix templates, not individual pages.
From audit to fixed site: how the fix sprint works
Fix blockers first, then serious issues on high-traffic journeys, then the long tail. A good fix sprint follows harm and traffic, not the order of the WCAG numbering.
We rank each issue on two axes: impact (does it stop someone completing a task, make it hard, or merely annoy) and reach (checkout template versus one archived page). A keyboard trap in checkout is a day-one fix. A missing caption on a three-year-old video can wait for week two.
Fixes are made in code you own: theme templates, React or Vue components, CSS, and CMS configuration. On WordPress we fix the theme or child theme rather than patching output with plugins, and we flag plugins that are themselves inaccessible so you can decide whether to replace them. Content fixes, such as rewriting vague link text or adding alt text to a media library, can be done by us or by your team with a short guide.
After fixes, we re-test the affected journeys with the same tools and assistive technology, update the issue log to show what is resolved, and leave you with a short list of anything that depends on a third party. That re-test is part of the work, not an extra.
How much does a website accessibility audit cost in the UK?
Quotes across the UK vary widely, from low-cost automated reports to large consultancy engagements with user testing panels. What moves the price is scope, not the name on the report. Our audit is quoted per project after we see the site, and the fix work is quoted from the resulting issue log.
The main cost drivers are the number of distinct templates and components, the number of journeys, whether dynamic web-app behaviour is involved (live search, dashboards, drag-and-drop), whether native apps are in scope, how many PDFs matter, and whether you want an accessibility statement drafted. On the fix side, what matters is how many issues sit in shared components versus one-off content, and whether the theme or page builder fights against accessible markup.
Sometimes the honest answer is that repairing an old page-builder theme will cost more than rebuilding. In that case we quote an accessible rebuild: static sites from US$150, SEO sites with many pages from US$300, online shops from US$750, and custom web apps or portals from US$900. Rebuilds include accessibility testing before launch.
Ongoing, the care plan from US$120/mo (after two free months) can include regression checks when you add pages or plugins, so the site does not quietly drift back.
Accessibility, SEO and AI search: why the same fixes help all three
Much of what makes a site accessible also makes it easier for search engines and AI systems to understand: real headings, descriptive link text, text alternatives for images, transcripts for video, and content in HTML rather than images. An accessible site is usually a better-structured site.
Screen readers and crawlers both read the underlying markup, not the visual design. A page whose headings run in order, whose navigation sits in proper landmarks, and whose buttons have names is easier for a screen reader user to scan and easier for Google to parse. Alt text written for people describes images in a way image search can use. Transcripts give AI answer engines text to quote.
Performance overlaps too. Removing an overlay script, lazy-loading carousels and simplifying heavy page-builder markup tends to improve Core Web Vitals. We keep an eye on both during fixes; our technical SEO audit covers the crawl and speed side in more depth, and the AI search optimisation page covers how answer engines read your pages.
Accessibility is not an SEO trick, and nobody can guarantee rankings. But the work rarely conflicts with search visibility, and it often helps.
Commissioning an accessibility audit from a team in India
Accessibility testing is done in a browser and with assistive technology, so location makes little difference to the quality; what matters is method and access to a staging copy for fixes. We start in the UK late morning, which is our afternoon, and you can book walkthrough calls in UK business hours.
The first two weeks usually look like this. Days one and two: scope agreed, staging access granted, automated pass run. Days three to seven: manual keyboard, screen reader and zoom testing across the agreed journeys. Around day eight: the issue log and a recorded walkthrough of the worst barriers. Then the fix sprint quote, approved by you before any billing for that phase.
Communication is on WhatsApp and email in English, with screen-share calls when a recording is not enough. If your content team or another developer will make some fixes, we explain issues to them directly with examples in their own code.
Quotes and invoices are in USD from India; UK businesses usually pay from a GBP account through Wise, bank wire or PayPal, in milestones set out in the written quote. The code changes, issue log and any statement draft belong to you. We will say plainly what we do not do: we do not recruit disabled user-testing panels or give legal opinions, and we suggest specialists for either when you need them.
Worked example: a Leeds recruitment firm's job application form
Suppose a recruitment firm in Leeds gets an email from a candidate who uses a screen reader and could not submit an application. This is an illustrative scenario, not a real client.
A focused website accessibility audit of the job search, job page and application form finds five problems. The search filters are custom checkboxes that do not announce their state. The CV upload button has no accessible name. Required fields are marked only with a red asterisk. On error, the form reloads with a red message at the top and focus returns to the page start. And the “Apply” button on mobile is 20 pixels tall beside another link, failing Target Size.
The fix sprint replaces the filter controls with native inputs styled to match, labels the upload control, adds “required” in text and in the markup, moves focus to an error summary that links to each failed field, and enlarges the mobile buttons. None of this changes the look of the site much. The candidate is told the form has been fixed and offered an alternative route in the meantime, which the firm's own process already allowed.
The firm then adds an accessibility statement with a contact route. If it later rebuilt the site, the recruitment website design page describes how accessibility is built in from the start.
Website accessibility audit checklist you can start today
You can run a rough first check in twenty minutes before commissioning a full website accessibility audit. It will not replace one, but it tells you how urgent the work is.
- Put the mouse away and complete your main journey with only the keyboard
- Check you can always see where keyboard focus is
- Zoom the browser to 400% and look for cut-off text or sideways scrolling
- Open the site on a phone and try to tap every menu item without mis-taps
- Turn on VoiceOver or NVDA and listen to your home page's headings and links
- Submit your contact form empty and check the error messages make sense
- Look for grey text on white and text over images
- Check videos have captions and that nothing autoplays with sound
- Make sure the cookie banner can be operated by keyboard and does not hide focus
- Note every barrier with a screenshot; that list becomes the audit's starting point