Website Compliance Checklist Before You Launch

Opening answer

A website compliance checklist before you launch should catch four things you can test on a staging URL: WCAG 2.2 AA barriers in the source (contrast, labels, keyboard access, and target size), privacy notices and opt-out paths that match the states you actually serve, cookie consent that blocks non-essential tracking until a visitor says yes, and HTTP security headers that browsers will enforce. Plugin banners and accessibility overlays can look finished while the underlying page still fails those tests. This is a practical launch gate for an owner, agency, or builder. It is not legal advice, and it is not a substitute for counsel in your jurisdiction.

Treat launch as a gate, not a last-minute plugin

Most sites fail because the team treated compliance as trim: a contrast overlay, a cookie banner from the plugin directory, a privacy policy copied from another industry, and a hope that HTTPS alone counts as security. Those pieces can ship while the form still has no labels, analytics still fires on first paint, and the response headers still allow framing.

A useful check is source-level. Disable JavaScript overlays. If the page is still usable from a keyboard, contrast still holds in CSS, tracking scripts stay silent until consent, and the headers still appear in `curl`, you have something that will survive a plugin outage. If any of those only work while a third-party widget is loaded, the launch is not done. Our team runs this gate on Forged Sites before DNS points at production. The rest of this post is the owner-facing version.

Accessibility: WCAG 2.2 AA in the HTML, not in a widget

WCAG 2.2 is the current W3C Recommendation. It extends 2.1, adds nine success criteria, and still uses the familiar A / AA / AAA levels.[1] W3C advises using 2.2 when you are writing or updating an accessibility policy, because content that conforms to 2.2 also conforms to 2.0 and 2.1.[1]

You do not need to memorize every criterion. You do need the four that break the most SMB sites in the first five minutes of a keyboard-and-eyeball pass.

Contrast. Success Criterion 1.4.3 (Level AA) requires at least 4.5:1 for normal text and images of text, and at least 3:1 for large-scale text (18 point, or 14 point bold).[1][2] Buttons, footer links, placeholder text, and error messages fail this more often than hero headlines. Check hover and focus states. Non-text contrast (1.4.11) asks for at least 3:1 on custom controls, meaningful graphics, and focus outlines.[1][2]

Labels. Associate text labels with form inputs, group related controls, and do not rely on placeholder text alone.[2] If a screen reader cannot tell a visitor what a field is for, the field is not ready.

Keyboard. Success Criterion 2.1.1 (Level A) requires that all functionality be operable from a keyboard, except where the path of the movement is the point (freehand drawing is the usual example).[1] Tab, Enter, Space, and arrows should reach every control, and focus must never trap.[2] Then check 2.4.11, new at AA in 2.2: sticky headers, cookie bars, and chat bubbles must not hide the focused control entirely.[3]

Target size. Success Criterion 2.5.8 (Level AA) sets a minimum pointer target of 24 by 24 CSS pixels, with spacing, equivalent-control, inline-link, user-agent, and essential exceptions.[3] Icon-only social links, close buttons, and mobile menu icons are the usual misses. Measure the clickable box, not the visible glyph.

Public-sector sites in the United States now have a written technical standard under Title II of the ADA. The Department of Justice's 2024 rule adopts WCAG 2.1 Level AA for web content and mobile apps that state and local governments provide or make available, including through contractors.[4] An April 2026 interim final rule pushed the larger-entity compliance date to April 26, 2027, and the smaller-entity date to April 26, 2028.[4] That rule is about public entities, not your private storefront. It is still the clearest federal statement that "accessible" means meeting a WCAG AA bar, not installing a toolbar. For a 2026 private launch, WCAG 2.2 AA is the current W3C target: it covers 2.1 AA and adds the mobile and cognitive criteria (target size, focus not obscured, accessible authentication) that users will notice even when a statute still cites 2.1.

Overlays and banners are not the same as a pass

An overlay is a third-party script that sits on top of the live page and claims to remake it for assistive technology. A consent banner is a UI that claims to collect a choice. Neither is a substitute for the underlying markup, CSS, and script loading order.

The Federal Trade Commission made that distinction expensive for overlay marketing. In January 2025 it announced a proposed $1 million settlement over allegations that a vendor misrepresented the ability of its AI-powered plug-in to make any website WCAG-compliant. The complaint said the product did not make all user websites WCAG-compliant, so the claims were false, misleading, or unsubstantiated.[5] The Commission approved the final order in April 2025. It bars the company from representing that its automated products can make any website WCAG-compliant or can ensure continued compliance over time unless it has evidence to support those claims.[6]

That is not a ban on widgets. It is a warning about the claim that a widget equals a standard. DOJ's Title II rule set a technical standard for the content people actually use. It noted comments about overlays and automated checkers without treating those tools as the measure of conformance.[7] If the HTML is unlabeled, the overlay cannot make 3.3.2 true. If the contrast lives only in a "high contrast mode" the visitor has to find, 1.4.3 is still failed for the default page.

Run the accessibility part of the checklist with the overlay disabled. If the page collapses, you do not have source-level access. You have a dependency.

