Website Accessibility Requirements in the US and UK: What Business Owners Need to Know About WCAG
If you run a business website in the United States or the United Kingdom, accessibility is no longer something to leave for a later phase. Regulators in both countries treat an unusable website as a barrier to disabled customers, and one technical standard, WCAG, keeps appearing in the rules. This guide explains what website accessibility requirements look like in the US and UK, what WCAG actually asks for, and how to audit and fix a site without wasting money.
This article is general information based on official guidance available on October 4, 2026. It is not legal advice. Ask a qualified lawyer how the rules apply to your organization.
Quick answer
- The standard: WCAG 2.2 is the current version of the Web Content Accessibility Guidelines from the W3C. Level AA is the level most rules and contracts refer to.
- US: The Department of Justice says the Americans with Disabilities Act (ADA) applies to what businesses open to the public offer on the web. A specific standard, WCAG 2.1 Level AA, is written into the rule for state and local governments. Federal agencies follow Section 508.
- UK: The Equality Act 2010 requires service providers to make reasonable adjustments for disabled people. Public sector bodies must also meet WCAG 2.2 AA and publish an accessibility statement.
- EU: The European Accessibility Act has applied to covered services, including e-commerce, since June 28, 2025.
- In practice: Build and test to WCAG 2.2 AA, combine automated scans with manual checks, and do not rely on an overlay widget to do the work.
What web accessibility means and who it helps
The W3C describes web accessibility as websites, tools and technologies being designed and developed so that people with disabilities can use them. That covers auditory, cognitive, neurological, physical, speech and visual disabilities.
In practical terms it means a blind customer can complete your checkout with a screen reader, someone who cannot use a mouse can reach every button with a keyboard, and a deaf viewer can follow your product video through captions.
The same W3C page points out that accessible design also helps people without disabilities: older users, people on small screens, someone with a broken arm, someone reading a phone in bright sunlight, and people on slow or expensive connections. Clear labels, readable contrast and predictable navigation make a site easier for everyone.
WCAG explained: versions and conformance levels
WCAG is published by the World Wide Web Consortium (W3C). According to the W3C overview, WCAG 2.2 was published on October 5, 2023, with an update on December 12, 2024, and it is also an ISO standard (ISO/IEC 40500:2025). Its 13 guidelines sit under four principles: content must be perceivable, operable, understandable and robust.
Three points matter for planning:
- Versions build on each other. The W3C states that content conforming to WCAG 2.2 also conforms to 2.1 and 2.0. Meeting 2.2 therefore satisfies rules that still cite an older version.
- WCAG 2.2 added nine success criteria over 2.1, covering areas such as focus visibility, minimum target size, alternatives to dragging and accessible authentication. The W3C lists them on its What's New in WCAG 2.2 page.
- WCAG 3 is not ready. The W3C's WCAG FAQ says it is years away from completion. It is a draft, so do not plan around it.
Levels A, AA and AAA
| Level | What it means | How businesses use it |
|---|---|---|
| A | Meets all Level A success criteria, the most basic set. | A floor, not a target. Failing Level A usually blocks some users completely. |
| AA | Meets all Level A and Level AA criteria. | The level named in the US state and local government rule, Section 508 and the UK public sector regulations. The sensible target for most sites. |
| AAA | Meets all A, AA and AAA criteria. | Useful for selected pages or audiences. The W3C does not recommend requiring it as a general policy for entire sites, because some content cannot satisfy every AAA criterion. |
The W3C also states that conformance applies to full web pages. A page with one inaccessible component, such as a third-party booking form, does not conform.
The legal position in the US
Businesses open to the public (ADA Title III)
The Department of Justice's Guidance on Web Accessibility and the ADA says the Department has consistently taken the position that the ADA's requirements apply to all the goods, services, privileges or activities offered by public accommodations, including those offered on the web. "Public accommodations" is the ADA term for businesses open to the public.
The same guidance says businesses have flexibility in how they comply with the ADA's general requirements, and it points to WCAG and the Section 508 standards as helpful references. In other words, the guidance describes the obligation but does not prescribe one technical standard for private businesses.
State and local governments (ADA Title II)
Here a standard is fixed. The Department's fact sheet on the web and mobile app rule names WCAG 2.1 Level AA as the technical standard for state and local governments' web content and mobile apps. The fact sheet records that an Interim Final Rule published on April 20, 2026 extended the compliance dates: April 26, 2027 for entities with a population of 50,000 or more, and April 26, 2028 for smaller entities and special district governments.
This rule does not cover private businesses directly. It matters if you build or supply websites, portals or apps for public bodies, because your product will need to meet the standard they are held to.
Federal agencies (Section 508)
Section 508 of the Rehabilitation Act requires federal agencies to make their information and communication technology accessible. The Revised 508 Standards apply to technology that agencies procure, develop, maintain or use, and they incorporate the WCAG 2.0 Level A and AA success criteria. If you sell software to a federal agency, expect accessibility to be part of procurement.
The legal position in the UK
Private businesses (Equality Act 2010)
The government's disability quick start guide for service providers explains that the Act applies to all service providers in Great Britain, whether or not a charge is made. Providers must think ahead and take steps to address barriers that impede disabled people, rather than waiting until a disabled person has difficulty. What counts as reasonable depends on the circumstances, including cost, the organization's resources and how practical the change is.
The 2026 Code of Practice for services, public functions and associations, published on GOV.UK, states that the obligation also applies to the provision of services on a website. The guidance we reviewed does not set a named WCAG level for private businesses, which is why most organizations adopt WCAG 2.2 AA as a working benchmark.
Public sector bodies
GOV.UK's guidance on the public sector accessibility regulations is specific. Public sector websites and mobile apps meet the legal requirement if they meet WCAG 2.2 AA, and the body must publish an accessibility statement. The Government Digital Service monitors compliance, and the Equality and Human Rights Commission (in Northern Ireland, the Equality Commission for Northern Ireland) can use its legal powers, including investigations, unlawful act notices and court action.
Selling into the EU: the European Accessibility Act
The European Accessibility Act (Directive 2019/882) sets common accessibility rules for certain products and services, including e-commerce, banking services, e-books and passenger transport services. The EU's Your Europe business guidance says the requirements apply to products and services placed on the market after June 28, 2025, and that a service-based business with fewer than 10 employees and under EUR 2 million in turnover is exempt.
The Act is a directive, so each member state applies it through its own national law. If your US or UK business sells to consumers in EU countries, take advice on whether and how those national laws reach you. We did not find a plain statement on that point in the official pages we reviewed.
At a glance
| Jurisdiction | Who is covered | Standard named in official guidance |
|---|---|---|
| US, ADA Title III | Businesses open to the public | None prescribed; WCAG and Section 508 cited as helpful |
| US, ADA Title II | State and local governments | WCAG 2.1 Level AA |
| US, Section 508 | Federal agencies and the technology they buy or use | WCAG 2.0 Level A and AA |
| UK, Equality Act 2010 | Service providers in Great Britain | None named in the guidance reviewed; reasonable adjustments duty |
| UK, public sector regulations | Public sector bodies | WCAG 2.2 Level AA plus an accessibility statement |
| EU, European Accessibility Act | Providers of covered services such as e-commerce, with a microenterprise exemption | Set through national law in each member state |
The most common accessibility failures and how to fix them
WebAIM's annual automated analysis of one million home pages gives a useful picture of where sites go wrong. Its February 2026 report found detectable WCAG 2 failures on 95.9 percent of home pages, and six issue types account for most of them. These are automated findings only, so the real number of problems is higher.
| Failure | Share of home pages (WebAIM 2026) | Typical fix |
|---|---|---|
| Low contrast text | 83.9 percent | Adjust brand colors or text colors to meet contrast ratios; fix it once in the design system. |
| Missing image alternative text | 53.1 percent | Add meaningful alt text; mark decorative images as decorative; make alt text a required CMS field. |
| Missing form input labels | 51 percent | Give every field a programmatic label, not just placeholder text. |
| Empty links | 46.3 percent | Give icon links, such as social icons, an accessible name. |
| Empty buttons | 30.6 percent | Label icon-only buttons such as menu, search and close. |
| Missing document language | 13.5 percent | Declare the page language in the template; a one-line change. |
The Department of Justice guidance lists a similar set of barriers and adds three that scanners often miss: using color alone to convey information, videos without captions, and sites that cannot be operated with a keyboard.
Most of these are cheap to fix in shared templates and components. The expensive problems are structural: custom widgets built without keyboard support, checkout flows from third parties, and large libraries of PDFs.
Why overlay widgets are not a substitute
Overlays are scripts that add a toolbar to your site and claim to repair accessibility problems automatically. Two official sources justify caution.
First, the Department of Justice web guidance says automated accessibility checkers and overlays need to be used carefully, and that a clean report does not necessarily mean everything is accessible.
Second, in January 2025 the Federal Trade Commission announced an order requiring accessiBe to pay USD 1 million over allegations that it misrepresented the ability of its accessWidget product to make any website WCAG compliant. The FTC alleged that the product did not make all user websites compliant.
The practical reason is simple. A script added on top of a page cannot reliably know what an image shows, what a form field is for, or how a custom component should behave. Those problems live in the source code and content, and that is where they need fixing.
How to audit your website
The W3C's evaluation guidance is blunt: no tool alone can determine whether a site meets accessibility standards, and knowledgeable human evaluation is required. A sensible audit has four layers.
- Automated scan. Run a scanner across key templates to catch contrast, labels, alt text and similar issues. This is fast and finds only part of the picture.
- Manual checks. Work through the W3C Easy Checks: page titles, headings, keyboard access and visible focus, text resizing, forms and error messages, and media alternatives. Try completing your main user journey with the keyboard only.
- Assistive technology testing. Test key journeys with a screen reader on desktop and mobile. Where possible, involve disabled users, which the W3C also recommends.
- Structured report. For a formal assessment, the W3C's WCAG-EM methodology describes how to sample pages and report results against each success criterion.
Audit cost and duration depend on the number of unique templates and components, the complexity of interactive features, how much third-party code is embedded, and the volume of documents and video. Page count alone is a poor guide: a 5,000-page site built from eight templates is less work than a 40-screen web application with custom controls.
Prioritize fixes by user impact. Blockers on revenue or service journeys (login, search, checkout, contact forms) come first, followed by template-level issues that repeat across the site.
Building accessibility into a new project
Retrofitting is always more expensive than building correctly. For a new website or web application, put these in place from the start:
- Write the target into the contract. Name "WCAG 2.2 Level AA" in the requirements and acceptance criteria, including for third-party components. If you are hiring an outside team, our guide on how to outsource software development covers how to specify requirements like this.
- Design for it. Check color contrast, focus states, target sizes and error messages at the UI and UX design stage, before any code is written.
- Use an accessible component library. Fix a button, modal or date picker once and every page inherits it.
- Test continuously. Add automated checks to the build pipeline and a manual keyboard and screen reader pass before each release.
- Train content editors. Alt text, heading order, link text and captions are content decisions, and they break after launch if nobody owns them.
- Publish an accessibility statement. It is mandatory for UK public sector bodies and good practice for everyone else: say what standard you target, known gaps and how to report a problem.
For technical readers
- Start with semantic HTML: native buttons, links, form controls, headings and landmarks. Use ARIA only where native elements cannot express the pattern.
- Manage focus deliberately in single-page applications: move focus on route changes, trap it in modals and return it on close.
- Note the WCAG 2.2 additions at AA: Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Target Size (2.5.8) and Accessible Authentication (3.3.8). The W3C also lists 4.1.1 Parsing as obsolete and removed in 2.2.
- Run an accessibility rules engine in continuous integration against rendered components, and treat new violations as build failures.
- Audit third-party embeds (chat, payments, consent banners, maps) separately, since they count toward page conformance.
Frequently asked questions
Is WCAG compliance legally required for my business website?
It depends on who you are and where you operate. WCAG is written into the rules for US state and local governments, US federal agencies and UK public sector bodies. For private businesses, the official US and UK guidance reviewed here describes a duty not to exclude disabled people but does not prescribe a WCAG level. WCAG 2.2 AA is the benchmark most organizations work to. A lawyer can advise on your position.
Should I target WCAG 2.1 or WCAG 2.2?
Target WCAG 2.2 Level AA. The W3C confirms that content conforming to 2.2 also conforms to 2.1 and 2.0, so you cover rules that cite older versions as well.
Does accessibility apply to mobile apps?
Yes, in the regimes that name a standard. The US state and local government rule covers web content and mobile apps, and the UK public sector regulations cover websites and mobile apps. The same principles apply to any customer-facing app.
Can an accessibility plugin or overlay make my site compliant?
Do not assume so. The Department of Justice says overlays need to be used carefully, and the FTC took action against one overlay vendor over claims that its product could make any website WCAG compliant. Fix the underlying code and content.
How often should a site be audited?
There is no single official interval for private businesses. A practical approach is automated checks on every release, a manual review after any significant redesign or new feature, and a full audit periodically. UK public sector bodies are required to review their accessibility statement regularly.
Does the European Accessibility Act affect UK or US companies?
It can be relevant if you provide covered services, such as e-commerce, to consumers in EU member states. The rules are applied through national laws and there is an exemption for service microenterprises, so get advice specific to the countries you sell into.
Conclusion and next step
The rules differ in detail between the US, the UK and the EU, but they point to the same working answer: build and maintain your site to WCAG 2.2 Level AA, verify it with both tools and people, and fix problems in the code and content rather than covering them with a widget.
A good first step is small. Spend an hour running the W3C Easy Checks on your home page and your most important journey, using only a keyboard. The results will tell you whether you need a few template fixes or a full audit. If you would like a development team to review an existing site or scope accessibility into a new build, you can request a quote and describe what you have.