Accessibility laws worldwide, and where to start your audit

A few years ago, is our website legally required to be accessible? had a comfortable answer for most private companies. Probably not. The laws applied to you only if you were a government body or worked in a heavily regulated sector. That answer no longer holds. Country by country, the law has caught up with the web, and the places where it hasn't are getting harder to find.

If you sell to people in Europe, serve a public in North America, or operate in the UK or Australia, some version of this duty now reaches you. The laws are converging on a single technical standard, so learning what compliance means once covers most of the markets you're likely to care about.

WCAG is the standard nearly every accessibility law points at

Nearly every accessibility law in the world points, directly or in effect, at the Web Content Accessibility Guidelines from the W3C, known as WCAG. Most name WCAG 2.1 Level AA as the bar to clear, and its spirit fits in four words. Content should be perceivable, operable, understandable and robust for everyone.

In Europe the standard carries a European label, EN 301 549, but underneath it is WCAG. The next version of EN 301 549, expected during 2026, moves the reference up to WCAG 2.2. So while the legal wrappers differ from country to country, the thing you actually build and test against barely changes. One measuring stick satisfies compliance in many jurisdictions at once.

Accessibility laws, country by country

European Union. Two laws, two audiences. The Web Accessibility Directive has required public-sector websites and apps to meet the standard since 2019. The European Accessibility Act (EAA) has been enforceable since 28 June 2025, and it reaches the private sector, covering e-commerce, banking, e-books, transport booking and more. Each member state enforces it in its own way, with penalties ranging from fines to, in some countries, criminal liability for persistent failure. If you sell to European consumers, this one likely applies to you regardless of where your company sits.

United States. The ADA has long been read by courts to cover websites, and Section 508 governs federal agencies. What is new is concrete. The Department of Justice adopted WCAG 2.1 AA as the enforceable standard for state and local governments under ADA Title II, so the duty now has a specific technical bar rather than only case law. Watch the dates here, because they just moved. In April 2026 the DOJ extended the compliance deadlines by a year, to 26 April 2027 for entities serving 50,000 people or more, and 26 April 2028 for smaller ones. The extra year buys time to prepare, but it doesn't change where things are heading.

United Kingdom. The Equality Act 2010 sets the general duty not to discriminate, and the Public Sector Bodies Accessibility Regulations 2018 put WCAG 2.1 AA and a published accessibility statement on the public sector specifically.

Canada. The federal Accessible Canada Act aims at a barrier-free Canada by 2040, and the provinces are moving too, with Ontario's long-standing AODA joined by newer laws such as British Columbia's Accessible BC Act, driving public-sector organisations toward the same WCAG target on staggered deadlines.

Australia. The Disability Discrimination Act 1992 underpins the duty, and government policy has adopted WCAG for public-facing services for years.

The details, deadlines and enforcement powers vary a good deal from place to place, but they are almost all aiming at the same WCAG target. For a fuller list by country, the W3C keeps a policies reference worth bookmarking.

Where accessibility law is heading

Look across all of it and the same things hold almost everywhere.

  1. The standard is WCAG. Build and test against it and you are aligned with most of the world at once.
  2. The scope is widening. The direction of travel is from public sector, to regulated sectors, to ordinary commercial websites. Betting that it stops before it reaches you is a poor bet.
  3. A published position is expected. More and more regimes want an accessibility statement, a public account of your conformance level, the known gaps, and what you are doing about them. You cannot write one that stands up without first knowing where you actually stand, which is why the audit comes first.

The cost of non-compliance is real, and it is also almost entirely avoidable. A clear picture and a plan is a much calmer place to operate from than a legal letter.

How to start an accessibility audit

Comply with WCAG is a goal, not something you can drop onto a sprint board. The task that actually gets you there is an accessibility audit, and a good one has two halves that do very different jobs.

Automated testing, for whole-site coverage

