Website Accessibility Law UK: Rules and Deadlines for 2026.

If your accessibility statement says the site is compliant, can a disabled person finish booking, paying or logging in today?

Many organisations treat that page, or a launch-day audit, as the finish line. Website accessibility law in the UK doesn't work that way. A public body has a technical duty that continues after go-live. A private organisation sits under a different statute, which looks at disadvantage rather than a badge on the footer. A statement that hides known failures is a liability, not a shield.

Key Takeaways

• Coverage depends on who you are. Public-sector bodies must meet WCAG 2.2 AA under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. Content must be perceivable, operable, understandable and resilient.
• Private companies aren't named in those regulations. The Equality Act 2010 can still apply when a digital service disadvantages disabled users, such as an inaccessible booking form or checkout.
• A statement must admit what fails. For public bodies it's a legal requirement. For everyone else it's a strong transparency step, not a claim of perfection.
• Every defect needs an owner, a deadline and a retest. That includes third-party widgets, and it happens after each release, not only at launch.
• Start with four applicability questions, then test three journeys. Law, the standard, testing, the statement, remediation and a this-month action list follow in that order.

Do the applicability check before you rewrite any public claim.

Who Must Comply Under UK Law

A council tax form and a shop checkout can both lock someone out. They do not sit under the same statute, and treating them as one rule is the usual mistake.

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 came into force on 23 September 2018. They cover public-sector websites and mobile applications. The duty to publish an accessibility statement sits in the regulations themselves. GOV.UK guidance on equality and accessibility regulations explains how public services meet that duty, and it points them to WCAG 2.2 at AA. A guidance page does not create a separate legal duty of its own.

Deadlines aren't one date

Websites published on or after 23 September 2018 had to comply from that date, older websites had until 23 September 2020, and public-sector mobile applications had until 23 June 2021, under the 2018 regulations. A legacy council site and a newer app are not the same clock.

Those dates opened the duty. They were not a one-off exam. A launch-day audit, or a statement published once and then left alone, does not show the service still complies after the next release. Each defect needs an owner and a deadline, then a retest when the fix ships.

The regulations are not a blanket rule for every commercial site. The instrument as made sets defined exclusions, including public-service broadcasters, certain non-governmental organisations, some school and nursery content, and specific categories of third-party or archival material. A school intranet page of old newsletters is not the same legal object as a benefits form.

Where the Equality Act still applies

The 2018 regulations and the Equality Act 2010 are easy to collapse into one idea. The regulations name public-sector bodies, set a technical standard, and fix a timetable. The Equality Act can still apply to a service offered to the public when the organisation is a bank, a retailer, or a supplier to the NHS, and is not a public-sector body. A court or tribunal can ask whether inaccessible design put a disabled person at a disadvantage. No single rule lists every private website.

Practical rule: "We're not a council" starts the analysis. It does not end it.

Work through this check for each site and app:

1. Is the organisation a public-sector body? If yes, the 2018 regulations apply unless a defined exclusion covers that content.
2. Does the site or app deliver a service to the public? Booking, paying, applying and contacting all count.
3. Could a disabled user fail a core task? A keyboard trap on checkout is that kind of barrier.
4. Does a supplier control part of that task? A payment iframe or chat widget can break the journey outside your templates. Name an owner, set a fix date, and retest after that supplier's next release.

Any yes means you treat the relevant standard as binding. Passing it on the day you go live is not the same as still passing it after the next release.

WCAG 2.2 AA Requirements in Practice

Think of a shop. Customers need to see the door, reach the counter, understand the prices and trust the building. WCAG asks the same four things of a digital service, and those principles match the legal wording.

The Department for Education's accessibility standards page identifies the Web Content Accessibility Guidelines as the practical benchmark. Current government guidance refers to WCAG 2.2 at level AA, and public bodies must use the latest published version. Teams assess representative pages and functions. A single automated scan isn't proof.

Presumed compliance means satisfying Level A and Level AA success criteria, not a marketing line that says "we follow best practice".

Perceivable

People can take in the content. Every meaningful image has a text alternative, and video that carries speech has captions. Body text needs a contrast ratio of at least 4.5:1 against its background, or 3:1 for large text. A pale grey caption on a white card fails this even when the layout looks tidy.

Operable

People can use the controls. Every control works from the keyboard, the focus indicator stays visible, and nothing traps the user in a widget. Time limits can be extended. A modal that won't close with Escape is a common failure on booking flows.

