Website Accessibility Compliance: A UK Business Guide to Meeting WCAG 2.2 and Avoiding Legal Risk in 2026

Most UK businesses discover the state of their website accessibility in one of three ways: a customer complaint, a procurement questionnaire they cannot answer honestly, or a solicitor’s letter. None of those is a good moment to start. WCAG 2.2 compliance is not a specialist add-on to a web project — it is the difference between a site that roughly 16 million disabled people in the UK can actually buy from and one that quietly turns a proportion of them away at the door, every day, without ever registering as a lost sale in your analytics.

The legal position is often described in terms that are either alarmist or dismissive, and both are wrong. There is no UK statute that says “your website must meet WCAG 2.2 AA” if you are a private company. There is, however, the Equality Act 2010, which places a continuing duty on anyone providing services to the public to make reasonable adjustments so disabled people are not put at a substantial disadvantage — and a website is a service. Courts and regulators reach for WCAG because it is the recognised technical benchmark for what “accessible” means. That is how a voluntary international guideline becomes the practical yardstick for a statutory duty.

This guide is written for the person who has to make a decision about it: an operations director, a marketing lead, a founder, or the IT manager who has just been forwarded an accessibility clause in a tender. It covers what WCAG 2.2 actually requires in plain terms, how to run a website accessibility audit that produces a fix list rather than a 200-page PDF nobody reads, how to prioritise those fixes by real user impact against real development effort, what the work costs in the UK in 2026, and — the part almost every organisation gets wrong — how to build accessibility into the way you commission and ship web work so you are not paying for the same remediation again in eighteen months.

What WCAG 2.2 actually is — and what “compliance” means in UK law

The Web Content Accessibility Guidelines are published by the World Wide Web Consortium (W3C). Version 2.2 became a W3C Recommendation in October 2023, superseding WCAG 2.1 from 2018 and WCAG 2.0 from 2008. It is backwards-compatible: everything in 2.1 is still in 2.2, plus nine new success criteria, minus one obsolete criterion (4.1.1 Parsing) that modern browsers made redundant. If your site already met 2.1 AA properly, you are most of the way to 2.2 AA and the gap is genuinely small.

WCAG is organised around four principles, usually shortened to POUR. Content must be Perceivable — users must be able to register it through some sense, which is why images need text alternatives and video needs captions. It must be Operable — every function must be reachable and usable, which is why keyboard access and adequate target sizes matter. It must be Understandable — predictable behaviour, clear labels, helpful error messages. And it must be Robust — coded so assistive technologies can interpret it reliably now and after the next browser update.

Underneath those principles sit success criteria at three conformance levels. Level A is the floor; failing it typically means a whole group of users cannot complete a task at all. Level AA is the working standard almost every regulation, tender and contract points at, and it is what you should target. Level AAA contains criteria that are not achievable for all content types — W3C explicitly says AAA conformance across a whole site is not a realistic policy goal. When someone says “we need to be WCAG compliant”, the sentence they mean is “we need to meet WCAG 2.2 Level AA across all user-facing journeys”.

The UK legal frame has two tiers. Public sector bodies are directly regulated by the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, which require conformance with the accessibility requirements of the harmonised European standard EN 301 549 — in practice WCAG AA — plus a published accessibility statement in a prescribed form. Monitoring sits with the Cabinet Office and enforcement with the Equality and Human Rights Commission. Everyone else — every private company, charity, and membership body — sits under the Equality Act 2010, where the duty is framed as anticipatory: you are expected to have thought about disabled users in advance, not to wait for someone to ask.

“Anticipatory” is the word that catches organisations out. The reasonable adjustments duty in the Equality Act is not triggered by a request. It applies to disabled people generally, in advance, and it is continuing — meaning it does not expire once you have done a project. A site that was audited and fixed in 2023 and has since had nine months of new landing pages, a new booking widget and a redesigned checkout is not covered by the 2023 audit.

The numbers that frame the decision

Accessibility arguments tend to be made emotionally and lost financially. It is worth grounding the case in figures a finance director recognises, because the scale of the addressable audience is consistently underestimated and the scale of the technical problem is consistently overestimated.

