Your generated site looks finished on a laptop. The colours are consistent, the copy sounds confident and the contact form has a send button. None of that proves customers can use it, enquiries arrive or you control the domain. This checklist covers the evidence to collect before launch.
A polished preview hides operational failures
An AI builder can produce a convincing first screen within hours. It cannot know whether a certification claim is true, whether the company owns its domain account or whether the person receiving enquiries has access to the mailbox.
Accessibility creates the same gap between appearance and evidence. W3C says automated tools cannot check every aspect, require human judgement and can return false or misleading results. A tool helps evaluate a site; it cannot decide that the site is accessible (W3C evaluation tool guidance, checked: 2026-10-05).
The legal context also needs restraint. The European Accessibility Act is Directive (EU) 2019/882, and Member States apply their implementing provisions from 28 June 2025. Its listed scope includes services such as e-commerce and consumer banking, not every business website by name (Directive EU 2019/882, checked: 2026-10-05; European Commission EAA overview, checked: 2026-10-05).
This article does not decide whether your company or site falls within that scope. Read the directive and national implementing law, or ask a qualified lawyer. Accessibility remains a sensible launch requirement regardless of that legal answer.
The launch gate needs several kinds of evidence
The directive itself does not mention WCAG. Its Article 15 creates a route through harmonised standards. EN 301 549 connects European ICT accessibility requirements with WCAG.
Version 4.1.1 was published in September 2026 and aligns relevant web, document and software clauses with WCAG 2.2. It creates no presumption of EAA compliance until referenced in the Official Journal (EN 301 549 v4.1.1, checked: 2026-10-05).
AccessibleEU said in September 2026 that version 4.1.1 was not yet the legal reference point. It said version 3.2.1, based on WCAG 2.1 AA, remained the reference until Official Journal publication. This is AccessibleEU's stated position, not a legal opinion about your site (AccessibleEU update, checked: 2026-10-05).
A practical launch gate can use current WCAG checks, form delivery tests and ownership evidence without claiming legal certification. That is the standard behind a website built from a written plan, not just from a generated preview.
Run the checks before changing the domain
Scan representative pages
Run an automated scan on the home page, one service page and the complete contact journey. Save the date, tool version and results. Fix clear failures, then scan again.
Microsoft's Power Pages guidance separates Accessibility Insights FastPass from a full Assessment. FastPass automatically checks dozens of requirements, while Assessment combines guided checks for WCAG 2.2 AA. Microsoft also states that custom HTML and content remain the builder's responsibility even when the platform itself targets accessibility (Power Pages accessibility guidance, checked: 2026-10-05).
Do not turn the score into a compliance claim. A 2017 UK Government Digital Service experiment placed 143 intentional barriers on one test page. Across ten tools, the best individual tool found 37 percent of those planted barriers, or 41 percent when prompts for manual inspection counted. The study used old tools and one artificial page, so it illustrates limits rather than a universal detection rate (GDS tool experiment, checked: 2026-10-05).
Use a keyboard, screen reader and zoom
Put the mouse aside. Move through the entire page with Tab and Shift+Tab, activate menus and submit the form. The focus indicator must stay visible, and the order should follow the task rather than the visual decoration.
Use Windows Narrator or another screen reader to hear the heading structure, link names, field labels and validation errors. Microsoft recommends testing with user tools such as Narrator and Immersive Reader, not relying only on automated output (Power Pages accessibility guidance, checked: 2026-10-05).
Zoom to 400 percent and confirm that content reflows without requiring horizontal and vertical scrolling together. WCAG 2.2 criterion 1.4.10 describes reflow at a width equivalent to 320 CSS pixels. Also check text contrast, information conveyed by colour and text alternatives for images under criteria 1.4.3, 1.4.1 and 1.1.1 (WCAG 2.2, checked: 2026-10-05).
Send a real enquiry
Complete the form as a customer would, including one invalid attempt. Check the confirmation shown on screen, the message received by the business and the data actually included.
Record who received it and when. Test from a phone and a desktop. If the site has a fallback delivery route, test the failure condition rather than assuming the second logo in a settings panel means it works.
The form also needs an operating owner. Someone must know where messages go, how failures appear and who responds when the named recipient is absent.
Verify domain, hosting and source access
Sign in to the domain registrar from an account controlled by the company. Confirm the registrant, recovery address, billing owner and people with DNS access. Save recovery details in the company's password manager.
Repeat the check for hosting, analytics and form delivery. Then ask whether the site can be exported and what happens if the builder account closes. A downloadable copy is useful only when it contains the actual pages, assets and configuration needed to run elsewhere.
Do not accept a verbal assurance that the domain "belongs to you." The evidence is access under a company-controlled account and a documented recovery path.
Read every factual claim aloud
Generated copy often describes a typical company in the sector. Mark every number, certification, location, client claim, delivery time and guarantee. Keep only what a source inside the business proves.
Read service pages as an owner and as a customer. Can the customer tell what is included, what is excluded and what happens next? Replace abstract promises with a step or boundary the business actually follows.
Set an owner for future updates. Platform and browser behaviour changes after launch, so connect the site review with a named process for change notices.
What not to do
Do not treat a green automated score as proof of WCAG or EAA compliance. W3C explicitly requires human judgement, and the EAA question depends on the service and national law.
Do not publish invented testimonials, client counts, certifications or performance claims. Removing unsupported copy is safer than weakening it with "typically" or "often."
Do not let a contractor or platform hold the only registrar login. A website can be rebuilt; a disputed domain can interrupt email and customer access at the same time.
When you can handle this yourself
You can run this launch gate internally when someone can edit the site, access the registrar and hosting accounts, receive form submissions and reproduce every factual claim. Keep one evidence sheet with the scan, manual checks, test enquiry and account owners.
Bring in help for a full accessibility evaluation, legal assessment of EAA applicability, complex account transfer or a platform that cannot export usable source. A lawyer decides legal scope. An accessibility specialist tests beyond the obvious path. A developer confirms whether an export can actually run.
Launch when the evidence is boring: the keyboard works, the form arrives, the claims are true and the company controls the accounts. A polished screenshot then becomes one part of a working site, rather than the only proof it is ready.