Understandable

People can tell what to do next. Labels are attached to inputs, error messages say what went wrong and how to fix it, and navigation stays consistent. "Invalid input" on a date field doesn't meet that bar. "Enter the date as DD/MM/YYYY" does.

Robust

Assistive technology can read the page. Markup is valid and semantic, and custom components expose the right names and roles. A _div styled to look like a button often isn't announced as one.

WCAG 2.2 is where teams slip. Focus must not sit fully hidden behind a sticky header. Targets should be at least 24 by 24 CSS pixels. A drag action needs a single-pointer alternative. Help should appear in a consistent place. Don't ask users to re-enter information they already gave, such as an address copied from the previous step.

Documents travel with the site. If a form downloads a PDF, PDF accessibility tips from Documind are a useful check before you treat that file as out of scope. The same care belongs in component design, which is why inclusive design principles belong in the build, not in a post-launch tidy-up.

How to Test Your Website for Accessibility

For public-sector websites and apps, the 2018 regulations create a legally enforceable duty to make services perceivable, operable, understandable and resilient. GOV.UK guidance on making your website or app accessible treats compliance as presumed when content meets Level A and AA success criteria in the applicable WCAG. Delivery teams should treat that as an engineering acceptance criterion across templates, components, content and third-party integrations, not as a final visual audit. Map each AA criterion to automated tests, keyboard and screen-reader cases, and a manual review of journeys such as authentication, payments, forms and error recovery. Unresolved defects need an owner and a remediation date, because the public statement must describe known failures, alternatives and a feedback route.

Work in this order.

1. Map the journeys that complete a task. Sign-up, login, checkout, booking, contact and account changes matter most, because a barrier here stops the service.
2. Run an automated scan with axe or WAVE. These tools catch missing alt text and low contrast quickly. They can't judge whether a label makes sense or whether the reading order is logical, so the scan is a net, not a verdict.
3. Do a keyboard-only pass. Tab through each journey. Focus should be visible, the order should follow the task, and no control should trap the cursor. Checking keyboard support in UI components is a practical companion when a design system has custom menus.
4. Listen with a screen reader. Use NVDA on Windows, VoiceOver on macOS and iOS, or TalkBack on Android. Headings, button names and form errors should be announced without you looking at the screen.
5. Zoom to 200 per cent and narrow the viewport to 320 CSS pixels. Content should reflow. If the user must scroll sideways to reach a submit button, the layout has failed the task.
6. Break the forms on purpose. Check labels, required-field messages and whether someone can correct an error without starting again.
7. Include third parties. Payment iframes, chat widgets and embedded maps often fail outside your repository. If you don't control the code, you still own the journey.
8. Map each failure to a WCAG 2.2 AA criterion and rate severity by task impact. A contrast miss in the footer isn't the same as a keyboard trap on pay.
9. Log an owner and a target date, then retest after every release. That log is the evidence behind the statement and the remediation plan.

Pair the technical pass with observation of real tasks. Usability testing methods show where a journey fails even when the markup looks tidy. If you need engineering capacity for the fixes, web development should take the defect log as acceptance work, not as a separate clean-up project.

Writing an Accessibility Statement That Holds Up

Public-sector organisations must publish an accessibility statement as well as meet the standard. GOV.UK requirements for public-sector websites and apps say the statement should explain how accessible the service is and identify areas that don't meet the requirements. A disproportionate-burden claim can be available in the right circumstances. It doesn't remove the duty to assess, document the reasoning and offer an accessible alternative where possible. The statement is a public disclosure and an accountability mechanism.

A credible statement covers six things in plain language. Say how accessible the service is today. Name the parts that don't yet meet the requirements. If you rely on disproportionate burden, give the reasons and the alternative. Explain how someone can request the content in another format. Give a feedback route for reporting problems. Point to the enforcement route through the Equality Advisory and Support Service. Add the date of the last review and the date of the last test. Readers skip those dates, and auditors don't.

Use five headings you can copy:

• Status of the service. One or two sentences on what a user can and can't do.
• Known limitations. The specific failures, not a vague promise to improve.
• Non-accessible content and why. Exemptions, archival material or a documented burden claim.
• Feedback and contact. A named route, not a dead inbox.
• Enforcement. How to escalate if the feedback route fails.

