Website Accessibility for US (ADA) and UK Businesses: WCAG 2.2 Guide

Accessibility used to be treated as a nice-to-have. In the US it is now a steady source of demand letters and lawsuits, and in the UK it sits inside equality law that already applies to every business serving the public.

The rules differ between the two countries, and between private companies and public bodies, but the technical answer is the same: build to the Web Content Accessibility Guidelines (WCAG), test with real assistive technology and fix problems in the code.

This guide explains the legal position in the US and UK as of October 2026, what WCAG 2.2 AA asks for, a practical checklist, the tools to test with, and why overlay widgets are not a shortcut.

What Does the Law Require for Website Accessibility in the US?

In the US, the Americans with Disabilities Act (ADA) applies to websites in two ways. Title III covers businesses open to the public and has no detailed web regulation; Title II covers state and local governments and now has a specific rule requiring WCAG 2.1 Level AA.

Title III: Private Businesses

The Department of Justice (DOJ) guidance published in March 2022 states that businesses open to the public must provide full and equal enjoyment of their goods and services to people with disabilities, including online. It also says the DOJ "does not have a regulation setting out detailed standards", so businesses can choose how they make their sites accessible, while pointing to WCAG and the federal Section 508 Standards as helpful guidance.

In practice, that flexibility is where the litigation comes from. Without a safe-harbour standard, plaintiffs test sites against WCAG and file claims where barriers exist. Seyfarth Shaw's annual count found 3,117 federal website accessibility lawsuits in 2025, up 27% on 2024, with New York (1,021) and Florida (961) leading. The authors note that many more demand letters and state court cases are not included in those numbers.

Title II: State and Local Government

In April 2024 the DOJ published a rule requiring state and local government web content and mobile apps to meet WCAG 2.1 Level AA. An interim final rule published on 20 April 2026 extended the compliance dates by one year:

• 26 April 2027 for public entities serving a total population of 50,000 or more;
• 26 April 2028 for entities serving fewer than 50,000 people and for special district governments.

The rule applies whether a public entity builds content itself or through a contractor, and it explicitly covers mobile apps provided by or for the entity. If you supply software or websites to US public bodies, expect WCAG 2.1 AA in your contracts.

What Does UK Law Require for Website Accessibility?

In the UK, the Equality Act 2010 requires all service providers, including private businesses, to make reasonable adjustments for disabled people, and that duty covers websites. Public sector bodies have an additional, specific duty to meet WCAG 2.2 AA and publish an accessibility statement.

Private Businesses: The Equality Act 2010

The reasonable adjustments duty for services is anticipatory: providers should think in advance about the barriers disabled people may face rather than wait for a complaint. The draft statutory code of practice for services, laid before Parliament in 2026, states plainly that "the obligation also applies to the provision of services on a website", and advises providers to review accessibility regularly.

Public Sector: The 2018 Regulations

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 require public sector websites and apps to meet WCAG 2.2 AA, according to current GOV.UK guidance. Bodies must publish and regularly review an accessibility statement explaining how accessible the service is and any exemptions or disproportionate burden claims.

The Government Digital Service monitors compliance through sampling, and the Equality and Human Rights Commission (EHRC) in Great Britain and the Equality Commission for Northern Ireland (ECNI) enforce it.

How Do US and UK Accessibility Rules Compare?

Both countries expect accessible websites; the difference is how explicit the technical standard is and who enforces it. Private businesses in both countries face a general duty, while public bodies face a named WCAG level.

If you sell into the EU as well, check the European Accessibility Act requirements for in-scope products and services separately; they are outside the scope of this guide.

What Is WCAG 2.2 AA and What Changed from 2.1?

WCAG 2.2 is the current W3C accessibility standard, published as a Recommendation in October 2023. Level AA is the conformance level laws and contracts usually reference. WCAG 2.2 keeps the 2.1 criteria except 4.1.1 Parsing, which was removed, and adds nine new success criteria.

The new criteria at Levels A and AA, which are the ones most organisations must meet, are:

• 2.4.11 Focus Not Obscured (Minimum), AA: sticky headers, cookie banners and chat widgets must not completely hide the element that has keyboard focus.
• 2.5.7 Dragging Movements, AA: anything done by dragging, such as sliders or reordering, needs a single-pointer alternative.
• 2.5.8 Target Size (Minimum), AA: pointer targets of at least 24 by 24 CSS pixels, with listed exceptions.
• 3.2.6 Consistent Help, A: help options such as contact details or chat appear in the same relative place across pages.
• 3.3.7 Redundant Entry, A: do not make users re-enter information they already gave in the same process.
• 3.3.8 Accessible Authentication (Minimum), AA: no cognitive tests such as remembering or transcribing a password without an alternative; allow paste and password managers.

