Developer Implementation Checklist

Use this checklist to ensure the ExpressConsent snapshot captures every critical consent element exactly as your users saw it.

Compatibility and Framework Considerations

Supported Frameworks: The ExpressConsent script is compatible with most modern web frameworks (React, Angular, Vue, etc.) and static sites. Just ensure that your content is fully rendered in the DOM at the moment of capture. Single-page applications should have the consent form visible and populated when the user triggers the snapshot (typically on form submit).

Avoid Unsupported Technologies: Do not rely on rendering techniques that can’t be captured in a DOM snapshot. For example, avoid drawing form elements or text in a <canvas> or via WebGL — canvas drawings will not appear in the captured DOM image. Similarly, Flash or Silverlight (legacy technologies) are not supported. Use standard HTML elements for all consent-related UI.

Cross-Domain Iframes: If your consent form or critical text is inside an iframe, be cautious. A cross-origin iframe’s content will not be captured by the parent page’s snapshot — it will appear blank. Wherever possible, avoid embedding consent elements in cross-origin iframes. If an iframe must be used (for example, an embedded form from a third-party), ensure the ExpressConsent script is also injected into that iframe so it can capture its DOM separately. (Same-origin iframes can be captured when the script runs in the parent page, but the safest approach is to have the consent elements in the main page DOM.) Also note that old HTML <frame>/<frameset> elements are not supported.

Content Security Policy (CSP): If your site uses a strict CSP, update it to allow our script and resources. The ExpressConsent snippet and its dependencies must be permitted to run. Also ensure that any essential assets (fonts, styles) are not blocked by CSP. For example, if your styles or icon fonts are hosted on a different domain, add rules or use crossorigin="anonymous" on link tags so that our snapshot process can fetch them. This prevents missing CSS from causing an incomplete or mis-styled replay of your page.

Ensure All Consent Elements Are Present and Visible

Consent Checkbox: Use a standard HTML checkbox input for consent (e.g. <input type="checkbox" id="consent">) or a well-supported custom control. The checkbox must be visible and clearly appear as checked in the UI when the user gives consent. Avoid techniques that hide the checkbox off-screen and replace it entirely with an icon or image without reflecting the checked state in the DOM. If you style checkboxes, ensure that a checked state adds a visible tick or highlight in HTML/CSS (for instance, using the :checked pseudo-class or adding a CSS class). The snapshot will capture exactly what is in the page at that moment, so a checked box should look checked in the screenshot (whether it’s the default browser style or a custom visual). Example: If using a custom checkbox component, make sure it ultimately toggles an element in the DOM (like adding a checked mark or changing the input’s checked attribute). This guarantees the state is recorded.

Text Input Fields: All text-based inputs (e.g. phone number, name, email) should retain the user-entered values in the DOM at capture time. The snapshot system records the current state of inputs, so if a user typed a phone number into an <input> field, that value should be present in the element’s value. Avoid exotic input mechanisms where the visible text isn’t an actual input value. For instance, some custom UI libraries might place text in a pseudo-element or only bind it via JavaScript without updating the input’s value property — such approaches can result in empty fields in the snapshot. Instead, use standard <input> or <textarea> elements or ensure your framework’s two-way binding updates the input’s value attribute. Double-check that masking libraries or input validators aren’t clearing the field on submit. In short, the text the user entered should still be visible in the form at the moment of submission, so it appears in the evidence screenshot.

TCPA Disclaimer Text: The legal disclaimer (e.g. “By clicking this checkbox, I consent to receive calls/texts…”) must be present as regular text in the HTML. Do not use images to display this text (images might fail to load or not capture clearly) — use actual text nodes so that it’s guaranteed to appear. Place the disclaimer text near the checkbox (commonly as a label or paragraph next to it) exactly as the user sees it. Do not hide or shorten the text at snapshot time. For example, some designs show an abbreviated notice with a “Read more” link; this is risky because the snapshot might only show the shortened text. It’s best to show the full TCPA wording in plain view. If you must use expandable text for mobile, ensure that it is expanded when the form is submitted (see Responsive Design below). The goal is that the screenshot clearly captures the full consent language with no ambiguity.