Start by finding out where you stand across the whole site, not just the homepage. This is what machines are good at. Automated testing checks every page, every time, and catches the mechanical failures that make up a large share of real-world barriers: missing form labels, broken heading order, insufficient colour contrast, missing alt attributes, keyboard traps. It works page 900 as carefully as page 1.

This is exactly what the automated accessibility checks in Webperf Cloud and Webperf Audit are for. They give you a whole-site baseline with the number of pages each issue affects, which is what turns a wall of findings into a prioritised remediation plan. Fix a heading-order problem in one template and you can repair hundreds of pages in a single change.

Most accessibility complaints and legal claims cite these same mechanical failures, which means the fastest and cheapest part of an audit is also the part that clears away most of your legal exposure. Good reason to run it first.

A trained professional, for the judgment calls

Automated testing cannot finish the job, and any vendor who tells you otherwise is selling you a false sense of safety. A checker can confirm that alt text is present; it cannot tell you the words describe the image. Nor can it judge whether a page makes sense read aloud, whether a custom widget is actually operable with a screen reader, or whether an error message helps a confused visitor recover. Those are judgment calls, and judgment is human.

So the second half is a manual audit by a trained accessibility professional, ideally one who works with people who use assistive technology every day, or better still, testing that involves those users directly. This is where the subtle, high-impact barriers surface, the ones that pass every automated check and still lock people out. It is people before tools, applied where it matters most.

Research by Deque, the company behind the widely used axe testing engine, put the share of issues fully covered by automation at around half. Treat the exact number with caution, since it depends heavily on what you count, but the shape of it is not controversial. Automation clears a large, cheap, high-volume half of the problem. The other half needs a person.

What makes someone a professional here is breadth rather than a single skill. They need to understand user experience, the legal requirements, frontend code and how a change lands in it, and how to talk to stakeholders who did not ask for this work. Certification from the International Association of Accessibility Professionals (IAAP) is a reasonable signal, whether CPACC, WAS or the combined CPWA. It is not a guarantee. Accessibility is wide enough that two certified people can have very different strengths, so ask what they have actually audited.

A sensible sequence

  1. Run the automated baseline first. Not as a warm-up, but because the manual audit depends on it. The machine clears the mechanical rubble across every page and hands over the map: the page inventory, the templates, and where each issue clusters. That map is what a professional needs before they can choose a defensible sample, and if you do not give it to them they will build one themselves before starting.
  2. Book the manual review on the pages and flows that matter most: sign-up, checkout, contact, anything legally load-bearing. Fixing the homepage while the checkout excludes keyboard users is effort in the wrong place.
  3. Fix templates before pages, so one change lands everywhere at once.
  4. Close the loop with a re-test, then keep the automated checks running after every release. This matters more for accessibility than for anything else, because the people your site fails are the least likely to file a bug report. They leave, silently, while every dashboard looks normal. (We made this case at length in accessibility is a habit, not a checkbox.)

A guide to manual testing you can do yourself

Hiring the professional is the right call for the audit that has to stand up legally. But do not hand them a site nobody has measured. A competent auditor cannot begin without a quantitative picture, because WCAG-EM's second and third steps ask them to map the variety of the site and sample it representatively, and neither is possible by intuition. If you do not supply that picture, the good ones will go and get it themselves before they do anything else. That happens either way. The only real question is whether you own the automatic audit or not.

It is worth owning, for three reasons. You pay for it once, at your own scale, rather than as a line on someone's hourly invoice. It covers every page rather than whatever the auditor could crawl in an afternoon. And it is still running after they leave, which is what turns a one-off report into something you can re-measure against yourself.

The same logic applies to your own team. Manual testing is not a dark art. The basics take an afternoon to learn, they surface real barriers, and they make everyone who does them fluent in what these requirements actually mean, which pays off in every design review afterwards.

Start with the free automated tooling, because it costs nothing and narrows the field. The axe DevTools browser extension for Chrome and Firefox, or ARC Toolkit, will check the page you are looking at. Then put the mouse away and do the following by hand.

