Ecommerce compliance audit checklist for 2026

In 2026, an ecommerce store faces compliance obligations across four distinct regulatory areas: web accessibility, payment security, privacy law and AI transparency. Each has its own enforcement mechanism, its own penalty structure and its own technical requirements.

This checklist covers all four pillars. For each one, you get specific audit items with clear pass/fail criteria. Run through this on your own store. If you find gaps, the referenced deep-dive posts explain the underlying requirements in detail.

This is not a legal opinion. It is a practical starting point for identifying your highest-risk compliance gaps before a regulator or plaintiff finds them first. If you are wondering who should own this process, our guide on building a compliance team covers roles and responsibilities.

How to use this checklist

Work through each section systematically. For each item, the test tells you what to check. The pass criterion tells you what compliant looks like. The fail criterion tells you what puts you at risk.

Priority order: start with WCAG (highest litigation frequency) and PCI DSS (mandatory since March 2025). Privacy and AI Act are lower immediate risk but growing fast. If you are approaching a peak traffic period, see our guide on Black Friday compliance risks for time-sensitive considerations.

Pillar 1: WCAG accessibility

WCAG 2.1 AA is the baseline standard for web accessibility. In the US, courts use it to assess ADA compliance. In the EU, the European Accessibility Act references EN 301 549, which maps directly to WCAG 2.1 AA. Failing WCAG is the single most common reason ecommerce stores face ADA lawsuits or EAA enforcement action.

For deeper background on the US litigation landscape, see ADA web accessibility lawsuits in 2025. For the EU enforcement angle, see European Accessibility Act: what ecommerce stores must do.

1.1 Keyboard navigation

Test: Unplug your mouse. Navigate the homepage, product listing, product detail page, cart and checkout using only the Tab, Shift+Tab, Enter and arrow keys.

Pass: Every interactive element (links, buttons, dropdowns, modals, form fields, quantity selectors, "add to cart" buttons, payment fields) is reachable and operable by keyboard alone. A visible focus indicator (outline or highlight) appears on the currently focused element at all times.

Fail: Any element that requires a mouse click to activate. Focus disappearing into a modal or dropdown without being trapped appropriately. The checkout button unreachable without a mouse.

1.2 Image alt text

Test: Right-click several product images and inspect the HTML. Check the alt attribute on each img element.

Pass: Product images have descriptive alt text naming the product, variant and relevant detail ("Navy linen shirt, front view"). Decorative images have empty alt attributes (alt=""). Icons that convey meaning have text alternatives.

Fail: alt="" on product images. alt="image001.jpg" or filenames as alt text. No alt attribute at all. The same generic alt="product image" on every item.

1.3 Form labels and error messages

Test: Inspect every form field in checkout, account creation and contact forms. Check for a label element associated via for/id matching, or an aria-label or aria-labelledby attribute. Submit the form with empty required fields and observe error messages.

Pass: Every input has a programmatically associated label. Error messages identify the specific field with the problem ("Email address is required") and are announced by screen readers (associated via aria-describedby or role="alert").

Fail: Placeholder text used as the only label (disappears when typing). Error messages shown visually but not associated with their fields in the DOM. Required fields indicated only by color (red border) with no text or icon alternative.

1.4 Color contrast

Test: Use a contrast checker (WebAIM Contrast Checker, browser DevTools accessibility panel) on your primary text, button labels, link text and any text overlaid on images.

Pass: Normal text (below 18pt) meets 4.5:1 contrast ratio against its background. Large text (18pt or 14pt bold and above) meets 3:1. UI components (button borders, input outlines) meet 3:1 against adjacent colors.

Fail: Grey text on white backgrounds that falls below 4.5:1. White text on light colored buttons. Price text in a muted color that fails contrast. "Sale" badge text that blends into the badge color.

1.5 Checkout flow accessibility

Test: Complete a full checkout (or as far as the payment step) using a screen reader (NVDA on Windows, VoiceOver on Mac) and keyboard only.

Pass: The screen reader announces all steps, form fields, error messages and success states correctly. Payment fields (card number, expiry, CVV) are labeled. The order summary is accessible. The "place order" button is clearly labeled and reachable.