Under known limitations, be specific. "The booking calendar can't be operated with a screen reader. Until 30 June you can book by phone on 0161 000 0000, Monday to Friday, 9am to 5pm. The calendar fix is owned by the digital team and is booked for the July release." That sentence is checkable. "We aim to be fully accessible" isn't.

A statement isn't proof the service is accessible. It's credible only when it names real failures and shows someone owns them.

Vague lines such as "fully accessible" or "WCAG compliant", with no test date and no defect list, are the first thing a complainant will compare with your logs. If the logs don't match, the statement makes the position worse.

Fixing Defects and Confirming Your Obligations

A launch checkbox doesn't hold. Between January 2022 and September 2024, the Government Digital Service assessed 1,203 public-sector websites and 21 mobile applications and identified 29,787 accessibility issues, according to the accessibility monitoring report for 2022 to 2024. Public-sector organisations fixed 16,482 of them, 55.3%. After reports, organisations normally had around 12 weeks to respond, and 68% had either fixed the problems or set a short-term plan. More than a third had done neither. A separate measure found that 85% had published an accessibility statement, which shows a statement can exist while defects remain.

Who follows up

Public bodies face complaints through the enforcement route in the statement, plus GDS monitoring. Private firms don't get that monitoring letter. They face Equality Act claims, typically in the county court, where the question is disadvantage, not whether a badge was published. Weak records also create procurement risk when a buyer asks for test evidence.

What to fix first

Work in this order, and don't sort the backlog alphabetically.

• Critical barriers that block a task, such as checkout or login.
• High-traffic pages, where the same defect hits more people.
• Lower-impact issues, including contrast on secondary content. Colour-blind friendly colours help you separate a real contrast failure from a brand preference.

Give every defect an owner and a deadline. Record limitations you can't fix yet, in the statement, with the alternative. Retest after each release, including dependency updates. Supplier contracts should require accessible components, accessible content you don't write yourselves, and test evidence for third-party integrations. "WCAG compliant" in a brief, with no acceptance tests, doesn't transfer the duty.

A sequence for this month

Within one week, run the applicability check for each service you operate. Within two weeks, test your three most important journeys and log every defect. Within a month, publish or update the statement with known limitations, a feedback route and a review date. Then add a retest step to the release checklist so it isn't optional.

We build accessibility into products as standard, and accessibility, speed and security are tested before anything goes public. Web development here includes CMS builds, API integrations, performance optimisation and accessibility work. For Edinburgh Council we consolidated five venue websites into one accessible platform with Spektrix ticketing built in, which is the sort of multi-site problem public bodies face. Similar release discipline shows up in work for H2OiQ and Cultaholic. If you want an audit and a remediation plan, talk to us. See the Edinburgh Council platform if you want a public-service example. This article is general information, not legal advice. A specific legal question needs a qualified solicitor.

Frequently Asked Questions

Do private companies need an accessibility statement?

No. The 2018 regulations don't require a private company to publish one, because they apply to public bodies. A statement is still strong evidence that you've looked for barriers under the Equality Act 2010. Publish one if the site handles bookings, payments or contact requests. List what doesn't yet work, how users report problems, and when you last tested. Draft it this week and refine it after the next audit.

Does an automated scan prove my website complies?

No. Tools such as axe or WAVE catch missing alt text and low contrast. They can't judge meaning, focus order or whether a form error makes sense. Compliance is assessed by sampling representative pages and functions against Level A and AA criteria in WCAG 2.2. Combine the scan with keyboard and screen-reader testing of key journeys, then keep the results as evidence.

What happens if a public body's site fails the requirements?

Users report problems through the feedback route in the statement, and unresolved issues can go to the Equality Advisory and Support Service. The Government Digital Service monitors reported public-sector sites and checks whether organisations fix issues or publish a plan. Weak records create reputational and procurement risk. Keep dated test logs and remediation plans, because an auditor or complainant will ask for them first.

How often should I retest my website?

Retest after every significant release. New features and third-party updates reintroduce barriers. Run a fuller review at least once a year, and check your three most important journeys with each release. Log each result against the relevant WCAG 2.2 AA criterion, with an owner and a date. Put the retest on the release checklist so it happens without a separate decision.

About the Author

Hamish Kerry is a member of the Arch team who writes about accessible digital product design. His interests include AI, app and web development, and how emerging technologies can support meaningful change.

Hamish's LinkedIn: https://www.linkedin.com/in/hamish-kerry/

Arch builds websites and apps with accessibility included as standard. For help planning and maintaining accessible digital products, contact the Arch team.