Two of those numbers deserve unpacking. The 94.8% figure comes from an annual automated analysis of a million home pages — and because automated tooling only detects a subset of WCAG failures, it is a floor, not a ceiling. The real proportion of home pages with at least one AA failure is higher. Meanwhile the Click-Away Pound research found that a substantial majority of disabled online shoppers who hit a barrier simply leave and buy elsewhere rather than contacting the retailer. That is the mechanism that makes this invisible in your reporting: the failure looks like a bounce, and a bounce looks like disinterest.

The nine new criteria in WCAG 2.2 are also worth naming, because the gap analysis from 2.1 is a genuinely small piece of work. At Level A: 3.2.6 Consistent Help and 3.3.7 Redundant Entry. At Level AA: 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), and 3.3.8 Accessible Authentication (Minimum). At Level AAA: 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, and 3.3.9 Accessible Authentication (Enhanced). Six of the nine sit at A or AA, so six are in scope for a normal compliance target.

Where UK business websites actually fail — a risk-scored view

The failures that matter are not evenly distributed. A small number of issue types account for the overwhelming majority of real-world barriers, and they cluster in three places: the visual layer, the interactive layer, and the forms that take your money. The grid below scores the patterns that come up most often on UK SME sites at first assessment, rated by how likely they are to stop a task completely rather than merely make it harder.

Read that grid as a triage tool rather than a scorecard. Anything marked high risk is a barrier that can end a session entirely: a keyboard user who cannot open your navigation menu has no path forward, and a screen reader user who submits a form and hears nothing back has no way to know whether it worked. Items marked partial degrade the experience and will appear in an audit report, but a determined user can usually still complete the task. Fix the first category before you touch the second, regardless of how easy the second looks.

The most common failures, by frequency

The WebAIM Million study runs an automated accessibility scan across a million home pages every year and publishes the distribution of detected errors. It is the closest thing the industry has to a census, and its value is that the ranking barely moves year to year — the same handful of problems dominate, which means a small, well-chosen fix list eliminates most of the barrier surface on a typical site.

Notice what those six categories have in common: none of them is technically difficult. Low contrast is a design token change. Missing alt text is a content process. Empty links are almost always an icon anchor with no accessible name — a social media icon in a footer, a magnifying-glass search button, a card that wraps an image with no text inside. Missing labels are a form-markup habit. There is no architectural rewrite hiding in this list, which is why the “accessibility is too expensive” objection usually collapses on contact with an actual audit.

The harder problems are the ones automated tooling cannot see: whether your focus order matches your visual order, whether an ARIA live region actually announces, whether alt text is accurate rather than merely present, whether a modal traps focus correctly, whether an error message tells the user how to fix the problem. Those need a human, and they are where audit budgets should be concentrated. A scanner that reports zero errors is telling you that your site passed the roughly one-third of criteria a machine can evaluate — nothing more.

This is the same structural point that shows up in security work, where an automated vulnerability scan and a manual penetration test answer different questions and neither substitutes for the other. If that framing is useful, our guide to how often UK businesses actually need a penetration test makes the automated-versus-manual distinction in more depth, and the logic transfers almost directly to accessibility testing cadence.

What accessibility work costs in the UK in 2026

Pricing is opaque in this market because the deliverables vary enormously and the word “audit” is used for everything from a five-minute scanner export to a fortnight of assistive-technology testing with disabled participants. The table below gives realistic UK planning ranges for an organisation with a site of moderate complexity — roughly 15 to 40 distinct page templates, a contact or booking form, and either a checkout or an authenticated area.

Two planning notes on those figures. First, the remediation line is the one that varies most and the one most often omitted from budgets. Commissioning an audit without funding the fixes produces the worst possible outcome: a dated document that establishes, in writing, that you knew about the barriers and did not address them. If your budget only stretches to one of the two this year, fund a smaller audit and keep money for fixes.

Second, the cost curve strongly favours doing this early. Retrofitting accessibility into a finished build routinely costs several times what designing it in would have, because you are unpicking decisions — a colour palette baked into a design system, a component library built on non-semantic markup, a checkout flow whose step logic assumes a mouse. The exact multiplier is arguable; the direction is not. Any web project you commission from this point should carry the requirement from the brief onwards, which is a procurement decision rather than a technical one. Our guide to building a three-year IT roadmap covers how to get commitments like this into a dated, costed plan rather than leaving them as good intentions.

What a real remediation programme looks like