Privacy: notices, opt-outs, and signals, without pretending you are a lawyer

U.S. privacy law is still a state map. The California Privacy Protection Agency describes the CCPA, as amended by the California Privacy Rights Act, as the first comprehensive consumer privacy law in the United States, with the CPRA amendments in effect since January 1, 2023.[8] Residents have rights the Agency summarizes as limit, opt-out, correct, know, equal treatment, and delete.[8]

Whether your company is a CCPA "business" depends on thresholds the Agency publishes, including a gross annual revenue figure of $26.625 million for the preceding calendar year as of January 1, 2025, plus the 100,000 consumers-or-households test and the 50% revenue-from-selling-or-sharing test.[8] Many small sites will not meet those numbers. Many will still collect California personal information or share identifiers with ad and analytics vendors in ways counsel may read as a "sale" or "share." Do not guess from a blog post. Do run the website pieces those laws keep asking for.

A launch check can see the following without opening a case file:

1. A privacy policy linked with the word "privacy" on the homepage and other pages, as the CPPA says covered businesses must do.[8]
2. If you sell or share personal information, a working opt-out. The CPPA states that businesses must honor qualifying opt-out preference signals (it names Global Privacy Control as an example) and, in most instances, must also provide a clear link labeled "Do Not Sell or Share My Personal Information," "Your Privacy Choices," or "Your California Privacy Choices."[8]
3. Methods to submit know, delete, and correct requests that actually work. Covered businesses must confirm those requests within 10 business days and respond within 45 calendar days (extendable by another 45 with notice). Opt-out and limit requests have a 15-business-day outer bound.[8]

California is not the only state on the map. Connecticut's Attorney General, writing with California and Colorado on Data Privacy Day 2025, reminded residents that the Connecticut Data Privacy Act lets them opt out of sale and sharing through a global opt-out preference signal, and that as of January 1, 2025, covered businesses must treat those browser signals as requests to opt out of sales or targeted advertising.[9] A GPC-aware footer is not a California-only flourish.

Write the policy against the laws that apply to you. Name the categories you collect, the purposes, the third parties, and the rights that exist in those states. Then click every footer link on a phone. If "Do Not Sell" 404s, or GPC is ignored while ads still retarget, the checklist failed.

Cookie consent that blocks scripts until yes

A banner that says "we use cookies" while the network tab already shows a flood of advertising pixels is not consent. It is a sticker.

The UK Information Commissioner's Office is one of the clearer public regulators on the mechanics, and its rules sit on the ePrivacy-plus-GDPR stack that still governs tracking you load for European and UK visitors. If no exception applies, you must obtain prior consent before using storage and access technologies.[10] Silence, a skipped banner, or continued browsing is not a yes: if the visitor does not take a positive action, you must not use the technologies that require consent.[10] The mechanism must make it as easy to refuse as to accept, it must set technologies only after valid consent or an exception, and it must let people withdraw consent with the same ease they gave it.[10]

That is the test, not the presence of a popup. Open a private window, load the homepage, choose Reject (or close the banner without choosing), then look at cookies, localStorage, and third-party requests. Session, security, and load-balancing cookies can be in bounds under a "strictly necessary" exception. Analytics, ads, social pixels, and fingerprinting scripts are not. If they fire on first paint, the banner failed.

This is not a rare miss. In its 2025 online tracking strategy, the ICO reported that 60% of the cookie-related complaints it received in 2024 related to people not being given the option to reject non-essential tracking.[11] In a review of the top 100 websites, it found 30% setting advertising cookies without consent or after a user chose not to consent.[11]

