Web Development

European Accessibility Act, ADA and WCAG 2.2: Is Your Website Legally Compliant? (EU, UK, USA, Canada)

Researched 16 October 2026. This guide distinguishes legal scope from technical testing; it is not a legal opinion or a certification of any website.

Quick answer: a score cannot certify legal compliance

A website is not legally compliant simply because an automated checker gives it a high score or a supplier adds an accessibility badge. The useful answer depends on the business, the service, the countries involved and the actual customer journey. Establish the applicable duties, choose a technical testing target, remove barriers and keep evidence of what was checked. For a new commercial website, WCAG 2.2 Level AA is a sensible engineering target, but the law applying to a particular organisation may reference a different version or impose additional duties.

This guide separates the European Accessibility Act, US disability law, UK duties and Canadian requirements. It then turns that distinction into a practical buying and testing plan. The point is to make it possible for a customer to find a product, understand an offer, authenticate, pay and obtain help independently. A visually polished homepage says little about whether those tasks work.

Consider a shopper who uses a keyboard instead of a mouse. They reach a product, choose a size and add it to the basket, but the delivery modal traps the cursor. The purchase stops there. Improving the colour contrast on the homepage would leave that barrier untouched. Assess complete tasks before deciding whether the project needs small repairs or a wider website redesign.

Start with scope: four legal systems, several different duties

European Union: identify the covered service

The European Accessibility Act applies through national implementing laws to specified products and services, including consumer e-commerce services, from 28 June 2025. It is not a blanket statement that every website is covered in the same way. Microenterprises providing services are exempt under the Directive: the definition uses fewer than ten people and annual turnover or an annual balance sheet total not exceeding EUR 2 million. Product-related obligations differ. Read the Directive itself, including scope, definitions and exemptions, rather than treating a vendor's checklist as the law.

For a retailer, the practical starting document is a list of countries where it offers its consumer purchasing service. Germany, France, Denmark, Sweden, the Netherlands, Ireland, Portugal and Spain share the EU framework, but national implementation, supervision and other accessibility duties still need checking. Record the legal entity, the service, the relevant national law and any exemption relied on. The European Commission's business accessibility guide is a useful starting point for that review.

Do not treat a possible exemption as a reason to make checkout inaccessible. A small supplier may have contractual accessibility requirements from a larger customer. It may also grow beyond a threshold, introduce a different service or encounter other applicable laws. Engineering a reusable accessible checkout now can avoid replacing it after those circumstances change. The decision about legal scope and the decision about good customer service are related, but they answer different questions.

United States: separate Title II from Title III

The US Department of Justice's Title II web and mobile rule concerns state and local government entities. Its technical standard is WCAG 2.1 Level AA. The current official guidance gives 26 April 2027 for entities with populations of at least 50,000 and 26 April 2028 for smaller entities and special district governments. Those are the dates shown when this article was researched; older summaries may show earlier deadlines. See the DOJ rule fact sheet.

A private online store should not borrow those public-sector deadlines as a grace period. Title III concerns businesses open to the public, and the DOJ explains its position on website accessibility in separate ADA web guidance. The application to particular businesses and disputes requires legal analysis; a WCAG claim is not an automatic answer to every ADA question. Ask the adviser assessing your US exposure to distinguish statutory duties, relevant judicial treatment and the technical standard used in your contract.

United Kingdom: reasonable adjustments and public-sector rules

UK service providers have reasonable-adjustment duties under the Equality Act 2010, or the Disability Discrimination Act 1995 in Northern Ireland. Public-sector website and app regulations are a separate layer; their guidance should not be copied wholesale into a private retailer's legal statement. The UK government's accessibility guidance explains that distinction. Specify whether a project is a commercial service, public service or public procurement delivery before choosing its acceptance wording.

Canada: province and sector matter

Canada does not have one universal website rule identical to the ADA. Ontario's guidance, for example, addresses designated public-sector organisations and businesses or nonprofits with at least 50 employees, with WCAG 2.0 AA requirements and specified exceptions. Its scope includes which content and websites the organisation controls. Start with Ontario's official website guidance if that jurisdiction applies, then check other provinces and federal-sector obligations separately. Do not describe an Ontario assessment as certification for every Canadian customer.

Use a comparison that keeps law and testing separate

The table is a scoping aid, not a legal conclusion. Give the same scope statement to the lawyer, designer, developer and auditor. Otherwise each person can sincerely deliver a different result: a policy assessment, a redesigned homepage, a clean automated report and a user test of only the login page. The project needs one agreed boundary.

