Download a sample Auditzo accessibility report and see how verified findings can be documented with plain-English explanations, WCAG-oriented references, supporting evidence, developer-ready remediation notes, and retest guidance.
Accessibility buyers should know what they are getting before ordering a review. The sample report helps you evaluate report depth, evidence style, developer usefulness, and stakeholder readability.
Preview the kind of accessibility evidence report your team can expect before requesting a full review.
Understand how screenshots, affected pages, observed behavior, and evidence references can support remediation.
Review how findings can be written with affected components, expected behavior, suggested fixes, and retest notes.
Help website owners, agencies, legal, compliance, marketing, and development teams understand the expected output.
The sample format shows how Auditzo can organize accessibility observations into clear, evidence-backed findings for business, compliance, and development teams.
A business-readable summary of key accessibility observations, priority areas, and recommended next steps.
A structured view of findings by issue, severity, affected area, WCAG-oriented reference, and remediation priority.
Examples of how screenshots, affected components, and evidence references can be used to explain findings.
How keyboard access, focus behavior, menus, dialogs, and user interaction states may be documented.
How accessible names, labels, roles, links, form fields, and screen-reader-oriented observations may be captured.
Developer-friendly direction for planning fixes and validating selected updates after remediation.
Automated accessibility tools are useful for candidate detection, but they are not enough for a serious remediation conversation.
Auditzo reports are designed to add human review, context, evidence references, practical impact, and remediation direction so the website team can understand what to fix first.
To understand the difference before reviewing the sample, see our guide on accessibility scanner vs manual audit.
Want a quick automated first look at your own page? Run Auditzo's free website accessibility scanner before deciding whether you need a deeper human-reviewed audit.
View WCAG Accessibility Audit| Typical scanner export | Auditzo report approach |
|---|---|
| Generic scanner output | Human-reviewed findings with evidence context |
| Long issue lists without prioritization | Severity and remediation priority based on practical user impact |
| Limited explanation for business teams | Plain-English issue explanation, user impact, and next steps |
| Developer has to guess the affected component | Affected page/component, reproduction context, and validation guidance |
| May miss keyboard, workflow, and third-party widget behavior | Keyboard, interaction, embedded widget, and evidence-led review where in scope |
The exact scope depends on the website, page types, approved review plan, platform, and third-party widgets. A full review can include the following areas where relevant.
Selected pages, templates, components, user-facing states, and relevant interaction flows.
Keyboard reachability, focus behavior, menu/dialog operation, and logical focus movement.
Accessible names for buttons, links, form fields, images, icons, iframes, and interactive controls.
Contrast, visual link distinction, responsive reflow, visible content, and layout behavior.
Iframe titles, embedded tools, popups, listing widgets, chat widgets, forms, and vendor-controlled components.
Practical validation steps after remediation so teams know how to confirm fixes.
The report structure helps stakeholders understand what was reviewed, what was observed, why it matters, and what should happen next.
Download Sample PDF| Report section | What it explains |
|---|---|
| 1. Important notice | Technical review boundaries, safe-use language, and non-certification notice. |
| 2. Executive summary | Business-readable overview of findings, severity, themes, and priority next steps. |
| 3. Scope and methodology | Reviewed pages, tools, manual review process, and evidence treatment. |
| 4. Findings summary | Findings grouped by severity, page, theme, affected component, and remediation priority. |
| 5. Detailed findings | Issue explanation, user impact, WCAG-oriented reference, recommended fix, validation steps, and evidence references. |
| 6. Evidence package guidance | How screenshots, files, evidence IDs, and supporting notes map back to findings. |
| 7. Retest plan | Recommended validation methods after remediation, including keyboard, visual, and accessibility-tree checks. |
| 8. Closing summary | Priority order and recommended next steps for the website team. |
A structured finding table helps teams compare issues by area, severity, affected component, and remediation direction.
| Issue | Area | Severity | Affected page/component | Example remediation direction |
|---|---|---|---|---|
| Mobile menu control has no clear accessible name | Navigation and interactive controls | High | Mobile header/menu | Add a meaningful accessible name such as “Open menu” and retest with keyboard and screen-reader-oriented review. |
| Required form fields rely on placeholder-only labels | Forms, controls, and labels | High | Lead/contact form | Add persistent visible labels and programmatic label association for each required input. |
| Icon-only widget controls have unclear names | Embedded widgets and third-party frames | High | Third-party listing/widget controls | Add descriptive labels where controllable or coordinate with the widget provider for accessible control names. |
| Repeated links do not identify their destination | Link purpose and non-text content | Medium | Cards, CTAs, or image links | Make repeated links destination-specific, such as “View more about [Project/Product/Service Name]”. |
| Content overflows at narrow viewport widths | Responsive reflow | Medium | Responsive layout/card section | Review fixed widths, overflow, card heights, and responsive wrapping; retest at 320 CSS pixels. |
| Heading structure is unclear or inconsistent | Page semantics | Low | Page template or content sections | Normalize H1/H2/H3 usage so the programmatic outline matches the visual content hierarchy. |
Developers need more than a generic warning. Useful findings explain the observed issue, why it matters, how to fix it, and how to validate the fix.
This format helps internal teams, agencies, or vendors understand what to review before planning remediation.
A useful accessibility report should not only say that something is wrong. It should help the website team understand where the issue appears, how it was observed, and what evidence supports the finding.
For a more practical view of how these supporting materials can be organized, see our accessibility evidence package example.
Visual context showing where the selected issue appears on the reviewed page.
Examples of how links, controls, image links, buttons, and form fields may be announced.
DevTools Accessibility pane context for roles, names, labels, states, and ARIA relationships.
Focus path, reachability, focus return, keyboard operation, and dismissal behavior where relevant.
Narrow viewport or 320 CSS pixel examples where layout, visibility, or overflow may affect users.
A file-by-file map explaining which evidence item supports each finding in the full report package.
Auditzo can review selected pages, templates, forms, navigation, embedded widgets, responsive states, and user-facing components, then provide a clear technical accessibility evidence report.
This sample is useful for anyone who wants to understand the expected audit output before requesting an accessibility evidence review.
See what a serious accessibility review deliverable looks like before starting.
Check whether the output is actionable enough to support real remediation work.
Understand how evidence-backed reporting can support client delivery and implementation planning.
Review technical observations that can support internal or counsel-led accessibility review.
Preview how forms, product cards, filters, cart flows, and conversion-critical components may be documented.
Understand how listings, property cards, embedded widgets, forms, PDFs, and responsive pages may be reviewed.
See how complex components, dashboards, modals, tables, and onboarding flows may be reported.
Review how landing pages, CTAs, popups, embedded tools, and lead forms may affect accessibility.
Use these related pages to compare accessibility review options, platform-specific review paths, remediation support, and pricing.
Run an automated first-pass check on one public webpage for supported WCAG 2.2 A/AA-oriented accessibility issues.
Run Free Accessibility ScanTechnical accessibility review with WCAG-oriented issue mapping, evidence, and remediation guidance.
View WCAG AuditA business-friendly accessibility audit overview for ADA/WCAG-related website concerns.
View ADA AuditPlatform-aware review of Shopify themes, product journeys, variants, cart interactions and selected app interfaces.
View Shopify Accessibility AuditSupport after findings are documented and fixes need planning, implementation, or retesting.
View Remediation SupportAccessibility review for real estate websites, property cards, IDX/listing widgets, forms, and PDFs.
View Real Estate AuditPlatform-aware accessibility review for Wix-built websites and common Wix implementation patterns.
View Wix AuditAuditzo provides technical accessibility observations and remediation-oriented notes. This page and the sample report do not replace legal counsel or final compliance decisions.
See how Auditzo documents accessibility findings with plain-English explanation, severity, affected components, supporting evidence, developer notes, and remediation guidance.