Test with the keyboard. This is the single highest-value thing a beginner can do, and it needs no software at all. Plenty of people navigate this way, whether because of sight loss, a motor impairment, or simply preference. Tab moves forward through interactive elements, Shift+Tab moves back, arrow keys move within a group such as a radio set or a menu, Enter activates, and the spacebar scrolls the page (Shift+Space scrolls back up).

Now watch what happens. Can you always see which element has focus, or does the outline vanish somewhere? Does the order follow the visual layout, or does it leap to the footer and back? Can you open the menu, use the date picker, dismiss the cookie banner, and get through checkout without ever touching the mouse? Does focus ever get stuck inside a modal, or disappear into an element you cannot see? A keyboard trap in a checkout is a total blocker for real customers, and it is one of the easiest things in the world to find.

Test with a screen reader. One is already on the machine in front of you. On macOS and iOS, VoiceOver lives in System Settings under Accessibility. On Windows, Narrator is built in, though the screen readers real people actually use are NVDA (free) and JAWS, so professionals test with those. Expect to feel clumsy for the first twenty minutes; that is normal and not a reason to stop.

Listen to a page top to bottom. Do the headings describe the structure, or is everything one flat wall? Do links say where they go, or does the page announce read more eleven times? Do form fields announce their label, their format requirements, and their error state? Does the custom dropdown someone built from div elements announce itself as anything at all?

Check images and tables by reading, not by validating. A tool can only see whether alt exists. You have to decide whether it says the right thing. Decorative images should carry an empty alt="" so a screen reader skips them entirely. Images carrying information need text that conveys the same information, which usually means describing what the image tells the reader, not what it depicts. For complex tables, a <caption> right after the opening <table> tag gives the listener context before the numbers start.

Zoom, and then zoom further. Set the browser to 200% and check nothing is cut off or overlapping. Narrow the window to phone width and confirm the content reflows into one column instead of demanding horizontal scrolling. Then check that your interface still works with text spacing increased. This catches a whole class of failures that look fine on a designer's 27-inch monitor.

Simulate, carefully. Simulation tools build empathy and catch obvious problems, provided nobody mistakes them for the experience itself. Funkify simulates a range of disabilities in the browser, the Web Disability Simulator extension covers colour blindness, low vision and dyslexia, and Coblis checks an uploaded image for colour blindness. There are Figma plugins that do similar work at the design stage, which is the cheapest place to fix anything.

The caveat: this is triage, not an audit. It will find real barriers and it will make your team fluent in what accessibility actually means, which is worth a great deal on its own. It will not produce a defensible conformance claim. For that you need coverage, method and evidence, which is exactly the gap WCAG-EM fills.

WCAG-EM, the method that makes an audit hold up

WCAG tells you what a page must do. It does not tell you how to evaluate a whole website, which pages to look at, or how to write up what you found. That is the job of WCAG-EM, the WCAG Evaluation Methodology from the W3C.

It is worth being precise about what it is. WCAG-EM adds no new requirements. It defines no new success criteria. It is a procedure for applying the ones that already exist, so that two evaluators looking at the same site reach comparable conclusions, and so that the person reading the report can see how you got there. That repeatability is the whole point, and it is what turns we tested some pages into a finding a regulator, a procurement officer or a court can actually weigh.

The five steps