The single biggest predictor of whether an accessibility project succeeds is whether it was sequenced or simply started. Below is the shape of a programme that works for a mid-sized UK organisation with an existing site: roughly ten to twelve weeks from first scan to a defensible position, with the heavy user-facing wins landing early rather than at the end.

Overlay widgets versus fixing the source

Somewhere in the first fortnight of any accessibility project, someone will forward a link to an accessibility overlay — a JavaScript snippet promising WCAG compliance and legal protection for a few hundred pounds a year. It is worth addressing directly, because the pitch is persuasive and the evidence against it is strong enough that hundreds of accessibility practitioners, including many disabled developers, have publicly signed a statement recommending against them.

The mechanical problem with overlays is straightforward. Assistive technology users already have their own tools, configured to their own preferences, often over many years. An overlay that injects its own reading mode, its own keyboard handling and its own ARIA into the page is adding a second layer of interpretation between the user and the content. Sometimes it helps. Frequently it interferes, and the user has no way to switch it off before it has already changed how the page is announced.

The strategic problem is that overlays address the machine-detectable subset — and even there, imperfectly, because guessing alt text for an image from its filename produces a description that is present but wrong, which is arguably worse than absent. They cannot evaluate whether your focus order is logical, whether your error messages are useful, whether your link text makes sense out of context, or whether your booking journey can be completed without a mouse. Those are the failures that stop transactions.

The narrow, honest use case for an overlay is as a temporary mitigation on a legacy system with a hard decommission date, deployed alongside a funded remediation plan and an accessible alternative contact route, and disclosed openly in your accessibility statement. Deployed instead of remediation, it is a subscription that buys documentation of the fact that you were aware of the problem.

Scoring your own readiness before you spend anything

Before commissioning an audit it is worth knowing roughly where you sit, because the answer changes what you should buy. A site at 20 out of 100 needs a design-system intervention, not a detailed criterion-by-criterion report. A site at 70 needs exactly that detailed report, because the remaining failures are specific and individual. Score yourself honestly against ten questions and read the gauge below as the typical UK SME starting position.

The ten questions, each worth ten points, and each answerable in under a minute by someone with no accessibility training. Can you complete your primary conversion journey — enquiry, booking or checkout — using only the Tab, Shift+Tab, Enter, Space and arrow keys, with the mouse unplugged? Can you see clearly, at every step of that journey, which element currently has focus? Does the focus order follow the visual order of the page, without jumping backwards or into hidden content? Does every image that conveys information have alt text that a colleague would recognise as accurate, and every decorative image an empty alt attribute?

Continuing: does every form field have a visible label that remains visible after the user starts typing? When a form is submitted with an error, is the problem described in words that name both the field and the fix? Does your body text meet a 4.5:1 contrast ratio against its actual background, including text over images and in your brand colours? Can the page be zoomed to 400% without horizontal scrolling or content loss? Does every video carry accurate captions? And do you have a published accessibility statement that names a real standard and a real date?

Six or fewer yes answers means the work is structural and should start with design tokens and shared components. Seven or eight means a targeted audit will give you a short, actionable list. Nine or ten means you are in maintenance territory, and the priority becomes governance — making sure the next redesign or the next third-party widget does not undo it.

Benchmarks: where organisations typically land, criterion by criterion

Aggregate scores hide the shape of the problem. The rows below break first-assessment performance down by area, which is more useful for planning because it tells you which team owns which gap. Design owns contrast and focus styling. Development owns semantics, components and forms. Content owns alt text, link text and captions. Procurement owns third-party embeds. Very few accessibility programmes fail for technical reasons; most fail because nobody was named as the owner of a particular row.

The two lowest rows are the two newest concerns, and they are related. Non-text contrast at 1.4.11 requires that the parts of the interface a user must perceive to operate — input borders, toggle states, icon controls, focus rings — meet 3:1 against adjacent colours. Modern design trends favour pale grey borders and low-contrast placeholder text, so a fashionable interface fails this criterion almost by default. Focus not obscured at 2.4.11 is new in WCAG 2.2 and catches a pattern that spread widely before anyone considered it: the sticky header, the sticky cookie banner and the sticky chat bubble, each of which can cover the element the keyboard has just moved focus to.