Because 2.2 is a superset of 2.1 in all practical respects, meeting WCAG 2.2 AA also satisfies a WCAG 2.1 AA requirement.

What Should a Website Accessibility Checklist Cover?

Start with the failures that appear most often, then work through structure, interaction and content. WebAIM's 2026 analysis of a million home pages found detectable WCAG failures on 95.9% of them, with low-contrast text, missing image alternative text, missing form labels, empty links, empty buttons and missing page language accounting for 96% of detected errors.

1. Colour contrast: text and essential icons meet AA contrast ratios in every state, including hover, focus and disabled.
2. Text alternatives: informative images have meaningful alt text; decorative images have empty alt attributes.
3. Forms: every field has a visible, programmatically associated label; errors are described in text and linked to the field.
4. Links and buttons: each has an accessible name that makes sense out of context; icon-only buttons are labelled.
5. Language: the page declares its language, and passages in another language are marked up.
6. Keyboard: everything works with a keyboard alone, focus order is logical, and the focus indicator is clearly visible.
7. Headings and landmarks: one logical heading outline and proper header, nav, main and footer regions.
8. Media: captions for video, transcripts for audio, and no autoplaying sound.
9. Motion and timing: carousels can be paused; animations respect reduced-motion settings; time limits can be extended.
10. Documents: PDFs that users need to complete a task are accessible or offered in an accessible alternative format.
11. WCAG 2.2 additions: focus not hidden by sticky elements, adequate target sizes, drag alternatives and accessible login.

Which Tools Should You Use to Test Accessibility?

Use automated tools to catch the obvious, repeatable errors and manual testing to find the rest. Automated scanners detect only a portion of WCAG issues; keyboard and screen reader testing by a person is essential.

• Automated scanners: axe DevTools, WAVE and Google Lighthouse in the browser; axe-core or Pa11y in your build pipeline so regressions fail before release.
• Screen readers: NVDA or JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android.
• Keyboard-only pass: unplug the mouse and complete key journeys such as search, sign-up and checkout.
• Zoom and reflow: check the page at 200% and 400% zoom and at narrow widths.
• Contrast checkers: for brand palettes during design, not after build.
• User testing: where possible, include disabled users in research; they will find problems no checklist anticipates.

Accessibility is also easiest to fix during a rebuild. If you are planning one, add it to your website redesign checklist from the start, alongside performance and SEO.

Do Accessibility Overlay Widgets Make a Website Compliant?

No. Overlay widgets, the toolbars and scripts that claim to fix accessibility automatically, cannot make a website conformant on their own, and relying on them has drawn regulatory action. The DOJ itself cautions that automated checkers and overlays "need to be used carefully".

In January 2025 the US Federal Trade Commission (FTC) announced a complaint alleging that accessiBe misrepresented the ability of its AI-powered tool to make any website WCAG compliant; the order, finalised in April 2025, required the company to pay 1 million US dollars. The Overlay Fact Sheet, signed by over a thousand accessibility practitioners and disabled users, states that "full compliance cannot be achieved with an overlay" and recommends fixing issues at their source.

Overlays can also conflict with the assistive technology people already use, and some signatories raise privacy concerns about tools that detect assistive technology. Budget for remediation in code instead.

How Should B2B and Ecommerce Sites Prioritise Accessibility Work?

Prioritise the journeys that generate revenue or leads, then templates, then long-tail content. A fully accessible blog with an inaccessible checkout or quote form still excludes customers and still carries legal risk.

For ecommerce, that means product discovery, product pages, cart and checkout. For B2B, it means service pages, case studies, contact forms and any client portal; our guide to B2B website design covers how these pages should work. For a new site, build accessibility in from the first design; see what a first business website needs.

Organisations working across regions should apply one standard everywhere. A bilingual site for the Gulf benefits from the same WCAG work, as covered in our guide to website design in the UAE.

How VEATEX Helps

VEATEX is a Shopify, web and software development agency that also builds Peppol e-invoicing platforms for the GCC, working with clients in the US, UK and the Gulf for over 11 years. We build websites and Shopify themes to WCAG 2.2 AA, fix accessibility issues in templates and components rather than with overlays, and add automated checks to release pipelines. Explore our website design and development services or ask us to review your site.