For international projects based in the UAE, Saudi Arabia, Qatar, Kuwait, Bahrain or Oman, the location of the development team does not settle the customer's legal obligations. The same applies to agencies in India, Pakistan or Bangladesh delivering work for European or American buyers. Put the intended markets and contractual responsibilities in the brief before requesting proposals. Our guide to choosing a development company explains how to make that brief comparable.

What WCAG 2.2 contributes to a commercial website

WCAG is a W3C technical standard containing testable success criteria. It is organised around making content perceivable, operable, understandable and robust. Version 2.2 adds requirements addressing issues such as obscured keyboard focus, dragging interactions, redundant entry and accessible authentication. Use the W3C specification for precise criteria and exceptions; a shortened checklist cannot replace it.

Translate the target into ordinary customer tasks

Ask whether a person can understand the product without relying solely on a photograph, operate the menu without a mouse, distinguish an error without colour alone and complete payment without an inaccessible challenge. These questions make the technical work concrete. The implementation may involve native controls, meaningful labels, content changes, focus management or replacing an unsuitable third-party component. Accessibility is not exclusively a front-end coding task.

Treat language and direction as part of the journey

A bilingual store needs testing in both languages. Arabic and English can have different labels, different line lengths and different reading order failures. A menu that works in English can become confusing when its visual direction changes but its document order does not. Product codes, amounts and telephone numbers need particular attention. The Arabic website and RTL guide helps plan those details without assuming that translating words is sufficient.

Build an audit around complete journeys

Choose representative pages and states

An inventory should include templates, interactions and important variations. A product page with one option is not representative of a product with subscriptions, unavailable combinations and quantity discounts. List a home page, search results, filters, product detail, basket, checkout, account, returns, contact and privacy controls. Add the states people encounter when something goes wrong: invalid input, unavailable stock, failed payment and expired authentication.

The sample should be chosen deliberately and documented. W3C's evaluation methodology provides a structured approach, while tool-selection guidance explains why software alone cannot determine all accessibility issues. A useful report identifies the tested pages and states, browsers, assistive technologies, criteria and limitations. It should distinguish repeated component defects from isolated content defects so the repair team can estimate the real work.

A practical checkout inspection

Start with a clean session and attempt a normal purchase using only the keyboard. Record every place where focus disappears, moves unexpectedly or reaches invisible controls. Repeat with a screen reader operated by a knowledgeable tester. Does changing quantity announce the updated total? Does an invalid postcode explain the correction? Is the selected delivery option understandable? Can the shopper review the final amount before committing?

Then exercise the failure path. Reject a payment in the test environment, return to the basket and try again. Use a long address, a translated label and a smaller screen. These are ordinary operating conditions, not exotic edge cases. A form that is usable only when every field is completed correctly on the first attempt has not been tested as a service.

Record defects so another person can reproduce them

A useful ticket states the page and account state, steps, expected outcome, observed outcome, affected user and supporting evidence. Include the relevant criterion where applicable, but do not stop at its number. Explain that the dialog closes visually while keyboard focus stays behind it, for example. Developers need to understand the interaction, and reviewers need an unambiguous way to confirm the fix.

Include people with disabilities without outsourcing responsibility

User research can expose barriers that a technical checklist misses. Compensate participants, avoid asking one person to represent every disability and provide test instructions in accessible formats. Separate usability findings from formal conformance findings while acting on both. A participant's successful purchase is valuable evidence about that session; it is not proof that every route, browser and disability need has been covered.

Fix the system before polishing individual pages

Shared components deserve early attention because they appear across many routes. Repairing navigation, modal behaviour, form labels and error summaries can improve a large portion of the site. Review the design system's colour combinations, focus treatments and spacing before editors create another hundred pages. A component library should make the correct option easy for ordinary content staff, not require specialist judgement for every button.

After structural repairs, review content. Alternative text should communicate the image's purpose in context, not repeat the filename or stuff search keywords into it. Link wording should tell the reader where they are going. Product instructions should not depend on phrases such as click the red circle when another description would be clearer. Tables need understandable relationships, and documents offered for download need their own assessment.

Do not rebuild a working store merely because an audit produces a long list. Ten thousand affected URLs may share one broken component. Conversely, a short list can contain a checkout blocker requiring substantial architectural work. Request an estimate by defect category and reusable component. The custom e-commerce cost guide provides a broader framework for separating platform work from content and integration work.

Third-party widgets need an owner