Note also that a high score on the top row is not reassuring. Document language and page titles are trivially automatable, which is exactly why they score well — scanners find them, so they get fixed. The rows that score badly are the rows machines struggle with. That inverse relationship is the strongest available argument for spending audit money on human testing rather than on more tooling.

How much of WCAG a machine can actually check

The most consequential number in this whole subject is the one below, because it determines how you spend your budget. Automated accessibility tooling is genuinely good at what it does, and it should run continuously in your build pipeline. But the proportion of WCAG failures it can detect is a minority, and every hour of testing strategy should be planned around that fact rather than around the reassuring green tick on a dashboard.

The exact figure moves with the tool and the methodology — some vendors report higher numbers by counting guided manual checks their product prompts for, which is a fair claim but a different measurement. What nobody disputes is the shape: a substantial majority of criteria require a person to make a judgement. Whether alt text describes the right thing. Whether a heading level reflects the document structure or just a font size. Whether the reading order makes sense. Whether an error message actually tells the user what to do. Whether a colour-coded status is also conveyed some other way. A scanner can confirm that an alt attribute exists; it cannot confirm that “image1.jpg” is a bad description of your managing director.

The practical consequence is a two-track testing model. Automated checks belong in continuous integration, running on every pull request, configured to fail the build on new violations rather than on the historical backlog — otherwise the gate is permanently red and everyone learns to ignore it. Manual checks belong on a calendar: a keyboard-only pass on every new template before release, a screen reader pass on any journey that takes money or personal data, and a full external audit annually or after any significant redesign.

That split mirrors how mature organisations already treat monitoring elsewhere in their estate — continuous automated signal for the things machines are good at, scheduled human review for the things they are not. The reasoning we set out in our guide to proactive network monitoring for UK businesses applies almost unchanged here: the value is in detecting regressions the same week they ship, not in discovering them a year later in an audit.

The legal exposure, described accurately

UK accessibility risk is frequently either overstated by vendors selling remediation or dismissed by businesses who have never seen a claim. The accurate position is more specific than either, and it has four distinct components that apply to different organisations in different measure.

The Equality Act 2010. Section 20 imposes a duty to make reasonable adjustments where a provision, criterion or practice puts a disabled person at a substantial disadvantage compared with someone who is not disabled. Section 29 applies that duty to anyone providing services to the public. A website is a service. The duty is anticipatory, so it is not discharged by responding helpfully once someone complains, and it is not limited by whether you intended to exclude anyone. What counts as “reasonable” is contextual — the size and resources of the organisation, the cost of the adjustment, and its practicability all matter — which is why a sole trader and a national retailer are not held to the same standard. It is also why documented, funded, ongoing effort is the strongest position to be in: reasonableness is judged on what you did, not on whether you achieved perfect conformance.

The reason UK case law in this area is thin is not that claims are rare. It is that claims in the county court under the Equality Act are typically settled privately, often with a confidentiality clause and a commitment to remediate, which means they generate no reported judgment. Low visibility is not low frequency. Organisations tend to learn about the risk only when it arrives.

The public sector regulations. If you are a public body — or a supplier delivering a digital service on behalf of one — the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 apply directly. They require conformance with the accessibility requirements of EN 301 549, which incorporates WCAG at Level AA, and they require an accessibility statement in a prescribed format covering compliance status, non-accessible content, and a feedback mechanism. Monitoring is carried out centrally and enforcement sits with the EHRC. In practice, the sharpest edge for private companies here is contractual: public sector procurement passes the obligation down the supply chain, and an accessibility clause in a framework agreement is enforceable against you even though the regulations themselves are not.

The European Accessibility Act. Directive (EU) 2019/882 began applying in June 2025 and reaches a broad set of consumer products and services placed on the EU market — including e-commerce, consumer banking, e-books, ticketing and transport information services. It is not UK law, but it applies by market rather than by establishment: a UK business selling to consumers in an EU member state is within scope of that member state’s implementing legislation. Enforcement is national, and micro-enterprises providing services are generally excluded, but any UK company with meaningful EU consumer revenue should establish its position rather than assume Brexit removed the question.