Radio Buttons or Additional Consent Fields: If your form uses radio buttons or multiple checkboxes (e.g. separate opt-ins), the same rules apply. Each selected option should be visibly selected (e.g. the radio button filled in). Use native form controls for reliability. The snapshot will show the selection state as long as it’s reflected in the DOM (via checked attributes or visible styling).

Avoid Practices That Reduce Snapshot Fidelity

Heavy Animations on Critical Elements: Avoid using animations or transitions on the consent checkbox or disclaimer text at the exact time of snapshot. Animations can make elements momentarily invisible or in flux. For example, a fade-in animation on the disclaimer that hasn’t finished could make the text appear semi-transparent or not at all in the screenshot. If you have a pop-up or modal for consent, ensure it’s fully rendered and static when the user triggers the snapshot (perhaps by waiting for the animation to complete before allowing form submission). In general, it’s safest to keep consent elements static — fancy animations are not worth the risk of them not appearing correctly in evidence.

Delayed or Async Content Loading: All consent-related elements and their styles should load before the user attempts to submit the form. Do not design the page such that the consent text or checkbox is injected via JavaScript at the last second (or after form submission). For instance, avoid fetching the disclaimer text from a remote API on submit. If that request fails or is slow, the snapshot could miss the text. Instead, include the necessary HTML upfront or load it early. Our system does wait for network idle when rebuilding the DOM, but it can only load what was present in the captured DOM. So, if your script adds the consent text late (or only in response to a hover/click that might not happen in the submission flow), it might not be in the DOM snapshot. Bottom line: render all crucial consent info in the initial page or well before the user clicks “submit.”

Lazy-Loading of Images/CSS for Consent Elements: Do not lazy-load images or styles that are part of the consent section. For example, if the disclaimer includes an icon or the checkbox uses a background image, load it normally (e.g., no loading="lazy" on those images). Our snapshot process will attempt to load images and embed styles, but relying on lazy loading can be problematic if the element wasn’t in view or the network was idle by the time of capture. Similarly, ensure any CSS that styles the form or marks checkboxes is not gated behind media queries that might not apply or dynamic loads. All needed CSS for the consent form should be present so that the screenshot has proper styling. If your CSS is hosted on another domain, enable CORS or include it such that it can be fetched (e.g., use the crossorigin attribute as mentioned above). Missing CSS could mean missing visual indicators in the replay.

Avoid Obscuring or Hiding Elements: It should go without saying, but don’t hide the consent elements via CSS or overlays at submission. Sometimes developers temporarily disable a form or overlay a spinner on submission — be careful that this doesn’t cover or remove the consent text/checkbox immediately. If you show a loading spinner or redirect quickly, consider capturing the snapshot before those actions obscure the form. The ideal implementation triggers the snapshot at the moment of user action (e.g., the instant the submit button is clicked) and before any redirect or full-page reload. Our library is designed to capture at the form submission event; just ensure you’re not simultaneously removing the form from the DOM too quickly. If using single-page frameworks, don’t immediately unmount the component with the consent info on submit — give a slight delay (a few milliseconds) for the snapshot to clone the DOM.

Use Masking Carefully: If you use the data-expressconsent-mask attribute (or similar) to mask sensitive info, be very selective. Do not mask the consent checkbox or legal text. Masking causes the content to be anonymized or blanked out in the snapshot. For example, a masked input’s value “hello” would turn into “*”. While it’s okay (and often recommended) to mask private data like passwords or credit card fields, the phone number or email address given for consent might be important to show. Decide what your business needs visible in evidence: if the actual phone number is sensitive, masking will at least show that something was entered (the field won’t be empty, it will show placeholder symbols). But the checkbox and disclaimer text should never be masked — those need to be clearly legible in the snapshot. In short, only mask what is absolutely necessary and never mask the existence of consent itself.