The methodology is five steps, in order.

  1. Define the evaluation scope. Say exactly what is being evaluated and what is not, which conformance level you are targeting (almost always WCAG 2.1 AA, and increasingly 2.2), and your accessibility support baseline, meaning the browsers and assistive technologies the site is expected to work with. Skipping this step is how audits end in arguments about whether the subdomain and the PDFs were ever in scope.
  2. Explore the target. Before sampling, get to know the site. Identify the common pages, the essential functionality, the variety of page types, the technologies the site relies on, and anything else relevant such as legally required pages or content in other languages.
  3. Select a representative sample. Auditing every page by hand is impossible on any real site, so you sample deliberately. The structured sample is chosen to cover the variety you mapped in step 2. The random sample is roughly 10% of the structured one, chosen blind. And you include complete processes, meaning whole flows end to end, such as sign-up or checkout. A process is only accessible if every step is; one broken step breaks the entire journey, which is why the flow is sampled as a unit rather than as loose pages.
  4. Evaluate the sample. Check the initial pages, check the complete processes, and then, importantly, compare the structured and random samples. If the random pages turn up issues or content types your structured sample missed, that is evidence your sample was not representative. You go back to step 3, add pages covering what you missed, and repeat until the two agree. This feedback loop is the part most homegrown audit processes lack.
  5. Report the findings. Document the outcome of every step, so the method is visible and not just the verdict. Optionally record the evaluation specifics, provide a conformance statement, and give an aggregated score. The W3C's free WCAG-EM Report Tool walks you through the whole thing and produces the write-up.

Steps 2 and 3 are where the quantitative baseline earns its place, and now you can see why. The method asks the evaluator to map the site's full variety and then sample it representatively, and there is no honest way to do that on a site of any size without measuring it first. The sample is also the load-bearing part of the whole exercise: a conformance claim is only as defensible as the sample it rests on, and a sample chosen from guesswork is exactly what a regulator or an opposing lawyer will push on. Measure first, and the human judgment that follows is applied to the right pages.

WCAG-EM 1.0 and 2.0

WCAG-EM 1.0 has been the stable reference since July 2014 as a W3C Working Group Note. It is written for websites and web pages, and it is what most auditors, procurement documents and national monitoring bodies mean today when they say WCAG-EM.

WCAG-EM 2.0 arrived as a first Draft Note in February 2026, with a further draft published in July 2026. It even sheds the word website from its own name, becoming the W3C Accessibility Guidelines Evaluation Methodology. The five-step spine is unchanged, and the vocabulary has been generalised throughout: web page becomes view, and website becomes digital product. That is not cosmetic. The scope now stretches to native mobile apps, kiosks, e-books and documents such as PDF, Word and EPUB, which is a direct answer to how the European Accessibility Act works. The EAA does not care that your booking flow ends in an app or that your terms arrive as a PDF; both are in scope, and until now the evaluation methodology only really covered the web half. Step 5 also gains an option for machine-readable reports, which matters if you want audit results to flow into tooling rather than sit in a document.

The practical advice is simple. Audit against WCAG-EM 1.0, because it is the stable, cited, expected version. Read 2.0 now if your product is more than a website, since it tells you where the ground is moving, and note that it is a draft and not yet something to claim conformance against. If you have opinions, the working group is still taking comments.

From method to accessibility statement

This is the piece that closes the loop with the law. Most of the regimes in this article expect a published accessibility statement, and a statement is only as good as the evaluation behind it. A WCAG-EM audit produces exactly what the statement needs: a defined scope, a stated conformance level, an honest list of known gaps, and a date. Run it on a rhythm rather than once, and the statement stays true rather than quietly becoming a lie about a site that has shipped four hundred releases since.

If the specification itself is heavy going, and it is, the W3C's own WCAG-EM overview explains the same process in plain language and is the better place to start your first one.

Meeting WCAG without the deadline scramble

The law is catching up to something disability advocates have said for decades. A website that excludes people is a broken website, whether or not a regulator has noticed yet. The regulators are noticing now, on nearly every continent, and they have helpfully agreed on one standard so you do not have to chase a dozen.

Meet it with two tools working together. Let the machine give you coverage across every page, continuously, and let a trained human give you judgment where coverage isn't enough. Put a method around the human half, so the result is repeatable rather than one person's impression on one afternoon. Do all of that on a regular rhythm, and you stop scrambling before each deadline. Accessibility turns into a normal part of how the team builds and ships.

And start pressing Tab on your own site this week. It costs nothing, and what you find will tell you how urgent the rest of this is.

Webperf Cloud runs the automated half across every page on your site, with each issue counted by pages affected. Compare the plans or email hello@webperf.cloud. If you need the manual half too, we'll happily point you toward auditors who do it well.