US exposure. The ADA lawsuit risk for websites is a genuinely different regime and the most litigious of the four. Thousands of web accessibility claims are filed in US federal and state courts each year under Title III of the Americans with Disabilities Act, and the plaintiff bar is organised and prolific. UK businesses are not automatically in scope, but a US-facing storefront, US pricing, US shipping or a US entity all move you closer to it. Two details matter for planning: the vast majority of these claims settle rather than reach judgment, and a meaningful proportion of the sites sued had an accessibility overlay installed at the time — which is the clearest available evidence that the widget does not function as legal insurance.

Underneath all four is a commercial exposure that arrives far more often than any legal one: the procurement questionnaire. Accessibility conformance questions are now routine in UK public sector tenders, in enterprise vendor onboarding, and increasingly in mid-market B2B purchasing. A supplier who can attach a dated conformance report and a published statement answers in a paragraph. A supplier who cannot either declines to bid or writes something optimistic that will not survive scrutiny.

A worked example: what remediation looked like for one UK firm

A Leeds-based professional services firm of about 70 people ran a website that had been redesigned two years earlier and looked, by any conventional measure, entirely current. The trigger was not a complaint. It was a tender for a local authority framework that asked for a WCAG conformance statement and the date of the most recent audit. Nobody could answer, so the bid was withdrawn from a process the firm had a genuine chance of winning.

The initial automated scan returned just over 4,100 errors across 380 pages, which produced the usual reaction in the leadership meeting. The manual audit reframed it: those 4,100 errors resolved to 23 distinct root causes, of which 6 accounted for roughly 80% of the count. The brand’s secondary grey, used for all body copy, ran at 3.1:1 against white. The focus outline had been removed globally by a CSS reset in the original theme. Every service card on the site was an image wrapped in an anchor with no accessible name, which is why the empty-link count was in the hundreds. The enquiry form used placeholder text in place of labels. The cookie banner captured focus and could not be dismissed by keyboard. The main navigation opened on hover only.

Fixing those six took eleven working days including testing, and dropped the automated error count by roughly 88%. The remaining 17 root causes — a bespoke date picker in the booking module, an embedded video player without captions, a legacy PDF fee schedule, several genuinely ambiguous alt text decisions — took a further four weeks and involved replacing two third-party components outright rather than attempting to patch them.

The outcome that mattered to the board was not the error count. It was that the firm could answer the procurement question the following quarter, and that the enquiry form’s completion rate rose noticeably once the labels and error messages were fixed — a change that benefited everybody using it, not only the users the work was undertaken for.

We assumed this was going to be a compliance exercise that made the site uglier. What actually happened is that we found out our contact form was hard for everyone to use, and the accessibility audit was just the first thing honest enough to tell us.

That last observation generalises. Accessibility failures are rarely exotic edge cases; they are usually ordinary design and code quality problems that disabled users encounter first and most severely. Low contrast is harder for everybody in bright sunlight on a phone. Unlabelled form fields confuse everybody once autofill has populated them. A keyboard-inaccessible menu breaks for anyone whose trackpad has failed. Fixing accessibility tends to improve baseline usability, and the measurable gains often show up in conversion metrics rather than in compliance reports.

Common accessibility mistakes to avoid

The failures below are not obscure. They are the ones that show up repeatedly on sites built by competent teams who simply had not been asked the question, and each of them is cheaper to avoid than to remediate.

• Removing the focus outline and never replacing it. A CSS reset containing outline: none is present in a large share of themes and starter templates. It makes the design tidier for mouse users and makes the site unusable for keyboard users, who now cannot tell where they are. If the default ring clashes with your brand, style it — a 2px offset outline in your magenta or blue at 3:1 against the background satisfies both the criterion and the design review.
• Treating alt text as a field to fill rather than a decision to make. Alt text describes the purpose of an image in context, not its contents. A photograph of a building on a contact page might reasonably be decorative with an empty alt attribute; the same photograph on an architecture portfolio needs a description. A chart needs its finding stated, not “bar chart”. Automated alt generation produces text that passes the scanner and fails the user.
• Using ARIA to paper over non-semantic markup. The first rule of ARIA is not to use it if a native HTML element will do the job. A div with role="button" needs keyboard handlers, focus management and state announcements that a real button element provides for free. Incorrect ARIA is measurably worse than none: it tells assistive technology something confidently untrue.
• Placeholder text instead of labels. Placeholders vanish the moment typing begins, fail contrast requirements in almost every design system, and are inconsistently announced across screen readers. Every input needs a persistent, programmatically associated label. This is the single most common form failure and the single easiest to fix.
• Signalling errors with colour alone. A red border communicates nothing to a screen reader user and little to the substantial number of people with colour vision deficiency. Errors need text that names the field and states the correction, placed adjacent to the input, summarised at the top of the form, and announced through a live region so it reaches someone who never sees the visual change.
• Auditing once and calling it done. Accessibility is a property of your current code, not a certificate you earned. A conformant site plus six months of new landing pages, a new booking widget and a marketing team pasting styled HTML into the CMS is no longer a conformant site. Without a regression check in the pipeline, sites drift back measurably within a year.
• Ignoring third-party embeds. Your chat widget, booking engine, payment iframe, review carousel and cookie consent banner are all part of the experience the user has and the obligation you carry. Cookie banners in particular are notorious — they load first, capture focus, and frequently cannot be dismissed without a mouse, which means the very first interaction on your site is a barrier.
• Buying an audit without funding the fixes. An unremediated audit report is a dated internal document establishing that you identified specific barriers and did nothing about them. If the budget only covers one, scope the audit smaller and keep money for remediation.

