How to Make Your Website Accessible and Compliant: a 2026 Method

What are the steps to make a website accessible?

Every accessibility programme that works follows roughly the same order, whatever the size of the organisation. Ownership and scope come before testing, testing comes before fixing, and evidence runs through all of it.

• 1. Pick the standard: WCAG 2.2 Level AA, plus EN 301 549 if you serve the EU. Write it, with the version, into a short policy.
• 2. Name an executive sponsor and an accessibility lead, and agree who does what in a RACI.
• 3. List your digital estate: templates, key tasks such as sign-in and checkout, apps, documents, emails, videos and third-party components.
• 4. Score your maturity 0 to 4 across the practices that make accessibility stick (policy, design system, testing, content, procurement, training, monitoring).
• 5. Audit a sample with automated tools, manual keyboard and zoom checks, and screen readers on desktop and mobile.
• 6. Log each issue with severity, owner and a fix-by date; fix blockers first and offer an alternative on day one.
• 7. Fix at the source: the design system, templates and components.
• 8. Prevent new issues with role checklists, automated checks in the release pipeline and training.
• 9. Ask suppliers for Accessibility Conformance Reports and add accessibility clauses to contracts.
• 10. Publish an honest accessibility statement with a feedback route, keep evidence and report to leaders every quarter.

Who benefits from an accessible website?

More people than most teams assume. The World Health Organization estimates that about 1.3 billion people, roughly 1 in 6 worldwide, experience significant disability. The US Centers for Disease Control and Prevention reports that more than 1 in 4 US adults have some type of disability, and the UK Department for Work and Pensions' Family Resources Survey counted about 16.7 million disabled people, a quarter of the population, in the year to March 2025.

Those figures cover blind and low-vision people, deaf and hard-of-hearing people, people with limited dexterity or tremor, and people with cognitive, learning and mental health conditions, as well as temporary and situational limits such as a broken wrist or a phone in bright sunlight. They use screen readers, magnifiers, voice control, switches, captions and the keyboard alone. Picture those tools as you test, and most of WCAG starts to make sense. The same fixes, such as visible labels, clear errors and captions, also make the service easier for everyone else.

Which standard should you follow: WCAG 2.1, 2.2 or EN 301 549?

The Web Content Accessibility Guidelines (WCAG) from the W3C are the technical baseline behind almost every accessibility law and contract. WCAG 2.2 is the current version: a W3C Recommendation last updated in December 2024 and approved as the international standard ISO/IEC 40500:2025 in October 2025. It added nine success criteria, six of them at Level A or AA, covering focus not being hidden, dragging alternatives, minimum target size, consistent help, not asking for the same information twice and accessible sign-in. It also removed the old 4.1.1 Parsing criterion.

WCAG versions are backwards compatible, so a site that meets 2.2 AA also meets 2.1 AA and 2.0 AA, apart from the removed criterion. That is why building to 2.2 is the sensible choice even if a law in one of your markets names 2.1 or 2.0. In the EU, the harmonised standard EN 301 549 adds requirements for software, documents and real-time communication; its version 4.1.1, based on WCAG 2.2, was published in September 2026 and gives a presumption of conformity only once cited in the Official Journal. WCAG 3 is still an incomplete draft, and the W3C recommends meeting WCAG 2.2 now.

Which accessibility laws apply to your website?

The method is the same everywhere, but the legal hook differs. In the EU, the European Accessibility Act has applied through national laws since 28 June 2025 to listed consumer services including e-commerce and banking; service providers that are microenterprises (fewer than 10 staff and turnover or balance sheet of 2 million euros or less) are exempt from the service requirements. National authorities enforce it: the Dutch regulator ACM, for example, published tests of about 100 large webshops in March 2026 and found 61% not accessible.

