European Accessibility Act Website Requirements: A Readiness Guide
You cannot determine whether the European Accessibility Act applies to your website, or what it legally needs to pass, from the evidence supplied for this guide. The defensible action is to document the service for qualified counsel, adopt a technical target from retained authoritative sources, test each important journey against that target and preserve the results.
WebStackRank is a digital agency that builds and tests websites for business decision-makers across the GCC and Europe. It can implement approved accessibility acceptance criteria, but it cannot replace qualified counsel or an independent conformance auditor.
What this page provides that existing WebStackRank pages do not: a six-question applicability handoff, an owned WCAG 2.1 AA acceptance register, a seven-step booking-flow test, a remediation-versus-rebuild matrix and a source-controlled accessibility-statement worksheet.
Evidence boundary: what this guide cannot decide
No verified official source for the European Accessibility Act, a national implementation, EN 301 549 or WCAG was supplied. This draft therefore does not assert legal scope, dates, exemptions, penalties, mandatory conformance levels, colour contrast ratios or enforcement routes. Those omissions are publication blockers, not permission to insert values from memory.
WCAG 2.1 AA is a named target in the approved topic plan, but the source pack does not establish that it is the legal target for any particular service or jurisdiction. In project terms, it would mean a defined collection of testable accessibility criteria at Level A and AA. The exact criteria, versions and thresholds must be obtained from authoritative sources and approved before this page calls them requirements.
An accessibility statement is a public account of a service's assessed accessibility status, known limitations, feedback route and review history. This guide provides a controlled drafting structure, but the evidence does not establish where a statement is legally required, what it must contain or where it must be linked.
Six-question EAA applicability handoff
The six-question EAA applicability handoff is the first page-specific element. It does not decide whether the Act applies. It creates a dated factual record that an authorised legal reviewer can assess without reconstructing the website from emails.
- Who uses each public journey? Record whether it serves consumers, businesses, staff, partners or a mixture. Include the route, purpose and a current screenshot.
- What can a visitor complete? List purchases, bookings, payments, applications, registrations, account tasks and support requests. Keep transactional and informational journeys separate.
- Where is the service offered? Record the markets selectable during checkout, booking, delivery or account creation. Website language alone does not establish the service area.
- Which entity provides the service? Name the contracting or operating entity. Give counsel the requested organisation facts instead of assuming that labels such as startup or local office settle the issue.
- When did material features change? Record the original launch, significant releases and the build currently in production. Tie each date to a release record.
- Which third parties enter the journey? Identify payment, booking, identity, chat, video, consent and document components. Record who can change each component.
Send the record to counsel with a precise question: which laws and national implementations apply to these recorded services, and which technical standard and version should the project adopt? Ask for the governing sources to be named and retained.
Reopen the decision when the facts change. Adding checkout, public booking, account management or another served market changes the service profile that was reviewed. The legal owner should decide whether the original conclusion remains usable.
Owned WCAG 2.1 AA acceptance register for design, code and content
The owned WCAG 2.1 AA acceptance register is the second page-specific element. It turns a legally approved and sourced target into assigned work. It must not be labelled an EAA compliance checklist until qualified review confirms the governing requirements.
| Owner | Area | Pass or fail test | Evidence |
|---|---|---|---|
| Design | Colour, focus, error states, resizing and narrow layouts | Test every approved component and state against its cited criterion. | Token reference, annotated screenshot, viewport and citation. |
| Code | Keyboard navigation, names, relationships, dialogs, messages and focus movement | Operate the rendered component using the inputs and assistive technology named in the plan. | Route, build, browser, assistive technology, steps and defect link. |
| Content | Headings, links, alternatives, labels, instructions and errors | Review the rendered page, including generated and translated states. | Page checklist, reviewer, date, screenshot and correction. |
| QA | Complete priority journeys | Finish each task with every method required by the approved plan. | Step log, environment, failures, retest and acceptance record. |
| Legal owner | Applicability and target | Confirm or reject the conclusion against retained authoritative sources. | Dated instruction, jurisdiction, source URL and review trigger. |
Keyboard navigation means completing interactive tasks without relying on a pointing device. A useful record covers focus order, visible focus, controls that cannot be reached, keyboard traps, dialogs, validation and the route back from an error. A successful Tab sequence on the home page does not establish that checkout or booking works.
For any numerical assessment, including a colour contrast ratio, retain the colours and states tested, tool and version, measured result, authoritative criterion and approved threshold. Do not publish a ratio or pass threshold until the corresponding source is supplied.
Seven-step keyboard-navigation and screen-reader booking test
The seven-step booking-flow test is the third page-specific element. Consider a visitor who selects an appointment, enters contact details, corrects an error and receives confirmation. This scenario demonstrates record structure; it is not first-hand testing or proof of compliance.
- Open the service page. Record whether the title, heading, explanation and next action form a meaningful sequence.
- Choose a service. Reach and operate the selector by keyboard. Compare the visible wording with the name announced by the named screen reader.
- Select a date and time. Record focus order, instructions, unavailable choices and selected state. Flag any operation that requires a pointer.
- Enter contact details. Compare visible labels, conveyed field names and instructions available before submission.
- Trigger an error. Leave one required field incomplete. Record focus position, the conveyed message and the route back to the field.
- Submit the booking. Record whether the control operates and how processing, success or failure is communicated.
- Read the confirmation. Check whether the service, date, time, contact route and next action remain available.
A hypothetical defect record could read: “Build 184; booking route; named Windows browser and named screen reader; keyboard input. Steps one to four passed. Step five failed because focus remained on Submit and the new error was not conveyed. ACC-17 assigned to front-end development. Retest required.” This is an example, not a claim that the test occurred.
Preserve the original failure after correction. Append the replacement build, changed behaviour, tester and retest result so a reviewer can distinguish a repaired defect from an unsupported declaration.
Can the existing website be remediated without rebuilding?
Yes, an existing website can be remediated when its templates, components, content system and integrations allow approved corrections to be implemented and tested reliably. Rebuilding is justified only when recorded system constraints make those corrections unsafe, temporary or impractical.
The remediation-versus-rebuild matrix is the fourth page-specific element. Use it after an audit. The decision should follow evidence about shared failures and constraints, not a supplier's preference for a larger engagement.
| Observed condition | Response | Decision evidence |
|---|---|---|
| A shared navigation, form or dialog causes failures across many routes and can be changed centrally. | Remediate the component and retest every affected journey. | Component inventory, corrected build and route-level retests. |
| Most findings concern headings, link wording, alternatives or labels. | Run governed content remediation first. | Content inventory, ownership list and corrected rendered pages. |
| A third-party booking or payment component blocks completion and has no supported correction path. | Escalate to the vendor and assess replacements. | Reproduction steps, vendor response and integration constraints. |
| Duplicated, unowned templates cannot receive a reliable global correction. | Compare controlled template replacement with a wider rebuild. | Template count, regression risk, migration scope and test plan. |
| The CMS cannot store necessary labels, alternatives or relationships reliably. | Change the content model or platform layer. | Model gap, proposed fields, migration test and editor workflow. |
Group findings into shared components, page-specific content and third-party dependencies. Correcting one owned component may repair several journeys. Rebuilding surrounding layouts may leave a defective booking provider untouched. If implementation is approved, WebStackRank's industry-specific web development service describes the available build context.
Source-controlled accessibility-statement worksheet
The source-controlled accessibility-statement worksheet is the fifth page-specific element. It is a drafting control for legal, technical and content owners. It is not finished statement copy.
- Service identity: name the website or digital service and responsible organisation.
- Target and assessment: state only the standard, version, scope and result supported by retained records.
- Known limitations: describe each unresolved barrier, affected journey, available alternative, owner and review point.
- Feedback route: provide a monitored contact method and request details that help reproduce a barrier.
- Assessment method: state whether testing was internal, independent or combined, with the assessment date.
- Escalation information: add a jurisdiction-specific route only after qualified review verifies it.
- Review history: record substantive changes without refreshing the displayed date cosmetically.
The supplied evidence does not establish whether, where or how the statement must be linked. Counsel must confirm that point from the applicable official source. Once approved, use a stable route and ensure the statement is reasonably discoverable.
Pre-launch workflow for automated and manual checks
Automated checks can identify repeatable defects covered by their rules. Human testing is still needed for meaning, reading and focus order, error recovery, keyboard operation, screen-reader output and complete task performance. Neither method is a legal opinion.
- Freeze the approved standard, version, criteria, jurisdictions and sources.
- Inventory priority routes, states, shared components and third-party boundaries.
- Run automated checks and retain the tool version, ruleset, build and output.
- Run keyboard-navigation tests through complete tasks.
- Run screen-reader tests with the combinations named in the plan.
- Test approved zoom and narrow-layout conditions.
- Correct findings and append retest evidence without deleting the initial failures.
- Obtain independent, legal and business-owner review.
WebStackRank's published QA process includes “axe-core + manual screen-reader” testing, according to Website Development Process: Our 7-Phase SOP, published 18 May 2026. This verified statement describes WebStackRank's process; it does not establish an EAA requirement.
Keep accessibility and performance evidence separate. Teams coordinating a wider launch can use the Core Web Vitals launch checklist, but each discipline requires its own expected results, environments and acceptance record.
What belongs in the internal evidence pack?
The pack should allow a reviewer to reproduce the decision without searching email or chat history. Include the applicability handoff, legal instruction, authoritative sources, selected standard and version, route inventory, acceptance register, automated reports, manual journey logs, defect history, retests, statement draft, unresolved risks and named approvals.
The legal owner owns applicability and governing sources. The technical owner owns component coverage and build identifiers. QA or the auditor owns environments, methods and results. The content owner controls headings, alternatives, labels and statement copy. The business owner confirms that the tested journeys match real customer tasks.
Use the contact page to provide a route inventory and an already approved acceptance target if implementation support is required. Do not ask a development supplier to invent the legal target inside a proposal.
What remains unresolved before publication?
The Act's relevant website scope, dates, exemptions, national implementation, technical references, conformance levels, numerical thresholds, statement duties, enforcement routes and penalties remain unresolved. None can be added until an authoritative source is retained, dated, reviewed and visibly cited.
The operational preparation can begin now: inventory services, assign owners, identify important journeys and build reproducible records. This page cannot honestly tell readers what their website legally needs to pass until the missing source set and qualified reviews are complete.
Frequently asked questions
Who decides whether the European Accessibility Act applies to our website?
Qualified counsel or an authorised legal owner should decide applicability from verified official and national sources. A digital agency can document the website and implement an approved target, but it should not issue the legal conclusion.
What accessibility standard should we use?
The supplied evidence does not establish the legally required standard. Record the jurisdiction, authoritative source, standard and version before creating design, code or content acceptance criteria.
Can an automated scan prove that the website passes?
No such conclusion is supported here. Use automated checks as a defect feed, then retain manual results for complete journeys, keyboard navigation and the screen-reader combinations named in the approved test plan.
Can we remediate an existing website instead of rebuilding it?
Yes, when its components, content system and integrations can support reliable corrections. Rebuild only when documented constraints prevent the approved changes or make them too fragile to maintain.