Illustrative client report · 17 October 2026

Agency brochure site: accessibility review

Northline Studio · northline.example

Fictional demonstration. All clients, domains, findings, and evidence are illustrative. These reports show the deliverable structure; they are not scans of real sites or proof of product results.

Choose plan

Executive summary

Make the inquiry form and site navigation understandable first. These are the controls a prospective client needs to explore services and get in touch. Review the case-study image description next.

Pages reviewed: 4
Finding types: 3
Critical: 3
Moderate: 0

Counts represent distinct finding types in this fictional example, not the number of affected elements. Severity indicates review priority, not a compliance verdict.

Scope and method

Client journey: Discover services → read a case study → send an inquiry.

Example pages: //services/work/contact

Method represented: automated axe checks of each loaded public page. This sample does not cover signed-in areas, every interaction state, keyboard use, screen reader behavior, or a full WCAG evaluation. Findings require human confirmation.

This report identifies automated accessibility findings. It does not establish legal compliance; manual evaluation is still needed.

Accessibility rules & eligibility

Prioritized findings

Priority	Finding	Page / rule	Next step
Critical	Email field has no accessible label	`/contact` `label`	Connect a visible label to the email field.
Critical	Menu button has no accessible name	`/` `button-name`	Name the menu control and expose its expanded state.
Critical	Case-study image is missing an alternative	`/work` `image-alt`	Describe the project image or mark it decorative after reviewing its purpose.

Evidence and remediation

Two findings are expanded below to show how a report supports an implementation handoff.

Finding 1 · Critical

Email field has no accessible label

Affected element: #contact-form input[type="email"] on /contact

Why it matters: A person using a screen reader needs a reliable name for the field. An unnamed input gives no reliable indication of the information expected.

1 · Illustrative evidence schematic. Recreated interface fragment, not a screenshot or a live scan. Illustrative markup contains an email input with no associated label, aria-label, or aria-labelledby.

Suggested fix

Add a visible Work email label, connect it with for/id, and preserve the expected email input type and autofill hint.

Before · illustrative HTML

<input type="email">

After · suggested HTML

<label for="email">Work email</label>
<input id="email" name="email" type="email"
  autocomplete="email" required>

Verify the fix: Re-run the label rule. Tab into the field and confirm that a screen reader announces Work email, its input type, and required state. Submit an invalid email and review the error message separately.

Finding 2 · Critical

Menu button has no accessible name

Affected element: header button.menu-toggle on /

Why it matters: An icon alone does not tell a screen reader user what the button does. The expanded state helps people understand whether navigation is open.

1 · Illustrative evidence schematic. Recreated interface fragment, not a screenshot or a live scan. Illustrative markup contains only an SVG inside a button; the SVG is decorative and supplies no accessible name.

Suggested fix

Give the button an accessible name. Update aria-expanded when the menu opens or closes and connect aria-controls to the navigation container.

Before · illustrative HTML

<button class="menu-toggle">
  <svg aria-hidden="true">…</svg>
</button>

After · suggested HTML

<button class="menu-toggle" aria-label="Menu"
  aria-controls="site-nav" aria-expanded="false">
  <svg aria-hidden="true">…</svg>
</button>

Verify the fix: Re-run the button-name rule, then open and close the menu with Enter and Space. Confirm the state is announced, links are reachable, and focus remains predictable when the menu closes.

Recommended handoff

Confirm findings in the live interface and agree on owners and scope.
Resolve the critical findings first; review each suggested change in context.
Test the client journey with a keyboard and assistive technology.
Re-scan the same pages, record remaining manual review work, and share the changes with the client.