Fail: Payment iframe (Stripe, Adyen, Braintree) fields unlabeled or inaccessible. Step indicators that are visual only with no text equivalent. Quantity spinners that do not announce their current value. Any step where the screen reader loses track of focus.

1.6 Page structure and headings

Test: Use a browser extension (headingsMap, axe DevTools) to view the heading hierarchy on your key pages.

Pass: One h1 per page containing the primary topic. Headings follow a logical hierarchy (h1, then h2, then h3) without skipping levels. Navigation landmarks are marked up correctly (nav, main, footer, aside).

Fail: Multiple h1 elements on a single page. Headings used for visual styling rather than structure (using h3 because it looks like the right size). No landmark regions, making screen reader navigation difficult.

1.7 Automated scan baseline

Test: Run the axe browser extension or Lighthouse accessibility audit on your homepage, a product page and the checkout.

Pass: Zero critical or serious violations in the automated scan. Note that automated tools catch 30-40% of WCAG violations. A clean automated scan is necessary but not sufficient.

Fail: Any critical violations (these represent clear WCAG failures). Serious violations on checkout or cart pages.

Pillar 2: PCI DSS 4.0

PCI DSS 4.0 introduced two new requirements that became mandatory in March 2025: Requirement 6.4.3 (script management for payment pages) and Requirement 11.6.1 (change detection for payment pages). These apply to every merchant that accepts card payments online, regardless of whether you use a hosted payment page.

For a detailed breakdown of these requirements, see PCI DSS 4.0 for ecommerce: requirements 6.4.3 and 11.6.1 explained.

2.1 Script inventory for payment pages

Test: Load your checkout page and open the browser network panel. Filter by script type. List every JavaScript file that loads on the payment page: first-party, third-party and fourth-party (scripts loaded by other scripts).

Pass: A documented inventory exists listing each script, its business justification and its authorized source. Scripts without a documented justification do not load on the payment page.

Fail: No inventory exists. Analytics scripts, marketing pixels, A/B testing tools, live chat scripts or any non-payment script loads on the payment page without a documented justification. This is the most common gap: marketing teams add pixels to every page, including checkout.

2.2 Script integrity controls

Test: Inspect the script tags on your checkout page. Check for integrity attributes (Subresource Integrity) and that third-party script sources are pinned to specific versions rather than loading from dynamic endpoints.

Pass: All scripts on the payment page have either Subresource Integrity (SRI) hashes or are loaded from controlled, version-pinned sources. Third-party scripts are loaded from specific versioned URLs, not generic "latest" endpoints.

Fail:Third-party scripts loaded with no integrity checking. Scripts loaded from CDNs with paths like /latest/script.js that can be changed by the vendor at any time. No mechanism to detect if a script's content changes.

2.3 Payment page change detection

Test: Ask whether you have a mechanism to detect unauthorized changes to your payment page HTML, HTTP headers and scripts. This can be a commercial tool, a custom monitoring script or a security service.

Pass: An automated system checks your payment page at regular intervals (at least weekly, ideally daily) and alerts on unexpected changes. Results are logged and reviewed.

Fail: No automated change detection. Changes to the payment page are noticed only if someone manually checks. This is the gap that web-skimming attacks (Magecart) exploit: a script is injected, card data is stolen for weeks, and no one detects it until chargebacks arrive.

2.4 Third-party script vendor review

Test: For each third-party script authorized on your payment page, verify that the vendor has provided written acknowledgment that they are responsible for the scripts they place on your pages.

Pass: Written agreements exist with each vendor confirming their responsibility for their scripts. Vendors that cannot provide this acknowledgment are removed from the payment page.

Fail: No vendor agreements covering script responsibility. This is a documentation gap that PCI assessors specifically check.

2.5 Scope of payment page definition

Test: Define your "payment page" scope. Under PCI DSS 4.0, this includes all pages in the cardholder data flow, not just the final payment step. If cart, shipping and payment details are on separate pages, all are in scope.

Pass: All pages in the checkout flow are treated as payment pages for script management purposes. The inventory and change detection from 2.1-2.3 cover all of these pages.

Fail: Only the final "enter card details" page is treated as in scope. Other checkout steps with their own script loads are excluded from the inventory.

Pillar 3: privacy and consent

