If your business offers services to the public, accessibility law probably already covers your website. In the UK, the Equality Act 2010 requires service providers to make reasonable adjustments for disabled people. In the EU, the European Accessibility Act has applied to e-commerce and other consumer services since 28 June 2025, with an exemption for service microenterprises. In the US, the Department of Justice says the ADA applies to the websites of businesses open to the public. In all three, meeting WCAG 2.2 Level AA is the practical benchmark.
The three laws at a glance
| UK: Equality Act 2010 | EU: European Accessibility Act | US: ADA Title III | |
|---|---|---|---|
| Who is covered | Anyone providing services, goods or facilities to the public in Great Britain, of any size | Businesses providing covered products and services to consumers in the EU, including e-commerce | Businesses that are "public accommodations" (open to the public) |
| Small business exemption | None, but what is "reasonable" depends on size and resources | Service microenterprises (under 10 staff and up to €2m turnover or balance sheet) are exempt for services | None, though there are limited defences such as undue burden |
| Mentions websites? | No; applies to services however delivered | Yes; covers websites and apps for covered services | Not in the Act; DOJ guidance says it covers web services |
| Technical standard | None in law; WCAG used as the benchmark | Harmonised European standards (EN 301 549, based on WCAG) | None in a regulation for businesses; WCAG used in guidance and settlements |
| In force | Since October 2010 | Applies from 28 June 2025 | Since 1990; DOJ web guidance March 2022 |
| Enforcement | Individual claims in the county court (England and Wales) or sheriff court (Scotland); the Equality and Human Rights Commission | National market surveillance authorities in each EU country; penalties set nationally | DOJ and private lawsuits |
UK: the Equality Act 2010
Who is covered
Section 29 of the Equality Act 2010 says a person providing a service to the public must not discriminate against a person requiring the service. That includes businesses of every size, and it includes services provided online. Section 20 sets out the duty to make reasonable adjustments. Schedule 2 applies that duty to service providers.
What the duty means for a website
- It is anticipatory. For services, the duty is owed to disabled people generally, not only to a person who has already complained. You are expected to think ahead about barriers.
- It is about "substantial disadvantage". If a disabled person is put at a substantial disadvantage compared with non-disabled people, for example they cannot book, buy or contact you because the site does not work with a screen reader or keyboard, you must take reasonable steps to avoid it.
- "Reasonable" depends on you. Cost, practicality, the size of your business and how much difference a change makes all count. Fixing missing form labels on a booking form is very likely to be reasonable. Rebuilding an entire site overnight may not be.
- Section 20(6) says that where the disadvantage relates to providing information, reasonable steps include providing it in an accessible format.
The Equality and Human Rights Commission's statutory Code of Practice on services explains the duty in more detail. The Equality Act applies in England, Wales and Scotland. Northern Ireland has its own disability discrimination law.
What about the UK public sector rules?
The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 set a specific standard and require an accessibility statement. They apply to public sector bodies, not to private small businesses, unless you deliver a public service on a public body's behalf.
EU: the European Accessibility Act
The European Accessibility Act (EAA) is Directive (EU) 2019/882. EU countries had to apply their national laws from 28 June 2025.
What it covers
It covers certain products (such as computers, smartphones, self-service terminals and e-readers) and certain services provided to consumers. The services include e-commerce, consumer banking, e-books, electronic communications, and websites and apps for passenger transport services. For a typical small business the key one is e-commerce: selling goods or services to consumers online.
The microenterprise exemption
Article 4(5) says microenterprises that provide services are exempt from the accessibility requirements and related obligations for those services. Article 3 defines a microenterprise as one that employs fewer than 10 persons and has an annual turnover not exceeding €2 million or an annual balance sheet total not exceeding €2 million.
- The exemption is for services only. A microenterprise that makes or imports covered products is not exempt for those products.
- Businesses above the threshold can claim a "disproportionate burden" exemption only on the specific grounds and with the assessment the Directive sets out. It is not a general opt-out.
- There are transitional periods. Service contracts agreed before 28 June 2025 may continue unchanged until they expire, but for no more than five years from that date. Countries may let service providers keep using products they lawfully used before 28 June 2025 until 28 June 2030.
Does it apply to UK businesses?
The EAA is not part of UK law. But if a UK business sells to consumers in the EU, the law of the EU country where it offers its service can apply. If you have more than 10 staff or more than €2 million turnover and you actively sell to EU consumers online, check the national law of the countries you sell into.
The harmonised standard used to show compliance is EN 301 549, which for web content is based on WCAG Level AA. Building to WCAG 2.2 AA covers WCAG 2.1 AA too, because 2.2 adds criteria and removes only one obsolete one.
US: the ADA
Title III and websites
Title III of the Americans with Disabilities Act covers "public accommodations": businesses open to the public, such as shops, restaurants, hotels, doctors' and lawyers' offices. The Department of Justice's Guidance on Web Accessibility and the ADA, dated 18 March 2022 and still published on ADA.gov, says the ADA's requirements apply to all the goods, services, privileges or activities offered by public accommodations, including those offered on the web.
The same guidance says businesses have flexibility in how they comply, points to WCAG as helpful technical guidance, and states that it has no binding legal effect. There is no DOJ regulation setting a web standard for private businesses. Courts have also differed on whether a business that exists only online is a "place of public accommodation". Even so, WCAG is the standard most demand letters and settlements refer to.
Title II is different
In April 2024 the DOJ issued a rule requiring state and local governments to meet WCAG 2.1 Level AA. On 20 April 2026 it published an interim final rule extending the compliance dates by one year: 26 April 2027 for public entities serving 50,000 people or more, and 26 April 2028 for smaller ones. This rule applies to government bodies, not to private businesses, but it shows which standard the DOJ uses.
WCAG 2.2 AA explained simply
The Web Content Accessibility Guidelines (WCAG) are published by the W3C. WCAG 2.2 became a W3C Recommendation on 5 October 2023. It has success criteria at three levels: A (minimum), AA (the usual target) and AAA (highest). "Meeting AA" means meeting every Level A and Level AA criterion.
The criteria are grouped under four principles. Content must be:
- Perceivable: people can see or hear it, for example images have text alternatives and text has enough contrast.
- Operable: people can use it, for example with a keyboard only, and with enough time.
- Understandable: it is clear and predictable, for example forms explain errors.
- Robust: it works with assistive technology such as screen readers.
WCAG 2.2 added nine success criteria. Those at Level A and AA are:
| Criterion | Level | What it means |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | When you tab to a control, sticky headers, cookie banners or chat widgets must not completely hide it |
| 2.5.7 Dragging Movements | AA | Anything you can do by dragging (sliders, maps, reordering) can also be done with simple taps or clicks |
| 2.5.8 Target Size (Minimum) | AA | Tap and click targets are at least 24 by 24 CSS pixels, or have enough space around them, with some exceptions |
| 3.2.6 Consistent Help | A | Help options such as a phone number or contact link appear in the same place across pages |
| 3.3.7 Redundant Entry | A | Do not make people re-type information they already gave in the same process |
| 3.3.8 Accessible Authentication (Minimum) | AA | Logging in must not depend on a memory or puzzle test without an alternative, for example allow password managers and pasting |
WCAG 2.2 also removed criterion 4.1.1 Parsing, which the W3C describes as obsolete.
The top fixes for a small business website
These cover many of the barriers disabled visitors meet on small sites, and most can be fixed without a rebuild.
- Alt text on images (WCAG 1.1.1, Level A). Every meaningful image needs a short
altdescription of what it shows or does. A logo that links home:alt="Smith Plumbing, home". Purely decorative images get an emptyalt=""so screen readers skip them. - Labels on every form field (1.3.1, 3.3.2, 4.1.2). Each input needs a visible label linked to it, for example
<label for="email">Email</label>withid="email"on the field. Placeholder text that disappears when you type is not a label. - Colour contrast (1.4.3 and 1.4.11, Level AA). Normal text needs a contrast ratio of at least 4.5:1 against its background; large text at least 3:1. Buttons, input borders and icons that you need to see need 3:1. Pale grey text on white is the most common failure.
- Keyboard access (2.1.1, Level A) and visible focus (2.4.7, Level AA). Put your mouse away and press Tab. You should be able to reach every link, button, menu and form field, see where you are, and use them with Enter or Space. Menus that only open on hover and custom buttons made from
divelements often fail. - Page language (3.1.1, Level A). Set it in the HTML, for example
<html lang="en-GB">. Screen readers use it to choose the right pronunciation. - Meaningful link text (2.4.4, Level A). "Read more" repeated ten times tells a screen reader user nothing. Say where the link goes: "Read more about boiler servicing".
- Headings in order (1.3.1). Use real heading elements (
h1,h2,h3) for structure, not bold text. Screen reader users jump between headings to find content. - Captions on video (1.2.2, Level A). Pre-recorded video with speech needs captions.
- Do not rely on colour alone (1.4.1, Level A). If a form error is shown only by a red border, add text that says what is wrong.
- Make the cookie banner and chat widget accessible too. They are often the first thing a visitor meets. They must be reachable by keyboard and must not hide focused content (2.4.11).
What automated checks can and cannot find
The W3C puts it plainly: evaluation tools "can not determine accessibility, they can only assist in doing so", and human judgement is required. In practice:
| Automated checks reliably find | Needs a person to check |
|---|---|
Images with no alt attribute | Whether the alt text actually describes the image usefully |
| Form fields with no programmatic label | Whether labels and error messages are clear |
| Text colours below the contrast ratio (where the background can be determined) | Contrast of text over images and gradients |
Missing lang on the page | Whether the reading order makes sense |
| Empty links and buttons, duplicate IDs, some ARIA misuse | Whether the whole site can be used with a keyboard from start to finish |
| Skipped heading levels | Whether a screen reader user can complete a booking or purchase |
| Small tap targets (some cases) | Whether captions are accurate and video has audio description where needed |
SiteVerdict runs automated WCAG 2.2 checks of the first kind. Use them to find and fix the mechanical problems quickly, then do a short manual test: tab through your key pages, try your contact or booking form with the keyboard only, and if you can, try it with a screen reader such as NVDA (free, Windows) or VoiceOver (built into Mac and iPhone).
Overlays and widgets
Some products add a toolbar or script that claims to make a site accessible automatically. A widget does not change the underlying code, so missing labels, keyboard traps and poor structure usually remain. Fix issues at source, in your theme, content and forms.
A sensible plan for a small business
- Run an automated check on your homepage, contact page and any booking or checkout page.
- Fix alt text, form labels, contrast and page language first. These are usually quick.
- Do the keyboard test on the same pages and fix anything you cannot reach or see.
- Ask your web developer or platform which theme settings affect contrast, focus outlines and menus.
- Add a short accessibility page: what you have done, known issues, and how people can contact you for help or an alternative. This is not required by law for most private businesses, but it helps visitors and shows reasonable steps.
- Re-check after redesigns, new plugins or new forms.