The 12-point WCAG 2.2 readiness checklist

This is the working list to hand to whoever owns your website. It is ordered by leverage — each item resolves more real-world barriers than the one below it — and it is deliberately achievable without specialist tooling for the first several items.

1. Unplug the mouse and complete your primary journey. Enquiry, booking or checkout, start to finish, keyboard only. Record every point where you get stuck, where focus disappears, or where you cannot tell what is selected. This single exercise finds more genuine barriers than any scanner.
2. Restore and style a visible focus indicator across every interactive element, with at least 3:1 contrast against adjacent colours, and confirm it is not hidden behind sticky headers, cookie bars or chat bubbles at any scroll position (2.4.7, 2.4.11).
3. Audit your colour tokens, not your pages. Check every text-on-background combination in the design system against 4.5:1 for body text and 3:1 for large text, and every UI component border, icon and state indicator against 3:1 (1.4.3, 1.4.11). Fixing tokens fixes thousands of instances at once.
4. Give every form input a persistent visible label that is programmatically associated with the field, add appropriate autocomplete attributes to personal-data fields, and make sure required fields are marked in text as well as visually (1.3.5, 3.3.2).
5. Rewrite error handling so every validation failure produces text naming the field and the correction, positioned next to the input and summarised at the top of the form, announced via an ARIA live region, and never signalled by colour alone (3.3.1, 3.3.3, 4.1.3).
6. Fix heading structure so each page has exactly one h1 and headings descend without skipping levels, chosen for document structure rather than font size, with landmark regions marking header, navigation, main and footer (1.3.1, 2.4.6).
7. Give every link and button an accessible name. Icon-only controls need visually hidden text or an aria-label; image links need meaningful alt text; “read more” and “click here” need enough context to make sense when read out of the surrounding paragraph (2.4.4, 4.1.2).
8. Check every interactive target is at least 24 by 24 CSS pixels, or has adequate spacing around it — social icons, close buttons on modals, pagination controls, and inline icon buttons in tables are the usual offenders (2.5.8).
9. Provide a non-drag alternative for every drag interaction: sliders operable with arrow keys, reorderable lists with move-up and move-down controls, map interactions with a text or list equivalent (2.5.7).
10. Review authentication for cognitive load. Allow pasting into password and one-time-code fields, do not require users to memorise or transcribe anything, and replace or supplement any puzzle-based CAPTCHA with a non-cognitive alternative (3.3.8).
11. Test at 400% zoom and 320 CSS pixels of width, confirming there is no horizontal scrolling, no clipped content, and no functionality that becomes unreachable, then apply the text-spacing overrides and confirm nothing overlaps (1.4.10, 1.4.12).
12. Publish an accessibility statement naming the standard targeted, the date last tested, the method used, the known outstanding issues with expected resolution dates, and a monitored contact route for reporting problems — then diary a date to update it.

Making it stick: accessibility as process, not project

Everything above describes a remediation. The harder and more valuable change is the one that stops you needing another one in eighteen months, and it is organisational rather than technical. Four mechanisms do most of the work.

Put it in the contract. Every web development engagement, every theme purchase, every agency statement of work should name WCAG 2.2 Level AA as an acceptance criterion with testing evidence required before final payment. Suppliers respond to what is measured at sign-off. A brief that mentions accessibility in the aspirations section and omits it from acceptance criteria will produce a site that mentions accessibility in the aspirations section.