Privacy compliance spans two regulatory environments: the EU (GDPR plus member state implementations) and the US (24 state privacy laws including CCPA/CPRA in California). Both require some form of consent or opt-out mechanism for data collection. The specific requirements differ, but the operational gap is the same: most stores collect data before getting consent.

For a detailed breakdown of the most common GDPR cookie consent mistakes, see GDPR cookie consent for ecommerce: the 5 mistakes most stores still make.

3.1 Cookie consent implementation

Test: Visit your store from a fresh browser (or incognito/private mode) without any prior cookies. Observe the cookie consent banner. Check: do non-essential cookies fire before you interact with the banner?

Pass: No analytics, marketing or personalization cookies are set until the user actively consents. Only strictly necessary cookies (session, cart, CSRF) fire on initial page load. The consent banner appears before any tracking begins.

Fail: Google Analytics, Meta Pixel, TikTok Pixel or any other tracking script fires on page load before banner interaction. This is the most serious cookie consent violation and the most common. The banner is cosmetic if tracking has already started.

3.2 Consent mechanism quality

Test: Count the clicks required to accept all cookies. Count the clicks required to reject all non-essential cookies.

Pass: Rejecting cookies requires the same number of clicks as accepting. A "Reject all" or "Necessary only" button is present and equally prominent as the "Accept all" button.

Fail: Accepting requires one click. Rejecting requires navigating to "Manage preferences," toggling multiple categories off and saving. This asymmetry is specifically prohibited by CNIL guidance (France) and has resulted in fines for Google and Facebook.

3.3 Consent withdrawal

Test: After accepting cookies, find the mechanism to change your consent preferences. How many clicks does it take from any page on the site?

Pass: A persistent, discoverable link or icon (footer link, floating button) allows users to reopen the consent panel and change their preferences. Withdrawing consent is as easy as giving it.

Fail: No persistent withdrawal mechanism. Consent preferences are only changeable by clearing browser cookies. The privacy policy links to cookie information but there is no interactive consent panel accessible after initial choice.

3.4 Cookie classification accuracy

Test: Review your cookie policy or CMP categories. Check whether Google Analytics, Hotjar, Meta Pixel and similar tools are classified as "strictly necessary."

Pass: Only cookies that are technically essential for site function (session management, cart, authentication, CSRF protection) are classified as strictly necessary. Analytics, marketing, personalization and A/B testing cookies require consent.

Fail: Google Analytics classified as strictly necessary. Conversion tracking classified as strictly necessary. Any marketing or analytics tool in the necessary category. This is a deliberate misclassification that DPAs specifically audit for.

3.5 US state compliance: opt-out signals

Test: Enable the Global Privacy Control (GPC) signal in your browser (Firefox with the GPC extension, or Brave with GPC enabled). Visit your store and check whether the signal is honored.

Pass: The GPC signal is detected and your store automatically treats the visitor as having opted out of sale/sharing of personal information. No action required from the user.

Fail: GPC signal is ignored. The store does not detect or respond to opt-out preference signals. This violates CCPA/CPRA for California visitors. California, Colorado and Connecticut all require GPC signal recognition.

3.6 Data subject rights process

Test: Find the mechanism for users to request access to, deletion of or correction of their personal data. Submit a test request and track the response.

Pass: A clear, accessible mechanism exists (form, email address or dedicated portal). Requests are acknowledged within 72 hours. Full responses are delivered within 30 days (GDPR) or 45 days (CCPA). A process exists to fulfill deletion requests across all systems including email marketing platforms and analytics tools.

Fail: No obvious mechanism for data requests. Requests sent to a general support email with no defined process. Deletion capability exists in the ecommerce platform but not in email marketing, analytics or ad platform databases.

Pillar 4: EU AI Act

The EU AI Act's transparency obligations under Article 50 became applicable in August 2026. Most ecommerce stores deploy AI systems without the required disclosures. For a full breakdown of which systems are in scope and what transparency requires, see EU AI Act for ecommerce: transparency requirements you cannot ignore.

4.1 AI system inventory

Test: List every tool on your store that uses machine learning or automated decision-making. Include: recommendation engines (Nosto, Klevu, platform-native), search ranking, dynamic pricing tools, chatbots, fraud detection and personalization engines.