Responsive Design and Viewport Matters

Ensure Visibility on All Screens: Your consent UI should be responsive, but never let responsiveness hide the consent details. Some mobile designs try to save space — e.g., showing a shorter consent blurb or hiding lengthy text behind a link. Do not remove or significantly truncate the consent language on smaller screens. If space is an issue, use a slightly smaller font or a scrollable container, but the full text should still be there. Remember, the snapshot tool captures the viewport size and uses it during rendering. So if a user on a phone checks the box, the system will recreate the page at mobile dimensions. If your mobile CSS had display: none for the lengthy legal text, the screenshot will likewise show nothing — which is unacceptable. Always display the critical text, even on mobile (you can use a shorter paragraph in addition to a full linked terms page, but the key consent phrase should be visible).

Collapsible Sections: If you use accordions or tabs in your form (for example, the form is on one tab and terms on another), ensure that by the time of submission, the section containing the consent checkbox and text is open and visible. A common pattern on mobile is an accordion where the user opens the “Terms and Conditions” section to read the disclaimer. If your design requires that, make sure the form cannot be submitted unless that section is expanded or that the snapshot is taken after the user opens it. One strategy is to programmatically expand the accordion when the user checks the box, so it’s definitely open for the snapshot. The goal is that the screenshot should show the checkbox alongside the full disclaimer, regardless of device size.

Testing and Verification

Run Internal Tests: After implementing the ExpressConsent script and following the above guidelines, perform a dry-run. Use a test environment or staging site to go through the consent flow as a user would: fill in the form, check the box, and submit (triggering captureAndUpload). Then retrieve the snapshot image from your dashboard and inspect it carefully. Verify that the screenshot contains:

• The checked checkbox (with a visible check mark or highlight).
• The user’s input values (e.g., the phone number or email you entered) visible in the form fields (not blank).
• The full TCPA/legal disclaimer text next to the checkbox.
• Proper styling (nothing looks drastically different than the live page, fonts are loaded, etc.).

Pixel-Perfect vs. Accuracy: Minor visual differences (like a missing animation, or a custom font that maybe renders in a default font if it failed to load) can be acceptable. What’s not acceptable is any missing consent information. If you notice any missing or incorrect element in the snapshot, address it immediately. For instance, if the check mark didn’t show, your custom checkbox might not have been captured — you may need to adjust how it’s implemented (ensure a fallback, or use the native checkbox appearance). If text was missing, check if it was present in the DOM at submit time or if something removed it. By iterating on these tests, you can reach a point where every snapshot is consistently accurate.

Multi-Viewport Testing: Test on both desktop and mobile scenarios. For example, do one submission from a desktop browser and one from a phone. Compare the snapshots. On desktop, the wider layout might show the consent in a footer or sidebar, whereas on mobile it might stack. Confirm that in both cases the content is complete. All viewports are important — your clients might retrieve a snapshot from a mobile consent just as often as desktop, and both need to stand up as evidence.

Continuous Verification: After deployment, periodically verify that snapshots remain accurate, especially if you make front-end changes. If you update your form or re-style the site, run another test. It’s good practice to include snapshot verification in your QA process whenever the consent form UI is modified.

When in Doubt, Ask: If you have an unusual implementation or are unsure about support (maybe a new framework or a complex interactive feature in the consent flow), reach out to our support or check our documentation. We aim to support virtually all websites, and if something isn’t working, we want to know. For example, if your site uses a custom web-component for the consent checkbox and you’re not certain it’s capturing correctly, we can help determine if any tweaks are needed. Our goal is the same as yours: 100% fidelity for consent evidence. We will update this checklist as we discover new best practices or limitations, so staying in touch helps everyone.

---

By following this checklist, your snapshots will consistently show the checkbox, inputs, and legal text exactly as users experienced them, providing reliable, defensible evidence of consent.