In the US, the ADA applies to businesses open to the public, including online, and the Department of Justice calls WCAG helpful guidance; risk comes mainly from lawsuits, with the law firm Seyfarth Shaw counting 3,117 federal website accessibility suits in 2025. In the UK, the Equality Act 2010 requires reasonable adjustments, including accessible formats, and public sector bodies must meet WCAG 2.2 AA and publish a statement. Canada, Australia and New Zealand each have their own mix of federal or human rights law and government standards. Check the official page for every market you serve, note the date you checked, and confirm your position with an adviser.

How do you audit a website for accessibility?

Use three kinds of testing, because each finds different problems. Automated tools check code rules quickly and repeatably: the WebAIM Million 2026 report found detectable WCAG failures on 95.9% of the top million home pages, led by low-contrast text, missing alternative text and missing form labels. But WebAIM is clear that automated tools cannot find everything.

Manual testing covers keyboard use, focus order and visibility, zoom and reflow, colour use and errors. Assistive-technology testing uses screen readers, magnifiers and voice control on real tasks. Testing with disabled people, paid for their time, shows whether the service is usable. Write a test plan first: the standard, the scope, a sample by template and by task, the assistive technology and browsers with versions, the severity rules and the sign-off.

A worked example: what one audit found

Kade & Co is a fictional composite: a 90-person online homeware retailer in Amsterdam selling across four EU countries. Its April 2026 baseline audit covered 22 templates, tasks, apps, documents and components. The numbers below are the sample case used throughout The Digital Accessibility Compliance Kit, and they show why a scanner alone is not enough.

• Blockers included an unreachable Pay button, a keyboard trap in the address look-up and an image-only puzzle at sign-in.
• Open issues at month end fell from 84 in April to 15 in October, with no open blockers.
• Only 51% of closed issues met their fix-by target, an honest number that shaped the next quarter's plan.

How do you decide which accessibility issues to fix first?

Rate severity by its effect on a person trying to complete a task, not by WCAG level. A blocker stops someone buying, paying, signing in, getting help or reading a required document. A high issue makes a task possible only with great effort. A medium issue is harder than it should be with a workaround. A low issue is an annoyance. Raise one level on task-critical flows used by many people, and never lower a severity to hit a target.

Set fix-by targets by severity in your policy, for example days for blockers and months for low issues, and give every blocker an interim alternative on day one, such as taking the order by phone. Then group issues by root cause, such as the button component or the colour tokens, and fix them once in the design system. Track open issues at each month end so leaders can see whether fixes outpace new problems.

Do accessibility overlays work?

An overlay is a script that changes your page in the visitor's browser and often promises automatic compliance. It does not change your source code. The European Commission states that overlays are not an appropriate solution for meeting the Web Accessibility Directive and that issues should be fixed at source. In April 2025 the US Federal Trade Commission approved a final order requiring the overlay provider accessiBe to pay 1 million US dollars over claims that its tool could make any website WCAG-compliant. Spend the money on fixing your top issues instead.

What are the most common accessibility mistakes?

• Treating a clean automated scan as proof of compliance
• Testing pages but never a whole task from start to finish
• Fixing page by page instead of in the design system
• Removing focus outlines for looks
• Using placeholder text instead of labels
• Publishing auto-generated captions or alt text without checking them
• Making an untagged PDF the only way to complete a task
• Buying software without asking for an Accessibility Conformance Report
• A statement that claims full compliance or lists nothing as inaccessible
• Asking customers about their disability instead of what they were trying to do
• One generic training course for every role
• Stopping after the first audit

How do you keep a website accessible after the audit?

Accessibility slides back with every release unless it becomes a standard of work. Add automated checks to the release pipeline, ask each role for one habit (designers check contrast and focus, authors write alt text and headings, developers keyboard-test their own change), train people for their role, review supplier reports at renewal, and keep an evidence register with owners and review dates. Review the dashboard monthly and report to leaders quarterly. If you want to measure your team's judgement before and after training, AssessAll's Digital Accessibility and Inclusive Design Judgment assessment gives a starting point; to turn those habits into personal goals, Jobulary's guide to the WOOP method is a practical next step.