Pass: A documented inventory exists. Each system is classified by AI Act risk tier (most ecommerce AI is limited risk). The inventory is reviewed when new tools are added.

Fail: No inventory. Unknown which tools use AI. No classification has been attempted.

4.2 Chatbot disclosure

Test: Initiate a conversation with every chatbot or virtual assistant on your store. Check whether the first message clearly identifies the system as AI.

Pass:The AI identifies itself as an AI system at the start of every interaction. The disclosure is explicit ("I'm an AI assistant") and appears before any substantive exchange.

Fail: The chatbot presents as a human or uses a human name without disclosure. The AI nature is only discoverable in the footer or a separate disclosure page. Any delay in disclosure beyond the initial greeting.

4.3 AI-generated content labeling

Test: Identify any product descriptions, review summaries, category descriptions or marketing copy generated by AI tools. Check whether these are labeled.

Pass: AI-generated content visible to consumers is labeled in a way that is perceptible and accessible. A small "AI-assisted" or "AI-generated" label on the content is sufficient. The label is present in the rendered page, not just in metadata.

Fail: AI-generated copy presented as human-written with no disclosure. AI-generated product images with no indication they are synthetic. Review summaries created by AI and presented as direct customer sentiment.

4.4 Recommendation system transparency

Test: Check whether your product recommendation sections include a disclosure that recommendations are personalized, and whether a non-personalized alternative exists.

Pass: Personalized recommendation sections are labeled as such ("Recommended for you based on your browsing history"). At least one non-personalized sort or view option is available (best sellers, new arrivals, price).

Fail: Personalized recommendations presented with no disclosure. No non-personalized option available. The fact that the site is adapting to user behavior is nowhere communicated.

4.5 Automated decision explainability

Test: For fraud detection or credit-related AI (buy now pay later decisions): does a defined process exist to explain a declined transaction to the affected user?

Pass: Users who are declined by an automated system receive a meaningful explanation of the factors involved. They are told they can request human review. The explanation is in plain language.

Fail: Declined transactions result only in a generic error message. No human review option exists. No explanation of the decision factors is available.

Scoring your audit

Count your failures across all four pillars. Any single failure represents regulatory exposure. Prioritize by potential impact:

• Immediate risk: Checkout accessibility failures (ADA lawsuits), pre-consent tracking scripts (GDPR fines), scripts loading on payment pages without inventory (PCI DSS violation). Our compliance ROI calculator helps quantify the business case for addressing these first.
• High risk: Missing "Reject all" button, no change detection on payment pages, undisclosed AI chatbots.
• Medium risk: Color contrast failures, missing GPC signal handling, no AI-generated content labels.
• Lower risk: Heading hierarchy issues, cookie classification edge cases, recommendation transparency gaps.

The stores that get hit first are the ones with checkout accessibility failures and pre-consent tracking. Fix those two first. Everything else can follow a reasonable remediation schedule.

Running this audit continuously

A one-time audit captures your current state. It does not protect you next month when a developer adds a marketing pixel to checkout, an app update changes your cookie behavior or a new AI tool gets installed.

Every change to your theme, your app stack or your checkout can introduce new violations. Compliance is not a project with an end date. It is a continuous state that requires ongoing monitoring. If you are planning a platform migration, our replatforming compliance checklist covers the specific risks of moving between platforms.

Automated scanning covers the items on this checklist that are detectable programmatically: accessibility violations, script inventory on payment pages, cookie behavior, AI disclosure presence. Manual review covers the rest. The combination is what keeps you clean between audits.

Frequently asked questions

What are the four pillars of ecommerce compliance in 2026?

The four pillars are WCAG web accessibility, PCI DSS 4.0 payment security, privacy law (GDPR and US state laws) and EU AI Act transparency. Each has its own enforcement mechanism and penalty structure.

Which compliance area should ecommerce stores prioritize?

Start with WCAG accessibility (highest US litigation frequency) and PCI DSS 4.0 (mandatory since March 2025). Privacy and AI Act carry lower immediate risk but are growing fast.

How often should ecommerce stores run compliance audits?

A one-time audit captures your current state but goes stale quickly. Combine annual manual audits with continuous automated monitoring to catch regressions from theme updates, app installs and content changes.