Put it in the pipeline. Add an automated accessibility check to continuous integration and configure it to fail on new violations rather than on the accumulated backlog. A gate that is red on day one gets bypassed by week two. A gate that only turns red when someone introduces a regression gets respected, and it catches the drift that would otherwise accumulate silently between audits.

Put it in the component library. Accessibility is far cheaper as a property of shared components than as a property of pages. If your modal, dropdown, tab set, date picker and form field are correct once in a design system, every future page inherits that correctness at no marginal cost. This is the single highest-return investment in the whole subject, and it is why organisations with a mature design system score dramatically better at first assessment than those assembling pages from bespoke markup.

Put it in someone’s job. Name an owner — not a committee — responsible for the accessibility statement being current, the automated check being green, and the annual audit being scheduled. Give them a defined cadence: monthly automated review, quarterly keyboard pass over changed templates, annual external audit. Treat the response time to a reported barrier as a service commitment with a target, in the same way you would treat any other incident. The framework we set out for setting IT support SLAs that match your actual risk works well for this: a barrier that blocks a purchase is a priority one incident, not a backlog item.

Organisations that do those four things stop having accessibility projects. The cost moves from a periodic five-figure remediation to a modest ongoing overhead, the procurement questions become easy to answer, and the underlying point — that a meaningful share of your potential customers can use your site — stays true between audits rather than only just after them.

At a glance — WCAG 2.2 and UK accessibility compliance

The summary below collects the facts most often needed when briefing a board, a supplier or a colleague who has just been handed responsibility for this.

How Cloudswitched approaches accessibility work

We build and maintain websites for UK businesses, which means accessibility is part of how the work is specified rather than a separate service bolted on afterwards. On an existing site that usually starts with an audit that produces a prioritised, developer-readable fix list mapped to WCAG 2.2 success criteria — not a scanner export — followed by remediation sequenced so the global design-system fixes land first. On a new build it means WCAG 2.2 AA in the acceptance criteria from the brief onwards, accessible components in the design system, and an automated check in the deployment pipeline so regressions surface the week they are introduced rather than at the next audit.

Frequently Asked Questions

Is WCAG 2.2 a legal requirement in the UK?

Not directly for private companies. WCAG is a technical standard published by the W3C, not legislation. What is legally binding is the Equality Act 2010, which requires service providers to make reasonable adjustments so disabled people are not put at a substantial disadvantage — and a website is a service. WCAG is the benchmark courts, regulators and procurement teams use to judge whether a site is accessible, which makes it the practical standard even where it is not the statutory one. For UK public sector bodies the position is different: the 2018 accessibility regulations make conformance with EN 301 549, which incorporates WCAG at Level AA, a direct legal obligation.

What is the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 adds nine success criteria and removes one. The additions at Level A and AA — the levels most organisations target — are Consistent Help, Redundant Entry, Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum) and Accessible Authentication (Minimum). The removal is 4.1.1 Parsing, which modern browsers made redundant. Everything else in 2.1 carries forward unchanged, so a site that genuinely met 2.1 AA has a short, well-defined gap to close rather than a fresh audit’s worth of work.

How much does a website accessibility audit cost in the UK?

A sampled manual audit covering 10 to 15 key templates typically runs £3,000 to £7,000. A full WCAG 2.2 AA audit including transactional journeys such as checkout and registration generally falls between £6,000 and £15,000. Adding moderated usability testing with disabled participants takes it to £10,000 to £25,000. Budget separately for remediation, which commonly runs £8,000 to £40,000 or more depending on how much of the front end you control — a bespoke build is usually cheaper to fix than a heavily customised third-party theme.

Do accessibility overlay widgets make a website compliant?

No. Overlays operate on the machine-detectable subset of accessibility issues and cannot evaluate the majority of WCAG criteria, which require human judgement about context, purpose and clarity. They also risk conflicting with the assistive technology a user has already configured. Hundreds of accessibility practitioners have publicly recommended against them, and a notable proportion of US web accessibility lawsuits have been filed against sites that had an overlay installed. There is a narrow legitimate use as a disclosed temporary mitigation on a legacy system with a decommission date, deployed alongside a funded remediation plan — but not as a substitute for one.