Reviews, chat, payment fields, consent tools and delivery selectors often come from different suppliers. Make a dependency register that records who can change each component and how a defect is escalated. Ask vendors for evidence relevant to the version and configuration you actually use. A report for another product edition or an old release does not establish the behaviour of your checkout today.

If a critical supplier cannot fix a blocker, assess an accessible replacement or a genuinely usable alternative process while the issue is resolved. Do not hide the problem behind an accessibility statement. A telephone number may help some customers but create barriers for others, and it may not provide equivalent hours, prices or independence. The adequacy of an alternative needs careful consideration under the applicable duties.

Privacy controls are part of this work. A person must be able to understand and operate the consent interface without a mouse or perfect vision. Coordinate accessibility testing with the cookie-consent implementation review, so neither team breaks the other's work when changing banners, overlays or focus behaviour.

Put measurable acceptance terms in the contract

Avoid a deliverable called ADA compliant website with no explanation. Specify the technical version and level, scope, supported environments, evaluation method, remediation cycle and evidence required at handover. State who resolves third-party failures and who approves any exclusions. The commercial acceptance process should include retesting after repairs; a first audit identifies work rather than completing it.

For budgeting, separate discovery, audit, remediation, content repair, user research and maintenance. A hypothetical project with 24 hours of discovery, 48 hours of assessment, 72 hours of repairs and 24 hours of retesting contains 168 hours. At an explicitly assumed blended rate of USD 80, that is USD 13,440 before tax and third-party charges. This is a worked planning example, not a market price or a quote for your site. Replace every assumption with actual scope and supplier estimates.

Ask what happens when the chosen payment widget changes or the marketing team launches a new landing page. The best initial audit loses value if no one owns subsequent changes. Include accessibility checks in the website maintenance plan, with responsibilities for templates, content, suppliers and customer feedback. A low maintenance fee that excludes those tasks should not be compared with a service that includes them.

Track progress by resolved user barriers, not only the number of tickets closed. A useful release note might say that keyboard users can now select a delivery slot, that the payment error is announced, and that the revised product selector was retested in Arabic and English. Preserve the test account and product examples needed to repeat those checks. If a future release changes one of those components, the team can run the same journey again instead of debating whether the earlier audit still applies. This small regression set is particularly valuable when a store has frequent promotional campaigns or several agencies working on different sections.

A workable first month

During the first week, establish scope, collect customer complaints and inventory the purchase journey. In the second week, assess representative templates and high-risk interactions. In the third, repair the most serious shared-component and transaction barriers. In the fourth, retest, document remaining work and agree the ongoing release process. This is a suggested sequence, not a guarantee that a complex site can be remediated in a month.

Give one person responsibility for coordinating the programme, while keeping implementation with the teams that own design, content and code. W3C's planning and management guidance treats accessibility as an ongoing organisational activity. In practice, a short issue review during release planning is often more useful than a large annual report that nobody converts into tickets.

Publish an accurate statement where appropriate, with the assessment date, known limitations, contact route and planned improvements. Do not claim complete compliance while significant barriers remain. Preserve the underlying evidence so that a new developer can understand which claims were supported and which were provisional. Honest documentation also helps customer support give useful answers rather than promising that a tool has made the whole site accessible.

Frequently asked questions

Does WCAG 2.2 AA guarantee that a website is legally compliant?

No. It is a technical conformance target. Applicable laws, service scope, national implementation, contractual duties and other obligations must be assessed separately. Testing also needs to cover the relevant pages, states and complete processes.

Can an accessibility plugin replace an audit?

No single plugin establishes accessibility across a whole service. Tools can help identify or address particular issues, but manual evaluation, assistive-technology testing and verification of complete customer journeys remain necessary.

Does the European Accessibility Act cover every small website?

No. Coverage depends on the products or services and the applicable national implementation. The Directive exempts microenterprises providing services, subject to its definition. Other legal or contractual accessibility duties can still matter.

Are US private stores allowed to wait for the Title II deadlines?

The Title II web rule addresses state and local governments. Private businesses must assess their own applicable duties, including Title III where relevant; public-sector deadlines do not provide a general grace period for private stores.

Should a bilingual store be tested twice?

Test the important journeys in every supported language. Translation, reading direction, label length, errors and embedded widgets can introduce different barriers even when the pages share the same underlying components.

The decision to make now

Commission a scoped assessment of the service customers actually use, with a repair and retesting budget attached. Keep the legal applicability review separate but coordinated. The outcome should be a working journey and defensible evidence, not a decorative badge. That is also a better brief for a custom website development project than a vague request to make the site compliant.