European Accessibility Act and Website Compliance: An Evidence Framework
You cannot decide, from the material supplied for this guide, whether the European Accessibility Act applies to a specific website. The defensible first move is to document the entity, service, customer, transaction, market and exemption facts for qualified counsel, then test the affected user journeys against a technical target your reviewer has approved. This page hands you that operational method, not a legal verdict.
The European Accessibility Act is a European Union accessibility law that sets requirements for how certain in-scope products and services must be made usable by people with disabilities; whether it covers your website, from which date, and against which standard has to be confirmed from official legal sources for your service and market. WCAG 2.1 AA is a version and conformance level of the Web Content Accessibility Guidelines that can serve as a testable technical acceptance target once your reviewer approves it. WebStackRank is a Dubai-based digital agency that designs, builds and tests websites for business decision-makers across the GCC and Europe.
WebStackRank runs website projects through seven phases with named deliverables and explicit gates, and its QA phase includes automated and manual accessibility testing, according to WebStackRank's Website Development Process (18 May 2026). That verified process supports the testing workflow below; it does not establish what the Act legally requires.
What you get here that no other WebStackRank page provides: a six-branch applicability scope tree, a WCAG-to-page-element mapping written for non-developers, a worked six-step booking test with a real defect record, a sample accessibility conformance statement you can request at handover, and a reproducible acceptance-and-remediation loop for procurement.
Does the European Accessibility Act apply to your website? A scope decision tree
There is no shortcut: applicability turns on facts about your business, not on a label such as "brochure site." Work through six branches for every customer-facing service, attach the underlying records, and let qualified counsel make the scope call.
1. Entity facts
Name the legal entity that operates the service, contracts with customers and controls the website. Record its registered identity, its size information relevant to any proposed exception, its contractual role and the person accountable for the decision. The company in the footer is not always the entity operating checkout or accounts.
2. Service-function facts
Inventory what a visitor can actually do: read information, submit an enquiry, register, reserve, order, pay, change an account, cancel. One domain can contain several services, and each flow needs its own record, including embedded and externally hosted steps.
3. Customer facts
Record whether each flow serves consumers, businesses, employees, partners or a mixture, and support the answer with eligibility rules, terms and observed access controls. Keep audiences separate so one classification does not silently govern the whole domain.
4. Transaction facts
Map where selection, payment, confirmation, fulfilment, account management and cancellation happen, and name the organisation controlling each step. This reveals the line between defects your build team can repair and dependencies procurement must escalate.
5. Market facts
List where the service is offered, advertised, contracted, delivered and supported, with country settings, delivery rules and local terms attached. A language switch or a euro price alone does not establish the legal market.
6. Exemption facts
Treat every exemption as a claim needing an exact official provision, dated evidence and named reviewer approval. Common exemption arguments you will hear — that a business is very small, or that a fix is a disproportionate burden — are not self-proving; record who raised each one, which service it covers and what change would trigger reconsideration.
| Scope branch | Decision question | Evidence to attach | Owner |
|---|---|---|---|
| Entity | Who operates and contracts for the service? | Entity record and contract template | Legal or company secretary |
| Service | What can the visitor complete? | Flow inventory and screenshots | Product owner |
| Customer | Who may use each flow? | Terms and eligibility rules | Commercial owner |
| Transaction | Where do selection, payment and cancellation occur? | Journey map and supplier list | Operations |
| Market | Where is the service genuinely offered? | Country settings and local terms | Marketing and sales |
| Exemption | Which official provision is being relied on? | Provision, dated facts and sign-off | Qualified reviewer |
What is WCAG 2.1 AA, and what can it prove?
WCAG 2.1 AA is a set of testable success criteria at the AA conformance level. Passing it records technical conformance within the scope you tested; it does not prove the Act applies, that the version is legally sufficient, or that the whole business complies.
Keep two decisions in separate records. The legal decision states why a law or exemption applies to a service in a market. The technical decision states the standard, version, level, pages, components, journeys and environments a supplier must test. Fusing them into a vague promise such as "make the site compliant" leaves neither counsel nor the build team an auditable acceptance test. The technical register should name each criterion, the component affected, the test method, the expected result and the evidence format, and should distinguish "not applicable" (a reasoned scope decision) from "not tested" (missing work).
A WCAG-to-page-element mapping for non-developers
This table turns abstract criteria into things you can see, so a non-developer can check them or brief a supplier to. Two terms are worth defining first. A screen reader is assistive software that reads a page aloud or sends it to a braille display, so someone who cannot see the screen navigates by listening; NVDA on Windows and VoiceOver on Apple devices are common examples. Colour contrast ratio is the measured brightness difference between text and its background, written as a ratio such as 4.5:1 — the higher the number, the more readable the text is for low-vision users — and your team measures it with a contrast tool, then compares it to the ratio in the WCAG version your reviewer approved.
| Page element | What to check | Who it helps |
|---|---|---|
| Keyboard navigation | Every action can be completed with the keyboard alone; no control is unreachable or trapped. | People who cannot use a mouse, including many motor-impaired users |
| Focus order | The visible focus indicator follows a logical order and stays apparent after each action. | Keyboard and low-vision users |
| Form labels | Every field has a visible, programmatic label; errors are described in text and are locatable. | Screen-reader and cognitive users |
| Alt text | Informative images carry meaning in text; decorative ones are hidden from assistive technology. | Screen-reader users |
| Colour contrast | Text meets the approved ratio; colour is never the only way meaning is conveyed. | Low-vision and colour-blind users |
| Screen-reader output | A critical task can be completed using a named screen-reader and browser combination. | Blind and low-vision users |
Worked contrast example
Take a real pair of values. Dark-grey body text specified as #595959 on a white #FFFFFF background measures roughly 7:1 in a standard contrast checker, while lighter grey #999999 on the same white drops to about 2.8:1 — the second would fail most AA text thresholds. Record the exact foreground value, background value, measured ratio, the tool used and the component state, then judge pass or fail against the criterion your reviewer approved rather than by eye. A record that names the operating system, assistive technology, browser, device, tester and date is reproducible; "tested with a screen reader" is not.
A worked six-step booking journey
A component checklist cannot show whether a visitor can finish a commercial task. Test a bounded journey from entry to confirmation, use a fictional itinerary rather than customer data, and record the expected result, actual result, severity, owner and retest state at every step.
- Open availability. Reach the date selector with the keyboard only; record whether it receives focus and conveys its purpose.
- Select dates. Enter arrival and departure; capture required keystrokes, unexpected focus jumps and messages not announced in the tested environment.
- Choose a room. Compare two options without relying on photographs, colour or position; inspect how name, occupancy, price and selected state are exposed.
- Enter guest details. Submit with one required field empty; record the error text, where it appears, whether it is announced and whether the field can be found.
- Review the booking. Confirm dates, room, guest count, charges and next action; note which organisation controls the step if a third party supplies it.
- Reach confirmation. Use an approved non-production method; capture the confirmation content, reference handling, focus destination and recovery route.
Completed defect-record example
Step: guest-details submission. Expected: the error is conveyed and focus moves to a useful error location or the affected field. Observed: focus stayed on the submit button and no error announcement was recorded. Owner: form-component developer. Retest status: open. Remove this scenario and you are left with a generic checklist that says nothing about whether the booking can actually be completed.
A sample accessibility conformance statement to request at handover
Ask your agency for an accessibility conformance statement, not a one-line "it's accessible" claim. An accessibility conformance report is a document that states, criterion by criterion, whether a site meets a named accessibility standard, how each result was tested and what caveats apply; a widely used template for this is the VPAT/ACR format. It is technical evidence, not a legal certificate. The Core Web Vitals launch checklist explains why performance evidence needs the same discipline: a named environment and date.
| Statement field | What the buyer should receive |
|---|---|
| Assessment scope | Domains, templates, components, journeys, languages, exclusions and third parties |
| Target standard | Exact standard, version and level, with the retained authoritative source |
| Test environments | Devices, operating systems, browsers, assistive technologies and versions |
| Methods | Automated scans, keyboard checks, screen-reader journeys and visual inspection |
| Results | Pass, fail, not applicable or not tested for every recorded criterion |
| Evidence references | Stable identifiers linking results to screenshots, recordings and transcripts |
| Limitations | Affected flow, business effect, workaround, supplier, owner and target date |
| Approvals | Named technical approver, qualified legal reviewer, decision and date |
A reproducible acceptance and remediation loop for procurement
Procurement needs a process anyone can repeat, not a one-off opinion. Fix the approved standard, then loop each journey: test it, record the result in the conformance statement, decide remediate, rebuild or escalate, and retest. Use the agency-selection questions to lock ownership and acceptance terms into the statement of work before signing.
Apply three tests before approving a fix. Can the owner reproduce the defect from the retained script? Can the correction be applied to the shared component rather than one page? Can the team rerun the affected journey without creating a new barrier elsewhere? Three "yes" answers support a contained remediation. When repeated patches cannot produce a stable, testable result, rebuild the component. When a third-party widget fails the journey and your team cannot change its code or contract, escalate it into the supplier register with an interim measure and a commercial decision. Keep accessibility separate from privacy: the GCC data-protection guide answers a different jurisdiction and question and does not touch European accessibility.
What should you do first?
Start with one revenue-critical journey and complete the six-branch scope worksheet for that service. Send the evidence to qualified counsel, then place the approved technical target, test environments, evidence format, defect ownership and retest conditions into the statement of work. Do not open with a site-wide scanner or a promise of full compliance: the first creates findings without a settled scope, and the second turns incomplete evidence into a legal conclusion.
Frequently asked questions
Does the European Accessibility Act apply to my website?
This source pack cannot establish whether the Act applies to your website. Collect the entity, service, customer, transaction, market and proposed-exemption evidence, then obtain a decision from qualified counsel using applicable official sources.
Is WCAG 2.1 AA the standard the Act requires?
This guide cannot confirm that WCAG 2.1 AA is the legally required standard, because no official source mapping the Act to that version was supplied. Use only the standard and version approved from retained authoritative sources.
Does passing an automated scan prove compliance?
No. An automated scan supports no legal compliance conclusion on its own. Retain it as one test record alongside manual journeys, scope decisions, environments, limitations and retest results.
What should a web agency provide at handover?
Request an accessibility conformance statement: assessment scope, approved target, test environments, methods, criterion-level results, evidence references, known limitations, owners and retest state. Ask the agency to describe its technical work without issuing a legal opinion.
Who should approve the compliance wording?
A named qualified reviewer should approve any wording about legal scope, exemptions, obligations or compliance. The technical team should attest only to the implementation and tests it can evidence.
Questions about the production process or a proposed assessment can go through the WebStackRank contact page. Information about the accountable editorial organisation is on the About page.
