Business growth
Create a Marketing Campaign Accessibility Testing Evidence Pack
A compact evidence pack for recording what accessibility checks were performed on a campaign asset, what they found, and what was or was not covered.
By Chamko Research Team Updated 3 min read
Quick answer
A compact evidence pack for recording what accessibility checks were performed on a campaign asset, what they found, and what was or was not covered.
Overview
A compact evidence pack for recording what accessibility checks were performed on a campaign asset, what they found, and what was or was not covered.
Define the scope before testing
Record the asset URL or file, version, test date, viewport, browser, and user tasks covered. Identify the pages, components, and states included, such as form errors, modal dialogs, checkout steps, or embedded media. A report without scope can be misread as a guarantee about an entire website.
Name the standard or internal checklist used and identify whether the review was automated, manual, assistive-technology based, or a combination. Do not describe a limited smoke test as a full conformance audit.
Capture findings so another person can reproduce them
For each issue, record the affected component, steps to reproduce, observed result, expected result, impact, and evidence such as a screenshot or short recording where appropriate. Avoid capturing unnecessary personal data in test evidence. A screenshot may illustrate a visual problem but cannot demonstrate every keyboard or screen-reader issue.
Use language that explains the barrier in user terms as well as technical terms. Link the finding to a responsible owner and a retest condition. If a finding is uncertain, label it for further investigation rather than presenting an assumption as a verified defect.
Keep tools and limitations visible
Record the automated tools and versions used, plus any settings that affect results. Note known blind spots, such as issues that require human judgement, content understanding, keyboard testing, or assistive technology. Automated results are useful evidence but should not be treated as complete proof of accessibility.
If an external specialist conducted the review, record the scope and deliverables agreed with them. Avoid relying solely on a vendor badge or statement without understanding which assets and interactions were examined.
Connect evidence to remediation and release
Map each finding to a ticket, owner, priority, target date, and retest result. Store the evidence pack alongside the release record so the team can see which issues were fixed before publication and which remain open. For unresolved issues, record the decision-maker and mitigation rather than quietly excluding the issue from the report.
After a fix, repeat the relevant test on the current live or release-candidate version. If a shared component is used across many pages, sample the other contexts where the same defect may appear. Ensure the evidence pack reflects the version that was actually approved.
Retain evidence proportionately
Set access and retention rules for screenshots, recordings, test accounts, and reports. Keep enough information to support the decision and future troubleshooting, but avoid retaining sensitive captures indefinitely. Make the evidence easy for a new reviewer to find without granting broad access to unrelated user information.
Review repeated findings to improve design systems and authoring guidance. The pack should support practical remediation and honest reporting, not create a paper trail that looks complete while leaving real barriers unresolved.
Worked example
A campaign team launches a new event-registration page. Its evidence pack records keyboard navigation, labels, error messages, zoom, and the registration confirmation state, with separate notes for automated and manual checks. One error message is not announced to assistive technology. The team links the finding to a release ticket, fixes the form component, retests it, and updates the reusable checklist.
Implementation review
Accessibility evidence should describe what was tested and the limits of the review. Use WCAG and relevant local requirements as applicable, and obtain qualified review for formal conformance claims. Store evidence securely and avoid capturing real participant or customer information.
Key takeaways
- Record scope, method, environment, and version before reporting results.
- Make findings reproducible and connect them to retest evidence.
- State limitations clearly; automated scans alone do not prove conformance.
Conclusion and next steps
Keep the evidence pack honest about scope, test method, and untested areas. Link each finding to a fix and a reproducible retest, and avoid using a limited test as a broad conformance claim. Over time, turn repeated findings into reusable component checks and better authoring guidance.