If you use a vendor consent mode (including Google's), treat it as an implementation detail, not the law. Pair it with the same regulator test: default denied, no non-essential hits before a real choice, reject actually stops the tags, and a visitor can change their mind from a footer control. A tag-manager checkbox is not evidence. The network log is.

Security headers: what the browser will actually enforce

HTTPS is table stakes. The headers on that response tell the browser to stay on HTTPS, refuse framing, stop MIME sniffing, and limit where scripts can load. U.S. Cloud.gov sets `X-Frame-Options: DENY`, `X-Content-Type-Options: nosniff`, and `Strict-Transport-Security: max-age=31536000` when an app does not set them, citing the OWASP Secure Headers Project.[12] That is a reasonable minimum for a public marketing site as well.

HSTS. The `Strict-Transport-Security` header tells browsers to use HTTPS only for a stated `max-age`. OWASP describes it as an opt-in enhancement that also blocks the "click through this bad certificate" prompt, and it warns that a long `max-age` without `includeSubDomains` is weaker than it looks because cookies can be manipulated from HTTP subdomains.[13] Do not send `preload` until every hostname you cover actually serves HTTPS. A one-year `max-age` (31536000 seconds) is the usual production floor after you have confirmed the redirect.

Framing, sniffing, and CSP. `X-Frame-Options: DENY` (or a tight CSP `frame-ancestors` directive) stops other sites from stuffing your pages in an iframe. `X-Content-Type-Options: nosniff` stops browsers from guessing a file type. CSP is the header that actually limits script, style, image, and frame sources, which is why OWASP lists it among the active secure headers.[12] Start in report-only if you need to learn what the site loads, then enforce. A policy of `unsafe-inline` everywhere is barely better than no policy. Write the allowlist from your real origins, not from another site's snippet. Add `Referrer-Policy: strict-origin-when-cross-origin` and a Permissions-Policy that disables camera, microphone, geolocation, and payment APIs the site does not use.

Run a header check (`curl -sI` against your staging hostname) before launch. If HSTS, nosniff, and a frame restriction are missing, the site is not hardened.

A one-hour launch pass you can actually finish

You do not need a research lab to decide whether to ship. You need a staging URL, a laptop, a phone, and a network panel. This website compliance checklist is the pass we recommend finishing before DNS points at production.

1. Unplug the mouse. Tab through the header, the main form, the cookie UI, and the footer. Confirm a visible focus ring, a skip link that works, no trap, and no sticky bar covering the focused control.
2. Zoom the desktop layout to 200%. Confirm you can still read and operate the page.
3. Check contrast on body text, buttons, footer links, and error text against 4.5:1 (3:1 for large text). Check custom controls against 3:1.
4. Confirm every image that conveys meaning has alternative text, and every input has a programmatic name.
5. Tap the smallest icons on a real phone. If you miss them, they are under 24 CSS pixels or they have no spacing exception.
6. Open a private window. Reject cookies, or ignore the banner. Confirm analytics and ads do not load. Then accept, and confirm they do.
7. Enable a Global Privacy Control setting if you sell or share personal information. Confirm the site treats it as an opt-out, not as a decoration.
8. Click Privacy, Terms, Cookie Policy, Accessibility, and any "Do Not Sell" or "Your Privacy Choices" link on a phone. Confirm they 200, name the right business, and describe the rights you actually offer.
9. Inspect response headers for HSTS, CSP, X-Frame-Options or `frame-ancestors`, and `X-Content-Type-Options`.
10. Repeat the keyboard and consent tests after you disable any overlay or CMP preview. The source has to stand on its own.

If a step fails, fix the source, then re-run that step. Do not mark it "handled by plugin."

Practical takeaways

• Use WCAG 2.2 AA as the launch target. Contrast, labels, keyboard access, visible focus, and 24 CSS pixel targets catch the most public failures.[1][2][3]
• Judge accessibility in the HTML and CSS, not in a toolbar. FTC action in 2025 treated "our AI widget makes any site WCAG-compliant" as a claim that needed evidence the product did not have.[5][6]
• Treat Title II's WCAG 2.1 AA rule as the federal public-sector bar, and 2.2 AA as the current W3C bar for a private launch.[1][4]
• Put a working privacy link in the footer. If you sell or share personal information, honor GPC and provide a clear opt-out path.[8][9]
• A cookie banner that cannot reject is not consent. Prior, equally easy yes/no, and no non-essential tags until a positive action, are the regulator test.[10][11]
• Ship HSTS, a frame restriction, `nosniff`, and a real CSP.[12][13]
• Re-run the same checklist after the last content drop. A new landing page can undo last week's pass.

How we can help

Vigil is our compliance engine for Forged Sites. It checks WCAG 2.2 AA in the source, state-aware privacy pages and opt-out links, cookie consent that stays dark until a visitor opts in, and the security headers above, on edits and on deploys. You can see the standard we hold our own site to on our compliance page. Have more questions or want to get in touch? Contact our team and we will walk your staging URL through the same launch gate.

Citations

1. W3C, "Web Content Accessibility Guidelines (WCAG) 2.2" (2024-12-12)
2. WebAIM, Utah State University, "WebAIM's WCAG 2 Checklist" (accessed 2026-08-30)
3. W3C Web Accessibility Initiative, "What's New in WCAG 2.2" (WCAG 2.2 published 2023-10-05)
4. U.S. Department of Justice, ADA.gov, "Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments" (2024-04-08, updated with 2026 IFR dates)
5. Federal Trade Commission, "FTC Order Requires Online Marketer to Pay $1 Million for Deceptive Claims that its AI Product Could Make Websites Compliant with Accessibility Guidelines" (2025-01-03)
6. Federal Trade Commission, "FTC Approves Final Order Requiring accessiBe to pay $1 Million" (2025-04-22)
7. U.S. Department of Justice, Federal Register, "Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities" (2024-04-24)
8. California Privacy Protection Agency, "Frequently Asked Questions (FAQs)" (accessed 2026-08-30; revenue threshold effective 2025-01-01)
9. Connecticut Office of the Attorney General, "Attorney General Tong Reminds Consumers of Their Right to Opt Out of the Sale of Their Personal Information" (2025-01-29)
10. Information Commissioner's Office (UK), "How do we manage consent in practice?" (accessed 2026-08-30)
11. Information Commissioner's Office (UK), "Online tracking strategy" (2025 strategy; 2024 complaint and top-100 figures)
12. Cloud.gov / U.S. General Services Administration, "Security-related HTTP headers" (accessed 2026-08-30)
13. OWASP, "HTTP Strict Transport Security Cheat Sheet" (accessed 2026-08-30)