How do I test my own website for accessibility without hiring anyone?

Start with three things you can do today. Unplug your mouse and complete your main conversion journey using only the keyboard, noting every point where you get stuck or cannot see what is focused. Run a free browser extension such as axe DevTools, WAVE or the Lighthouse accessibility audit on your most important templates. Then check your body text and UI element colours against the required contrast ratios using any online contrast checker. Those three passes will surface the majority of the barriers a real user would hit, and they cost nothing but an afternoon.

Does the European Accessibility Act apply to UK businesses?

It can. The European Accessibility Act is EU legislation, not UK law, but it applies by market rather than by where a company is established. A UK business selling covered products or services — e-commerce among them — to consumers in an EU member state falls within the scope of that state’s implementing legislation. Enforcement is national and varies between member states, and micro-enterprises providing services are generally excluded. Any UK company with meaningful EU consumer revenue should establish its position deliberately rather than assume it is out of scope.

What is an accessibility statement and do I need one?

An accessibility statement is a published page setting out the standard you are working to, when the site was last tested and how, what is known to be non-conformant, when you expect to fix it, and how a user can report a problem. It is a legal requirement in a prescribed format for UK public sector bodies. For private companies it is not mandatory, but it is strongly advisable: it demonstrates the anticipatory, considered effort that the reasonable adjustments duty asks for, it answers most of a procurement questionnaire in one link, and it gives a disabled user a route to tell you about a barrier rather than simply leaving.

How often should we re-audit our website?

Annually as a baseline, and additionally after any significant redesign, platform migration, or the introduction of a new third-party component such as a booking engine or chat widget. Between full audits, run automated checks on every release and a keyboard-only pass on each new template before it goes live. Sites without that ongoing cadence measurably regress within a year, because new pages, new plugins and content added through a CMS all reintroduce issues that the original remediation removed.

Will improving accessibility hurt our design or our SEO?

Neither, in practice. Accessible design constrains a handful of specific choices — text contrast, target sizes, a visible focus state — and leaves everything else open; plenty of visually distinctive sites meet AA comfortably. On search, the overlap is substantial and positive: semantic heading structure, descriptive link text, image alt attributes, captions and transcripts, and correct page language are all things accessibility requires and search engines use. Accessibility work will not by itself move rankings, but it removes several technical problems that hold them back.

Who in our organisation should own website accessibility?

A named individual, not a committee — typically whoever owns the website commercially, working with whoever owns it technically. Their responsibilities are narrow and checkable: the accessibility statement is current, the automated check in the build pipeline is green, the annual audit is scheduled and budgeted, and reported barriers are triaged against a defined response time. The failure mode in almost every organisation that regresses is not a lack of skill but a lack of a name against the task.

What happens if someone complains that they cannot use our website?

Respond promptly, in the channel they used, and offer an immediate alternative route to complete whatever they were trying to do — a phone line, an email address, or a staffed process. Then log it as a defect with a priority reflecting whether it blocks a transaction, investigate the underlying cause rather than the single instance, and tell the person what you found and when it will be fixed. Handled that way, a complaint is a free audit finding. Handled badly, or ignored, it is the most common precursor to a formal claim.

Are PDFs on our website covered by accessibility requirements?

Yes. Documents you publish are part of the service you provide, and a scanned or untagged PDF is typically unreadable to a screen reader. There are three options for each one: remediate it with proper tags, reading order and alternative text; replace it with an HTML page, which is almost always the better answer for anything a customer needs to act on; or retire it if it is out of date. Price lists, forms, terms and application documents are the ones to deal with first, because they sit directly in a transactional path.

Related reading

These guides cover the planning, testing and governance disciplines that sit alongside accessibility work for UK businesses.

• Building an IT Roadmap: A UK Business Guide to Aligning Technology Spend with Strategy in 2026
• Penetration Testing Frequency: A UK Business Guide to How Often You Actually Need a Pen Test in 2026
• Network Monitoring for UK Businesses: A Practical Guide to Spotting Problems Before Your Users Do in 2026
• IT Support Response Times: A UK Business Guide to Setting SLAs That Actually Match Your Risk in 2026
• Microsoft 365 Copilot Data Security: A UK Business Guide to Controlling What Copilot Can See in 2026